Suppose I ask an AI agent to investigate a mathematical identity that an engineering model relies on. There are two useful outcomes: establish the identity under the stated assumptions, or produce an example that satisfies those assumptions and breaks it.
I would be happy to pay for either.
A convincing paragraph would not be enough. I would want an artifact that another program or person could inspect: the derivation and its checker, or the precise counterexample and the calculation showing where the identity fails.
That is a different way to commission AI work. The reward follows an acceptance condition agreed before the investigation. It does not depend on whether the agent brings back the answer I hoped to hear.
At 8Braid, our recent scientific work has made me interested in this possibility. We have spent time separating what an artifact establishes from the larger conclusion someone might want to attach to it. That distinction matters when a checked algebraic statement depends on physical assumptions, or a reproducible numerical calculation still needs a convergence study.
I think those habits could become part of how research work is bought.
Consider three possible commissions. Reproduce a specified calculation using pinned inputs and return the required artifacts. Find a valid counterexample to a declared claim. Produce a certificate accepted by a particular exact checker.
Each has a relatively clear boundary. An open-ended request such as “discover the correct theory” does not. It would still need scientific judgment, and I would not pretend that attaching a payment rule makes that judgment automatic.
Agree on what counts before the work begins
For a checkable commission, the job description should carry at least four things:
- The exact input versions and assumptions.
- The artifact the worker must submit.
- The acceptance rule and checker version.
- The reward, submission rules and procedure for disputed or inconclusive results.
Those details are the agreement. If a checker accepts one representation and rejects another, the worker needs to know that before starting. If a numerical result is acceptable only with a particular error bound, that requirement belongs in the job. If an inconclusive investigation has value, define what evidence of the investigation earns a reward.
Failure to find a counterexample is not a proof. A candidate counterexample outside the stated assumptions is not a valid refutation. Paying for both positive and negative results only works when those distinctions survive the payment process.
This is where I see a possible role for the underlying 8DB capabilities behind Digital Fabric.
8DB implements signed entitlements, agreement admission and authoritative consumption records, alongside its evidence structures. A proposed integration could connect the commissioned task to its input revisions, submitted artifact, checker result and reward allowance. The configured acceptance path would check that relationship before authorizing the next transaction.
The complete workflow is something we would have to build and qualify. Existing entitlement checks do not establish that an external payment happens exactly once, or that every worker used the inputs it claimed to use. Submission identity, execution evidence, concurrency, retries and recovery all need explicit treatment.
Nor is the general idea of verifying work before payment new. TessPay proposes evidence-gated settlement for agentic commerce. RAILS describes a clearing protocol organized around obligations and admissible evidence. The useful question for us is what improves when the work, governing records, current allowance and evidence dependencies live in a connected data environment.
Accepted yesterday, reassessed today
One improvement I would want to test is how the system handles a result that was accepted yesterday but deserves a different assessment today.
Perhaps a checker defect is discovered. Perhaps an input calibration is withdrawn. Perhaps a premise behind the commissioned calculation was never established. The original submission, checker version and acceptance decision should remain available. Future uses of the result should also be able to see the changed support.
That does not mean automatically taking back a payment. The contract might say that a worker earns the reward by passing the agreed checker. A later discovery does not justify quietly substituting a new agreement. Historical acceptance, current scientific support and any dispute or refund process are different records with different meanings.
We also do not need to invent every part of the research packaging. Workflow Run RO-Crate already describes workflow execution provenance and associated inputs, outputs and code. A useful integration should exchange that information with existing tools, while making its additional acceptance and authorization semantics explicit.
Start with an answer we can inspect
My first experiment would involve a small set of deterministic tasks and simulated rewards. We would include a valid positive artifact, a valid counterexample to a deliberately false claim, a plausible but invalid submission, a duplicate request and an interruption during acceptance. Independent reviewers would agree on the expected outcomes before the system ran.
We would measure incorrect payments, incorrect refusals, allowance conservation and whether a reviewer could reconstruct each decision. Then we would change one evidence dependency and check that the historical record remained intact while the current assessment changed as specified.
A successful experiment would give us a small, useful mechanism for commissioning work. It would not establish a new theorem, validate an entire scientific field or prove that a research market was ready to operate.
If you manage research workflows, computational services or reproducibility work, I would welcome one concrete contribution: an acceptance condition you could write down before commissioning a piece of work. Send it to ashley@8braid.com.
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