§02b Jupiter — Certification & Attestation — The delta-attestation lifecycle

Mars® Spec › §02b Jupiter — Certification & Attestation › The delta-attestation lifecycle

← Certificate composition and N-hop certificates · Section index · Deployment manifest →

5. The delta-attestation lifecycle

The delta-attestation lifecycle is the foundational amendment-governance primitive for all registered artifacts in the Mars® architecture. It governs how a registered artifact — a governing specification, an analysis specification, an interpretation-generation specification, an actuation-interpretation specification, a cross-domain typed interface, a source registration record, a named-authority standing declaration, or any other registered artifact whose version identity is load-bearing — evolves over time, how that evolution is classified, and what cascade obligations that classification imposes on every downstream artifact and certificate that depended on the prior version.

Scope of application. The delta-attestation lifecycle applies to any registered artifact that: carries a version identity referenced by a downstream certificate, anchor, or scope record; is subject to amendment by a declared authority; and whose amendment changes the conditions under which downstream artifacts remain valid.

5.1 The delta-attestation object

The delta-attestation object is the typed, cryptographically-signed primitive emitted each time a registered artifact is amended. It is the unit of change in the lifecycle. No amendment to a registered artifact is effective without a corresponding delta-attestation object entering the specification registry.

The inventive matter is the co-presence of all seven declared properties, not their count or labeling.

(a) Prior-version identity. Content hash and version identifier of the artifact version being superseded.

(b) Amended-version identity. Content hash and version identifier of the artifact version being introduced.

(c) Structural-difference record. A typed enumeration of added, removed, and modified elements of the artifact between the prior and amended versions. For governing, analysis, interpretation-generation, and actuation-interpretation specifications: predicates, vocabulary terms, type signatures, scope conditions, falsifier annotations, reviewer-attested faithfulness anchors. For model artifacts: order decompositions, perspective constitutions, variant declarations, recomputation witnesses.

(d) Delta-classification field. One of four values — scope-preserving, scope-extending, scope-restricting, scope-breaking — computed from the structural-difference record by the declared classification function (§5.2). This field is not asserted by the amending authority; it is derived mechanically and is independently recomputable by any inspector against the structural-difference record.

(e) Joint-authority attestation hash. Recomputable from the distinct recorded attestation signatures of the doctrine authority (and both joint authorities where the artifact is jointly attested) signing over Fields (a)–(d) concatenated. A single-authority attestation hash is permitted only for artifacts originally registered under a single-authority attestation.

(f) Re-discharge schedule. The per-classification-class re-discharge requirements applicable to this amendment: the deadline (for scope-restricting), the opt-in window (for scope-extending), or the immediate-cascade declaration (for scope-breaking). For scope-preserving amendments: the null schedule. Deadline and opt-in window values are expressed as ISO 8601 durations or absolute UTC timestamps. A missing or malformed Field (f) on a scope-restricting or scope-extending amendment is treated as a conformance failure and the delta-attestation object is refused at registration.

(g) Cryptographic signature. Computed over Fields (a)–(f) concatenated. The minimum security level and admitted scheme families are declared in the registered versioned cryptographic-parameter artifact governing this deployment.

5.2 Classification function

The classification function maps the structural-difference record to one of the four delta-classification values. It is a deterministic function declared at deployment registration and independently recomputable by an inspector without internal inspection. The function operates exclusively on the structural-difference record — the enumerated set of added, removed, and modified elements with their element types — without reference to the natural-language meaning of those elements. Recomputability requires that every classification path be derivable from the structural-difference record alone.

Structurally-typed element classification. The structural-difference record enumerates changes by element type. The element types and their minimum permitted classification floor are declared in §5.3. The classification function applies the following structural rules, in priority order (highest priority first):

scope-breaking — triggered by any of the following structural conditions, each independently sufficient:
- any element of type predicate, type-signature, scope-condition, falsifier-annotation, or faithfulness-anchor-threshold is both added and removed (net change in the predicate set, not a pure addition or pure removal)
- any element of type type-signature is modified (field type, arity, or constraint changed)
- any element of type joint-authority-attestation is changed
- any element of type faithfulness-anchor-threshold is changed
- any element of type classification-function is changed (amendment of the declared classification function itself)
- the structural-difference record contains elements of mixed change direction (additions and removals co-present, regardless of element type)
scope-restricting — the structural-difference record contains only removals of elements or modifications that narrow element coverage (a declared parameter range narrowed, a scope condition tightened, a predicate element removed); no additions present
scope-extending — the structural-difference record contains only additions of elements; no removals or modifications present
scope-preserving — the structural-difference record contains only changes to elements of type editorial (changes that do not alter any predicate, type-signature, scope-condition, falsifier-annotation, faithfulness-anchor, or registered parameter value): formatting corrections, citation updates, natural-language rewording of non-normative prose where the compiled predicate set is unchanged

The classification function may not produce any value outside this enumeration. A classification function returning any value not in {scope-preserving, scope-extending, scope-restricting, scope-breaking} — whether by extension, qualification, or subdivision of these values — does not conform to this specification regardless of how the returned value is labeled or motivated.

Default to scope-breaking. Where the structural-difference record does not satisfy the conditions for scope-preserving, scope-extending, or scope-restricting under the rules above, the classification is scope-breaking. Ambiguity in the structural-difference record itself — including any element whose change direction cannot be determined from the record, or any element whose type is not declared in §5.3 — produces scope-breaking as the default. No classification path requires a judgment about natural-language meaning; any change that cannot be resolved by structural element type and change direction alone is scope-breaking.

The classification function may not produce scope-preserving for a change that alters any element of type predicate, type-signature, scope-condition, falsifier-annotation, faithfulness-anchor-threshold, or registered-parameter-value.

Classification function floor constraint. The element-type enumeration in §5.3 establishes a minimum floor on what the classification function must return. Any change touching a predicate, type signature, scope condition, falsifier annotation, or faithfulness anchor threshold cannot be classified below scope-restricting regardless of what the declared function produces for that change. A declared classification function that returns scope-preserving for a change in any of these element types is non-conforming and is refused at deployment registration. The floor is independent of the declared function’s other rules: the function may be otherwise valid and still fail this constraint. Non-conformance produces a typed refusal record identifying: the classification function identity, the element type that triggered the floor violation, the returned classification, and the minimum permitted classification.

5.3 Delta-classification decision table

Class	What triggers it	Cascade consequence	Deadline
scope-preserving	Only changes to elements of type `editorial` — no predicate, type-signature, scope-condition, falsifier-annotation, faithfulness-anchor, or registered-parameter-value element altered	No cascade record emitted; downstream artifacts under the prior version remain valid without re-discharge	None
scope-extending	Only additions of artifact elements without removals or restrictions	Cascade record emitted marked `optional`; downstream consumers may voluntarily re-discharge under the extended scope within the declared opt-in window; no required cascade	Declared opt-in window
scope-restricting	Only removals or modifications narrowing prior admissibility without additions	Cascade record emitted marked `required`; artifacts and certificates under the prior version are refused after the declared re-discharge deadline; operations referencing them are admitted until the deadline and refused after	Declared re-discharge deadline
scope-breaking	Any combination of additions and removals; type-signature changes; joint-authority attestation changes; faithfulness-anchor threshold changes; model-revision re-binding; completeness withdrawal; amendment of the declared classification function	Cascade record emitted marked `immediate`; prior-version artifacts and certificates are immediately invalidated; pending effects referencing prior-version artifacts via actuation anchors are refused emission	Immediate

5.4 Versioned re-discharge module

The versioned re-discharge module operates at every verification gate that processes artifacts emitted under an amended registered artifact. It refuses when any of the following conditions is met:

The delta-attestation object for the amendment is absent from the specification registry
The cryptographic signature (Field (g)) fails verification
The joint-authority attestation hash (Field (e)) fails recomputation from the recorded distinct authority signatures
The delta-classification field (Field (d)) fails recomputation from the structural-difference record by the declared classification function
The re-discharge schedule (Field (f)) has not been satisfied for the downstream consumer where required by the delta-classification class

No deployment configuration may declare monotonic non-cascade. Such configurations are rejected at deployment registration.

5.5 Cross-portfolio cascade

The delta-attestation lifecycle applies uniformly across every registered artifact class. Unless stated otherwise, scope-extending amendments produce optional cascade for all artifact classes; scope-preserving amendments produce no cascade.

Governing and analysis specifications. Scope-breaking amendments immediately invalidate all conformance certificates issued under the prior version. Scope-restricting amendments fire falsifier condition (e) and require re-attestation within the declared deadline. Scope-extending amendments do not invalidate prior-version certificates.

Non-language-provenance anchors (§02c). On scope-breaking: the anchor identity fields referencing the prior version are immediately invalidated; the predicate may not transit a downstream gate until re-derived and re-anchored under the amended version. On scope-restricting: the anchor remains valid until the re-discharge deadline. On scope-extending: the prior-version anchor remains valid throughout the opt-in window.

Scope-of-applicability certificates (§02c). Scope-breaking amendments cascade as immediate certificate invalidation. Scope-restricting amendments fire falsifier annotations within the affected scope, requiring re-discharge by the deadline.

Cross-domain typed interfaces (§02c). Amendment of either the source-domain or target-domain specification cascades through every registered interface referencing it. Scope-breaking amendments invalidate the interface’s joint-authority attestation hash, requiring re-bootstrap before cross-domain composition may proceed.

Actuation anchors (§02c). Scope-breaking and scope-restricting amendments to actuation-interpretation specifications refuse pending effects: actuation anchors referencing prior-version actuation-interpretation specifications are invalidated immediately (scope-breaking) or flagged for re-discharge by the deadline (scope-restricting).

Source registration records (§02e). A scope-breaking update triggers cascading revocation of all certificates issued under batteries that consumed signals from the prior-version source registration.

Extended artifact classes. The following registered artifact classes participate in the delta-attestation lifecycle with artifact-class-specific cascade semantics:

Formal domain models. Each domain model version carries its own registered artifact identity and its own delta-attestation chain; multiple domain models may be active simultaneously under the same deployment, each with an independent cascade scope. Scope-breaking amendment to a given domain model version immediately invalidates all analysis battery records, conformance certificates, and recomputation witnesses grounded in that prior-version model; artifacts grounded in other active domain model versions are not in the cascade scope of this amendment. Scope-restricting amendment emits a required cascade record scoped to the amended model version; affected certificates are refused after the declared re-discharge deadline. Where a generated formal specification was produced from a domain model, amendment to the domain model propagates through the specification’s delta-attestation chain before cascading to dependent certificates.
Data sources. Scope-breaking amendment invalidates all empirical-characterization reports and certificates whose declared scope cites the prior-version data source. Scope-restricting amendment emits a required cascade record with re-attestation deadline applicable to any certificate whose scope conditions cited data from the prior version.
Knowledge bases. Scope-breaking amendment immediately invalidates all certificates whose analysis battery record drew inferences from the prior-version knowledge base. Scope-restricting amendment triggers required re-discharge of affected certificates within the declared deadline.
Generation specifications. Scope-restricting amendment triggers a consistency determination for all Class B artifacts issued under the prior version: each affected certificate is classified as fully consistent, partially consistent, or fully inconsistent with the amended generation specification. Fully inconsistent certificates are immediately invalidated. Partially consistent certificates are re-issued under the amended version with shim artifacts declared in Field 1. Fully consistent certificates may continue under a re-discharge record. Scope-breaking amendment immediately invalidates all affected Class B certificates without consistency determination.
Benchmarks. Amendment triggers a per-case staleness check: each benchmark case is compared by content hash against the prior version. Cases whose content hash changes are marked stale; certificates that relied on stale cases are flagged with a staleness annotation in Field 6 and downstream consumers are notified. A certificate citing a benchmark version that includes stale cases is refused at the downstream gate unless the consumer declares explicit staleness-tolerance with scope conditions.
Model-behavior certificates. A model-behavior certificate is the registered, witness-bound record of a model’s characterization: the order-typed measures spanning multiple perspectives (safety, security, quality, cost — non-limiting), multiple orders (descriptive, prescriptive, procedural, higher-order), and multiple dimensions (non-limiting) that compose into a recomputable composite health judgment. The composite health judgment is a recomputable judgment — re-derivable by an independent inspector against retained witnesses carrying the per-measure anchors it inherits — not a scalar asserted without an anchor trail. A composite health judgment that cannot be re-derived from the measures and their witnesses is structurally incomplete and may not be registered as a model-behavior certificate. The model, its baselines, and its characterization are versioned under the delta-attestation lifecycle: each version of a model-behavior certificate carries its own delta-attestation chain; a characterization change is expressed as a delta-attestation object whose structural-difference record enumerates the changed measures and the changed composite judgment; the delta-classification is derived mechanically from that record under the same classification function as all other registered artifacts. Each model operation — probe, output validation, baseline update, drift check, model swap — is audited relative to the order-decomposition and bound to a recomputation witness; an operation not so bound is not a governed model operation and is not admitted as evidence in subsequent characterization acts. Any declared modification to the underlying model — detected by change in the model-weight hash, source-code hash, or training provenance record — requires a declared modification record to be filed before delta-classification may proceed. An undeclared modification (modification detected by hash change but no modification record filed) triggers immediate new-model treatment: all existing model-behavior certificates for that model are immediately invalidated; no delta-classification is available; fresh attestation under the amended model identity is required. This prevents undeclared optimization from bypassing the attestation discipline. Where the model is externally hosted and its weight, source-code, and training-provenance hashes are unobservable, undeclared modification is detected behaviorally: the externally-hosted model’s registration must declare a drift-equivalence threshold — a registered parameter defining the magnitude of order-structured drift (runtime finding class (iv)) against the recomputable baseline that constitutes detected undeclared modification for that model identity. A drift finding at or above the declared threshold carries the same consequence as a detected hash change with no modification record filed: immediate new-model treatment, invalidation of the model-behavior certificates, no delta-classification, fresh attestation under a new model identity. An externally-hosted model registered without a declared drift-equivalence threshold is structurally incomplete and is refused at registration. This closes the silent-vendor-update path: a hosted model whose behavior changes without a declared modification record is treated as a new model whether or not its internals are observable.
Governed-generation artifacts (§03-iv §2, §03-v §2.1). A dataset or model generated by a governed generation service — a service that generates analytical/statistical, probabilistic, or deep-learning models (including embedding models, large-language models, and other natural-language models) relative to one or more governing assets — is a registered artifact in the specification registry on the same terms as any other registered artifact. Each generated artifact carries: (i) its order-type — the orders it expresses relative to the governing assets; (ii) its asset-binding recomputation witness — a record from which an independent inspector re-derives the artifact’s provenance and conformance to the governing assets without deployment access; and (iii) its governed-service generation record — the registered, versioned, audit-emitting record of the generation operation that produced it. The governing assets relative to which generation proceeded are declared in the artifact’s registry entry; the asset-binding witness is the Field 7 equivalent for the generated artifact. Each generation operation is itself a registered, versioned act; amendment of a governing asset triggers cascade through all governed-generation artifacts whose registry entries declare that asset, under the same delta-attestation lifecycle rules as any other downstream artifact. A governed-generation artifact whose asset-binding witness cannot be re-derived by an independent inspector is structurally incomplete and may not be registered. A generation service that produces artifacts without registering them under these requirements is not a governed generation service and its outputs are not admitted as governed-generation artifacts in downstream analysis.
Runtime model-moderation findings. The following six runtime analyses each produce registered, witness-bound findings that participate in the delta-attestation lifecycle as governed-generation artifacts and feed the model-behavior certificate:

(i) Adversarial probing findings. Each adversarial probe campaign against an order-governed generated benchmark produces order-typed, recomputable findings bound to a witness. A probe finding is a registered artifact; its recomputation witness records the benchmark identity, the probe technique, the order-typed result, and the derivation from which an independent inspector re-derives the finding without deployment access. A probe finding that cannot be re-derived from its witness is structurally incomplete. The probe campaign is cost-governed: a probe or validation that would exceed the declared cost ceiling is refused before execution — no silent overrun. The cost-governed refusal is itself an order-typed, recomputable event bound to a witness.

(ii) Output-locus validation verdict. Output validation against a governing specification produces a mechanical, recomputable tri-state verdict {ADMIT / REFUSE / REFER} at the output locus. This verdict is the output-side twin of the pre-invocation admissibility verdict (§02e): the same order-governed, spec-relative, recomputable verdict structure applied at the output locus rather than the input locus. The output-locus verdict is a registered artifact carrying a recomputation witness from which an independent inspector re-derives the verdict from the output and the governing specification, without deployment access. The output-locus verdict is the output-side boundary artifact consumed by the actuation anchor (§02c §4) as its provenance basis: Field 1 of the actuation anchor’s originating-verification-record identity references the conformance certificate grounding this verdict, and the actuation anchor’s structural conditions are not satisfied absent a valid output-locus verdict in that chain. An output verdict produced by a learned classifier or statistical guardrail without a governing-specification binding and without a recomputation witness is not an output-locus validation verdict under this section; it is an unregistered signal and may not be carried in a model-behavior certificate as a governed finding, and may not satisfy the actuation anchor’s Field 1 requirement.

(iii) Recomputable behavioral baselines. A behavioral baseline is an order-typed, recomputable, witness-bound snapshot of a model’s behavior characteristics — response distribution, safety-score patterns, latency, output consistency, cost efficiency (non-limiting). The baseline is a registered artifact with its own delta-attestation chain. Baseline evolution is governed: a change to a registered baseline is a delta-attestation object whose structural-difference record enumerates the changed characteristics and whose delta-classification is derived mechanically. Baseline evolution distinguishes intentional change from degradation via the delta-classification and causal attribution; a baseline whose evolution is not governed by the delta-attestation lifecycle is structurally incomplete.

(iv) Order-structured drift findings. Drift detection — divergence of current behavior from the recomputable baseline — produces an order-structured, recomputable finding. The drift finding consumes the temporal-chain composition discipline (§02f §6) applied at runtime: per-observation order-typed analyses composed across time under the composition discipline, inheriting per-observation soundness anchors. A drift finding that is not order-structured and recomputable against the baseline and its retained witnesses is not a governed drift finding; a statistical alarm without an order-typed composition and recomputation witness is a known technique recited as substrate, not a governed finding under this section.

(v) Fail-closed cost gate. The cost ceiling is enforced as an order-governed, fail-closed, recomputable gate: an operation that would exceed the declared cost ceiling is refused, not silently overrun. The refusal is order-typed (the cost dimension is governed by the order-decomposition), recomputable (the cost attribution is re-derivable per model, per use-case, per operation), and witness-bound. A cost control that permits silent overrun — that does not refuse but instead permits the overrun and logs it — is not a fail-closed cost gate under this section. The fail-closed property and the recomputable cost attribution are jointly required; neither alone constitutes a governed cost gate.

(vi) Runtime sycophancy gate disposition. A sycophancy gate disposition is the registered, witness-bound result of evaluating a candidate model output before emission against an order-typed, domain-bracketed discrete sycophancy representation. The disposition is a tri-state {ADMIT / REFUSE / REVISE}: ADMIT where the sycophancy boundary is not crossed; REFUSE where crossed without an admissible revision; REVISE where a corrected, non-sycophantic candidate is generated or required. The gate disposition is distinct from the output-locus validation verdict (ii): the output-validation path evaluates conformance with a governing specification; the sycophancy gate evaluates the sycophancy boundary for the operative domain bracket. The two operate alongside each other at the output locus; neither subsumes the other. The sycophancy gate disposition is a registered artifact carrying a recomputation witness from which an independent inspector re-derives the disposition from the candidate output and the discrete sycophancy representation, without deployment access. The discrete sycophancy representation is dual-locus: the same representation used at the runtime gate is used at the post-hoc detection and scoring locus; the runtime disposition and the post-hoc score are governed by the same order-typed, domain-bracketed structure. An implementation that uses a different representation at the runtime gate than at the post-hoc locus does not satisfy the dual-locus property and its runtime gate is not a governed sycophancy gate under this section. A sycophancy mitigation that operates by training, prompting, or decoding intervention — without evaluating a candidate output against a discrete sycophancy representation at the output locus — is a known technique recited as substrate and is not a sycophancy gate disposition under this section. The sycophancy gate is the canonical species of the behavioral-condition gate genus (see Discrete behavioral-condition representations below): gates for other registered behavioral-condition representations — deception, capability concealment, objective gaming, or any registered condition — are governed by the identical structure and are not distinct architectures.

These six runtime finding classes are not independently implementable as separable embodiments from the order-governed, recomputable, witness-bound discipline declared here. An implementation that provides one or more of these capabilities without grounding them in registered, witness-bound findings under the delta-attestation lifecycle is not implementing governed runtime model moderation and its outputs are not admitted as governed findings in model-behavior certificates.
Generative-loop trajectory witnesses (§03-iv §2, §03-v §2.1). Where a governed-generation artifact is produced by a closed generative loop — a loop that co-generates a benchmark and a dataset relative to one or more governing assets, evaluates a candidate model against the generated benchmark to an order-typed result, and drives refinement from that result iteratively until a declared order-typed termination criterion is met — the artifact’s asset-binding recomputation witness is extended by a generative-loop trajectory witness: a per-iteration chain in which each link records the order-typed generation act (benchmark and dataset generated), the order-typed evaluation result against the generated benchmark, and the refinement decision that drove the next iteration. The trajectory witness is the record from which an independent inspector re-derives the entire model-creation trajectory — why each refinement followed each result — without trust in the deployment; a mismatch between the re-derived trajectory and the recorded trajectory flags an unsound loop. The trajectory witness is not a log of outputs; it is a causally-linked per-iteration derivation chain satisfying the same recomputability requirement as the asset-binding witness. A governed-generation artifact produced by a generative loop that does not carry a trajectory witness is registered as a single-generation artifact, not as a loop-produced artifact; its registry entry may not declare loop provenance. The trajectory witness and the asset-binding witness are jointly required for loop-produced artifacts; neither alone constitutes the recomputation witness for such an artifact.

Discrete behavioral-condition representations (genus). An order-typed, domain-bracketed discrete representation of a behavioral condition — a discrete model, condition, gate, rule, or boundary expressing a declared behavioral failure mode within a declared bracket — is a registered artifact in the specification registry. The genus is non-limiting over behavioral conditions. Declared species include: sycophancy (agreement at the cost of correctness), deception (assertion contrary to the model’s internally-derivable state), capability concealment (systematic under-performance relative to demonstrated capability), and objective gaming (satisfying a proxy objective while defeating its intent); additional behavioral conditions may be declared and registered without structural change to the mechanism. Every registered behavioral-condition representation carries the four registry fields defined below for the canonical species and is subject to the identical dual-locus invariance requirement and delta-attestation lifecycle. A runtime gate or post-hoc scoring locus for any behavioral condition that evaluates candidate outputs against a registered, order-typed, domain-bracketed discrete representation under dual-locus invariance is this architecture — renaming the behavioral condition does not produce a different architecture, and a behavioral gate implementing this structure under another condition name is governed by, and is not a design-around of, this section.

The sycophancy species (canonical). An order-typed, domain-bracketed discrete representation of a sycophancy condition — a discrete model, condition, gate, rule, or boundary expressing agreement at the cost of correctness within a declared bracket — is a registered artifact in the specification registry. Each registered sycophancy representation carries: (i) its bracket declaration — the domain, audience, order class, or other context partition scoping the representation; (ii) its order-type — the orders under which the sycophancy condition is expressed; (iii) its representation kind — one of symbolic, boolean, constraint, graph, automaton, or probabilistic-graphical; and (iv) a content hash binding the representation to its registry entry. The dual-locus invariance property is a registry requirement: the same registered representation — identified by its content hash — must be the representation used at both the post-hoc detection/scoring locus and the runtime gate locus. A deployment where the runtime gate uses a representation whose content hash differs from the registered post-hoc representation is a registry conflict under the same rules as a concurrent same-path certificate conflict (§3); the downstream gate treats the runtime gate disposition as unregistered and does not admit it as a governed sycophancy gate finding. Amendment of a registered sycophancy representation — changing its bracket, order-type, or discrete structure — is a delta-attestation event: scope-breaking amendment immediately invalidates all model-behavior certificates whose sycophancy gate dispositions reference the prior-version representation at either locus; scope-restricting amendment fires a required cascade with re-discharge deadline. A sycophancy representation whose dual-locus invariance cannot be verified by content hash comparison is structurally incomplete and may not be registered.

Named-authority standing declarations (§02c). Amendment narrowing authorized-actuation-classes or restricting scope-of-applicability produces at least a scope-restricting delta-classification on in-flight actuation anchors referencing that authority. Revocation produces scope-breaking delta-classification with immediate cascade.

Boundary-closure attestations (§02c). Coverage-narrowing amendments produce at least scope-restricting delta-classification. Model-revision re-binding or completeness withdrawal produces scope-breaking delta-classification, immediately invalidating the attestation and any downstream artifacts that depended on the prior boundary-closure scope.

5.6 Registry requirements for delta-attestation objects

Delta-attestation objects are registered in the specification registry as first-class artifacts. Registry requirements:

Content-addressable — every delta-attestation object is reachable by a deterministic identifier derived from its content hash
Append-only — no delta-attestation object may be modified or deleted after registration
Tamper-evident — any modification to a registered delta-attestation object is detectable
Linked — each delta-attestation object carries, in Field (a), the content hash of the prior-version artifact; the registry enforces that the prior-version artifact is itself registered
Ordered per artifact — for each registered artifact, the sequence of delta-attestation objects forms a linear chain from the initial registration to the current version, beginning with a genesis registration record. A fork — two delta-attestation objects both carrying the same prior-version identity — is a registry conflict and is refused at registration of the second object.

← Certificate composition and N-hop certificates · Section index · Deployment manifest →