Evolution Loop

The Evolution Loop is the governed workflow by which world models come into being and grow over time. It runs in two phases:

• Phase 1 — Initial onboarding (episodic batch): a new customer’s world model is authored from operator-gathered source material, supplemented by World Agent web research, reviewed collaboratively, and published as a version.
• Phase 2 — Post-deployment iteration (continuous): customer-operator feedback against historical decisions drives World Agent rule-change proposals, which flow back through Phase 1’s review and publication machinery for the next version.

Both phases share two invariants:

• Human sign-off is required at every publication. The World Agent proposes; the operator decides.
• The unit of authority is the published world-model version per ADR-026. In-progress changes between publications are working-set state, not authority.

Phase 1 — Initial onboarding

Source-material ingestion (the primary path)

Onboarding a new customer into a domain starts with the operator gathering source material that describes the domain’s problem space — web resources, statute, regulatory guidance, scholarly publication, internal customer documentation. The operator ingests this corpus into the distillation pipeline.

The World Agent then:

• Stores each ingested document as a provenance source — a durable record of the source-of-truth artifacts the rule set derives from
• Parses the corpus to extract proposed rules covering the observable domain shape
• Anchors provenance per proposed rule back to specific source-material excerpts
• Assigns the provenance tier — typically Distilled for direct source extraction, Authoritative when extracting from authoritative sources within the corpus (per World Model — Authoritative-source dimension)

Distillation is authoring. The operator’s act of selecting and ingesting source material is the authoring intent; the World Agent operationalizes it. Blank-page rule drafting remains a valid affordance for cases where source material is sparse or implicit, but it is secondary to the source-material-driven path.

Web-research gap-filling

Operator-provided source material has reach limits. To produce a usable rule set, the World Agent supplements with bounded online research, shaped by observation of the ingested corpus:

• Gap analysis — the World Agent identifies areas where the ingested corpus has weak or no coverage: concepts referenced but not defined, regulatory framings implied but not provided, scope edges the source material doesn’t address.
• Query construction — research queries derive from gap analysis, shaped by domain vocabulary established in operator-provided sources to stay relevant.
• Source evaluation — web-sourced material is evaluated for authority, recency, and relevance before being adopted as rule provenance.
• Provenance — web-sourced rules carry the Researched tier (per World Model — Authoritative-source dimension), distinct from the Distilled tier of operator-provided synthesis and ranked below it because the source selection is machine-mediated. The distinction is surfaced clearly in the review session.

The research scope is tied to the domain being authored — not unbounded web traversal. Source-quality criteria filter what gets adopted. Operator review at the next step surfaces all web-sourced rules with clear provenance markers; the operator can accept, modify, or reject.

Collaborative rule-set review

The unit of review is the rule set, not the individual candidate. Operator and World Agent iterate together over the generated set:

• The World Agent surfaces the full proposed rule set with rule text, generated predicate code, the materialized behavioral tests, provenance citations, and implementation-readiness-gate evidence per rule
• The operator works through the set in their judged order — by theme, by provenance tier, by perceived risk — not in a fixed queue
• Per-rule actions (accept, modify, reject, request revision, request additional research) are available as session affordances; the operator can also bulk-act over groups of related rules
• Iteration is collaborative: the operator can ask the World Agent to revise rules, explore gaps further, refine generated predicates; the World Agent surfaces evidence, generates alternatives, and accepts operator guidance

Individual rule acceptance within a session does not broadcast a separate notification. The rule set evolves as working-set state until the operator triggers version publication (see Episodic version publication).

The two gates within review

Two gates stand between a proposed rule and inclusion in the published rule set. Both must clear before the operator can accept a rule into the next-version working set. Together they verify the rule from two angles: does the generated code do what the natural-language form says? and does the rule belong in this world model?

Implementation-readiness gate

The first gate. Automated; the World Agent’s responsibility. It runs during authoring (codegen generates the predicate to pass it), and its completeness property is re-enforced as a hard gate at publication per ADR-108 (see Episodic version publication). It verifies the generated predicate code is behaviorally complete against an independent reading of the rule’s intent:

• The behavioral spec discriminates, and the predicate passes it. A behavioral spec — the inputs the outcome should depend on, the partition of outcomes over them, and discriminating case-pairs (including negative cases the rule must not fire on) — is extracted from the rule’s natural-language text independently of any predicate, then deterministically materialized into tests anchored to the rule’s emitted outcome. The predicate is generated to pass those tests (a test-driven inversion); a candidate that fails routes back into the bounded repair loop, and exhaustion raises with nothing enshrined. Because the spec’s lens is independent of the predicate, this catches a predicate that does the wrong thing relative to intent — not merely one that disagrees with itself.
• Every consumed input matters (dead-input gate). A deterministic mutation gate rejects a predicate that reads an input whose value never changes the outcome across the spec’s case space. Where the spec catches a missing input, this catches a dead one.
• Inputs are declared and codegen is held to them. Per ADR-107, the rule declares its inputs as typed, documented metadata, and codegen is bound declared == read — an undeclared read or a declared-but-unread key routes back into the repair loop.
• Code provenance is captured. The code dimension of the rule’s two-dimensional provenance (per World Model) is recorded: which natural-language form generated the code, which configuration values are baked in at code-gen time, what the generator’s safety constraints rejected.
• Runtime safety constraints hold. Per ADR-083 D2 the generated predicate passes AST-level static analysis: no I/O, no mutation, no nondeterministic constructs. Per ADR-083 D3 the runtime app sandbox catches what static analysis misses.

The World Agent runs this gate against its own outputs, surfaces failures to the operator within the review session, and re-generates until the gate passes.

Conformity gate

The second gate. Operator-mediated, within the review session. Verifies the rule against the domain’s authoritative sources and the existing rule corpus:

• Authoritative-source verification. The proposed authoritative-source citations resolve; the rule’s natural-language form is consistent with what the cited sources say; the provenance tier is calibrated correctly (Authoritative vs Curated vs Distilled vs Researched vs Observed vs Assistant-drafted per World Model).
• No contradiction with existing rules. The proposed rule does not contradict the existing rule set under the action, including other working-set additions queued for the next version.
• No tier-T1 conflicts. A new T1 rule that would override an existing T1 rule in the same action surfaces as a conflict for operator adjudication (T1 rules are unconditional hard-floor overrides; two T1 rules cannot fire on the same input without a defined suppression chain).

The World Agent surfaces the verification evidence; the operator runs the final check during review. Acceptance persists an ApprovalDecision row keyed by (candidate_id, operator_id, decided_at) with rationale captured verbatim. This is a record of operator activity, not agent memory — the bridge between operator decisions and any agent memory observation about a decision is provenance via (source_type, source_ref) per memory system.

Episodic version publication

Publication is operator-controlled and deliberate. When the operator decides the working set is ready, they trigger world-model-version publication from the operational control plane.

The publication action commits a new version atomically:

• A new WorldModel version row is minted with monotonic version sequence
• A fresh EvaluationAuthorityRef is minted per ADR-030 (opaque across the context boundary)
• The per-(org, domain, action) action modules are generated with embedded schema digest and code provenance, signed with the per-version content hash per ADR-080 D1, and written to the module store
• The WorldModelCard is minted per ADR-082 D2 with the rule set, provenance summary, action-registry summary, and restatement summary
• The worlds.world_model_card.published outbox row is written in the same transaction; consumed by the platform’s System Card projection handler

All four artifacts commit atomically; rollback drops all four. Until the publication transaction commits, the working set’s accumulated changes are not visible to any consumer.

Publication runs vocabulary reconciliation, then hard-gates on behavioral completeness per ADR-108 D5 + ADR-107 D5. Before the deterministic mint, a reconciliation phase runs holistically per declared action over its assigned enshrined rules: an LLM proposes canonical input names and a per-rule rename map (the one irreducible semantic judgment — “is total_income the same quantity as gross_income?”); types, required, enum values, and provenance are derived deterministically under that map; deterministic realignment then rewrites every impacted rule’s predicate, applies_when, declared inputs, and behavioral spec together onto the action’s canonical input ontology. That naming call is cassette-pinned and memoized — a steady-state republish with an unchanged rule set makes no LLM call. Publication then fails unless every enshrined rule is behaviorally complete (its persisted spec is internally consistent, passes, and has no dead input) and each realigned rule still passes its re-materialized behavioral suite (the consistency gate). Remediation is two-tier and the operator never edits code: mechanical failures (AST safety, declared == read, dead input) auto-repair in the codegen loop; semantic failures (the natural-language rule and its intended behavior disagree, the text is ambiguous, or a vocabulary harmonization is low-confidence or would rewrite an already-published input name) route to the operator — natural-language chat-steering, and at publish a surfaced rename preview the operator arbitrates before it is applied (a name any published version exposed is conserved; harmonizing it fails loud). The materialized behavioral suite ships in the content-addressed deploy bundle beside the minted modules, with a deploy-time backstop that re-runs the shipped suite against the deployed predicate — so the enforcement is a carried, self-verifying artifact, not only a publish-time assertion. Deploy sources each action’s input schema from its persisted ontology, with the rules’ union retained only as a drift check. The platform proves an internal property — every intended input measurably matters and the predicate matches the spec drawn from the rule’s own text — not that the rule is correct about the world; real-world truth stays the operator’s responsibility.

Between publications, the operator can re-open a published version’s working set, iterate on it (potentially across multiple collaborative review sessions), and publish a new version when ready. Working-set persistence is part of the worlds-side state.

A published version is the unit of authority per ADR-026. Consumers — deployed decision modules, customer audit chains, System Cards — pin to versions and never see in-progress changes.

Phase 2 — Post-deployment iteration

Once a world-model version is in production serving decisions, the loop continues through structured customer-operator feedback against historical decisions.

Customer-operator feedback against historical decisions

Customer-side operators review decisions the deployed modules have made and provide structured feedback. The feedback surfaces, exposed through the Customer Dashboard, include:

• Decision annotation — operator marks a specific decision with a note explaining what should have been different and why
• Rule-level commentary — operator flags a specific rule as too restrictive or too permissive in a category of cases
• Outcome report — operator records what actually happened after the decision (the customer agent did Y, the customer accepted Z, the regulator pushed back, etc.)
• Flag-for-review — operator marks a decision for later review without an immediate annotation (the lightweight signal — see override-pattern aggregation below)

Feedback rides the platform-side audit-grade record per ADR-076 D3; retention discipline in the Retention Registry. Per-deployment identifiers stay attached as provenance.

World Agent processes feedback into rule-change proposals

Accumulated feedback flows to the World Agent, which processes it into proposed rule changes for the next publication cycle:

• Revisions to existing rules (tighten, loosen, refine, restate)
• Additions for gaps that feedback reveals
• Retirements of rules that consistently don’t fit observed cases

The World Agent aggregates feedback across the customer’s accumulated decisions. A single flagged decision is interesting; the same pattern recurring across the customer’s decision history is a candidate for rule change. The aggregation applies an N-threshold gate (configured per world model from the Operations app authoring surface; no single hardcoded value), and routes only a recurring pattern — not a one-off signal — into the proposal flow.

Proposals flow into a collaborative review session (per Collaborative rule-set review) as candidate changes to the working set. The operator reviews them with the World Agent, decides what survives, and publishes when ready.

Spectral does not auto-publish rule changes from feedback. The operator remains the enshrinement authority per ADR-080 D5. Feedback is input, not commitment.

Platform substrate: override-pattern aggregation

The platform-side foundation for Phase 2 feedback is the override-pattern signal aggregation pipeline:

• OnDecisionRecordedSignalHandler consumes DecisionRecordedEvent when the decision carries customer-operator feedback (flag-for-review, annotation, commentary, outcome report) per Event System
• Routes into the override-pattern aggregation pipeline by feedback shape
• Emits override_pattern_signal.aggregated when a cluster crosses the operator-triage threshold
• The worlds-side consumer in spectral.worlds.application.evolution_loop consumes the aggregated signal and routes it into the World Agent’s rule-change proposal flow

The substrate carries customer-operator feedback to the World Agent in a structured way. Aggregation by feedback shape keeps idiosyncratic per-customer signals out of the proposal stream while making genuinely systemic gaps reachable.

Rule-level health signal

Every rule in a published world model carries a rolling discriminative health signal that addresses: is this rule still producing meaningful decision-time signal in production? The signal is rule-scoped and computed across audit-chain entries that reference the rule (matched, suppressed, or short-circuited via applies_when).

Definition

For each rule r, the health signal is computed over a rolling window of completed /decide invocations that referenced r (via audit-chain decision metadata):

Metric	Meaning
match_rate[r]	Fraction of relevant invocations where the rule matched
applies_when_pass_rate[r]	Fraction of invocations where the applies_when filter let the rule into evaluation
errored_predicate_rate[r]	Fraction of invocations where the predicate raised (short-circuit to YELLOW)
last_updated[r]	Most recent decision that contributed

The rolling window is rule-age-aware: for rules with fewer than N samples in history, the window is “all decisions ever”; for established rules, the window is the last K decisions (K chosen per world model, managed configuration).

Interpretation

The triple (match_rate, applies_when_pass_rate, errored_predicate_rate) classifies the rule’s current health:

Pattern	Classification	Implication
match_rate moderate; errored_predicate_rate ≈ 0	Discriminating	Rule is working as intended — it fires on the cases the operator expected.
match_rate ≈ 0; applies_when_pass_rate low	Plausibly never-triggered	The applies_when filter rarely activates this rule; candidate for review of the filter or retirement.
match_rate ≈ 1 whenever applies_when passes	Plausibly over-broad	Rule may be subsuming a broader pattern than intended; candidate for refinement.
errored_predicate_rate non-trivial	Plausibly under-specified	The predicate raises on real-world inputs; the implementation-readiness gate cleared but production reveals gaps.

Thresholds are managed-configuration, not hard-coded.

Who computes it

A RuleHealthService in spectral.worlds consumes audit-chain projections through the notification flow and updates the rolling window per rule referenced by each decision’s metadata. The computation is idempotent per decision (same decision can be reprocessed without drift). The service exposes the current health vector to the World Agent via an intra-worlds read; the World Agent does not compute the signal itself.

What triggers a rule-lifecycle action

Nothing automatic. The health signal is an input to the World Agent’s Phase 2 proposal flow — it appears in the agent’s coverage reports, in gap analyses, and in operator-facing summaries. The World Agent may propose a rule change (revision, retirement, refinement) based on the signal, but every such proposal passes through Phase 1’s collaborative review and operator-controlled publication path as any other change.

Automatic retirement would bypass human authority over the domain standard, which is the whole point of the governed loop.

Where the signal surfaces

• World Agent coverage reports — flags rules in “plausibly never-triggered” or “plausibly under-specified” states when the operator asks about coverage.
• Operator dashboards in the Operations app — surfaces the health vector per rule for ad-hoc review.
• World Model Card metadata — aggregates the distribution of rule-health states per version (how many are discriminating, how many are flagged, etc.) without exposing per-rule signal externally.

What the signal does NOT do

• Does not flow to customers. The signal is world-model-internal; the customer-facing System Card surfaces aggregate distribution, not per-rule health.
• Does not automatically demote or retire rules. Those remain governed publication-path decisions.
• Does not affect decision outcomes. Rules with flagged health still contribute normally to decisions; the signal is a trigger for evolution review, not a runtime weight.

Versioning and release

Version releases follow semver conventions with a restatement discipline: configuration restatement, rule restatement, action restatement. Release notes document rule changes, including corrections.

A rule found to have been misread from its source is corrected in the release notes of the version that fixes it. Prior decisions made against the version with the misread rule are not retroactively invalidated — they were correct decisions against the published standard at that time. The published version is the unit of authority per ADR-026.

What’s next

• System Card — the World Model Card + System Card pair published against each version
• Version Attribution — how the world-model version stays metadata across the context boundary
• World Agent — the resident agent that runs Phase 1 generation and Phase 2 proposal flows
• Operations App — Publication — the operator surface for triggering version publication
• Customer Dashboard — the customer-side feedback surfaces feeding Phase 2