World Model System

Audience

Primary audience is the Spectral operations team (world-model authors, curators) and platform engineers working in spectral.worlds. Customers consume the world model indirectly — through the binding decisions deployed action modules produce, and through the World Model Card + System Card surfaces.

The World Model System is Spectral’s mechanism for establishing and evolving the operational authority a domain requires. It exists because any single caller’s view of a domain is bounded by their experience — the decisions they have made, the situations they have anticipated, the rules they already know. A domain’s actual operational territory is strictly larger than any one caller’s view of it. Encoding “what should happen” inside the caller’s own LLM is encoding that caller’s map, not the territory.

The World Model System replaces that map with a governed, executable standard. Rules are grounded in authoritative sources, curated through human-gated evolution, compiled to deterministic decision modules via world-agent code generation, and deployed for the customer’s domain. The decision modules run outside the LLM’s reasoning loop at decision time. Agents call the deployed action module for (org, domain, action) via /decide; the deterministic module evaluates and returns a binding { status, work_frame, decision_metadata } per ADR-077.

The world-model system supplies the executable authority; the platform pillar hosts and runs the deployed modules. The two contexts communicate through narrow, explicit seams: the module store (worlds publishes; platform reads and executes) and override-pattern signals (platform aggregates customer-initiated review-requests + noteworthy marks; operators consume as evolution-loop evidence). See Contract Surfaces for how this stays decoupled.

Primitives

A World Model is a Spectral-managed authoring authority for a domain, scoped to (org_id, domain_id) and versioned. Each version declares a context schema (the typed vocabulary of attributes decisions consume), a configuration block (stable values per version that derivations and rule code-generation read), and an action registry (the set of registered actions, each holding its own rules). For the full specification, see World Model.

A Rule is the atomic unit of an action. A rule is a natural-language assertion about expected behavior that the world agent compiles to a deterministic predicate, paired with metadata (id, tier T1/T2/T3, outcome, description, suppresses, dual provenance), an optional applies_when filter, and inline tests. Rules move through a three-status lifecycle from Candidate to Enshrined to Retired; publish/deploy decide which enshrined rules ship. For the full specification, see World Model.

A Domain is the full operational territory a world model governs — the complete space of situations, edge cases, and decisions the standard is responsible for characterizing. Per ADR-086 D2 the domain is also the action-grouping container at the tenancy level.

A Problem Space is the subset of a domain that a specific deployment exercises. Operators decompose a domain into problem spaces during world-model authoring; the action registry materializes those problem spaces as registered actions with their rules.

A World Agent is the internal resident of a World Model. It generates predicate code from natural-language rules, suggests inline tests, proposes provenance citations, runs the implementation-readiness gate, and (per ADR-081 D5) serves a post-release customer-facing explain-this-decision affordance. It is not a decision-maker at the enshrinement gate — the operator is. For the full specification, see World Agent.

A World Model Card is the version-scoped methodology disclosure published with each world-model version per ADR-082 D2. Operator-authored: scope, sources, decision log, authority basis, two-dimensional provenance summary.

A System Card is the deployment-scoped operational record per ADR-082 D3: per-(org, domain) totals, p50/p95/p99 latency, four-state status distribution, methodology disclosure, version history. Customer-facing through the Customer Dashboard; sourced from the platform pillar’s audit chain.

The three-zone structure

A world model’s coverage of its domain is partitioned into three zones.

Known — enshrined rules accepted into the world rule catalog. Published and deployed action modules evaluate the assigned enshrined subset pinned into each version.

Unknown — discoverable rules that exist in the domain but have not yet been found and enshrined. The system deliberately leaves space to challenge known rules and explore here. The Evolution Loop is the mechanism for moving rules from Unknown to Known.

Unknowable — rules that exist in the domain but cannot yet be perceived with current methods. No current discovery process can surface them. The world model acknowledges this zone rather than pretending completeness. Incompleteness is a first-class design property, not a gap.

System architecture

The World Model System is implemented as a context separate from the decision host. Three contexts structure the code: spectral.worlds (the authoring authority — rule storage, the World Agent, the Evolution Loop, the two gates, the module store publication path, and the World Model Card), spectral.platform (the decision host — decision API, decision-server, module store consumption, audit chain, System Card), and spectral.core (substrate transport plus cross-cutting plumbing — events, auth, db, retention, llm, embeddings, tools). Both worlds and platform depend on core; core depends on neither.

Worlds publishes the module store contents — typed contract surfaces — that platform consumes without importing worlds internals. The integrity controls for the Evolution Loop itself — the implementation-readiness gate, the conformity gate, human sign-off, the module integrity check per ADR-080 — sit on top of these mechanisms, not in lieu of them.

Mechanism deferred to Contract Surfaces. Worlds and platform never import each other; integration happens through the module store, producer-owned typed event payloads, and callee-owned OHS Protocols. For this page, the takeaway is that published action modules flow out of worlds via the module store, customer-side signals flow back as override-pattern events, and the World Agent’s synchronous capabilities are exposed through callee-owned protocols — never as cross-context imports.

What’s next

• World Model — context schema, configuration, action registry, rule architecture, provenance, lifecycle, versioning
• World Agent — code generation, applies_when generation, both modes (operator + customer), memory architecture
• Evolution Loop — signal sources, both gates (implementation-readiness + conformity), human sign-off, publication
• System Card — World Model Card (version-scoped methodology disclosure) + System Card (deployment-scoped operational record)
• Version Attribution — how the world-model version stays metadata across the context boundary