Defined Claim: what an AI service promises to deliver
In the proposed Ghast Protocol, a Defined Claim is a service promise fixed before purchase and kept stable for that transaction. It identifies accepted inputs, the promised output, and the conditions and evidence used to decide whether the service delivered.
Under these inputs, limits and conditions, what exactly did this service promise to complete?
“Fix my code” leaves both the scope and the finish line open. A more reviewable request names the files that may change, the expected result, the checks to run, and the work excluded from the task.
A coding task: requirements, evidence and acceptance
In a Ghast Workbench stable-client test, an agent was asked to fix a small calculation function. The original implementation added unit prices without multiplying by quantity. For [(12.5, 2), (5, 3)], it returned 17.5 instead of 40.
| Part | In this example |
|---|---|
| Requirements | Change only total.py so each unit price is multiplied by quantity. Preserve the tests; do not install dependencies, use the network, commit or push. |
| Delivery evidence | The failing test output, the actual file diff, the passing test output, and a check that the test file stayed unchanged. |
| Acceptance | Compare the current files and test results with the original request, then decide whether to accept the delivery. |
In the actual run, the agent changed one expression and both tests passed. An independent local rerun also passed. The test file and README stayed unchanged. Python can create a __pycache__ directory during a test run; that generated cache is separate from the source-file change.
The run took place in Workbench. Sold as a Capability, the same task would also fix its input version, delivery deadline, evidence requirements and verification rules before purchase. See Defined Claims in the whitepaper.
What do passing tests establish?
These two passing tests support the conclusion that the conditions they cover were met. They do not, by themselves, establish that:
- every input and edge case is correct;
- the code has no other defects;
- other operating systems, models or environments have been verified; or
- publication, purchase or settlement has occurred.
Match each piece of evidence to the promise it can support: test output supports a test result; a file diff supports the scope of a change. An agent saying “done” still needs to be checked against the actual artifact and execution result. Anthropic’s guide to agent evaluations likewise distinguishes the run transcript from the final state in the environment.
How is a task request different from a Defined Claim?
A Workbench task request guides execution and human review. A Defined Claim is the service promise that the proposed Protocol uses as the reference for purchase, Delivery Evidence, Verification and subsequent resolution.
Writing a clear task helps a reviewer decide whether it is complete. It does not automatically create a Protocol transaction or turn written restrictions into technical permission controls.
Continue with the tested Coding walkthrough, Team assignment and review example, or the whitepaper chapter on Delivery Evidence and Verification.