World Model System

Version Attribution

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

The short answer: they don’t coordinate. The attributed EvalSet is the sole data carrier between spectral.worlds and spectral.platform, and the authority version on that envelope is metadata, not synchronization. The platform context does not react to world-model version transitions; the worlds context does not know when the platform runs a scan. The two contexts share a contract surface (EvaluationAuthorityRef) and nothing more.

The principle

EvalSet is the sole data carrier between worlds and platform. Every scan pulls an EvalSet from worlds with an attribution envelope including world_model_id, world_model_version, and an authority_ref handle. The attribution envelope is carried through the pipeline onto EvalResult, VerdictResult, and ultimately AgentPerformanceCard. 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, surfaces it on artifacts, 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 world signals against that concept and emits EvalSets keyed to its current authority. None of that awareness leaves the worlds context except as the value on the attribution envelope.

What the platform does NOT do on a version transition

Not done	Why
No supervisor reset	Agent behavioral continuity does not break when the domain standard gets more precise. Cross-version trend is real signal; resetting the supervisor would discard it.
No cross-version aggregation split	A score drop at a version bump is a thing to see, not a boundary to hide. Dashboards render continuous series; the version bump is annotated, not a partition.
No changeset-acceptance pause	Publication is a Worlds-internal event. The scan pipeline has no mechanical reason to pause during it.
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 `WorldModelCard` auto-generation pipeline); `spectral.platform`’s scan pipeline does not subscribe — there is nothing for it to do on a version transition.
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.

Visualisation — markers, not boundaries

Where version transitions are visible to customers (trend charts, scan history, cross-scan 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.

score
 │
 │     ╭────╮              ╭─
 │   ╭─╯    ╰──╮    ╭──────╯
 │  ╱          ╰────╯                     ← 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 WorldModelCard and its release notes

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 changeset acceptance 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 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 one struct (the attribution envelope), not a protocol.
Every cross-version reasoning question (“did the agent 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 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.

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

What’s next

The World Model System cluster ends here. The system-design spine continues with the platform mechanism that consumes EvalSets:

System Design overview — primitives the platform is built around
Optimization Engine — how the platform consumes the EvalSet through the scan pipeline