Digital Signature / Proof

Proof instance identity and host binding

A proof is an identified value bound to exactly one host representation. Identity comes from the producing system or a governed IRI; a signing time, a file name or the proof value alone never designates the record.

1. Which identifier authoritatively designates this proof instance, and which system assigned it? identity
2. Which host record or representation is this proof bound to, and is the binding enveloped, enveloping, detached or internally detached? relationship
3. What distinguishes this proof record from the host content it protects and from the verification material it merely references? definition
4. How is a revision of the proof record distinguished from a newly created proof over the same host? provenance

Proof kind classification

Classifies the instance as an asymmetric digital signature, a symmetric MAC, an unkeyed digest, an electronic seal, a time-stamp token, a selective-disclosure proof or a zero-knowledge attestation, because the properties each kind can support differ materially.

1. Which proof kind does this instance belong to, drawn from a governed enumeration that keeps signature, MAC, digest, seal, time-stamp token and selective-disclosure proof distinct? classification
2. Does the chosen kind support data-origin attribution provable to a third party, or only integrity and shared-key authentication? constraint
3. What regime-specific qualification, if any, is claimed for this kind, and which authority defines that qualification? authority
4. Which external type identifier, object identifier or cryptosuite name expresses this kind in the container format in use? interoperability

Proof record state and permitted transitions

The state of the proof record itself — drafted, issued, attached, superseded, withdrawn or flagged as having unverifiable material — kept strictly distinct from key revocation, credential status and host document status.

1. Which state does this proof record currently hold, and what is the permitted transition set from that state? state
2. Which events cause a state transition, and which of those events originate outside this model? lifecycle
3. How is withdrawal of a proof recorded without asserting revocation of the underlying key or credential? exception
4. Who is entitled to change the state of this proof record, and under what authority? authority

Method, algorithm identifiers and parameters

Records the algorithm or cryptosuite identifier, hash function, parameter set and variant options needed to reproduce verification, and the strength claim against which algorithm sunset constraints are assessed.

1. Which algorithm or cryptosuite identifier, in which registry, states the method that produced this proof? definition
2. Which parameter values must be known to reproduce verification, including hash function, parameter set, curve, salt length, context string and any pre-hash variant? requirement
3. What security strength or parameter category does the method claim, and against which published sunset or deprecation date is it assessed? measurement
4. Is the method identifier itself cryptographically covered by the proof, so that algorithm substitution can be detected? security

Proof value, encoding and coverage

The proof value octets, the encoding and container serialization that carries them, and which header or attribute fields the value cryptographically covers versus which travel unprotected.

1. In which encoding and container serialization is the proof value recorded, and does that serialization permit a detached payload? interoperability
2. Which header, attribute or metadata fields are cryptographically covered by this proof value, and which are unprotected? composition
3. Which values must be rejected outright, such as an unsecured or none algorithm, an ambiguous canonical form, or a value whose covered representation cannot be reconstructed? security
4. How is the stored proof value shown to be byte-identical to the value captured at registration? quality

Verification-method reference and binding

How the proof nominates the public key, certificate, verification method or key-binding confirmation needed to verify it, carried strictly as a reference with coverage metadata and no imported key or credential ownership.

1. Which verification method does this proof nominate, and in which resolvable reference form is it expressed? relationship
2. Which controller or holder is asserted to control that verification method, and who makes that assertion? ownership
3. Which verification material travels embedded as a hint rather than being resolved, and is that hint covered by the proof? evidence
4. What does this reference deliberately not establish about the key's trustworthiness, currency or revocation state? constraint

Claimed, operating, controlling and verified signer roles

Five roles that are routinely conflated are kept apart: claimed signer, signing actor, verification-method controller, credential subject, and the verified signer identity that only a completed verification can establish.

1. Which party does the proof claim as its signer, and in which field is that claim carried? identity
2. Which actor or system operated the signing process, and is it distinct from the claimed signer? provenance
3. Which signer identity, if any, was actually established by a completed verification, and against which verification method? validation
4. How is a discrepancy between claimed signer, credential subject and verified identity recorded rather than silently resolved? exception
5. Which external party records are referenced for each role, and which model owns each of them? ownership

Signer capacity and on-behalf-of representation

Whether the signer is a natural person, a legal person, a device or an automated agent, in what stated capacity, and whether the proof is made on behalf of another party under an external mandate.

1. Is the signer a natural person, a legal person, a device or an automated agent, and does that choice change the applicable proof kind? classification
2. In what stated role or capacity is the signer acting, as declared within the proof? definition
3. Is the proof made on behalf of another party, and which reference records the represented party? relationship
4. Which external mandate, delegation or authority record is cited for the representation, and is it evaluated anywhere in this record? authority

Proof purpose, commitment type and scope of use

Records the declared reason for the proof — such as authentication, assertion, capability invocation or delegation, or a commitment type such as proof of origin, receipt or approval — with the domain, challenge and nonce that limit where it may be accepted.

1. Which declared proof purpose or commitment type does this proof carry, and from which governed vocabulary is it drawn? classification
2. Which security domain, audience or challenge limits the contexts in which this proof may be accepted? constraint
3. Which party checks that the declared purpose matches the intended use, and where is that check performed? process
4. How is a proof handled when no purpose is declared or the declared purpose is unrecognised? exception

Separation of asserted security and legal properties

Per-property declaration of integrity, authenticity, origin attribution, approval, authorization, non-repudiation support and legal effect, each with its own basis and evidence reference, so that a successful cryptographic check is never read as asserting all of them.

1. Which of integrity, authenticity, origin attribution, approval, authorization, non-repudiation support and legal effect does this proof actually assert? requirement
2. For each asserted property, is the basis the cryptographic check, a declared purpose, an external policy, or an external legal determination? evidence
3. Which properties are explicitly not asserted, and how is that non-assertion made machine-readable to a consumer? constraint
4. What additional conditions must hold before non-repudiation support may be claimed, given that a signature alone does not establish when it was created? quality
5. Which applicable law or forum determines legal effect, and why is that determination excluded from this record? ownership

Multi-proof composition patterns

Distinguishes an unordered set of independent proofs over the same content, an ordered chain in which each proof covers the previous one, an endorsement that signs another proof's value rather than the content, and a threshold or multi-party proof that yields one proof from several participants.

1. Which composition pattern applies here: single proof, unordered co-signature set, ordered chain, endorsement of another proof, or threshold and multi-party proof? composition
2. Which earlier proof does this proof depend on, and does it cover that proof's value or only the same underlying content? relationship
3. What minimum and maximum number of participating proofs or parties satisfies the requirement, and is a partial set meaningful on its own? constraint
4. How is the outcome recorded when some members of a set verify successfully and others do not? exception
5. What evidence establishes the claimed order of a chain, given that a signer-supplied time does not? evidence

Claimed signing instant and proof-of-existence reference

The signing time inside a proof is a signer claim, not evidence. It is recorded as a claim alongside any declared expiry, references to external proof-of-existence evidence, and the separate instant at which this record observed the proof.

1. What instant does the proof claim as its creation time, and in which time representation is that claim expressed? temporal
2. Which external proof-of-existence evidence corroborates the claimed instant, and precisely what does that evidence attest? evidence
3. Does the proof declare an expiry or validity window, and how does that differ from the host record's own validity period? constraint
4. At what instant was this proof observed or ingested, and how is that kept distinct from the claimed signing instant? provenance
5. Under what conditions may the claimed instant be relied upon, and who makes that decision? decision

Recorded verification status

An explicit, never-defaulted status carried against the proof: the outcome an external verifier returned, when it was evaluated, under which referenced policy, what it covered, and how long it may be relied on.

1. What explicit verification status does this record carry, drawn from an enumeration that includes not-yet-verified and an indeterminate outcome? state
2. Which verifier produced this outcome, at which evaluation instant, and under which referenced validation policy? provenance
3. For how long may a recorded outcome be relied on before re-verification is required, and what invalidates it earlier? quality
4. Which checks does the recorded outcome cover, and which checks were outside the verifier's declared scope? constraint
5. Who may read or write the recorded status, and what must be captured whenever it changes? access

Protected subject declaration

States exactly which host statement, artifact version, field set, named graph or event occurrence is placed under protection, the topology of the proof relative to it (enveloped, enveloping or detached), and which parts of the host record are deliberately outside the protected subject. The host reference is carried; the host is never owned.

1. Which single unit - host statement, artifact version, field set, named graph or event occurrence - is placed under protection by this proof? definition
2. Through which reference is the protected unit reached without this model assuming the host's storage or lifecycle? relationship
3. Is the proof enveloped within, enveloping over, or detached from the protected unit, and where does its carrier sit? classification
4. When more than one payload unit is covered by a single proof, how is each unit bound and enumerated separately? composition
5. Which parts of the host record are deliberately not part of the protected subject at all? constraint

Content identity, version and type descriptor

Pins which representation of the logical content is protected: authoritative content identifier, version, master-system reference, declared content type and content length, plus whether the representation is immutable. CMS requires the signed content-type attribute to match the encapsulated content type; JWS and COSE carry content-type hints that are advisory unless made critical.

1. Which authoritative master-system identifier and version designate the exact protected representation? identity
2. Which declared content type governs interpretation of the protected octets, and is that type value itself inside the protected input? classification
3. What content length is recorded for the protected representation, and is it protected evidence or advisory metadata? measurement
4. How is the protected representation distinguished from a later revision of the same logical content? temporal
5. Which governed registry or namespace supplies the content-type and identifier vocabularies used here? interoperability

Direct versus digest-based binding mode

Records whether the protected octets are carried inside the protected input (as in a JWS payload or CMS encapsulated content) or bound indirectly through a digest reference (as in an XML Signature Reference, a C2PA hashed URI or a time-stamp MessageImprint), and how a detached payload or an immutable external resource is pinned so a verifier obtains the identical octets.

1. Is the payload bound directly as octets inside the protected input, or indirectly through a digest over a referenced object? definition
2. When the payload is detached, by what contract does a verifier obtain byte-for-byte the same octets that were protected? process
3. For an external resource, which combination of locator, digest, algorithm and declared type constitutes the immutable pin? evidence
4. What does this binding explicitly not guarantee about a dereferenced resource beyond digest equality? constraint
5. Which party is accountable for supplying the detached payload at verification time? ownership

Digest method and value evidence

Records the digest algorithm identifier drawn from a governed registry, the digest value and its encoding, any parallel digests recorded for agility, and a precise statement of the octet stream the digest was taken over. The digest is computed by an external provider; this model retains the evidence and the description of its input.

1. Which digest algorithm identifier, drawn from which governed registry and version, produced the recorded digest? interoperability
2. What is the recorded digest value and in which encoding and length is it expressed? measurement
3. Over exactly which octet stream was this digest taken, and where is that determination recorded? evidence
4. When several digests cover the same payload, which one governs and by what selection rule? decision
5. How is a weakened or superseded digest algorithm flagged without altering the historical binding evidence? quality

Whole-object versus selected-part protection scope

Declares whether the whole object is protected or an explicitly selected part, and expresses the selection so any verifier reconstructs an identical input: byte ranges with exclusions, named boxes, node sets, field sets or subgraphs. Records the unprotected remainder and the requirement that excluded regions cannot change how the protected part is interpreted.

1. Is the protection scope the entire object or an explicitly selected part of it? classification
2. How are included and excluded regions, boxes or fields expressed so a verifier reconstructs the identical selection? composition
3. How is a selection expressed when the payload is a field set or graph rather than a byte range? relationship
4. Which parts of the host object remain outside the protected scope and may change without invalidating this proof? state
5. What prevents a change inside an excluded region from altering how the protected part is interpreted? security

Protected and unprotected parameter partition with criticality

Classifies every proof parameter as inside or outside the protected input, marks the subset that must be understood or the proof rejected, and fixes the precedence rule when the same parameter appears in both positions. Records how a relying party registers that it did not understand a critical parameter.

1. Which proof parameters sit inside the protected input and which are carried outside it? composition
2. Which protected parameters are marked critical, so a party unable to process them must reject the proof? requirement
3. When one parameter appears in both a protected and an unprotected position, which value governs? decision
4. How does a relying party record that a critical parameter was not understood? exception
5. Which parameters are advisory only and must never carry a security decision on their own? quality

Proof purpose, audience context and validity-window binding

Binds the declared purpose of the proof, the audience or domain it is intended for, any challenge or nonce tying it to a request occurrence, externally supplied authenticated data bound without being carried, and an expiry inside the protected input - where the chosen proof method relies on these. Distinguishes proof expiry from the host content's own validity period.

1. For which declared purpose is this protected payload bound, and which uses are thereby excluded? authority
2. Which audience, domain or context value is bound so the proof cannot be replayed in another setting? security
3. Which challenge or nonce ties this protected payload to one specific request occurrence? event
4. Which expiry instant is bound inside the protected input, and how does it differ from the host content's own validity period? temporal
5. Which externally supplied data is authenticated by the proof without being carried inside the payload? provenance

Protected-input preservation and binding failure states

Fixes which form of the protected input - full octet sequence, canonical serialization or digest - is preserved so dependent countersignatures and proof chains bind the identical input, how a dependent proof references it, and the explicit failure states recorded when a payload is missing, mutable, ambiguous or resolves to a different version. Substituting an empty, default or nearest-match value is prohibited.

1. Which exact form of the protected input is preserved for dependent proofs: full octets, canonical serialization or digest alone? retention
2. How does a dependent countersignature or chained proof reference the prior protected input or signature value? relationship
3. What evidence shows the target was cryptographically finalized before a dependent proof was taken over it? validation
4. What outcome is recorded when the referenced payload is unresolvable, mutable, ambiguous or of a different version? state
5. Which substitutions are prohibited outright rather than recorded as a degraded result? constraint

Ordered transform and canonicalization chain record

The indexed sequence of transform steps applied between a selected input and the protected bytes, together with the digest of those bytes. Step presence is three-valued: a step may be absent from the declaration, declared as an explicit identity or no-op transform, or declared as a substantive transform. XML Signature reference processing shows the distinction is not cosmetic, since an octet stream with no Transforms is digested directly while a declared canonicalization step converts a node-set to octets.

1. What is the exact ordered sequence of transform steps applied between the selected input and the protected bytes? composition
2. Is each position an explicit identity or no-op transform, a substantive transform, or absent from the declaration entirely? classification
3. Which digest algorithm and value identify the protected byte sequence that the chain produced? identity
4. Can an independent implementation reproduce the recorded protected bytes byte for byte from the declared inputs and steps? validation
5. When a chain declaration changes, which prior record does it supersede and from which instant is each version effective? lifecycle

Versioned algorithm identifiers, parameters and implementation pins

For each declared step, the governed URI or registered name of the algorithm, the version or edition intended, the named parameter values bound versus left at specification defaults, and the external implementation, version and configuration that actually produced the bytes. Canonical XML 2.0 makes the case concrete: one algorithm URI with four mandatory parameters and documented defaults, so an identifier alone does not determine output.

1. Which governed URI or registered name identifies each transform algorithm, and which version or edition of it is intended? identity
2. Which named parameter values are bound for each parameterised algorithm, and which are left at specification defaults? constraint
3. Which external implementation, version and configuration produced the recorded protected bytes? provenance
4. Which conformance test vectors demonstrate that independent implementations of the pinned algorithm and parameter set agree? interoperability

Character encoding, Unicode, line-ending and whitespace declarations

Declared treatment of input character encoding, output octet encoding, Unicode normalization form and the Unicode version under which it was computed, line-break normalization and whitespace trimming. These change the protected bytes without changing perceived content, and some are irreversible: compatibility normalization erases formatting distinctions and prevents round-trip conversion.

1. Which character encoding is assumed for the input and which octet encoding is produced for the protected bytes? definition
2. Which Unicode normalization form, if any, is applied, and under which Unicode version was it computed? constraint
3. How are line endings and insignificant whitespace treated before the digest is taken? requirement
4. Which of these normalizations are lossy for the host representation and therefore recorded as irreversible? quality

Ordering, duplicate keys, lexical value forms and graph normalization

Declared treatment of member, attribute and namespace ordering, duplicate key disposition, numeric and date lexical forms, namespace or prefix context when a fragment is detached, and graph-level canonicalization for dataset-shaped inputs. The cited rules are mutually incompatible across syntaxes, so the declaration names which rule set applies rather than asserting a universal ordering.

1. What deterministic ordering rule applies to map keys, object members, attributes and namespace declarations? constraint
2. How is a duplicate key or repeated member handled, and is a duplicate a hard failure? exception
3. Which lexical forms are mandated for numbers, booleans and date or time values in the canonical output? requirement
4. For graph-shaped input, which dataset canonicalization algorithm and internal hash algorithm produce the deterministic labelling? interoperability
5. How is namespace or prefix context handled when signed content is detached from its enclosing document? relationship

Reference, base URI and fragment resolution context

The declarations that fix what a reference resolved to at derivation time: the reference expression, the base URI and the precedence rule by which it was established, the media type governing fragment interpretation, whether resolution was same-document or external, and the rung of the URI comparison ladder at which two references count as the same input. Signer and verifier reaching different values here is a documented failure mode.

1. Which base URI applied when relative references were resolved, and by which precedence rule was it established? provenance
2. How is the fragment component interpreted, and which media type determines that interpretation? definition
3. At which rung of the URI comparison ladder are two references treated as identifying the same input? validation
4. Do the signer and the verifier obtain the referenced component from the same source, and how is that agreement established? interoperability
5. Is external dereferencing permitted for this reference, and which component is authorised to perform it? authority

Coverage, exclusions and irreversible-transform record

Which parts of the input the chain covers and which are deliberately excluded, expressed as a selection or exclusion map, together with the record of steps that discard information not reconstructible from the protected bytes and a reference plus digest for the retained pre-transform representation. Exclusion-list rather than inclusion-list framing is the pattern that survives adversarial review, because it prevents unbound content being added without changing the binding.

1. Which byte ranges, nodes or message components does the chain cover, and which are excluded? composition
2. Which declared steps discard information that cannot be reconstructed from the protected bytes? evidence
3. What content can change without changing the protected bytes, and has that been accepted for the declared purpose? security
4. Does the selection expression still select the same content when the host document is restructured or the fragment is relocated? state

Domain separation and purpose or context binding

The values mixed into the protected bytes so that a derivation cannot be lifted into another setting: a domain separation tag or structure context label, the declared proof purpose, the domain or audience, a challenge or nonce, an explicit type label, and externally supplied additional authenticated data. All must sit in the protected region; attributes taken from an unprotected region are never bound.

1. Which domain separation string or structure context label is incorporated into the protected bytes, and how is it made unique and versioned? security
2. For which declared purpose are these protected bytes valid, and which values bind them to an audience, domain or session? authority
3. Which explicit type label distinguishes this protected structure from other structures the same key may protect? classification
4. Which externally supplied additional authenticated data is bound into the derivation, and is an empty value distinguishable from an absent one? composition
5. Which instants bound the period in which these protected bytes are acceptable? temporal

Criticality declarations, complexity limits and divergence evidence

The per-derivation declaration of which steps and parameters are critical and must be understood or the derivation refused, which canonicalization-layer attack classes the chain claims to resist and by which declared mechanism, which input-complexity limits keep derivation bounded against poison inputs, and what evidence is recorded when two implementations diverge. This model declares and records; refusal, evaluation and enforcement are executed elsewhere.

1. Which chain steps and parameters are marked critical so that an unrecognised one must be refused rather than ignored? requirement
2. Which canonicalization-layer attack classes does this derivation claim to resist, and by which declared mechanism? security
3. Which input complexity limits bound the derivation so that a hostile input cannot exhaust the processor? constraint
4. Which transform algorithms are admissible for this derivation, and which are refused outright? decision
5. When two implementations derive different protected bytes from the same declared input, what evidence is recorded? evidence

Binding form classification and per-projection availability

Records which binding form a proof instance uses — enveloped (proof inside the covered data), enveloping (covered data inside the proof), detached (proof and data separate), or internally detached (both in one container without nesting) — at which level the classification applies, and whether the chosen target projection can express it at all. Form availability is projection-specific and asymmetric: XML Signature defines all three classical forms, CMS supports enveloping and detached via omitted eContent, PAdES packaging is enveloped at document level while the embedded CMS is detached over a byte range, and Data Integrity attaches the proof as a property of the secured document.

1. Which binding form does this proof instance use, and at which level (payload level or host-artifact level) is that classification asserted? classification
2. What does the host artifact actually contain — the proof only, the covered data only, or both — and where inside it does the proof node or dictionary sit? composition
3. Which binding forms are unavailable for the declared target projection, and which specification statement establishes that unavailability? constraint
4. On what recorded criteria was this binding form chosen over the alternatives that the projection does support? decision

Multi-proof topology, ordering and countersignature targets

Records how many proofs cover the same subject and how they relate: unordered peers, ordered chains where each proof references its predecessor, and countersignatures that cover another proof's cryptographic value rather than the payload. The distinction is load-bearing because CMS carries multiple SignerInfos and a countersignature unsigned attribute, COSE separates COSE_Sign from COSE_Sign1 and moved countersignatures into a separate specification with changed coverage, JWS General JSON Serialization carries a signatures array that Compact Serialization cannot represent, and Data Integrity distinguishes proof sets from proof chains linked by previousProof.

1. How many proofs cover this subject, and which of them are peers versus proofs taken over another proof's signature value? relationship
2. Is the multi-proof arrangement unordered or ordered, and which element carries the ordering? composition
3. Does the declared serialization variant physically permit the recorded number of proofs, or would expressing them force a structural change to the instance? constraint
4. What evidence records that a countersignature covers the target proof's cryptographic value and not merely the same payload? evidence

Detached payload discovery and reference descriptors

Records the descriptors a consumer needs to find and confirm detached content: URI or locator, digest algorithm and value, transform chain, byte range, HTTP header set, and the concatenation order when several objects form one payload. XML Signature dereferences Reference URIs with same-document and fragment rules and allows at most one Reference to omit the URI; JAdES sigD identifies one or more detached objects that are processed and concatenated into the payload; COSE places a nil object and makes unchanged transport an application responsibility; CMS omits eContent entirely; and PAdES binds by a ByteRange over the host file. Resolution itself is performed by the referenced runtime.

1. Which identifier or locator designates each detached payload object, and does it come from a master system, a governed IRI scheme or a Dimension-assigned identifier? identity
2. Which resolution inputs must a consumer be given to reconstruct the exact signed octets from the locator? process
3. What is recorded when a detached reference cannot be dereferenced or resolves to octets whose digest does not match the declared value? exception
4. Is the payload bound through a declared digest or directly over transmitted octets, and what substitution risk does that choice carry? quality

Transformation, canonicalization and signing-input declarations

Records the declared method by which covered data becomes the octets actually signed: the canonicalization or transformation algorithm and the structure it operates over, any context string or externally supplied authenticated data folded into the input, and payload-encoding flags. The projections diverge sharply — Canonical XML over an XPath node-set with an enveloped-signature transform, DER-encoded SignedAttrs in CMS, a CBOR Sig_structure whose first element is a context string plus external_aad, a base64url concatenation in JWS that changes shape when b64 is false, and RDF Dataset Canonicalization or JCS for Data Integrity with a mandatory error when a JSON-LD processor drops data. All computation is external.

1. Which transformation or canonicalization algorithm is declared, and over which node-set, octet range or dataset does it operate? definition
2. Which context string or externally supplied authenticated data is folded into the signing input without being transmitted inside the proof? security
3. Under which recorded conditions does the declared transformation become lossy or non-deterministic, and how is that condition captured rather than silently accepted? validation
4. Can the declared transformation chain be expressed in the target projection, and if not, what blocking reason is recorded? interoperability

Protected versus unprotected placement and critical-parameter declaration

Records, per declared parameter, whether it is integrity protected, whether it is marked as must-understand, and whether it may be added or replaced after signing. The projections implement one pattern with different mechanics: JWS keeps protected and unprotected header members disjoint and requires crit to appear only in the protected header; COSE treats a crit label absent from the protected bucket as a fatal error and reserves core algorithm labels from omission rules; CMS separates DER-encoded signedAttrs from unsignedAttrs; XAdES splits signed from unsigned qualifying properties and XML Signature only protects SignatureProperties that a SignedInfo Reference actually covers; JAdES confines all unprotected content to a single etsiU array.

1. For each declared parameter, is it inside the integrity boundary or in an unprotected or unsigned container? classification
2. Which parameters must a consumer understand in order to process the proof, and are they listed in the projection's critical-parameter mechanism? requirement
3. What must a consumer do on meeting a critical parameter it does not implement, and where is that outcome recorded? exception
4. Which parameters may be added or replaced after signing without invalidating the proof, and which are immutable? state
5. Which parameters feed a trust decision and therefore must not be accepted from an unprotected container? security

Signer and key identification mechanisms and carried evidence references

Records how a binding points at the verification key or signing certificate and what supporting evidence it carries. The mechanisms are not interchangeable: JWS offers kid, jwk, jku, x5c, x5u and thumbprint headers; COSE defines x5bag, x5chain, x5t and x5u with the end-entity identification required to be integrity protected, and warns that kid values are not unique; CMS identifies the signer by issuerAndSerialNumber or subjectKeyIdentifier with certificates and CRLs in the SignedData; XML Signature uses KeyInfo, KeyValue and KeyInfoReference; Data Integrity uses a verificationMethod URL checked against a controller. Carried certificate, revocation and timestamp material is recorded as evidence references only.

1. By which mechanism does this binding identify the verification key or signing certificate, and is that mechanism resolvable without out-of-band data? identity
2. Where did the carried certificate, chain or key material originate, and is it held as a copy, a reference or a digest? provenance
3. Does the target projection offer an equivalent key-identification parameter, and what is lost if it does not? interoperability
4. Is the key-identification parameter integrity protected in this binding, and if not, what risk note is recorded? constraint

Projection profile and encoding template requirements

Declares, for each target binding, a versioned profile fixing the serialization variant, required and forbidden parameters, the identifier space used for methods, the media type and content-type parameter, and the governing specification edition. The profile is a declaration, not an encoder: the referenced runtime performs the encoding. The identifier space differs by projection — ASN.1 OIDs in CMS, algorithm URIs in XML Signature, registered string tokens from the IANA JOSE registries in JWS, integer labels from the COSE registry, and cryptosuite string tokens in Data Integrity — so no profile may be treated as a model-wide default.

1. Which identifier names this projection profile, and which registry or specification governs that identifier? identity
2. Which serialization variant, structural tag or container placement does the profile fix? composition
3. Which parameters does the profile require, which does it forbid, and which does it leave to the adopting Dimension? requirement
4. In which identifier space does this profile express algorithms and methods, and how are their parameters carried? classification
5. Which media type and content-type parameter must accompany an instance produced under this profile? interoperability

Projection loss ledger and loss reporting

Records, per source-to-target projection pair, which of the enumerated loss classes are triggered and with what severity. The enumerated classes are: proof purpose or commitment, signer and key identity, signed properties, canonicalization and transformation, detached references, countersignatures, timestamps, certificate and revocation evidence, multi-signature topology, and long-term validation material. Losses are structural facts about the pair, not judgements about a particular instance, and their acceptance is an owner decision recorded against the ledger entry.

1. Which enumerated loss classes does this source-to-target pair trigger, and at what severity is each recorded? measurement
2. Which concrete parameter, property or structure is dropped, downgraded or re-encoded for each triggered class? evidence
3. Is a given loss caused by the target projection's own structure or only by the options selected in the chosen profile? relationship
4. When was this loss assessment made, against which profile and specification versions, and when was it last re-checked? temporal
5. Who owns the decision to accept a recorded loss, and where is that acceptance captured? ownership

Round-trip impossibility, unsafe fallback, media-type ambiguity and evidence conflicts

Records the verdict for a proposed movement between bindings and the conditions that block it. Grounded blocking conditions include: COSE single-signer and multi-signer structures cannot be converted because the structure identity is part of the signing input; JWS Compact Serialization has no syntax for an unprotected header and admits only one signature; an unencoded JWS payload may not contain '.' in compact form and may not appear in a JWT at all; a PDF instance carries the same media type for every version so the binding cannot be inferred from the type alone. It also records conflicts when embedded evidence duplicates or contradicts itself, and the fallback paths that are forbidden because they would silently weaken the proof.

1. Is movement from the source binding to the target binding permitted, blocked, or permitted only under a recorded loss acceptance? decision
2. Which specific structural or cryptographic facts make a byte-identical round trip impossible for this pair? constraint
3. Which fallback paths are explicitly forbidden because they would silently weaken or reinterpret the proof? security
4. How is the concrete binding of an instance determined when its media type does not identify the serialization variant or profile? interoperability
5. When embedded evidence duplicates or contradicts itself, which item governs and how is the conflict captured? validation

Binding profile version, logical proof version and host artifact version

Keeps three independent version axes apart. The binding profile version tracks the projection profile and the specification edition it was authored against, such as an ETSI deliverable version or a W3C cryptosuite token that may embed a year but is treated as an opaque governed string. The logical proof version tracks the model-level description of the proof itself. The host artifact version tracks the containing document, which for PDF is signalled only by the file header because the media type is identical for every version. Confusing the axes produces false compatibility claims.

1. Which three version values apply to this record, and where is each of them recorded? identity
2. What changes when only the binding profile version advances while the logical proof content is unchanged? state
3. Which version changes require producing a new proof rather than re-encoding the existing one? lifecycle
4. Which specification edition and which registry snapshot were in force when this binding was produced? provenance

Verification-method reference and resolution inputs

The reference that identifies the verification key material for a signature — a raw public key, an X.509 end-entity certificate, a verifiable credential, or a DID URL — together with the resolution inputs supplied and the resolution metadata and version reference returned. The external record itself is owned and operated by its issuer, controller or DID method; this finding captures the pointer and what was observed when it was retrieved.

1. Which identifier resolves the verification method used for this signature, and in which identifier space is that identifier authoritative? identity
2. Which binding form carries the verification key: bare public key, X.509 certificate, verifiable credential, or DID document entry? classification
3. What resolution inputs were supplied and what resolution metadata was returned when the verification method was retrieved? provenance
4. Which version of the verification-method record was in effect, and how would a later version be distinguished from the one actually used? temporal

Declared purpose and usage constraints of the verification method

What the verification method itself declares about the operations it may be used for, and what relying-party behaviour it demands — key usage bits, extended key usage purposes, DID verification relationships, and certificate-declared mandatory relying-party features. Whether a mismatch is tolerated is a policy decision made elsewhere; this finding records the declaration and the observed mismatch.

1. For which purposes was this verification method authorized, and where is each authorization declared? authority
2. What is recorded when the declared purpose does not cover the operation this signature was actually used for? exception
3. Does the verification method assert a mandatory relying-party feature such as stapled status evidence? requirement
4. Which controller or issuer asserts control over this verification method, and how is that assertion evidenced? ownership

Candidate certification paths, retrieval provenance and selection

The set of candidate paths assembled toward a trust anchor, where each intermediate certificate came from, which candidate was selected, and by which external path builder on what recorded ordering criteria. Path building is a search that may yield several defensible answers in mesh and bridge architectures, so the alternatives and the selection basis are context in their own right.

1. Which candidate certification paths were assembled for this signature, and how is each candidate identified? composition
2. From which store, extension or protocol message was each intermediate certificate obtained? provenance
3. Which candidate path was selected, by which builder, and on what recorded ordering or elimination criteria? decision
4. How were repeated subject-name and public-key pairs detected and excluded from candidate paths? constraint

Path validation inputs and recorded constraint outcomes

The initial inputs supplied to path validation and the per-certificate and per-path constraint outcomes recorded afterwards: basic constraints and path length, name constraints against tested name forms, certificate policies and policy mappings, and unrecognized critical extensions. The algorithm is executed by an external validator; this finding records what was fed in and what came back so the determination is reproducible.

1. Which initial path-validation inputs were supplied for this determination? requirement
2. What basic-constraints and path-length outcome was recorded for each certification authority certificate in the selected path? constraint
3. Which name constraints applied, and which subject and alternative name forms were tested against them? relationship
4. Which certificate policies and policy mappings survived to the end of the selected path? classification
5. How is an unrecognized critical extension encountered in the path recorded? exception

Trust anchor identity, anchor-carried controls and trust-store snapshot

The trust anchor that terminated the selected path, the path controls the anchor itself imposes below it, the trust store or trust list snapshot that made the anchor trusted at the recorded instant, and the service status the governing list reported for it. Operation of the store or list — admission, supervision, status determination — belongs to its scheme operator.

1. Which trust anchor terminated the selected path, and by which name and key identifier is it recorded? identity
2. Which path controls does the trust anchor itself impose on certification paths beneath it? constraint
3. Which trust store or trust list snapshot was in force, and how is that snapshot pinned so it can be reproduced? provenance
4. What status did the governing trust list report for the anchor's trust service at the recorded instant? state

Status mechanism and captured status determination

The mechanism that governs status for this verification method, the status value reported with its reason and effective date, whether that status is reversible, and the scope the evidence claims to cover. Mechanism-specific vocabularies are kept distinct rather than normalized, because suspension, hold and supersession do not map cleanly across certificate revocation lists, online status responses and credential status lists.

1. Which status mechanism governs this verification method, and what does the certificate or credential itself declare about it? classification
2. What status value was reported for the subject, with which reason code and effective date? state
3. Is the reported status reversible, and how are suspension and supersession distinguished from permanent revocation? lifecycle
4. What scope does this status evidence claim to cover, and does the subject demonstrably fall inside it? composition

Status-evidence authorization, replay binding and delivery

Who signed the captured status evidence, on what basis that signer was authorized to speak for the subject, how the recursion into the signer's own status was stopped, what binds the evidence to this request rather than to a replayed earlier one, and through which channel and cache it arrived. The signer's certificate and the responder service are operated externally; this finding records the authorization basis reported and the binding fields observed.

1. Who signed the captured status evidence, and on what basis was that signer authorized to speak for this subject? authority
2. How was the status signer's own revocation position handled without recursing without bound? exception
3. What binds this status evidence to this particular request rather than to an earlier response replayed at us? security
4. Through which channel and cache did the evidence arrive: stapled in protocol, fetched directly, embedded in the signed data object, or served from cache? interoperability

Validation instant, proof of existence and observation time

Which instant this trust-chain record is framed against — the current time, the best-signature time established by a proof of existence, or a replayed historical instant — together with the proof that supports a past instant, the separation of when facts occurred from when they were observed, and the clock-skew tolerance assumed when comparing an instant to an evidence window. A signature made before revocation and proven to predate it is a different case from one made after, and the model must be able to state which case it is describing.

1. Against which instant is this trust-chain record framed: current time, best-signature time, or a replayed historical instant? temporal
2. What proof of existence establishes that the signature and its supporting evidence existed before the claimed instant? evidence
3. When was each path and status fact observed or ingested, as distinct from when the underlying event occurred? provenance
4. What must be retained so this instant can be re-evaluated later without contacting live services? retention
5. What clock-skew tolerance and time source were assumed when comparing this instant against evidence validity windows? measurement

Evidence completeness and determinacy classification

Whether the assembled trust-chain and status record is complete enough at the declared instant to be determinate, or whether it is evidence-incomplete — missing, stale, out of scope, or unreachable — as distinct from a cryptographic failure. Also carries, verbatim and attributed, any validation indication issued by an external validator, and the failure-handling stance declared by the consuming environment. The model classifies the completeness of its own record; it does not decide trust and does not enforce an outcome.

1. Which required trust-chain and status elements are present, stale or missing for the declared instant? quality
2. Is this record determinate, or is it evidence-incomplete rather than cryptographically failed? validation
3. Which externally issued validation indication and sub-indication are carried with this record, and who issued them? interoperability
4. Which failure-handling stance for missing or stale status evidence did the consuming environment declare, and who declared it? decision
5. What does the recorded evidence reveal about the relying party's own query behaviour, and how is that limited? privacy

Signature and digest suite identification with parameter completeness

Records the signature and digest algorithm identifiers together with the registry namespace they belong to and the full parameter set needed to reproduce verification: scheme and encoding or padding, curve or group, modulus or key size, digest function and output length, pre-hash mode and any context or domain-separation string. Absent, inherited or ambiguous parameters are recorded as an explicit completeness status rather than silently defaulted.

1. Which algorithm identifier, in which registry namespace, denotes the signature suite used, and what is its exact string or numeric value? identity
2. Which parameters does the declared suite require in order to be unambiguous, and is each one present on the record? composition
3. Which curve, group or modulus size and which digest function and output length are bound to this signature? classification
4. How are absent, inherited or ambiguous algorithm parameters recorded so that they are never silently defaulted? exception
5. Is a pre-hash mode or context or domain-separation string in effect, and what is its value? constraint

Security strength, approval state and pinned algorithm policy

Records the security strength the declared suite targets and the table that claim is made against, the approval state each governing authority assigns to it (approved, acceptable, deprecated, legacy-use, restricted, disallowed, or registry equivalents such as Recommended, No, Deprecated, Prohibited), any sunset or transition date, the time basis the sunset is evaluated against, and the exact policy snapshot pinned when the assessment was made. Disagreement between authorities is recorded, not resolved.

1. What security strength in bits does the declared suite target, and against which strength table is that claim made? measurement
2. What approval state does each governing authority assign to this suite, and do those authorities disagree? authority
3. What sunset, deprecation or disallowance date applies, and relative to which time basis is it evaluated? temporal
4. Which exact policy snapshot version was pinned when this signature's algorithm state was assessed? provenance

Accepted-algorithm set and downgrade resistance

Records the verifier-side accepted-algorithm set that governed a verification episode, where that set came from, whether the algorithm asserted in the signature container fell inside it, and the controls against algorithm confusion, reuse of one key across multiple algorithms, and acceptance of none or other non-signing algorithm values. The accepted set is a policy reference plus per-episode scalars; the deciding engine is external.

1. Which accepted-algorithm set applied to this verification, and was it obtained from verifier policy or from the signature container? constraint
2. Did the algorithm asserted in the container fall inside the accepted set, and if not, which reason code is recorded? validation
3. Is the verification key bound to exactly one algorithm, and was that binding actually checked during the episode? security
4. How are unauthenticated, none or otherwise non-signing algorithm values handled and recorded? exception

Randomized, deterministic and hedged signing profile

Records whether the signature was produced with a randomized, deterministic or hedged per-message secret process, on what basis that claim rests, and the explicit limitation that deterministic and randomized signatures of the same suite are indistinguishable to a verifier holding only the signature value.

1. Which per-message randomness mode does the signer claim - randomized, deterministic or hedged - and for which suite? classification
2. What evidence supports the randomness-mode claim, given that a verifier cannot infer it from the signature value? evidence
3. What operational risk is recorded when the randomness mode is unknown or the signer's entropy source is unattested? quality
4. Does the recorded mode change the bytes a verifier must process or the identifier it must accept? interoperability

Hybrid, composite and post-quantum transition state

Records multi-algorithm proofs - composite or parallel hybrid - their ordered component algorithms and parameter sets, the combination rule that governs the overall result, the security property the combination claims relative to its components, and the post-quantum migration state assigned by a named policy and jurisdiction. No universal transition deadline is asserted.

1. Which component algorithms make up this composite or hybrid proof, and under which composite identifier are they combined? composition
2. What combination rule governs the overall result - must every component verify, or is a subset sufficient? constraint
3. Which post-quantum migration state is recorded for this signature, and which named policy and jurisdiction assign it? state
4. Which security property does the combination claim, and is that property weaker than the property of its strongest component? quality

Verification input set, validation time and time claims

Records the complete input set consumed by a verification episode: the covered byte sequence and the ordered canonicalisation or transform chain that produced it, the resolved verification-method reference, the validation time and the basis on which it was chosen, the validation material supplied versus fetched, and the claimed signing time held explicitly as an untrusted claim alongside any proof-of-existence reference that supports it.

1. Exactly which byte sequence was covered by the signature, and through which canonicalisation or transform chain was it derived? composition
2. Which validation time was used for this episode, and why was that time chosen rather than another? temporal
3. What signing time does the signature claim, and what external evidence, if any, supports that claim? provenance
4. Which validation material was supplied to the episode rather than fetched, and is it complete for the chosen validation time? evidence
5. Which verification method or key identifier was resolved for this episode, and in which reference form? identity

Verifier, tool and evidence pinning

Records who or what produced a verdict, with which software identity, version and configuration, at which observation or ingestion time as distinct from the validation time it was computed for, and which externally produced validation report the verdict is bound to and by which digest. It also records what must be held constant to re-derive the verdict and what is known to be non-reproducible.

1. Which verifying party, and which tool, library and version, produced this verdict? provenance
2. When was the verdict observed and ingested, as distinct from the validation time it was computed for? temporal
3. Which validation report or evidence object is this verdict bound to, and how is that binding integrity-protected? evidence
4. What must be held constant to reproduce this verdict, and which factors are known to be non-reproducible? validation

Structured verification outcomes and machine-readable reasons

Defines the closed outcome vocabulary a recorded verdict may take - valid, invalid, indeterminate, unsupported, malformed, policy-rejected and evidence-incomplete - each carrying at least one machine-readable reason code when it is not valid, together with versioned mappings to external status vocabularies and explicit marking of where those mappings lose information.

1. Which outcome value does this verdict carry, and from which closed vocabulary version is it drawn? classification
2. Which machine-readable reason codes justify the outcome, and is at least one recorded for every non-valid result? requirement
3. How does each local outcome map onto external status vocabularies, and where is that mapping lossy? interoperability
4. What distinguishes indeterminate and evidence-incomplete from invalid, and what would resolve them? decision
5. How is an unsupported algorithm distinguished from a malformed structure in the recorded outcome? exception

Separation of validity dimensions in a verdict

Requires each verdict to report cryptographic primitive validity, trust-path outcome, identity binding, authorization, proof purpose, qualification and legal effect as independent dimensions, each with its own outcome, reason code and owning authority, and each explicitly marked not-assessed when it was not evaluated. A successful primitive check never sets any other dimension, and any single summary flag must declare the derivation rule and the information it discards.

1. Which validity dimensions are reported for this verdict, and which are explicitly marked not assessed? composition
2. Which model or authority owns the determination of each dimension, and is that determination referenced rather than recomputed here? ownership
3. For which declared proof purpose was the signature accepted, and does it match the purpose the verification method authorises? relationship
4. Which rule governs deriving a single summary flag, and what information does that derivation discard? constraint
5. Where is any qualification or legal-effect determination recorded, and under which jurisdiction and instrument was it made? authority

Time-stamp request and message-imprint binding

The hash algorithm and imprint value submitted for time-stamping, the requested policy, the nonce and certificate-request flag, and above all an unambiguous statement of which object the imprint covers: the signature value, the signed data, or a prior evidence element. Without this statement a token proves the existence of an unknown digest.

1. Which exact byte sequence was hashed to form the message imprint, and is it the signature value, the signed data or a prior evidence element? composition
2. Which hash algorithm identifier and digest length formed the imprint, and was that algorithm acceptable under the algorithm policy in force when the request was made? constraint
3. Was a nonce supplied in the request, and does the returned token echo that identical value? security
4. Was a specific authority policy requested, and did the issued token assert that same policy? authority

Time-stamp token identity, generation time and accuracy

The token exactly as issued: serial number, asserted generation time, accuracy bounds, ordering flag, echoed nonce, authority hint, policy identifier and the certificate identifier binding it to a time-stamping unit key. These bytes are the proof; everything else in the model is commentary on them.

1. What is the token serial number, and which issuing-authority namespace makes that serial unique? identity
2. What generation time does the token assert, and with what stated accuracy bounds? temporal
3. Is the ordering flag asserted, and may two tokens from this authority be strictly ordered when their accuracy intervals overlap? constraint
4. Which certificate identifier binds the token to the time-stamping unit key, and is it the legacy or the version-2 form? provenance
5. Was the response status a granted issuance, and is any failure information recorded? state

Time authority reference, policy and time-source assurance

Which authority issued the trusted time, under which published policy and qualification status, and what assurance of traceability to Coordinated Universal Time that policy claims. Carried strictly as resolvable references plus the subject-specific binding.

1. Which authority identifier, certificate and published policy document govern the token relied on here? authority
2. What traceability to Coordinated Universal Time does the authority's policy claim for tokens of this class? evidence
3. Was the authority supervised or qualified under a named trust framework at the moment the token was generated, and according to which list? classification
4. If the authority is later found compromised or its policy is withdrawn, which recorded reference lets a verifier locate that determination? exception

Ordered relation between claimed, proven and observed instants

The defensible ordering among signer-claimed signing time, each proof of existence, revocation and compromise instants, and each validation instant, together with the accuracy and clock-uncertainty bounds that make some pairs unorderable.

1. How does the signer-claimed signing time relate to the earliest proof of existence recorded for the same signature? temporal
2. What is the earliest defensible proof-of-existence instant for this signature, and which evidence element establishes it? measurement
3. Which pairs of recorded instants cannot be strictly ordered because their accuracy or uncertainty intervals overlap? quality
4. Is any proof of existence established by a mechanism other than a time-stamp token, such as a time-mark held by a service provider or an archive time-stamp over an evidence chain? classification
5. Which recorded instants are event times asserted by an external party and which are observation or ingestion times recorded by this model? provenance

Signature input identification and digest

What the signature actually covers: the digest algorithm and value, the transform or canonicalization chain that produced the hashed octets, whether content is embedded, detached or absent, and the stable reference to the signed object in the system that owns it.

1. Which digest algorithm and digest value represent the signature input, and over which transformed octet stream were they computed? measurement
2. Which transforms or canonicalization steps must be replayed in order to regenerate an identical digest input? process
3. Is the signed content embedded with the signature, detached and referenced, or absent, and what happens to replay when a referenced object cannot be retrieved? exception
4. Which stable reference identifies the signed data object in the model that owns it, and does that reference pin a specific version? identity

Certification path and revocation-status snapshot with freshness

The certificates, certificate revocation lists and status responses actually used for one validation, captured with their own time fields and responder identities so that a later party can reconstruct the status picture that was available, rather than the one available today.

1. Which certificates form the prospective certification path, and are they retained by value or only by reference with a digest? composition
2. For each revocation source used, what are its production, this-update and next-update instants and its responder or issuer identity? evidence
3. Was each revocation response fresh enough under the freshness constraint applied at the validation instant, and was a nonce or only a cached response available? validation
4. If a certificate was revoked, what revocation instant and reason were recorded, and how does that instant compare with the proof of existence for the signature? relationship

Trust configuration and algorithm constraint snapshot

The trust anchors supplied to path validation, the state of the list or store they came from, the cryptographic suites treated as acceptable with their sunset instants, and the freshness, path and policy constraints applied. Retained so a replay can be run under either the original or a current constraint set and the difference attributed.

1. Which trust anchors were supplied to path validation, and from which list or trust-store state were they taken? provenance
2. Which cryptographic suites were treated as acceptable, and what sunset instant applied to each at the validation instant? constraint
3. Which freshness, path-length and policy constraints were applied, and which of them were mandatory rather than advisory? requirement
4. Can a replay distinguish a failure under the original constraint set from a failure that appears only under a stricter current constraint set? decision

Validation verdict, sub-indications and dependency references

The outcome an accepted external validation application returned: main indication, sub-indication, per-constraint results, the validation objects each conclusion depended on, the validation instant, and the report carrying them. The model records this outcome; it does not evaluate, decide or enforce.

1. What main indication and sub-indication did the validating application return for this signature? validation
2. Which specific validation objects did each conclusion depend on, and are all of them retained? relationship
3. Which validation report format and version carry the verdict, and is the report itself signed or sealed? interoperability
4. Was the result determined at a validation time other than the moment the report was produced, and which instant governs the conclusion? temporal
5. What must be shown to a relying party for this result to be actionable, including signatory identification and any pseudonym or qualification flag? requirement

Verifier identification and replay determinism

Which product, version, build and named configuration produced a recorded verdict, which inputs must be replayed unchanged, which parts of a replay still depend on network retrieval, and how a divergent replay result is recorded without touching the earlier record.

1. Which validating product, version and build produced this outcome, and under which named configuration was it run? identity
2. Which inputs must be replayed unchanged for the verdict to be reproducible, and which may legitimately vary? process
3. Which parts of a replay depend on live network retrieval rather than on retained evidence? quality
4. When a replay reaches a different verdict from the recorded one, how is the divergence captured without altering the earlier record? exception

Evidence embedding versus external evidence package

Whether durable evidence is carried inside the signature container, held beside it as a detached evidence record, or both, and what binds an external package to the exact signature and input it covers when the subject is re-containerised.

1. Is durable evidence embedded in the signature container, held as a detached evidence record, or maintained in both places at once? classification
2. Which container profile and level does the embedded evidence claim, and is that claim substantiated by the elements actually present? validation
3. If evidence is external, what binding ties the package to the exact signature and signed input it covers? relationship
4. How is the same evidence expressed when the subject moves between container formats or into a database projection? interoperability

Evidence renewal and chain continuity

How evidence is kept effective as algorithms and keys weaken: renewal by a new time-stamp over prior evidence when only the authority key is at issue, or hash-tree renewal over the full sequence when the digest algorithm itself is at issue, together with the continuity of the chain and the detection of gaps.

1. Was the most recent renewal a time-stamp renewal over prior evidence or a hash-tree renewal under a new digest algorithm? event
2. By which instant is the next renewal due, and which algorithm or key expiry drives that deadline? lifecycle
3. Is the chain from the first proof of existence to the most recent renewal unbroken, and where exactly does any gap fall? validation
4. Which redundant evidence chains exist under different digest algorithms or different authorities for this subject? composition
5. If a renewal is missed until after the protecting algorithm has already weakened, what is recorded and what assurance remains? exception

Transparency-log corroboration references

Inclusion and consistency proof references, log identity, entry locator and signed checkpoints, recorded as optional corroboration that something was published at a point in a verifiable append-only structure — and explicitly not as proof of signer identity, authorisation or the truth of the signed content.

1. Which log identity, entry index and tree size does the recorded inclusion proof refer to? provenance
2. Which signed checkpoint or signed tree head was current when the proof was captured, and which key signed it? evidence
3. What does this corroboration deliberately not establish about the signer or the signed content? definition
4. If the log is later shown to be inconsistent, is decommissioned, or its key is withdrawn, what remains provable from the retained evidence? exception

Evidence anomalies, degradation and supersession assertions

Conditions that damage or change the meaning of retained evidence — unavailable or retracted status responders, expired certificates, keys revoked or compromised after signing, a compromised time authority, digest-algorithm collision migration, orphaned signed content and clock uncertainty — recorded as new append-only assertions that supersede an earlier interpretation while leaving every earlier record byte-identical.

1. Which anomaly class applies here, and which prior evidence records does it affect? classification
2. Which superseding assertion replaces the interpretation of an earlier record, and does that earlier record remain byte-identical? state
3. Was a key revoked or found compromised after the proof of existence, and does the retained evidence still support validity at that earlier instant? temporal
4. If a digest algorithm protecting this evidence becomes collision-prone, what migration was performed and what residual risk remains? security
5. How long must the affected proof bytes and prior validation records be retained after a supersession assertion, and who decides that? retention

Governance state and its separation from reported validation outcome

A proof record carries a governance state set by an accountable role - for example declared, in force, superseded, expired by policy, invalidated by compromise, or withdrawn. This is categorically not the cryptographic validation outcome. Validation indications such as TOTAL-PASSED, TOTAL-FAILED or INDETERMINATE with sub-indications, C2PA error, warning and informational status codes, or a Data Integrity verification result, are recorded as attributed observations from an external validator at a stated time, never recomputed or overridden here. A record may simultaneously hold an in-force governance state and an INDETERMINATE reported outcome; the model must be able to express that without collapsing the two.

1. Which governance states may a proof record occupy, and which state transitions are permitted? state
2. How is the governance state kept distinct from the externally reported cryptographic validation outcome? validation
3. At what event time did the current governance state take effect, and when was that state observed or ingested? temporal
4. Which role holds the authority to set or change the governance state of a proof record? authority

Immutable correction by supersession

A proof record is never edited in place for substantive content. A correction is expressed by issuing a successor record that references the record it replaces and by moving the prior record to a superseded state while keeping it resolvable. This mirrors ordered proof chains linked by previousProof, C2PA update manifests that document modifications while preserving prior provenance, and the X.509 superseded revocation reason. The superseded record retains its original pins, its original reported outcomes and its own supersession links, so an evidentiary chain can be reconstructed at any past point.

1. What conditions require a proof record to be superseded rather than corrected in place? constraint
2. How is the ordered link between a superseding record and the record it replaces expressed and resolved? relationship
3. Which reason code and supporting evidence justify each supersession? evidence
4. For how long must a superseded proof record remain resolvable after it has been replaced? retention

Controlled change of signing method and key reference

Records a governed change to the algorithm or cryptosuite identifier, hash, format profile, or the key or signing-service reference used for proofs created after the change. Each method identifier carries a transition status drawn from the cryptographic transition regime - broadly acceptable, deprecated, restricted to verification of previously generated signatures, or disallowed - together with the effective interval of that status. A transition imposes remediation obligations on already recorded proofs: re-sign under a current method, augment with long-term validation material and archive time-stamps, or accept as legacy verification-only. Key generation, custody and rotation execution belong to the cryptographic key model; only the reference and the change record are held here.

1. Which signing method identifier and version are in force, and which transition status applies to it? classification
2. What remediation obligation does a method transition impose on proofs that were already recorded? requirement
3. Who decided the method change, and on what documented basis was it decided? decision
4. Over what interval does a superseded method remain acceptable for verification of existing proofs only? temporal

Trust-anchor set, signature policy and jurisdictional regime pinning

Pins, by reference and version, the signature policy and validation policy that govern a proof, the trust-anchor or trusted-list set applicable at event time including the list's published version and status history, and any jurisdictional trust-service regime asserted to apply, with a jurisdiction code and an effective interval. Signature policies are authored and signed by a signature policy issuer and may contain applicability rules about business or legal fitness that go beyond technical validation constraints; this model pins them and never authors them. A pinned regime reference records that a regime was asserted, not that a legal conclusion holds.

1. Which signature policy and validation policy versions are pinned to this proof record? identity
2. Which trust-anchor or trusted-list set, at which published version, was applicable when the proof was created? provenance
3. Which jurisdictional trust-service regime is asserted to apply, and over what effective interval? spatial
4. How does a change to the pinned policy or anchor set affect proofs that were already recorded? lifecycle
5. What prevents a pinned regional regime reference from being read as a universal legal conclusion? constraint

Emergency compromise response record

Captures the reference to an externally declared compromise of a key, credential, algorithm or trust anchor, the reason code, the asserted invalidity time from which affected proofs are treated as suspect, the frozen set of proof records within the blast radius, the required response actions and the outcome reported by the executing party. Trusted time-stamps or a preserved long-term validation evidence set may mitigate the compromise for proofs demonstrably created before the invalidity time, so mitigation evidence is recorded alongside the scope. Revocation, key destruction, certificate reissuance and incident handling are executed by the key and PKI models under their own timelines; this model records the reference, the scope and the reported outcome.

1. Which external compromise declaration or problem report triggered the response, and who issued it? event
2. From which asserted invalidity time are affected proofs to be treated as suspect? temporal
3. Which proof records fall within the compromise blast radius, and how is that set computed and frozen? composition
4. Which response actions were required, and what outcome did the executing party report? process
5. Does a trusted time-stamp or preserved evidence set mitigate the compromise for proofs created before the invalidity time? evidence

Bounded acceptance exceptions, expiry and rollback

Records a time-boxed exception under which a proof that does not satisfy its pinned policy is nonetheless accepted for a stated and limited purpose - for example an INDETERMINATE outcome caused by unavailable revocation data, a stale revocation freshness constraint, or a method whose transition status has become verification-only. Every exception carries a mandatory expiry, a purpose limitation, a compensating condition, the approving authority and a defined rollback that restores the pre-exception governance state. An exception never alters the reported cryptographic outcome and never edits a pinned policy; it records a bounded governance tolerance of a known deficiency.

1. On what stated grounds may a proof failing its pinned policy be accepted, and for which purpose only? exception
2. What mandatory expiry and re-evaluation point bound the exception? temporal
3. Which authority approved the exception, and which roles were barred from approving it? authority
4. What rollback restores the pre-exception governance state, and what evidence proves it happened? lifecycle

Governance role separation and prohibited combinations

Names the distinct accountable roles over a proof record and binds each to a party reference: responsible owner, signature-policy authority, signer or signing operator, verifier, trust administrator, cryptographic custodian, reviewer or auditor, records authority, and the external legal-effect assessor. The core prohibition is that no single party may simultaneously hold signing authorization, cryptographic key custody, verification-policy authority and legal-effect assessment for the same proof record. Where an adopting Dimension is too small to separate them, the conflict must be recorded explicitly with a compensating control rather than silently collapsed. Party identity attributes, credentials and authorization enforcement remain in the identity and access models.

1. Which governance roles must be assigned for a proof record, and which are optional? ownership
2. How is each role bound to an accountable party without copying identity attributes into this model? identity
3. Which role combinations are prohibited, and what compensating control applies when separation is not achievable? security
4. Over what period did each role assignment hold, and what evidences a handover between holders? provenance

Review and approval evidence for governance decisions

Evidence that a governance decision - a method change, a policy or anchor pin, a supersession, an exception grant, or the closure of a compromise response - was reviewed and approved by a competent and independent role before taking effect. Records the inputs that were before the reviewer at decision time, the decision code, any dissent or conditions, the recorded-at time and a reference to the corresponding entry in the externally owned audit trail. This is decision evidence held on the record plane; it is not the audit trail, which is captured, stored, queried and retained by the audit model.

1. Which governance decisions require documented review before they take effect? requirement
2. Which inputs and reports were before the reviewer at the moment of decision? evidence
3. What competence and independence criteria must the reviewer satisfy? quality
4. How is a review record linked to externally held audit entries without reproducing them? relationship

Separable disclosure classes for proof information

Classifies the components of a proof record into independently governed disclosure classes: host content, signature or proof bytes, certificates and public keys, signer identity attributes, revocation and status evidence, and sensitive validation diagnostics. Public verifiability of a proof does not imply public access to the signed payload, and never implies access to signer identity attributes. Proof timing values and status endpoints can themselves leak information about a controller, so expiry and status references are classified in their own right. Diagnostics that reveal internal trust configuration, failure detail or scope lists are treated as sensitive by default. Each class is bound to an externally authored access policy; evaluation and enforcement occur in the access model.

1. Which components of a proof record are separately classifiable for disclosure? access
2. What rule prevents public verifiability of a proof from implying access to the signed payload? privacy
3. Which validation diagnostics are treated as sensitive, and on what stated ground? security
4. How is a disclosure class bound to an externally enforced access policy without embedding that policy here? interoperability

Retention, legal hold, evidence preservation and tombstone referencing

Binds a proof record to an externally owned retention schedule and to any legal hold or evidence-preservation order, states the obligation to preserve the evidence set needed to revalidate the proof after credential expiry - certificates, the revocation data current at signing, the trust path, trust verification records, policies and algorithm details, together with long-term validation material and archive time-stamps where an augmentation or preservation profile applies - and records a tombstone once disposition has been executed elsewhere. A proof record commonly outlives the system that produced it, so the preservation obligation is stated by reference to a preservation profile rather than by local copying. Physical erasure, backup expiry, audit-record retention and host-record deletion are executed and evidenced by the records, storage and audit models.

1. Which retention schedule governs this proof record, and which authority issued that schedule? retention
2. How is a legal hold or evidence-preservation order recorded, and what exactly does it suspend? constraint
3. Which validation evidence must be preserved so the proof remains verifiable after credential expiry? evidence
4. What minimum information survives in a tombstone after the referenced record has been disposed of elsewhere? lifecycle
5. Which model or party executes disposition, and what does this model record about that execution? ownership

Owner package, delegated authority and namespace binding

A WM-XCT-034 deployment is only governable when a single named owner package in the adopting Dimension is accountable for the mixin's configuration, and when every capability the mixin does not perform is bound by name and resolvable reference to the external system that does perform it. The specifications this model aligns with consistently push key management, trust establishment and acceptance policy outside their own boundary, so the owner package's principal duty is to declare those delegations rather than to reimplement them. The same package fixes the namespace under which local terms, vocabulary extensions and minted identifiers resolve, so that a term coined by one Dimension cannot silently collide with a governed IRI.

1. Which named owner package and steward role in the adopting Dimension is accountable for this WM-XCT-034 configuration, and how is that accountability reachable? ownership
2. Which external authorities are declared as owning key custody, signing authorization, cryptographic execution, certificate and trust-list operation, trusted time, audit storage, legal effect and retention enforcement? authority
3. What namespace and registry bindings must be declared before any local term, proof-purpose value or minted identifier is written into a record? requirement
4. Who decides that an owner-package, namespace or delegation change has occurred, and what is recorded at the moment of that decision? decision

Canonical form of the context record, distinct from cryptosuite canonicalization

Two canonicalizations exist and confusing them is the most common failure mode in this domain. The first is whatever transformation a cryptosuite or envelope applies to produce the bytes actually signed — a Sig_structure, a pre-authentication encoding, a JCS or RDFC-1.0 output — which is owned entirely by the referenced signature mechanism. The second is the canonical form of this model's own context record, needed so that digests, comparisons and hand-offs are reproducible. This finding fixes the second and forbids the model from asserting or recomputing the first. Both canonical forms must fail closed on inputs they cannot represent, and both must be bounded against adversarial inputs designed to make canonicalization expensive.

1. What exactly constitutes the canonical byte form of a WM-XCT-034 context record, and which algorithm identifier and version produced it? definition
2. Which inputs must cause canonicalization to terminate with an error rather than to produce a repaired or approximated output? constraint
3. How is the record's own canonical form kept separate from the canonicalization owned by the referenced cryptosuite or envelope? composition
4. What evidence shows that two independent implementations reach byte-identical canonical output for the same record? quality

Change sets, preconditions and compatibility classes

A signature context record changes for reasons that are not edits to signed material: evidence is captured later, a status reference is re-checked, an augmentation level rises, a delegation target moves. Change control must therefore permit the record to evolve while guaranteeing that nothing purporting to be signed bytes is ever mutated in place. Changes are expressed as atomic operation sequences with explicit preconditions so that concurrent stewards cannot silently overwrite each other, and each change is classified against a compatibility ladder that treats a canonicalization-profile change, an identity-priority change or a binding change as breaking rather than routine.

1. What are the permitted states of a WM-XCT-034 context record between initial capture and supersession, and which transitions require a recorded change set? lifecycle
2. How is a change set expressed, precondition-checked and applied so that partial application cannot occur? process
3. Which changes are prohibited outright because they would alter material that is bound by an existing proof? validation
4. How is a proposed change classified as additive, deprecating or breaking, and what must consumers be told in each case? classification

Identity priority and byte-fidelity integrity for proof and evidence artifacts

Signature domains offer many identifier-shaped values that are not identifiers: a key identifier is explicitly a hint for key selection, a digest is a content address that binds an attestation to an immutable subject, a serial number is unique only within its issuing authority, and a file name is a projection detail. Identity must therefore follow a strict ladder from authoritative master-system identifier through governed IRI to a Dimension-minted opaque identifier, with the minted case flagged as local. Integrity is equally strict: the octets handed to a consumer must be the octets whose digest was recorded, because re-parsing or re-serializing after verification is a known vulnerability class.

1. Which identifier does a given signature, proof or evidence artifact carry, and at which rung of the identity priority ladder was it obtained? identity
2. Which accompanying values are recorded as hints or content addresses and must never be promoted to identity? classification
3. What evidence demonstrates that stored proof octets and referenced evidence octets were not altered between capture and delivery? evidence
4. Where did each artifact and its identifier come from, and which system remains its system of record? provenance

Separation of signer-claimed time, trusted evidence time and observation time

A proof carries at least three unrelated kinds of time and merging them destroys the evidentiary value of all three. Signer-claimed time is an assertion inside the signed material and provides no assurance on its own unless its accuracy can independently be trusted; trusted evidence time is asserted by an external authority that attests only that a datum existed at a point in time, with its own policy, granularity and accuracy claim; observation or ingestion time is the adopting Dimension's own record of when it captured or last re-checked the material. This model records all three distinctly, preserves each authority's accuracy claim rather than rounding it away, and never computes a derived best time on its own authority.

1. Which distinct time values are attached to this proof context, and which party asserted each one? temporal
2. In what form is each recorded time stored so that offset, precision and accuracy are not lost? state
3. Which events cause a new time value to be recorded rather than an existing one to be updated? event
4. What are the declared limits on the precision and comparability of the recorded times, and who owns any authoritative time determination? measurement

Scope-differentiated access and bounded exceptions

A signature context record is not uniformly sensitive. Public credential material and algorithm identifiers are often intended to be widely readable; the secured payload may be confidential; identity attributes about a claimed signer are personal data; status and diagnostic material can leak organizational structure and verification behaviour; and unprotected header parameters are attacker-influenceable and must never be treated as authoritative merely because they arrived with a valid record. Access is therefore declared per scope — bundle, layer, finding and artifact — with distinct treatment for payload, proof octets, public credential material, identity attributes, status evidence and diagnostics. Exceptions exist but must be explicit, time-boxed and reviewable; issuing, enforcing and recording their use is the adopting Dimension's job, not this model's.

1. Which access class applies to each scope and material category within a WM-XCT-034 record? access
2. On what terms may an exception widen access beyond the default, and how does it end? exception
3. Which elements of a proof context are treated as personal or linkable data requiring minimization before disclosure? privacy
4. Which parameters must never be trusted for an access or acceptance decision merely because they accompany the record? security

AGENTS.md bootstrap contract and format-neutral projection binding

An agent must be able to enter a WM-XCT-034 deployment without prior knowledge of its container. A single mandatory AGENTS.md bootstrap record names the model, its kind, and the resolvable specification, storage-type, interface and process references, together with the registry identifier and the accountable owner. Because the same semantics may be projected into Git trees, plain files, an MCP interface, a document database or an embedded signature binding, and because each of those loses something — key ordering, byte fidelity, numeric precision, attachment linkage, opaque-octet handling — no projection is canonical and every projection must publish what it lost. Resolution is strictly ordered and fails closed: if a declared reference cannot be resolved or its integrity cannot be established, the agent stops rather than proceeding on partial context.

1. Which fields must the AGENTS.md bootstrap record carry before an agent may act on a WM-XCT-034 deployment? requirement
2. In what order are bootstrap references resolved, and what happens when one of them cannot be resolved or verified? process
3. Which fidelity losses does each supported projection introduce, and how are they reported to a consumer? interoperability
4. What is the relationship between a projection, the canonical record and the host record that the mixin is attached to? relationship
5. How long is a bootstrap record and its projection loss report kept, and which policy governs their disposition? retention

Current and as-of projections of attached proof state

A read returns the proof descriptors attached to a host record, either as at the read instant or as at an explicitly supplied historical point. The projection states which host version each proof commits to, whether the set is complete or access-filtered, and — for chains — the asserted order. The as-of basis (event time or observation time) is supplied by the caller and never inferred, because a proof's asserted creation instant and the instant the system observed it can differ.

1. Which proofs are attached to the host record version that is current at read time, and which host version does each proof commit to? state
2. What as-of instant does a historical projection use, and is it evaluated against event time or against observation time? temporal
3. Does the returned projection represent the complete proof set or an access-filtered subset? access
4. For a proof chain, what ordering does the projection assert and which proof does each entry name as its predecessor? composition
5. Is the projection reproducible for the same as-of input, and what marker makes it reproducible? quality

Proof presence and prior verification are not current validity

The rule set preventing the most common misuse of this mixin. An attached proof asserts only that some party produced a proof over a specific protected input using a specific method; it asserts nothing about the truth of the host content, the current standing of the signer, or the acceptability of the record to any relying party. A stored verification result is an observation bound to the instant and inputs at which it was taken, and is invalidated for reuse when any pinned input changes.

1. What exactly does the presence of an attached proof assert, and what does it deliberately not assert? definition
2. Is a stored verification result an assertion about the present or an observation bound to the instant and inputs at which it was made? evidence
3. Which changes to pinned inputs invalidate reuse of a prior verification observation? constraint
4. What must a consumer independently evaluate before relying on a proof-bearing record? decision

Exact payload version pin and protected input construction

Preparation resolves the host payload to one immutable, content-addressed version, applies a named and versioned deterministic transformation, and records the resulting protected input octets or their digest with the digest algorithm and length. The recorded value is the sole thing the executor may operate on. At attachment the protected input is recomputed from the same pinned version and must be byte-identical, which is what detects time-of-check-to-time-of-use drift.

1. What exact octet sequence or digest constitutes the protected signing input handed to the executor? measurement
2. Which canonicalization or transformation profile produced the protected input, and can an independent verifier reproduce it? interoperability
3. Which immutable host payload version does the protected input pin, and how is that version identified? identity
4. Is the payload detached, enveloped or embedded, and what externally supplied context is folded into the protected input? classification
5. How is drift between the prepared protected input and the host record at attachment time detected and handled? validation

Pinned proof configuration: algorithm, method, purpose, context and policy

The configuration the request fixes before any key is touched: the algorithm or cryptosuite and its parameters, the verification-method or credential reference that will validate the result, the proof purpose and the verification relationship it must match, the context bindings scoping the proof to one audience and occasion, and the policy and profile versions in force. Wherever the securing mechanism allows, this configuration is itself covered by the protected input, so a returned proof cannot silently claim a different algorithm or key.

1. Which algorithm or cryptosuite and which parameter set are pinned, and are they covered by the protected input? requirement
2. Which verification-method, key identifier or credential identifier is pinned, and does it resolve to exactly one key? relationship
3. What proof purpose is asserted, and does it match the verification relationship the pinned method is authorised for? authority
4. Which security domain, audience, challenge or presentation header binds this proof to its intended context and occasion? security
5. Which policy and profile versions are pinned so that executor and verifier evaluate the same rules? provenance

Correlated, expiring request to an external signing or proving executor

A request record binds one signing input manifest and one pinned proof configuration to one correlation identifier, one creation instant and one expiry instant. Dispatch is guarded by an expected-revision precondition and an idempotency key so retries after a network failure cannot produce a second signing operation or extend the validity window. Asynchronous operation requires an explicit response delivery reference and the same correlation identifier echoed back.

1. What request correlation identifier is issued, and how does the executor echo it so a response matches exactly one request? identity
2. When was the request created and when does it expire, and what clock and skew govern those instants? temporal
3. Which idempotency key makes a retried dispatch safe, and what is the defined result of replaying that key? process
4. Which request lifecycle states permit dispatch, and which expected-version preconditions must hold for the transition to be accepted? lifecycle
5. Is the operation synchronous or asynchronous, and where and over which authenticated channel is the response delivered? interoperability

Executor boundary constraints and minimum disclosure

The refusal rules applied at dispatch. Private key access, signer or prover authorization and cryptographic primitive execution stay wholly with the executor, whose module keeps keys non-extractable and may require authentication before each key use. Every reference in the outgoing payload must resolve to immutable, digest-pinned content: a mutable reference lets content change between the executor's fetch and the model's own pin, which is precisely the substitution the protected input exists to prevent. Disclosure is minimised to the digest wherever a digest suffices.

1. Which operations are asserted to remain wholly inside the executor's cryptographic module, and what records that assertion? ownership
2. Does every reference sent to the executor resolve to immutable content, and how is that immutability demonstrated? security
3. Who authorises the signer or prover to use the pinned key, and which system holds that decision? authority
4. What is the minimum data set the executor requires, and which host content is deliberately withheld? privacy

Admission checks on a returned proof

Before a returned proof may be attached, all of the following must hold: a dispatched, unexpired request record exists for the claimed correlation identifier; the recomputed protected input or digest equals the manifest value byte-for-byte; the declared algorithm, parameters and verification-method reference equal the pinned configuration; the context bindings equal the pinned values; the response arrived inside the validity window; and the nonce or challenge has not been seen before for this host and purpose. Any single failure refuses the whole proof. These are structural comparisons against recorded pins — cryptographic verification itself is executed elsewhere, and a passing admission is not a verification result.

1. Which checks must all pass before a returned proof is admitted, and what happens if any single check fails? validation
2. How is an unsolicited or duplicate proof detected and refused? exception
3. Do the algorithm, parameters and verification-method reference in the returned proof match exactly what was pinned? evidence
4. Did the response arrive inside the validity window, and does the nonce or challenge prevent replay onto another host version? temporal
5. What is recorded when a proof is refused, and where does the refused material go? retention

Append-only, host-bound attachment of an admitted proof

Attachment copies the pinned host payload version, adds the admitted proof to it and yields a new host-bound version; the payload itself is unchanged and no previously attached proof is altered. Proof octets are stored byte-exact and never re-encoded, re-indented or normalised in storage. The new proof joins either an unordered proof set or an ordered proof chain, where chain position is asserted by an explicit previous-proof reference rather than by storage order. Attaching the same admitted proof twice under the same idempotency key yields no second version.

1. How does attachment append a new host-bound version without mutating the host payload or any previously attached proof? process
2. Are the proof octets stored byte-exact and immutable after attachment, and what detects later alteration? quality
3. If the same admitted proof is attached twice, how many host versions result? state
4. Is the new proof joining an unordered proof set or an ordered proof chain, and which existing proof does it follow? composition
5. What does attachment explicitly not do to the host record's identity, approval state or trust standing? decision

Independent co-signature binding to a pinned payload version

An independent co-signature is a proof appended by an additional party that binds to the same pinned payload version and canonical byte form as its siblings, and to nothing else. Its validity is computed without reference to any sibling proof, membership in the set is unordered, and the failure of one member does not by itself invalidate another. The set is a recorded fact about topology, not a derived count.

1. Which pinned payload version, canonicalization method and digest does this co-signature bind to, and how is that binding recorded at signing time? identity
2. Is this proof a member of an unordered co-signature set rather than a position in a dependency-ordered chain, and what recorded evidence establishes that distinction? composition
3. Does verification of this co-signature depend on any sibling proof, and what does the set report when one member fails or is indeterminate? relationship
4. Under which declared proof purpose and verification-method or key reference did this participant sign, and where is that reference resolved? authority
5. How is the independence of this co-signature preserved when the set is projected into a different securing mechanism or serialization? interoperability

Dependency-aware countersignature binding to prior signature bytes

A countersignature binds to the exact byte sequence or digest of one named prior signature rather than to the payload alone, creating an explicit ordered dependency. The covered signature is unchanged by the act. A countersignature may itself be countersigned, so positions form an ordered chain in which an indeterminate or failed earlier position propagates to every later position.

1. Which exact prior signature bytes or digest does this countersignature cover, and is the covered object a signature value or the payload itself? composition
2. What ordinal position does this countersignature occupy in its chain, and by what rule is that order prevented from changing afterwards? constraint
3. If the covered prior signature is reported failed or indeterminate, what status must this position and every later position report? validation
4. Is the dependency expressed by covering the prior signature bytes or only by pointing at a prior proof identifier, and how is the difference in binding strength recorded? interoperability
5. What exactly does the countersigning party attest to: the existence of the prior signature, or the meaning of the underlying payload? definition

Required participant, dependency and threshold declaration

A declaration bound to a pinned payload version that names each required participation slot, its role and purpose, whether the slot is an independent co-signature or a dependency position, and a reference to the externally owned rule that decides when the requirement is met. The declaration states the requirement; it never states the outcome.

1. Which participants, roles or verification-method references are required, and is each required slot independent or part of a dependency order? requirement
2. Which external authority owns the threshold or signature policy rule, and which result artefact is the only acceptable evidence that the rule is met? authority
3. How is each slot classified with respect to purpose, so that a signature collected for one purpose cannot be counted against a slot declared for another? classification
4. Once the declaration is bound to a pinned payload version, may slots be added, removed or reordered, and what is required instead? constraint
5. How is the declaration itself protected against substitution, given that it defines who must sign? security

Per-member and per-dependency completion reporting without inference

A read-only projection over what has actually been recorded: for each declared slot and each dependency position, whether a proof has been collected, what status an external validator returned for it, and where evidence is absent, stale or contradictory. Satisfaction of a threshold, an authorization or a workflow approval is reported only when an external decision result explicitly states it, and is otherwise reported as indeterminate.

1. What is the recorded completion state of each declared slot and each dependency position at a stated observation time? state
2. How many slots are satisfied, unsatisfied or indeterminate, and why is that count alone insufficient to conclude that the requirement is met? measurement
3. Which external decision or validation result, if any, explicitly states that the requirement is satisfied, and where is that result referenced? decision
4. What evidence supports each per-member outcome, and what is reported when that evidence is missing, stale or contradicted by another source? evidence
5. How are participants reported whose identity is sealed, or whose contribution is attributable only in aggregate? exception

Idempotency and optimistic-concurrency preconditions for every mutation

No co-sign, countersign, invalidate or supersede operation is accepted without a caller-supplied idempotency key with a request fingerprint, and an expected-version token for the target. A replayed key with an identical fingerprint returns the first stored outcome without appending anything; a replayed key with a differing fingerprint is rejected; a stale expected-version token fails the precondition and is never merged.

1. Which idempotency key, request fingerprint and expected-version token must accompany a mutation before it may be accepted? process
2. What is the exact outcome when a key is replayed with a different fingerprint, and separately when the expected-version token does not match the current version? exception
3. When two participants co-sign concurrently, which attempt is serialized first and how is the second attempt preserved rather than lost? relationship
4. How is an accidental retry distinguished from a genuine second signature by the same participant over the same pinned payload version? quality
5. Which time is recorded for a replayed mutation: the instant of the first accepted attempt or the instant of the replay? temporal

Immutability of original proof bytes and earlier versions

The original byte sequence of every proof, and every earlier version record, are immutable once accepted. Change is expressed exclusively by appending a new version record. Nothing that was covered by a signature may be altered, and a detected mismatch between stored bytes and the recorded digest is reported as an integrity failure rather than corrected in place.

1. Which actor, method and time produced each retained version record, and how is the original byte sequence preserved unaltered across storage projections? provenance
2. Which fields may be appended to an existing record without breaking a recorded signature, and which may never change? constraint
3. How is a mismatch between stored bytes and the recorded digest detected and reported, and why must it never be repaired in place? validation
4. For how long are earlier version records retained, and what is preserved when a record is tombstoned? retention

Scoped, reasoned invalidation assertion

An appended assertion by an entitled party that a named scope should no longer be relied upon from a stated instant. The scope is exactly one of: the proof instance, the signer or key binding, the payload binding, or a named policy use. The assertion carries a coded and human-readable reason. It does not revoke a key or certificate, does not write a credential status list, does not delete content and does not alter the proof it concerns.

1. Which single scope does this assertion target: the proof instance, the signer or key binding, the payload binding, or one named policy use? classification
2. Who is entitled to assert invalidation for that scope, and what recorded evidence supports the entitlement? authority
3. From which instant does non-reliance apply, and does the assertion disturb conclusions that were reached before that instant? temporal
4. What does this assertion explicitly not do to the key, the certificate, any status list, the transparency log entry or the stored content? constraint
5. What triggering event or finding prompted the assertion, and how is the reason recorded so that a consumer can act on it? event

Supersession and correction link with effective interval

A directed, append-only link stating that one proof or proof version replaces or corrects another, with a reason distinguishing correction of an error from routine replacement, and an effective interval indicating when the superseding record is the one to rely on. Supersession does not by itself change the superseded proof's cryptographic validity; where non-reliance is intended, a separate invalidation assertion is required.

1. Which record supersedes which, and is the link a correction of an error or a routine replacement? relationship
2. Over which effective interval is the superseding record the one to rely on, and how are overlapping or gapped intervals reported? temporal
3. What derivation relationship holds between superseding and superseded content, and how much of the earlier content is carried forward? provenance
4. Does supersession by itself change the superseded proof's recorded validity, and what must be asserted separately if non-reliance is intended? state
5. How is the supersession link expressed when the underlying mechanism supports only re-registration under the same issuer and subject, with no explicit replacement pointer? interoperability

Verification run request and determinacy pins

The complete set of caller-supplied and defaulted inputs that make a verification run reproducible: the validation or as-of time, the exact payload and payload version the proof is asserted to cover, the trust anchor set and the snapshot of it that was consulted, the cryptographic suite policy including algorithm sunset dates, the maximum permitted age of status evidence, and the pinned identity of the evaluating tool and its data sources. Path validation inputs are parameterised and time-dependent (SRC-043) and constraint groups differ per policy (SRC-013, SRC-097), so an unpinned run cannot be re-derived or contested.

1. Which inputs must be pinned before a verification run is accepted as reproducible? constraint
2. Which exact payload version is the proof asserted to cover, and how is that version identified? identity
3. Which trust anchor set was consulted, and which snapshot of it applied at run time? provenance
4. Under whose cryptographic suite policy, and with which sunset dates, was this run evaluated? authority
5. What maximum age of certificate status evidence was permitted relative to the as-of time? temporal

Time basis and proofs of existence

Separation of the distinct time values a verdict can be anchored to: the claimed signing time asserted by the signer, the best-signature-time derivable from trusted evidence, the validation or as-of time, and the instants at which each evidence object was produced versus observed. Signature validity turns on key status at signing time rather than verification time, and that determination requires independent time evidence (SRC-003); proofs of existence are carried by time-stamp tokens and evidence records (SRC-009, SRC-066) and are what allow a signature to remain assessable after certificate expiry or revocation (SRC-061, SRC-097).

1. Which time value is this verdict anchored to, and why was that value selected? temporal
2. Which referenced objects establish that the proof existed before a given instant? evidence
3. How is an unproven claimed signing time kept distinguishable from a proven one? quality
4. When was each status or evidence object produced, and when was it observed and recorded here? provenance

Separated verdict dimensions and machine-readable reasons

A verification result is recorded as independent dimensions rather than a single verdict: cryptographic integrity of the proof over the bound payload; trust path to an accepted anchor; completeness of supporting evidence; conformance to the pinned policy including algorithm constraints; identity or attribution of the asserted signer; and legal conclusion. Each dimension carries its own status and reason codes drawn from a declared code system. Authoritative validation procedures already distinguish failure from indeterminacy and require a sub-indication explaining which condition was not met (SRC-061, SRC-095, SRC-013), and non-PKIX suites report verification alongside separate warning and error lists (SRC-004). The legal dimension is always recorded as not determined by this model unless an external authority record is referenced.

1. Which verdict dimensions are reported separately, and what exactly does each one assert? classification
2. Which machine-readable reason code and code system explains each non-passing dimension? interoperability
3. How may dimension results be combined, and what must never be inferred from a single dimension? decision
4. Who owns the legal conclusion about this proof, and what does this model record in its place? authority

Verification run record and report projection

The stored record of one verification: run identity, the digest of the pinned inputs, the dimension results, references to every evidence object consulted, the asserting party, and the start and end instants of evaluation. The record is an observation attributable to a party at a time, not a warrant of validity, and it is projected into report bindings for exchange. Standardised report structures carry the validation status, signer information, constraint evaluation, time information and the validation objects used (SRC-095); reference implementations show that a single run legitimately yields several non-equivalent report projections at different levels of detail (SRC-013, SRC-097).

1. How is a single verification run identified so it can be cited later without ambiguity? identity
2. Under what conditions, if any, may a stored run record be changed after it is written? lifecycle
3. What must a report projection of a run contain to remain self-describing away from its store? composition
4. Which party asserted this run, and under what declared competence or accreditation? ownership
5. How long must a run record stay retrievable to support later comparison and review? retention

Comparison of verification runs and change attribution

The disciplined comparison of two runs over the same proof and payload version, producing a per-dimension difference set in which each difference is attributed to a cause class: elapsed time and newly available proofs of existence, trust anchor set change, status evidence change, policy change, algorithm sunset, evidence added by preservation, or evaluating tool change. The earlier verdict is never overwritten or invalidated; it remains a true statement about the inputs that produced it. Cause classes follow directly from the parameters that authoritative procedures make variable (SRC-061, SRC-043, SRC-096, SRC-097).

1. Are these two runs comparable at all, and against which invariants was that decided? validation
2. Which cause class explains each dimension difference between the two runs? relationship
3. Why does a later run never overwrite or retract the earlier recorded verdict? state
4. How much of the observed change is attributable to non-cryptographic causes? measurement

Preservation evidence unit and renewal record

One unit of evidence added to keep a proof assessable: an archive time-stamp token, an evidence record with its archive time-stamp chains and sequence, collected validation material, or evidence returned by an external preservation service. Units are recorded append-only and never modify the original proof bytes. Two renewal kinds are distinguished because they cover different risks: re-stamping the previous time-stamp addresses signature-algorithm weakening, while re-hashing the data objects together with the prior evidence addresses digest-algorithm weakening and starts a new chain (SRC-066, SRC-067).

1. What guarantees that registering this evidence unit leaves the original proof byte-identical? constraint
2. Which renewal kind does this unit represent, and what does it re-cover? process
3. How does this unit chain to the evidence already recorded for the same proof? composition
4. Which external service produced this evidence unit, and under which declared policy? provenance
5. Which digest algorithm and canonicalization does this unit depend on for later verification? evidence

Evidence coverage and renewal-need assessment

A calculated, always re-derivable assessment of whether existing evidence still covers a proof: the interval currently covered, discontinuities in the chain, the sunset horizon of every digest and signature algorithm appearing in the chain under the pinned policy, and the latest date by which a further evidence unit must be obtained for coverage to remain unbroken. Renewal must occur before the relevant algorithm weakens (SRC-066), algorithm status changes over time and differs between generation and verification (SRC-096), and implementations distinguish hard failure from advisory warning around sunset dates (SRC-097). The assessment recommends; obtaining evidence is an external service action.

1. Through which interval is this proof currently covered by recorded evidence? temporal
2. Which condition would trigger a renewal recommendation, and at what horizon? event
3. Where are the discontinuities or weak links in the recorded evidence chain? quality
4. Which party is accountable for acting on a renewal recommendation? ownership

Export projection, access separation and loss register

Projection of a proof and selected evidence into a target binding, where authorisation to disclose the payload and authorisation to disclose signer identity are evaluated separately, every semantic the target binding cannot carry is enumerated in a loss register, and any unsupported critical semantic causes refusal rather than silent downgrade. The refusal rule follows the established treatment of unrecognised critical extensions as invalidating rather than ignorable (SRC-007); payload separation follows detached-payload practice (SRC-007) and the report-object model that carries validation objects independently of the signed document (SRC-095). An exported proof asserts nothing about its own verification: any verification statement must travel as a separately identified run record.

1. Which authorisation covers the payload in this export, and which covers signer identity? access
2. Which semantics are lost, approximated or renamed in the target binding? interoperability
3. Which unsupported critical semantics force this export to be refused outright? exception
4. What statement must accompany an export so that presence is never read as validity? definition
5. How is a detached payload referenced so the export stays verifiable at its destination? composition

Disposition readiness report

A reported readiness state for retiring a proof and its evidence, combining the host record's lifecycle state, the applicable retention rule reference, any active legal hold or disposition freeze, outstanding preservation obligations from an external preservation arrangement, and blocking inbound references such as evidence units or run records that depend on the proof. Disposal is a distinct lifecycle category with its own program and system requirements and its own freeze semantics (SRC-078); preservation arrangements impose their own obligation periods and their own deletion surface (SRC-072, SRC-098). This model reports conditions and never executes, authorises or schedules deletion.

1. Which conditions currently block disposition of this proof and its evidence? state
2. Which legal hold or disposition freeze applies, and which party owns it? authority
3. Which retention rule and which host record govern the retention period here? retention
4. What minimal reference must survive disposition so dependent records stay consistent? lifecycle
5. Which system executes the disposal, and which system records that it happened? process