§02d Jupiter — Discrete Composition — The composed discrete program
Mars® Spec › §02d Jupiter — Discrete Composition › The composed discrete program
← What this layer covers · Section index · The model-as-map layered architecture →
2. The composed discrete program
The composed discrete program is the result of composing two or more discrete representations — each independently formed under the order-shape contract (§02a §5) — into a single executable program that operates over the combined order structure. The composition is order-governed: only representations satisfying the order-shape contract for compatible orders may be composed.
2.1 Formation inputs and the order-shape contract
Inputs. A discrete representation may be formed from any combination of governing-ground-truth artifacts — domain model, governing formal specification (lowered from a domain model), knowledge base, or data source — including from a data source alone. The formation method is unrestricted: deterministic, interpretive (including natural-language processing or a language model), or hybrid. What the formation produces — the order-governed, witness-bound representation — is the governed matter, not the formation mechanics. Where formation employs an interpretive or non-deterministic method, the recomputation witness takes the form of a justification record (which source elements under which orders yielded which structure); where deterministic, a replay record; either or both may be produced.
Data-source-alone formation. Where the input is a data source alone, formation proceeds by semantic analysis of the source’s tables, collections, or schemas and by data sampling, instantiating orders from the source’s schema, keys, constraints, and sampled content. Three formation regimes are recognized, usable alone or in combination: (a) the order-decomposition itself serves directly as the map governing formation, the data source’s schema and constraints supplying the content that instantiates the orders; (b) a minimal domain model is first derived from the data source and thereafter serves as the map; and (c) where semantic analysis is not possible or the domain is unknown or without specification, an emergent observation-driven regime applies in which order-typed structure is promoted from patterns observed over the data, the emergent structure being order-typed and witness-bound. Regime (c) is the disclosed fallback for the stated conditions. All three regimes are governed by the same order-shape contract and produce representations subject to the same composition witness requirements; they are not independently operable outside the order-governed, audit-bound formation architecture.
Order-shape contract (function follows form). Each order is specified by an order-shape specification that determines the structure produced for content of that order. The order owns its content; all members of an order share the order’s structural shape; and the shape is functional, not arbitrary — the shape is the behavior discipline. The representation kind (symbolic, boolean, constraint, graph, automaton, probabilistic-graphical, or any other formally-evaluable form) is the carrier realizing the order shape. The output structure is therefore invariant across representation kinds: the structure is the order shape; the kind is only its realization. This “function follows form” discipline is the mechanical basis of composition compatibility — two representations are composable at a shared order because the order shape, not the representation kind, governs the unification.
2.2 Composition requirements
Order compatibility. Two discrete representations are composable by order when they share one or more orders in common — that is, when both representations contain owner-sets governed by the same order. The shared order is the composition locus: the composition proceeds by identifying the owner-set for that order in each representation and asserting their structural identity.
The composition does not merge representations by flat union or concatenation. It produces an order-governed join: for each shared order, the representation elements from both inputs that belong to that order’s owner-set are unified under the order’s shape specification. The result is a single owner-set for that order in the composed program, populated from both sources and uniformly shaped under the order’s specification.
Non-shared orders are preserved. Orders present in one representation but not the other are carried into the composed program unchanged. The composed program’s order structure is the union of the order structures of its inputs; no order is dropped in composition.
Composition is not transitive by default. Composing A with B and then composing the result with C is not the same as composing A, B, and C simultaneously unless all three share orders that are pairwise compatible. Where the composition sequence is order-dependent, the declared composition sequence is carried in the composition witness (§2.4).
2.3 Structural requirements on the composed program
A composed discrete program must satisfy the order-shape contract at the composed level, not only at the constituent level. That is: in the composed program, structural uniformity within each order’s owner-set is enforced across all contributing representations. A composition that satisfies the contract in each constituent but not in the composed result does not produce a valid composed discrete program.
Reuse without limitation. A composed discrete program, once formed, may be consumed by any number of downstream consumers without re-derivation. The composition is infrastructure-agnostic: it does not depend on any trust relationship between the composing deployment and the consuming deployment. A consumer of the composed program verifies it against its composition witness (§2.4); no trust in the composer is required.
Composed program as governing specification. Where no specification is provided as an input, the composed discrete program may serve as, or be used to compose, a governing specification, bound to and recomputable from its source artifacts by the composition witness. This is not an alternative architecture — it is the same order-governed composition producing a specification-class artifact instead of consuming one; it is governed by the same composition requirements and the same witness obligations.
Emergent outputs. A composed discrete program may produce analysis outputs that neither constituent program would produce in isolation. These emergent outputs are order-typed: each emergent finding is attributed to one or more orders and is bound to its sources by the composition witness. An emergent output that cannot be attributed to a specific order — that arises from the join in a way that escapes order attribution — is not a valid output of this architecture; it must be returned as a typed gap referral with locus domain model (the order structure does not cover this output). Each emergent output additionally carries a declared validation status drawn from {validated-against-declared-benchmark, unvalidated-hypothesis} — the former with a measured error against the named benchmark; an unvalidated emergent output is consumable only as a hypothesis and is refused as authoritative input to a consequence-bearing operation (§02c §7).
Deterministic, probabilistic, and hybrid modes. An order, an operation, or a representation may be deterministic, probabilistic, or a hybrid thereof, and the order-shape contract and recomputation witness apply in each case. A probabilistic-graphical representation whose update is an order-governed operation is bound by a recomputation witness that records the prior distribution, the observation, and the update procedure, from which the posterior is re-derivable. The probabilistic character of an order’s content does not weaken the governance: admissibility and structure remain functions of the order-shape specifications. A probabilistic or hybrid composition is not a distinct architecture separable from the order-governed formation and composition machinery — it is a mode of the same primitive, subject to the same composition witness and order-shape contract.
2.4 The composition witness
The composition witness for a composed discrete program is a typed record that enables an independent inspector to re-derive the composed program and any of its outputs from the constituent representations and the shared order structure, without trust in the composing deployment.
Minimum required fields:
| Field | Content |
|---|---|
| Constituent representation identities | Content-addressed identifiers of each discrete representation participating in the composition, with their respective IR identity and version |
| Formation witness per constituent | For each constituent: the recomputation witness binding that constituent to its source — replay record (recorded inputs, formation method, and parameters or version, such that re-performing the formation reproduces the representation) where formation is deterministic; justification record (which source elements, under which orders, yielded which structure) where formation is interpretive or non-deterministic; either or both |
| Composition locus record | For each shared order: the order identity, the constituent owner-set identities, and the unification procedure applied to merge them |
| Composition sequence | The declared order in which constituents were composed (material when composition is order-dependent) |
| Composed-program content hash | Tamper-evident binding over the composed program artifact |
| Emergent-output attribution records | For each emergent output: the order(s) to which it is attributed, the constituent sources from which it arises, and the derivation trace under the order-decomposition |
| Use-verification records | For each traversal, lookup, evaluation, or analysis act performed over the composed program: a record from which an independent inspector re-derives the path taken through the order-governed structure without trust in the deployment; traversal and use of the structure are verifiable, not only its origin |
| Prior-link hashes | Content hashes of the constituent witness links, extending the §02a §5a.2 chain through the composition step |
The composition witness is a stage link in the multi-stage witness chain (§02a §5a.2). It chains from the constituent IR witness links through the composition step to the composed-program artifact and then to any analysis acts performed over the composed program. The witness extends beyond formation to use: a traversal, lookup, evaluation, or analysis over the order-governed structure is itself verifiable — the path taken through the knowledge is re-derivable by an inspector — because the use-verification records are part of the witness, not an optional annotation. A deployment that maintains formation recomputation witnesses but does not maintain use-verification records for traversals and evaluations over the composed structure is structurally incomplete at the witness level.
Relationship to §02a §4b governed traversal. The use-verification records above capture the path taken through the order-governed composition structure. Where §02a §4b governed traversal is additionally used over the composed program — navigating its metric space with declared inputs, parameters, and a steering-composition function — the §02a §4b traversal witness requirements apply in full and are additive to the use-verification records; they are not substitutes for each other. In the §02a §5a.2 chain, the §4b traversal witness link(s) appear between the composition-step link and the analysis-act links: [constituent IR links] → [composition witness link] → [traversal witness link(s)] → [analysis-act links] → [verdict link]. A composition witness that carries use-verification records but omits §4b traversal witness links where governed traversal was used is structurally incomplete at the chain level.
← What this layer covers · Section index · The model-as-map layered architecture →