§02d Jupiter — Discrete Composition — The model-as-map layered architecture
Mars® Spec › §02d Jupiter — Discrete Composition › The model-as-map layered architecture
← The composed discrete program · Section index · Cross-model composition →
3. The model-as-map layered architecture
The model-as-map layered architecture is the layered embodiment of the discrete-representation specification in which the formal domain model (§01) acts as a navigational map — the structure over which a composed discrete program executes — with a subordinate specification override layer that may adjust representation formation without affecting conformance determination.
3.1 The two layers
Layer 1 — The domain model as map. A domain model (§01) is not merely a source of order definitions. In this embodiment, it is the navigational structure through which the composed discrete program traverses. Each traversal step corresponds to moving through the model’s order structure: from one order to an adjacent order, governed by the declared inter-order relationships in the domain model. The program’s execution is a governed walk over the model’s topology. Where multiple domain models are active, each traversal step identifies the specific domain model version it consults; the traversal witness (§3.2) records that identity per step, and an inspector re-derives each step against the declared model version without assuming a single global model.
This makes the domain model a first-class runtime artifact rather than a compile-time input. The program does not compile the model into its internal logic and then discard it; the model is consulted at each traversal step. An inspector re-derives any traversal step by consulting the same model version under which it was performed. The traversal is independently re-derivable from the model and the program’s declared walk rules.
Layer 2 — The specification override layer. The specification override layer may adjust how representation elements are formed and how the program navigates the model — adjusting vocabulary, adding domain-specific formation rules, or providing supplementary traversal guidance. The override layer is strictly subordinate: it governs representation formation and traversal guidance, not conformance determination. Conformance is determined by the governing specification (§02a §5 governing-specification precedence rule), not by the override layer.
Where the override layer and the governing specification conflict, the conflict is recorded in Field 6 (falsifier annotations, condition (e) subtype override-conflict) and the verdict reflects the governing specification’s requirements. An override layer that suppresses a governing-specification conformance predicate without recording the suppression is a conformance defect of the deployment.
3.2 Traversal witness
The model-as-map architecture requires a traversal witness as part of the composition witness (§2.3). The traversal witness records each step in the program’s walk over the model:
| Field | Content |
|---|---|
| Model version identity | The content-addressed identity of the domain model version consulted at this traversal step |
| Entry order | The order at which this traversal step begins |
| Exit order(s) | The order(s) to which this step traverses |
| Walk rule identity | The declared walk rule applied at this step (from the program’s walk-rule declaration) |
| Override layer contribution | Any contribution of the specification override layer at this step; if none, explicitly declared as no-override |
| Step content hash | Tamper-evident binding over the state of the composed program at this step |
An independent inspector re-derives a traversal step by: (i) retrieving the declared model version; (ii) applying the declared walk rule at the declared entry order; (iii) confirming the exit order(s) match the declared exit order(s); (iv) verifying the override-layer contribution against the registered override-layer version. A traversal step whose outcome cannot be independently re-derived from the model and the walk rule is a conformance defect.
Distinction from §02a §4b governed traversal. The traversal witness defined in this section records order-structure navigation steps — the walk over the domain model’s topology under declared walk rules. It is distinct from the §02a §4b traversal witness, which governs metric-space navigation with declared inputs, registered parameters, a steering-composition function, and recomputable positions in the domain’s metric space. Both may be present simultaneously in a model-as-map deployment: the §3.2 traversal witness records which orders were visited and under which walk rules; the §02a §4b traversal witness records the metric-space traversal acts that operate over the content at those orders. The §3.2 traversal witness does not satisfy the §02a §4b traversal witness obligations, and an implementation that produces only the §3.2 record while using §02a §4b governed traversal is structurally incomplete. In the §02a §5a.2 chain, both witness types appear: [IR stage links] → [§3.2 model-navigation traversal witness] → [§4b metric-space traversal witness link(s)] → [analysis-act links] → [verdict link], where either may be absent if the corresponding traversal mode was not used.
3.3 Relationship to §02a §5 governing-specification precedence
The governing-specification precedence rule (§02a §5) applies without modification in the model-as-map architecture. The override layer is subordinate to the governing specification for conformance determination regardless of whether the deployment uses the model-as-map layered embodiment or a non-layered embodiment. The model-as-map architecture does not create an exception to this rule; it extends the traversal mechanism while leaving the precedence rule intact.
← The composed discrete program · Section index · Cross-model composition →