NORDLITH RESEARCH

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.

Read the accompanying paper · Browse all research

Contents
  1. A. Completion contract
  2. B. Evidence record schema
  3. C. State transition checklist
  4. D. Failure-injection matrix
  5. E. Worked example (synthetic)
  6. F. Review scorecard

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.

  1. Attempted: the workflow submits the document using correlation key brief-r3-7f2a. It records the content digest and required group ACL.
  2. Acknowledged: the repository returns a job ID and 202 Accepted. The workflow records acknowledgement but does not report delivery.
  3. Pending recheck: the workflow schedules a repository read in two minutes, with a ten-minute deadline.
  4. 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.
  5. Observed: a group-scoped access probe opens item D-1042 and observes revision 3.
  6. 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.

Continue reading