Imagine a manufacturer with five years of equipment failures, maintenance records and operating conditions. Another company has an analysis that might help it predict which parts will fail next.
There is a useful transaction here. There is also a difficult request: send over the dataset.
Those records may contain production volumes, supplier details and information about customers. The manufacturer might be willing to let someone answer a particular question while being unwilling to distribute everything needed to answer it. A confidentiality agreement matters, but it does not remove the practical consequences of creating another copy.
I think there is a product worth building around that distinction: a permitted analysis, sold with a defined allowance and a clear rule about what can leave.
The offer could be quite ordinary. Twenty executions of an approved analysis, against a specified dataset version, within thirty days. The buyer receives an agreed report. The computation takes place in an environment controlled by the data holder.
The thing being sold is useful access to a capability. Its terms need to be understandable to both the person buying it and the software carrying it out.
At 8Braid, we have been examining this as a possible application of the technology behind Digital Fabric. Digital Fabric is our implementation of governed transactions using 8DB. The underlying components include signed entitlements with scope, budget and expiry, agreement checks before redemption, and persistent records of what has been consumed. These provide a foundation for a programmable transaction. Turning them into a data-analysis service would require an integration and a measured pilot.
For this application, I would want the permission to identify the dataset revision, approved analysis, available allowance and output policy. A request should be checked against the current agreement before it is admitted. If two workers arrive for the final available execution, the system needs an authoritative answer about which one received it.
When the transaction is interrupted
That sounds like bookkeeping until something interrupts the transaction.
The buyer retries because a response was lost. A worker restarts after admission but before producing its report. The dataset owner changes the approved version. The allowance expires while a job is running. Each case needs a defined outcome, including what happens to a reservation, whether another execution is allowed and what the buyer is owed.
A database accepting a request does not, by itself, prove that an external worker executed it exactly once. The worker and transaction records must be connected through a recovery protocol. I would rather settle that question in a small experiment than discover it after someone has been charged twice.
Permission and privacy are different promises
There is an equally important distinction between authority and privacy.
A signature can authenticate an entitlement. It does not establish that the person issuing it had the right to license the underlying records. A purpose written into a policy does not prove that a buyer will respect that purpose after receiving an output. The application still needs trusted identities, verified authority and rules that its execution environment can actually enforce.
Keeping the raw files in place also does not make every answer safe to release. A report can reveal sensitive information. Several individually acceptable queries can reveal more in combination. The output policy may therefore need restrictions on the analysis itself, review of results, or a separately evaluated privacy mechanism.
That is why I see a collaboration opportunity here. OpenMined builds tools for governed computation across data silos. We could contribute the entitlement, consumption and connected evidence side of a specific workflow, while working with people who understand the execution and disclosure requirements. We should test the complete boundary together. We should not describe the database as supplying every privacy property the service needs.
Revocation deserves the same precision.
An owner could withdraw permission for subsequent controlled operations. The next request would encounter that changed state. But revocation cannot make a downloaded report disappear, undo what a person learned or guarantee that information is removed from a trained model.
It also should not silently erase a legitimate obligation. If work was commissioned under agreed terms, a later access change does not automatically cancel the payment owed for that work. Historical authorization, current permission and settlement need to remain distinguishable.
One data holder, one useful analysis
The first pilot I would propose is deliberately small: one data holder, one analyst, one analysis and public or synthetic records. We would agree on the output rule before running anything. Then we would test expiry, concurrent requests, changed permissions, duplicate submissions and recovery after interruption.
The measurements would include incorrect admissions, incorrect refusals, allowance reconciliation, recovery behavior and integration effort. Useful work must still get through. A service that protects its allowance by refusing everything has not solved the problem.
What interests me is the access this could make practical. A dataset that is too sensitive to distribute may still support a valuable, carefully bounded service. A smaller organization might buy one useful analysis without negotiating an unrestricted data transfer. The owner could retain a record of the permission, the execution and the result that was released.
That is a proposition to evaluate with a real workflow, not a promise that exported information remains under perfect control.
If you manage a valuable dataset or approve analytical workflows, I would like to hear one concrete requirement: what output rule would have to hold before you would let another organization run an analysis on your data? Send that requirement to ashley@8braid.com. It would give us something useful to build and test together.
Please use a hypothetical or non-confidential example. I will ask before attributing or quoting a private reply.
Part of AI With Authority. Start with Would You Give an AI $100 and Walk Away?.
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work