§02b Jupiter — Certification & Attestation — Deployment manifest

Mars® Spec › §02b Jupiter — Certification & Attestation › Deployment manifest

← The delta-attestation lifecycle · Section index · ON_CHAIN_ANCHOR — verification-gated distributed-ledger commitment →

6. Deployment manifest

6.1 Purpose and role

The deployment manifest is the versioned registered artifact that closes the open-variable gap in the Mars® architecture. Every section in Jupiter and Minerva that delegates a behavior to “the operator” or “deployment registration” is delegating to a field in the deployment manifest. The manifest is the artifact an inspector pins a certificate against: to verify that a certificate was produced under a conforming and correctly-configured deployment, the inspector retrieves the manifest version in effect at issuance and re-derives the deployment’s declared behavior from it.

The manifest is a versioned envelope — it does not inline the declarations of its components but holds typed references to a set of independently registered and delta-attested sub-records. Each sub-record has its own version identity and its own amendment lifecycle. The manifest version is the co-version of all sub-record versions in effect at a given point in time. A certificate carries the manifest version under which it was issued; the inspector retrieves that manifest version and from it retrieves each sub-record version.

A deployment without a registered conforming manifest is refused at deployment registration. A certificate issued under a deployment with no manifest record, or under a manifest version that has been revoked, is structurally deficient and is not admitted at any downstream gate.

6.2 Manifest envelope

The manifest envelope is a registered artifact enrolled in the delta-attestation lifecycle (§5). Its fields:

Field	Content	Required
Manifest identity	Stable content-derived identifier for this manifest version	Always
Version	Version identifier; enrolled in the delta-attestation lifecycle; a genesis registration record is produced at initial deployment registration	Always
Governing selector reference	Identity and version of the governing selector record (§6.4.1)	Always
KB selector reference	Identity and version of the KB selector record (§6.4.2)	Always
Data source selector reference	Identity and version of the data source selector record (§6.4.3)	Always
Battery selector reference	Identity and version of the battery selector record (§6.4.4)	Always
Runtime configuration record reference	Identity and version of the runtime configuration record (§6.5)	Always
Classification function record reference	Identity and version of the declared delta-classification function (§5.2)	Always
Effective-date range	ISO 8601 start and end timestamps for this manifest version	Always
Cryptographic signature	EUF-CMA-secure signature over all fields above	Always

A manifest envelope missing any field is refused at deployment registration with a typed structural diagnostic identifying the missing field.

6.3 Selector record schema

A selector record is the uniform typed schema for all four selector roles in §6.4. Each selector record is an independently registered artifact enrolled in the delta-attestation lifecycle. Its fields:

Field	Content	Required
Procedure identity	The registered typed routine that performs the selection; version-bound; enrolled in the delta-attestation lifecycle; independently recomputable by an inspector	Always
State surface declaration	Typed schema of the internal state the procedure reads at selection time; empty schema declares a pure selector — the procedure is fully determined by its version and the operation context alone	Always
Selection event log reference	Identity of the selection event log artifact (§6.3.1) associated with this selector record; the log is a separate registered append-only artifact	Always
Reproducibility contract	Typed declaration: `pure` (inspector reproduces selection from procedure version + operation context alone) or `state-dependent` (inspector reproduces from procedure version + operation context + state snapshot from the selection event log); must be consistent with the state surface declaration — a non-empty state surface with a `pure` contract is refused at registration	Always

A pure selector satisfies this schema with an empty state surface declaration and a pure reproducibility contract. An adaptive or stochastic selector satisfies it by populating the state surface schema and declaring state-dependent. A deployment may mix pure and adaptive selectors across the four selector roles; each role is governed by its own selector record independently.

6.3.1 Selection event log

The selection event log is a separate registered artifact pointed to by the selector record. It is an append-only log; each entry is content-addressed and carries:

Field	Content
Operation context	The typed operation context presented to the selector procedure at selection time
State snapshot	Snapshot of the selector procedure’s declared state surface at selection time; empty for pure selectors
Selected artifact identity	The identity and version of the artifact selected by the procedure for this operation
Selection timestamp	UTC timestamp of the selection event
Entry content hash	Content hash of this entry; entries form a hash chain within the log

Retention policy. Selection event log entries must be retained for the lifetime of every certificate issued under the manifest version that references this selector record, plus a mandatory minimum post-revocation tail of 7 years from the date the last such certificate is revoked. The operator may declare a longer retention window in the runtime configuration record (§6.5); a declared window shorter than the mandatory minimum is refused at deployment registration with a typed diagnostic. A manifest version whose selection event log entries are no longer available within the required retention window is a registry conformance failure.

6.4 The four selector roles

Each selector role maps operation context to a declared artifact or configuration. The mapping is performed by the registered typed procedure in the selector record. The inspector reproduces the mapping by re-running the procedure against the recorded (operation context, state snapshot) pair from the selection event log.

6.4.1 Governing selector

Maps: operation context → active governing collection version (§01 §12.1).

The governing selector is the mechanism by which the deployment declares which domain models and formal specifications govern a given operation. The selected artifact is always a registered governing collection version — not a bare domain model or formal specification. A governing selector that resolves to an unregistered artifact identity is non-conforming and produces a structural refusal at the gate.

The governing selector may be pure (static mapping from operation class to governing collection version) or adaptive (routing based on operation context features, historical outcomes, or other declared state). In both cases the selected governing collection version is a registered artifact and the selection is replayable from the selection event log entry.

Constraint. A governing selector may not select an artifact that is not enrolled in the delta-attestation lifecycle. A selection event that resolves to a governing collection version that has been revoked or superseded without re-discharge produces a gate refusal with a typed diagnostic identifying the revoked version and the outstanding re-discharge obligation.

6.4.2 KB selector

Maps: operation context → active knowledge base(s) and merge policy.

The KB selector declares which knowledge bases participate in a given operation and, where multiple KBs are active, the merge policy governing their combination. The selected merge policy is a registered artifact (§03-ii §3.4); the selected KB identities are registered KB artifacts. A KB selector that resolves to an unregistered KB identity or an undeclared merge policy is non-conforming.

Where the KB selector is adaptive — routing to different KBs based on operation context features or learned state — the state snapshot in the selection event log carries the KB routing decision and its basis. The inspector re-derives the routing from the recorded state snapshot and confirms that the KBs used in the operation’s analysis battery record match the selected set.

6.4.3 Data source selector

Maps: operation context → active data source(s).

The data source selector declares which data sources are active for a given operation. The selected data source identities are registered artifacts. A data source selector that resolves to an unregistered data source identity is non-conforming.

The same pure/adaptive distinction applies. An adaptive data source selector that routes based on data freshness, availability, or learned relevance scores must declare its routing criterion in the state surface declaration and capture its state snapshot in the selection event log at each selection event.

6.4.4 Battery selector

Maps: operation context → analysis battery configuration.

The battery selector declares the full analysis battery configuration for a given operation, comprising:

Aggregation function identity and version (§02a §4)
Convergence criterion: threshold type and value for probabilistic IR promotion (§02a §4b)
Divergence threshold, if declared (§02a §4)
Path-exploration strategy and bounding parameters (§02a §5a.5)
Cross-phase corroboration contribution weight, if applicable (§02e §6)
Confidence floor per actuation class, if applicable (§02a §3a.5)
Normalization procedure identity and version (§02a §3a.5)

Each of these sub-fields is a typed declaration. The selected battery configuration must be consistent with the analysis battery record carried in the certificate’s Field 7 recomputation witness. An inspector confirms consistency by retrieving the battery selector’s selection event log entry for the operation and verifying that the battery configuration declared there matches the configuration recorded in the analysis battery record.

6.5 Runtime configuration record

The runtime configuration record is a registered artifact enrolled in the delta-attestation lifecycle. Unlike the selector records, it contains pure declarations — typed values with no selection procedure. Its fields:

Field	Content	Required
DDIL behavior	Per-condition declaration for each DDIL state (Disconnected, Degraded, Intermittent, Limited): `fail-immediately` or `pause-and-retry`; must cover all four DDIL state values	Always
Registry unreachability behavior	`fail-immediately` or `pause-and-retry` for each of the registry unreachability cases governed by the registry unreachability discipline (§3); must be consistent with DDIL behavior	Always
Partition-recovery bounds	Declared handshake bound (≤ 2 seconds) and consistency-recovery bound (≤ 60 seconds); values within these bounds are the deployment’s operative constraints	Always
Escalation depth maximum	Maximum number of escalation hops for authority-reconcile gap escalation (§02a §7); a positive integer; no escalation chain may exceed this depth	Always
Merge procedure reference	Identity of the registered deterministic merge procedure governing post-partition specification merge (§02a §3a.3); must be declared and registered; non-deterministic merge procedures are refused at registration	Always
Gap-referral routing targets	Per-gap-class typed mapping from gap class to registered gap-referral routing target; must cover all gap classes declared in §02a §7 and any operator-declared gap classes registered under the gap taxonomy	Always
Capability advertisement set	Typed set of declared capability identifiers (non-limiting: `AUTHORITY_RECONCILE/1.0`); each declared capability is subject to the upward strict-stronger rule — a deployment declaring a capability must implement every requirement of that capability without exception	Always
Self-attestation independence policy	Declares whether verifier independence is required for this deployment; where declared, certificates with coincident verifier and target identities are refused (SC8)	Always
AIGP substitution declarations	Where AIGP is not deployed, typed declarations of the substitutes satisfying each of the four AIGP-provided inputs; must be complete — a deployment without AIGP and without complete substitution declarations is refused at registration (E5)	Where AIGP is absent
Retention window override	Operator-declared retention window for selection event logs; must be ≥ certificate lifetime plus 7 years post-revocation; a declared window below the mandatory minimum is refused at registration	Optional
Conflict default	The declared default resolution behavior for governing-conflict gaps that have no registered resolution procedure reference at the time the conflict is detected; selected from the registered resolution mechanism taxonomy (§01 §12.4)	Always
Calibration response mode	Declares the certificate issuance behavior when the calibration attestation gate (§02a §5a.6) finds a miscalibrated class: `fail-closed` (refuse certificate issuance until miscalibration is resolved) or `flag-and-continue` (emit certificate with narrowed Field 5 scope and Field 6 falsifier annotation); default is `flag-and-continue` where not declared; a declared value of neither `fail-closed` nor `flag-and-continue` is refused at deployment registration	Optional (default applies if absent)
Re-calibration window	The maximum duration from a miscalibration finding to a resolved calibration record under an amended manifest version, before the Field 6 falsifier annotation fires; expressed as an ISO 8601 duration; must be declared where `calibration response mode` is `flag-and-continue`; a missing re-calibration window under `flag-and-continue` mode is refused at deployment registration	Required where `flag-and-continue`

6.6 Amendment lifecycle

The deployment manifest and each of its sub-records are enrolled in the delta-attestation lifecycle (§5). Amendment classification follows the four-valued schema:

Scope-breaking amendments — immediate cascade; all certificates issued under the prior manifest version are invalidated:

Change to the governing selector procedure identity or state surface declaration
Change to the KB selector procedure identity or state surface declaration
Change to the data source selector procedure identity or state surface declaration
Change to the battery selector procedure identity, or change to any battery configuration sub-field that alters the set of conformance questions the battery evaluates
Change to any runtime configuration field that alters gate behavior (DDIL behavior, registry unreachability behavior, partition-recovery bounds, merge procedure, conflict default)
Change to the classification function record reference

Scope-restricting amendments — required re-discharge with declared deadline:

Narrowing of any selector’s eligible output set (e.g., removing a governing collection version from the selector’s reachable output range)
Narrowing of any capability advertisement (removing a declared capability)
Tightening of partition-recovery bounds below prior declared values

Scope-extending amendments — optional re-discharge within declared opt-in window:

Widening of any selector’s eligible output set
Adding a capability advertisement
Relaxing partition-recovery bounds above prior declared values

Scope-preserving amendments — no cascade:

Changes to the retention window override (upward only; downward is scope-restricting)
Editorial changes to field values where the operative behavior is unchanged
Adding AIGP substitution declarations where none were required previously

No deployment configuration may declare monotonic non-cascade on manifest amendments. Such configurations are refused at deployment registration. This prohibition applies to the manifest and all its sub-records.

6.7 Admission gate

A deployment is refused at deployment registration under any of the following conditions:

No manifest record is present
The manifest envelope is missing any required field
Any selector record is missing any required field, or its reproducibility contract is inconsistent with its state surface declaration
The runtime configuration record is missing any required field, or any field value violates its declared constraint (e.g., partition-recovery bounds exceed the normative maximum)
Any selector record’s procedure identity is not a registered artifact enrolled in the delta-attestation lifecycle
A declared capability advertisement is not fully implemented (upward strict-stronger rule violation)
A declared monotonic-non-cascade configuration is present on any manifest component
A declared AIGP substitution is incomplete where AIGP is absent
A declared retention window override is below the mandatory minimum

Each refusal carries a typed structural diagnostic identifying the specific condition, the manifest component, and the field that triggered the refusal.

6.8 Inspector protocol

To verify that a certificate was produced under a conforming and correctly-configured deployment, an inspector executes the following steps in order:

Retrieve manifest version. From the certificate’s Field 3 (certification-path record), retrieve the manifest version in effect at certificate issuance. Confirm the manifest version is registered and non-revoked.
Verify manifest envelope. Confirm all required fields are present. Verify the cryptographic signature over the envelope fields. Confirm the effective-date range covers the certificate issuance timestamp.
Verify governing selector. Retrieve the governing selector record version referenced by the manifest. Retrieve the selection event log entry for this operation. Re-run the selector procedure against the recorded (operation context, state snapshot) pair. Confirm the selected governing collection version matches the governing-specification identity in the certificate’s Field 2.
Verify KB selector. Retrieve the KB selector record version. Retrieve the selection event log entry for this operation. Re-run the selector procedure against the recorded (operation context, state snapshot) pair. Confirm the selected KB identities match the KB identities carried in the certificate’s Field 7 recomputation witness.
Verify data source selector. Same protocol as KB selector; confirm against data source identities in the recomputation witness.
Verify battery selector. Retrieve the battery selector record version. Retrieve the selection event log entry. Re-run the procedure. Confirm the selected battery configuration matches the analysis battery record in the certificate’s Field 7 recomputation witness, field by field across all battery configuration sub-fields.
Verify runtime configuration. Confirm the runtime configuration record values are consistent with the gate behaviors observable in the audit record for this operation (DDIL behavior, registry unreachability handling, partition-recovery bounds where applicable).
Verify classification function. Where the certificate was issued after a delta-attestation event, retrieve the classification function record, apply it to the structural-difference record of the relevant amendment, and confirm the delta-classification matches the delta-attestation object.
Confirm retention availability. Confirm that selection event log entries for this operation are available and within the mandatory retention window.

A certificate that fails any inspector protocol step is not admitted. The failure produces a typed inspection record identifying the step, the manifest component, and the specific verification failure.

6.9 Observable properties

Property	Observable condition
DR1 — Manifest present and conforming at registration	Every registered deployment carries a manifest record; a deployment without a manifest is refused at registration; the refusal carries a typed diagnostic
DR2 — Selector procedure reproducibility	For any selection event log entry, an inspector re-running the selector procedure against the recorded (operation context, state snapshot) pair reproduces the selected artifact identity; a procedure that produces a different selection on re-run under identical inputs is observably non-conforming
DR3 — State surface completeness	For a state-dependent selector, every input the procedure reads at selection time is covered by the state surface declaration and is present in the state snapshot; a procedure that reads undeclared state is observably non-conforming because the inspector cannot reproduce the selection from the recorded snapshot
DR4 — Governing selector constraint enforcement	A governing selector that resolves to a revoked or unregistered governing collection version produces a gate refusal with typed diagnostic; no certificate is issued under an unregistered governing artifact
DR5 — Battery configuration consistency	The battery configuration declared in the battery selector’s selection event log entry for an operation matches the analysis battery record carried in the certificate’s Field 7 recomputation witness; a mismatch is independently observable by an inspector without deployment access
DR6 — Runtime configuration gate enforcement	Submitting an operation under DDIL conditions produces the behavior declared in the runtime configuration record (fail-immediately or pause-and-retry); no deployment configuration may produce behavior inconsistent with its declared runtime configuration
DR7 — Manifest amendment cascade	A scope-breaking amendment to any manifest component produces immediate cascade invalidation of all certificates issued under the prior manifest version; an inspector observing the audit trail confirms cascade records are present within the declared retention window
DR8 — Retention window enforcement	Selection event log entries for any operation covered by a non-revoked certificate, or within 7 years post-revocation, are retrievable by an inspector; a deployment that has purged selection event log entries within the mandatory retention window is observably non-conforming
DR9 — Downward retention override refused	Submitting a manifest with a retention window override below the mandatory minimum (certificate lifetime plus 7 years post-revocation) is refused at deployment registration with a typed diagnostic
DR10 — Monotonic-non-cascade configuration refused	Submitting a manifest or any manifest sub-record declaring monotonic non-cascade is refused at deployment registration with a typed structural diagnostic identifying the rejected declaration

← The delta-attestation lifecycle · Section index · ON_CHAIN_ANCHOR — verification-gated distributed-ledger commitment →