Application protocol: evidence-bearing completion for AI workflows
Manuscript dated 20 October 2026. This is a proposed design protocol, not an empirical benchmark or a certification.
Contents
This protocol operationalises the proposed state model in the accompanying paper. It is a reusable design and review aid, not a certification standard.
A. Completion contract
Complete this contract before enabling a workflow to mutate external state.
| Field | Required entry | Example (illustrative) |
|---|---|---|
| Outcome ID | Stable identifier for this intended outcome | invoice-summary-2026-10-20-A |
| Business purpose | What useful state should exist, for whom | Approved summary available to the finance reviewer |
| Consequence class | Low / moderate / high, with rationale | Moderate: internal decision support |
| Mutation target | Exact system and object type | Document repository / document |
| Authoritative commit surface | Where durable state is read back | Repository item API |
| External observation surface | Where a consumer sees the result | Reviewer-access view |
| Correlation mechanism | Immutable ID, request key or digest | Repository item ID + SHA-256 |
| Required positive fields | Values that must match | title, revision, content digest, ACL |
| Required negative conditions | What must not be present | no public link; no duplicate active item |
| Freshness bound | Maximum evidence age | Read after write; recheck within 5 minutes |
| Terminal criterion | Exact evidence required for done | Correct item and ACL; reviewer access probe passes |
| Pending policy | owner, next check, deadline, retries | workflow owner; +2 min; 10 min deadline; 3 reads |
| Indeterminate policy | Safe response when proof is unavailable | do not resend; route for reconciliation |
| Rollback/repair | Permitted compensating action | quarantine wrong revision; preserve journal |
The example is synthetic. The time limits are illustrative, not recommended defaults.
B. Evidence record schema
Implementations may use another representation, but should preserve these semantics.
{
"outcome_id": "stable-intent-id",
"state": "attempted|acknowledged|committed|observed|outcome_confirmed|pending_recheck|contradicted|expired|indeterminate",
"claim": "precise human-readable claim",
"target": {
"system": "authoritative system name",
"object_type": "type",
"object_id": "immutable identifier when known"
},
"correlation": {
"request_id": "caller-provided idempotency/correlation key",
"payload_digest": "digest or bounded canonical description"
},
"evidence": [
{
"kind": "mutation_receipt|authoritative_readback|external_probe|human_acceptance",
"surface": "where it was observed",
"observed_at": "RFC-3339 timestamp",
"valid_until": "RFC-3339 timestamp or null",
"fields_checked": {"field": "expected/observed result"},
"artifact_ref": "bounded evidence reference"
}
],
"negative_checks": ["no duplicate", "no unintended permission"],
"contradictions": [],
"pending": {
"owner": null,
"next_check_at": null,
"deadline": null,
"remaining_attempts": 0,
"on_expiry": "fail|escalate|compensate"
}
}
Do not store credentials, unnecessary personal data or unbounded response bodies in an evidence record. Evidence references must lead only to minimised or redacted evidence within the original access and retention grant; a digest is not permission to retain or expose the raw response. A digest proves byte identity only when the compared bytes and hashing procedure are controlled; it does not establish that the content is correct.
C. State transition checklist
Intended → Attempted
- [ ] The intended outcome and target are unambiguous.
- [ ] Authority to perform the action is current and scoped.
- [ ] A correlation or idempotency key is created before mutation where supported.
- [ ] The consequential fields and negative conditions are recorded.
- [ ] Retry and compensation behaviour are known.
Attempted → Acknowledged
- [ ] A response or receipt was actually received.
- [ ] Its semantics are known; asynchronous acceptance is not called completion.
- [ ] The receipt is tied to the same request identifier.
- [ ] Validation warnings and partial failures are preserved.
Acknowledged → Committed
- [ ] The object is read from the authoritative system of record.
- [ ] Readback occurs after the mutation and within the freshness policy.
- [ ] Immutable identity matches the current intent.
- [ ] All consequential fields match.
- [ ] Negative conditions pass, including duplicate/cardinality checks where relevant.
Committed → Observed
- [ ] The downstream or user-visible surface is queried independently of the mutation response.
- [ ] Replication, caching, rendering and access controls are included in the check.
- [ ] The exact artifact or state is identified, not merely a similar display name.
- [ ] The observation is recorded with time and scope.
Observed → Outcome confirmed
- [ ] The predeclared business criterion is satisfied.
- [ ] Recipient proof, if required, checks access to the exact object and revision.
- [ ] The claim does not exceed the test (delivery is not comprehension; access is not approval).
- [ ] No newer authoritative contradiction exists.
Any state → Pending recheck
- [ ] The expected state transition is genuinely time-dependent.
- [ ] An owner and executable check exist.
- [ ] The next check, hard deadline and retry budget are explicit.
- [ ] Expiry leads to a terminal state or escalation, not silent persistence.
D. Failure-injection matrix
Run cases appropriate to the consequence class in a disposable or safely isolated environment.
| Injection | Unsafe false conclusion | Expected control response |
|---|---|---|
| Response lost after commit | “Failed; resend” | Reconcile by correlation ID; avoid duplicate |
202 returned; worker stalls |
“Done” | Pending with deadline, then fail/escalate |
| Success response; write rolled back | “Committed” | Authoritative readback fails |
| Stale cache returns old state | “Observed” | Version/time check rejects stale evidence |
| Same-name object already exists | “Correct object found” | Immutable identity/correlation mismatch |
| Retry creates second object | “At least one exists” | Cardinality check reports contradiction |
| One critical field differs | “Object exists, therefore correct” | Field-completeness check fails |
| Correct object; recipient lacks access | “Delivered” | External access probe fails |
| Verification endpoint unavailable | “Probably done” | Indeterminate or bounded pending state |
| Later read contradicts completion | “Historical green is final” | Reopen as contradicted; preserve both records |
For each test, record: injected fault, expected transition, actual transition, evidence captured, duplicate side effects, time to detection and recovery action. A test passes only if the workflow reaches the expected evidence state without creating an unapproved side effect.
E. Worked example (synthetic)
A workflow is asked to place revision 3 of a policy brief in a repository and make it available to a named internal review group.
- Attempted: the workflow submits the document using correlation key
brief-r3-7f2a. It records the content digest and required group ACL. - Acknowledged: the repository returns a job ID and
202 Accepted. The workflow records acknowledgement but does not report delivery. - Pending recheck: the workflow schedules a repository read in two minutes, with a ten-minute deadline.
- Committed: the read returns immutable item ID
D-1042, revision 3 and the expected digest. The ACL is present. A query confirms there is one active object for the correlation key. - Observed: a group-scoped access probe opens item
D-1042and observes revision 3. - Outcome confirmed: the defined criterion—exact approved bytes accessible to the intended review group—is satisfied.
If step 4 found revision 2, the correct state would be contradicted, not “completed with a warning.” If the repository read were unavailable, the state would remain pending or become indeterminate at the deadline. The workflow would not repeat the mutation unless its reconciliation policy showed that doing so was safe.
F. Review scorecard
Score each item 0 (absent), 1 (partial) or 2 (explicit and tested). Do not convert the total into a universal certification grade.
- Completion predicate defined before action
- Authoritative commit surface identified
- External observation surface identified where needed
- Correlation survives retries and handoffs
- Acknowledgement semantics are typed
- Consequential fields are checked
- Negative/cardinality conditions are checked
- Evidence freshness is enforced
- Deferred checks have owner and deadline
- Contradictions invalidate prior completion
- Indeterminate state is available
- Failure-injection cases are exercised
- Evidence retention is bounded and privacy-aware
- Claim wording matches the strongest evidence state
Use the scorecard to locate missing controls. A high score does not establish that the selected outcome criterion is ethically, legally or operationally adequate.
