plugin-quality: define what a sealed packet asserts once the session that produced it keeps acting

[kyle-sexton]

This was generated by AI during triage.

Parent

Refs #3357, finding P2. Blocked by the write-once decision carrier; the parent's plan expects one maintainer decision to settle both.

What this is

A sealed evidence packet is a snapshot: it asserts the state of the audited thing at the moment of sealing. But the session that produced it does not stop at the seal. It keeps operating, and it may keep changing the very state the packet describes.

Nothing currently says what the packet means once that happens. A reader finding a sealed packet cannot tell whether it describes the world as it is or the world as it was several operations ago, and the seal itself does not distinguish those cases: a packet whose every file verifies intact may still describe a state that no longer exists. The seal proves the packet was not tampered with. It does not prove the packet is still true.

Those are different properties, and conflating them is the risk here, because the seal's strength invites the stronger reading.

Why this is blocked rather than independently gated

It is the same question as the write-once carrier, asked about a different moment. That one asks what guarantees the packet's contents against its producer; this one asks what the packet claims given its producer keeps going. A decision that makes packets mechanically immutable implies one answer; a decision that treats write-once as a discipline with after-the-fact verification implies another.

Answering them separately risks two coherent answers that do not compose. Hence the blocking edge rather than two independent human gates: one maintainer touch on the carrier should settle both.

What will need deciding once the carrier resolves

1. What does a sealed packet assert? State of the world at seal time, or current state? Only the first is defensible, but the documentation should say so, because the second is what readers will assume.
2. Is staleness detectable? A reader should be able to tell that a packet describes a superseded state. That likely means the packet records enough about the moment of sealing for a later reader to check, rather than requiring them to reason about session history they do not have.
3. Does the producing session have obligations after sealing? If it changes state the packet describes, must it seal again, mark the earlier packet superseded, or nothing? Each has a different cost and the answer follows from question 1.
4. How does this interact with the multi-flush discipline? The skill already requires each evidence flush to be a new numbered artifact rather than an append. That is a sequence of snapshots, so the question of what each asserts relative to its successors is already latent in the existing design and may be most of the answer.

Acceptance criteria

• What a sealed packet asserts is stated explicitly in the packet contract, and matches what the seal actually proves.
• A reader can distinguish a packet describing current state from one describing a superseded state, without access to the producing session.
• The producing session's obligations after sealing are stated, including the case of no obligation if that is the decision.
• The answer composes with the write-once decision rather than contradicting it, and the two are readable together.
• Nothing in the plugin's surfaces implies the seal proves currency, which it does not.

Out of scope

• The write-once guarantee itself, which is the carrier.
• The mechanical findings in the parent, which need re-verification first.
• Changing what the sealing tool verifies.

Blocked by

• plugin-quality: decide how write-once is guaranteed when the agent bound by it is the party able to break it #3866

[kyle-sexton]

Decision: a sealed packet asserts the state of the world at seal time

Recorded 2026-09-28 by operator delegation.

1. A sealed packet is a snapshot: it asserts state at the moment of sealing, never current state. The documentation says so explicitly.
2. Staleness is detectable because the packet records its seal moment, so a later reader can check it without replaying session history.
3. The producing session's obligations after sealing follow the existing numbered-flush discipline: a later change produces a new numbered artifact rather than editing the sealed one.
4. The multi-flush design is already a sequence of snapshots, so this decision is consistent with it.

Basis: this issue's own reasoning ("Only the first is defensible"). #4970 documents this answer.