Problem
The PIC/TRACE bridge currently binds the signed authorization to the declaration and exact executed tool call, and when a transcript is required it binds transcript.before.tool_call to that execution.
transcript.after, however, is only required to be a JSON object.
That establishes presence, not identity or evidentiary sufficiency. A verifier therefore cannot distinguish:
- the actual successor observation produced for this execution,
- a substituted or replayed object,
- a self-asserted outcome supplied by the executor,
- a valid observation that nevertheless is insufficient to establish the requested transition.
This boundary is already stated in docs/integration/pic-trace-bridge-v1.md: the bridge binds authorization to the call and execution evidence "without claiming that TRACE proves the real-world outcome of the call."
#332 confirmed that no existing normative mechanism closes this layer and identified transcript.after as the narrow surface worth addressing.
This issue proposes only that narrow change. It does not propose importing STBP wholesale, turning TRACE into an application-state store, or making real-world outcome claims from execution evidence alone.
Related: #332, #279.
Requirements
A successor-observation extension to the PIC/TRACE bridge should satisfy all of the following.
1. Bind the exact successor observation
When a profile elects to make a successor-state claim, the verifier MUST be able to establish the exact observation bytes to which the claim refers.
The identity relation should use the bridge's existing RFC 8785 / SHA-256 convention rather than host-language object equality.
A candidate minimal field is:
{
"after": {
"observation": { "...": "..." },
"observation_digest": "sha256:..."
}
}
The precise schema shape is intentionally open. A detached successor-observation artifact bound by digest may fit the existing bridge architecture better than embedding the complete object.
The requirement is the invariant, not that specific representation:
the bridge MUST bind the exact successor observation used by the verifier.
2. Keep observation integrity separate from observation sufficiency
Matching a digest proves identity of the observation. It does not prove that the observation is authoritative enough to establish the requested transition.
The verifier therefore MUST NOT equate:
successor observation is integrity-bound
with:
authorized transition is established
A successor observation may be correctly bound and still be insufficient because its source is untrusted, stale, incomplete, or otherwise outside the verifier's policy.
3. Make the not-established result first-class
This is an instance of the discipline tracked in #279.
Where a verifier evaluates a requested transition from predecessor/execution/successor evidence, the outcome needs three distinguishable states:
- established — sufficient trusted evidence establishes the requested transition;
- contradicted — sufficient trusted evidence establishes that the requested transition did not occur;
- not established — the available evidence is insufficient to justify either conclusion.
Names should follow the surface rather than introduce a repository-wide enum, consistent with #279.
Critically, absence or insufficiency of successor evidence MUST NOT fall through to a positive result.
4. Do not let self-certification silently become closure
A bound successor observation may be produced by the same principal that executed the action.
That is not universally invalid: some transitions can be established by deterministic local evidence. But for a transition whose verifier policy requires an independent successor observer, executor-supplied evidence is insufficient.
The profile therefore needs a way for the verifier to evaluate the observation source against policy.
This does not require a universal rule that executor and observer differ.
The rule is narrower:
when the applicable verification policy requires independent observation, evidence from the executing principal alone MUST NOT establish closure.
The resulting outcome is the surface's not-established state unless trusted contradictory evidence exists.
5. State what the verifier may conclude, and what it may not
The profile text should define the assurance boundary explicitly.
A successful successor-observation binding permits the verifier to conclude only that:
- this is the exact observation associated with the bridge evaluation, and
- its source/freshness/trust properties satisfy the configured verification policy.
A transition-level positive conclusion additionally requires a defined predicate over the relevant predecessor, action/execution, and successor evidence.
The bridge MUST NOT imply that a bound after object, by itself, proves a real-world outcome.
Candidate verification model
Conceptually:
signed authorization
|
| binds exact authorized call
v
exact execution
|
v
successor observation
|
+-- exact observation bound?
+-- observation source trusted?
+-- freshness/policy satisfied?
+-- independence satisfied when required?
|
v
transition predicate
|
+-- true -> established
+-- false -> contradicted
+-- insufficient evidence -> not established
The transition predicate itself may be profile- or application-defined. TRACE does not need to understand arbitrary application state in order to enforce the evidence discipline around that predicate.
Why a digest alone is insufficient
Consider a Git-backed transition.
An authorized agent holds the push credential, performs the push, then supplies an after object saying that the repository is now at the desired commit.
Even if TRACE binds that after object perfectly, the evidence is still self-certified if the verifier has no trusted observation independent of the actor where independence is required.
The integrity problem and the closure problem are therefore different:
binding(after) solves substitution / identity
trust-policy(after) determines whether it is usable evidence
predicate(before, action, after) determines the transition result
Collapsing those steps would make a cryptographically intact claim indistinguishable from independently established closure.
Non-goals
This proposal does not require:
- TRACE to store application state;
- a universal predecessor/successor schema;
- a universal transition predicate language;
- independent observation for every transition;
- STBP as a TRACE dependency;
- a new repository-wide tri-state enum;
- replay/one-shot authorization semantics in this change.
Replay/uniqueness remains a separate concern noted in #332.
Suggested first implementation boundary
The smallest evaluable change appears to be:
- define a canonical binding for the successor observation associated with
transcript.after;
- define the observer/trust metadata needed to evaluate that observation under verifier policy, or bind a detached artifact that carries it;
- define the profile's positive / contradictory / not-established conclusion rules;
- add adversarial fixtures for:
- substituted
after;
- missing successor evidence;
- malformed/non-canonical successor evidence;
- stale successor observation;
- self-observation where independence is required;
- self-observation where independence is not required;
- trusted successor evidence satisfying the predicate;
- trusted successor evidence contradicting the predicate.
I would prefer to settle those semantics before proposing a schema or implementation diff, because the security boundary is in what a verifier is allowed to conclude, not merely in adding another digest field.
Problem
The PIC/TRACE bridge currently binds the signed authorization to the declaration and exact executed tool call, and when a transcript is required it binds
transcript.before.tool_callto that execution.transcript.after, however, is only required to be a JSON object.That establishes presence, not identity or evidentiary sufficiency. A verifier therefore cannot distinguish:
This boundary is already stated in
docs/integration/pic-trace-bridge-v1.md: the bridge binds authorization to the call and execution evidence "without claiming that TRACE proves the real-world outcome of the call."#332 confirmed that no existing normative mechanism closes this layer and identified
transcript.afteras the narrow surface worth addressing.This issue proposes only that narrow change. It does not propose importing STBP wholesale, turning TRACE into an application-state store, or making real-world outcome claims from execution evidence alone.
Related: #332, #279.
Requirements
A successor-observation extension to the PIC/TRACE bridge should satisfy all of the following.
1. Bind the exact successor observation
When a profile elects to make a successor-state claim, the verifier MUST be able to establish the exact observation bytes to which the claim refers.
The identity relation should use the bridge's existing RFC 8785 / SHA-256 convention rather than host-language object equality.
A candidate minimal field is:
{ "after": { "observation": { "...": "..." }, "observation_digest": "sha256:..." } }The precise schema shape is intentionally open. A detached successor-observation artifact bound by digest may fit the existing bridge architecture better than embedding the complete object.
The requirement is the invariant, not that specific representation:
2. Keep observation integrity separate from observation sufficiency
Matching a digest proves identity of the observation. It does not prove that the observation is authoritative enough to establish the requested transition.
The verifier therefore MUST NOT equate:
with:
A successor observation may be correctly bound and still be insufficient because its source is untrusted, stale, incomplete, or otherwise outside the verifier's policy.
3. Make the not-established result first-class
This is an instance of the discipline tracked in #279.
Where a verifier evaluates a requested transition from predecessor/execution/successor evidence, the outcome needs three distinguishable states:
Names should follow the surface rather than introduce a repository-wide enum, consistent with #279.
Critically, absence or insufficiency of successor evidence MUST NOT fall through to a positive result.
4. Do not let self-certification silently become closure
A bound successor observation may be produced by the same principal that executed the action.
That is not universally invalid: some transitions can be established by deterministic local evidence. But for a transition whose verifier policy requires an independent successor observer, executor-supplied evidence is insufficient.
The profile therefore needs a way for the verifier to evaluate the observation source against policy.
This does not require a universal rule that executor and observer differ.
The rule is narrower:
The resulting outcome is the surface's not-established state unless trusted contradictory evidence exists.
5. State what the verifier may conclude, and what it may not
The profile text should define the assurance boundary explicitly.
A successful successor-observation binding permits the verifier to conclude only that:
A transition-level positive conclusion additionally requires a defined predicate over the relevant predecessor, action/execution, and successor evidence.
The bridge MUST NOT imply that a bound
afterobject, by itself, proves a real-world outcome.Candidate verification model
Conceptually:
The transition predicate itself may be profile- or application-defined. TRACE does not need to understand arbitrary application state in order to enforce the evidence discipline around that predicate.
Why a digest alone is insufficient
Consider a Git-backed transition.
An authorized agent holds the push credential, performs the push, then supplies an
afterobject saying that the repository is now at the desired commit.Even if TRACE binds that
afterobject perfectly, the evidence is still self-certified if the verifier has no trusted observation independent of the actor where independence is required.The integrity problem and the closure problem are therefore different:
Collapsing those steps would make a cryptographically intact claim indistinguishable from independently established closure.
Non-goals
This proposal does not require:
Replay/uniqueness remains a separate concern noted in #332.
Suggested first implementation boundary
The smallest evaluable change appears to be:
transcript.after;after;I would prefer to settle those semantics before proposing a schema or implementation diff, because the security boundary is in what a verifier is allowed to conclude, not merely in adding another digest field.