Skip to content

§02a Jupiter — Base Analysis — Reverse-composition

Mars® Spec§02a Jupiter — Base Analysis › Reverse-composition

← Symbolic lift and order-typed representation · Section index · Verdict, gap analysis, and outputs →

6. Reverse-composition

Where a governing specification is not provided, the system composes a first-class governing specification from the available artifacts — domain model, knowledge base, data source, existing specification, or any combination. The composition is block-agnostic and count-agnostic.

Three explicitly-covered cases:

  • Composed from a data source alone — derived from its schema, types, keys, constraints, distributions, or statistics
  • Composed by combining two or more artifacts
  • Continuously maintained — because source artifacts may update, upsert, re-bind, or re-ingest, the composed specification may be continuously recomposed rather than derived once

The reverse-composed specification is first-class: analysis proceeds against it identically to a provided specification.

Witness form. Reverse-composition cases require a two-phase recomputation witness:

  1. Composition-process record — captures the derivation of the specification from the artifacts, formed independently of any governing specification (since none exists at composition time). This phase satisfies the binding obligation for the specification itself.
  2. Post-binding analysis record — captures subsequent analysis conducted under the composed specification. This satisfies the standard witness definition in §02b.

An implementation that provides only phase (ii) does not satisfy the reverse-composition binding requirement.

Version anchor for continuously-maintained specifications. A continuously-maintained reverse-composed specification must carry a version anchor: a content-addressed snapshot of the specification as of the analysis instant, bound to Field 2 as the governing-specification identity for that certificate. Subsequent maintenance does not alter the identity field of previously-issued certificates. The delta-attestation lifecycle (§02b) governs how scope changes propagate.

Superseded version and the composition-process record. A composition-process record (phase (i) of the two-phase recomputation witness) is anchored to the artifact versions from which the specification was composed at composition time. Where subsequent continuous maintenance produces a new version of the composed specification, the composition-process records of prior certificates remain anchored to the artifact versions used at their respective composition instants — they are not retroactively updated. The gap that requires addressing is when the prior composed specification version is superseded by a version classified scope-breaking under the delta-attestation lifecycle:

  • Scope-preserving update. The new composed specification version does not invalidate prior certificates. Prior certificates’ Field 2 still references a valid prior version; their composition-process records remain self-consistent. A downstream consumer may continue to rely on prior certificates within their temporal validity windows.
  • Scope-extending update. The new composed specification version does not invalidate prior certificates. Prior certificates remain valid for operations within their declared scope; downstream consumers may voluntarily re-certify under the extended scope within a declared opt-in window.
  • Scope-restricting update. The new composed specification version restricts the scope relative to the prior version. Prior certificates may over-attest under the new version’s scope. The delta-attestation lifecycle (§02b) triggers required re-certification: prior certificates are valid until their declared re-attestation deadline, after which they are refused. The composition-process record for each re-certified certificate is the two-phase witness from the re-composition at the new version’s artifact snapshot.
  • Scope-breaking update. The new composed specification version breaks prior scope — prior certificates are immediately invalidated by falsifier condition (e). The composition-process records of invalidated certificates do not become invalid on their own terms — they correctly describe the derivation of the prior version — but they no longer anchor a valid governing specification for new operations. Any operation requiring a valid current certificate must obtain one under the new composed specification version. The invalidated certificate is retained in the registry as a historical record; it is not deleted.

Composition lineage and self-reference refusal. A reverse-composed governing specification carries a composition-lineage record enumerating, by content hash, every artifact from which it was composed. Analysis of a target artifact against a reverse-composed specification whose composition lineage includes that target — or data derived from it — is refused, or is emitted only as a typed self-referential verdict class expressly excluded from conformance semantics: an artifact cannot be certified against a specification derived from itself, the circularity otherwise rendering every source artifact trivially conforming.

Candidate status and authority adoption. A reverse-composed specification is a candidate until adopted by a recorded act of an authority having declared standing (§02c §7); only an adopted specification is a governing specification for certification purposes. The adoption act, adopter identity, and standing reference are recorded in the specification’s bootstrap provenance. Comparison and drafting uses require no adoption.

Scope. Reverse-composition is distinct from the domain seed (modeling layer). The domain seed produces a formal model; reverse-composition produces a governing specification from analytical artifacts. The formal model is one of the artifacts from which a governing specification may be reverse-composed; the two operations compose.

Uses include: producing a specification where none exists; comparing a composed against a provided specification to surface divergence; presenting candidate specifications for operator selection, editing, or approval; continuously recomposing or maintaining the specification as its source artifacts change.



← Symbolic lift and order-typed representation · Section index · Verdict, gap analysis, and outputs →