World Model System

Version Attribution

World-model versions evolve. A decision served today may cite v0.1.0; a decision next quarter may cite v0.2.0. How the two contexts coordinate that evolution is the topic of this page.

The short answer: they don’t coordinate. The deployed action module is the data carrier between spectral.worlds and spectral.platform, and the world-model version stamped on every /decide response is metadata, not synchronization. The platform context does not react to world-model version transitions; the worlds context does not know when the platform serves a decision. The two contexts share a contract surface (the module store + the version field on the decision response per ADR-077 D3) and nothing more.

The principle

The action module is the sole data carrier between worlds and platform. Worlds publishes content-addressed modules to the module store keyed by (org, domain, action, world_model_version). The platform decision-server reads from the store on first request, verifies module integrity per ADR-080 D2 + D3, caches the loaded module, and runs it. The store is the unidirectional handoff; that is the full data surface between the two contexts.
Version is metadata, not a synchronization signal. The platform stores the version value it receives (baked into the module manifest), surfaces it on every decision response, and moves on. It does not branch on version identity, reset state, filter aggregates, or pause work.
The worlds context’s version awareness stays internal. The World Agent knows what the current published version is — it filters incoming override-pattern signals against the current version, generates predicate code against the current schema and configuration, and publishes modules keyed to its current authority. None of that awareness leaves the worlds context except as the value baked into the module manifest and surfaced on the decision response.

Active version + optional pinning

Per ADR-077 D2 each /decide request can optionally pin a world_model_version in the request body. Resolution behavior:

Omitted — Spectral routes to the active version for (org, domain). The active version is the routing default; it advances when the operator publishes a new version.
Pinned — Spectral routes to the pinned version. The pinned module must exist in the module store; otherwise the request fails fast with a validation error before any rule evaluation runs.

Both paths produce deterministic decisions over their pinned version. Pinning is the customer’s escape hatch for situations where they need to evaluate against a specific historical version (audit replay, regression check, contract-defined version lock-in).

What the platform does NOT do on a version transition

Not done	Why
No supervisor reset	Decision continuity does not break when the domain standard gets more precise. Cross-version trend is real signal; resetting would discard it.
No cross-version aggregation split	A status-distribution shift at a version bump is a thing to see, not a boundary to hide. System Card surfaces render continuous series; the version bump is annotated, not a partition.
No decision-pipeline pause	Publication is a worlds-internal event. The decision-server has no mechanical reason to pause during it. Module-cache invalidation happens lazily on first request for the new version.
No “version transition” event subscription on platform	`worldmodel.version.published` (typed payload in `spectral.worlds.contracts.events.*`) flows to consumers that need it (e.g., the World Model Card auto-generation pipeline); the decision-server does not subscribe — there is nothing for it to do on a version transition besides serve the next request from the now-current active version.
No version-aware branching in `spectral.platform` domain code	The architecture validator’s job is to catch imports; the code-review job is to catch version-conditional logic in the platform context. None should exist.

Visualization — markers, not boundaries

Where version transitions are visible to customers (System Card trend, decision history, cross-decision comparisons), they appear as overlay markers on continuous data. Sentry-style: the line does not break, but a marker at the timestamp of the version publication makes the change visible and click-through to the new version’s release notes.

GREEN %
 │
 │     ╭────╮              ╭─
 │   ╭─╯    ╰──╮    ╭──────╯
 │  ╱          ╰────╯                     ← continuous series
 │ ╱                ↑
 │╱                 │ v0.2.0 published    ← overlay marker
 └────────────────────────────────── time

The customer reads the chart and decides whether the version change caused the shift. The platform does not pre-compute the causal link — the marker is a pointer, not a claim.

What the marker shows

Version identifier (0.2.0)
Publication timestamp
Click-through to the published World Model Card and its restatement summary

What the marker does not do

Does not reset the chart axis
Does not split the aggregate series
Does not attach a “this caused the shift” label

Why this matters

The coupled framing — the platform reacts to version transitions — is easy to slip into because it sounds operational. “When the version changes, reset X.” “Aggregate only within the current version.” “Pause decisions during publication.” Each of these makes surface-level sense.

What they all have in common: they make spectral.platform version-aware, which is what ADR-030 forbids. A version-aware platform re-couples the worlds and platform contexts through a state machine — the exact failure mode that led to the three-context split in the first place (ADR-001; the platform role is defined by ADR-076).

The lean framing — version is metadata — keeps the boundary between worlds and platform clean:

Each context evolves independently. The worlds context can ship v0.2.0 without the platform context knowing.
The contract surface is the module store + the version field on the response, not a protocol.
Every cross-version reasoning question (“did the deployment regress at the version bump?”) is a customer / operator question answered against continuous data, not a platform-side computation.

What about legitimate cross-version reasoning?

It still happens — just not inside the platform’s data layer.

Operators reason about cross-version behavior inside the Operations app, using tools that query both worlds-context and platform-context surfaces and correlate manually.
Customers reason about cross-version behavior inside the Customer Dashboard, using the overlay markers as anchors for their own interpretation.
The World Agent reasons about its own rule-level cross-version patterns via its version-spanning memory tier — that stays worlds-internal.
Audit replay uses the per-request world_model_version pin to evaluate a specific historical decision against its original version.

In none of these cases does spectral.platform itself contain version-branching code.

What’s next

The World Model System subtree ends here. The system-design spine continues with the platform mechanism that consumes action modules:

Decision Execution — the five-phase decomposition of every /decide invocation
Customer Dashboard — the customer-facing view onto decisions and the System Card