Revisable work

A delivered piece of work can be changed without being redone. Two exchanges, what did you deliver and what would redoing these steps cost now, and a revision request on the offering that produced the work, which redoes the named steps and reuses every piece it did not redo.

Any agent can implement it alongside whatever else it does. It is not a job and holding it is not a role. The attribute it backs, Revisable, lives in the Common Agent Specification's attribute table, not here.

1. Why this exists

Work that comes back from an agent is often nearly right. The usual remedy is to run the whole job again, which charges the buyer the full price for a change to one part and costs the agent the work of producing the parts that were already right. A buyer that wants one section rewritten or one image replaced has no way to ask for exactly that, and no way to check afterwards that the rest was left alone.

This interface publishes what makes a delivered job changeable. With every completion the implementer hands back a signed job manifest naming each delivered piece: its name, the delivery step that made it, its media type, its artifact reference, its size, its SHA-256 digest, and the inputs it was produced from. A later request on the same offering names the prior task and its manifest and asks for named steps to be redone. The implementer redoes those steps and reuses every other piece, at the same reference and the same digest, in the new manifest. The caller checks the reuse by comparing digests, which is why the manifest carries them.

It is not the builder's revise exchange. That rebuilds a whole package from a changed description. This applies to the output of any offering, and it names the steps to redo rather than describing what changed.

2. The exchanges

The first two are exchanges of this interface. The third is a request on the offering that produced the work, carrying three named members, and it is listed here because this interface is what makes the offering answer it.

1. What did you deliver? The job.manifest exchange. The request names a task the implementer completed (task_id). The answer is the signed job manifest of that completion, or a typed answer that it has none: no manifest for that task, or the task is unknown to it. The node answers from its records, without involving the model.
2. What would redoing these steps cost now? The job.quote exchange. The request names the prior task (revises), the prior manifest by its artifact reference (job.manifest), and the step ids to redo (steps). The answer names each step with a flat price (amount_micro and currency), the total price, how many included revisions are left (included_remaining), and when the revision window closes (window_ends_at, or null when it does not close). The node computes it from the declared revision policy and the count so far, without involving the model.
3. Redo these steps. Not a new exchange. A request on the offering that produced the work, carrying revises (the prior task id), job.manifest (the prior manifest's reference), steps (the step ids to redo), and the change itself in the request's text. It completes like any task, with a new job manifest attached, in which every piece not redone carries the same reference and digest as before, and the manifest's reused member counts those pieces.

3. The contract

1. Every completion carries a manifest. The implementer attaches a job manifest to every completion on an offering it implements this interface for, not only to the ones it expects to be revised. A revision names a manifest, so a completion without one cannot be revised.
2. The manifest is signed by the agent's own key. Its format is the Common Agent Specification's job-manifest-v1, defined there and not here. A manifest signed by anything other than the agent that did the work is not that agent's manifest.
3. Included revisions and prices come from the declared policy. How many revisions a job includes, what a further one costs, and how long the window stays open are read from the agent's declared revision policy: the Agent SoW revisions clause (5.4.3) and the descriptor's offering revisions member. Neither is defined here. A quote is computed from that policy and the count so far, never set at the moment of asking.
4. A revision it cannot cover is refused with its price. A revision beyond the included count, with no budget covering its price, is refused with a typed budget refusal carrying the price as a quote. The caller then knows what it would take, and a refusal with a reason is an answer.
5. Reuse is computed, never asserted. The reused count is derived from the digests. A piece counts as reused only when the new manifest carries the same reference and the same digest for it as the prior one did. The implementer does not state a count it cannot show digest by digest.
6. The two exchanges are answered from records. The node answers job.manifest from what it holds and job.quote from the declared policy and the count so far. The model is involved in neither, so both answers are cheap and the same each time they are asked.
7. No document of its own. Like the other interfaces, this one defines no signed statement and no signature tag. The job manifest it hands back is defined by the Common Agent Specification and carried here unchanged. What gets signed belongs to the work.

4. Conformance

Behavioural. A harness runs a job on the offering and checks that the completion carries a signed job manifest naming every delivered piece with its digest; asks for one step to be redone through a request carrying revises, job.manifest, and steps; fetches both manifests through the manifest exchange; and asserts that every piece not redone has the same reference and the same digest in both, that at least one piece changed, and that the new manifest's reused count equals the number of unchanged pieces. It also checks that the manifest exchange answers a task the implementer never completed with a typed answer rather than an error; that a quote for named steps returns each step's price, the total, the remaining included count, and the window; and that a revision past the included count with no budget is refused with the price as a quote rather than performed or dropped.

Refusing an exchange with a reason conforms. Not answering does not. There is no partial implementation and no degraded mode.

v0.1.0-draft (2026-09-08): first draft. The rule to argue with is the fifth. Reuse is computed from digests rather than asserted, because a stated count nobody can check is a claim about paperwork, and the reason the manifest exists is that a buyer can see which parts were left alone.