Glossary

A belief is not the same as truth. A belief can be true, false, partial, useful, harmful, outdated, vague, or implicit. It is a representation of how things are, or how they are likely to be, that a system is willing to use for interpretation or action.

Informally:

belief = claim + authority to use the claim

Formally:

belief = claim + warrant + lifecycle

A claim says what is being asserted about the state of something. A warrant says why the claim is allowed to influence downstream reasoning, given the evidence and the rules for evaluating it. A lifecycle says whether the claim still holds over time — whether it has been reconfirmed, weakened, contradicted, or retired as evidence accumulates.

label:     validation_pending
claim:     validation has not yet been observed for the current fix
warrant:   no successful validation tool output exists after the
           most recent fix_attempted in this session
lifecycle: active until a successful validation is observed
           (transition to validation_complete) or until the
           half-life elapses (retire under stale_decay)
authority: confirmed_by_tool | asserted_by_assistant | confirmed_by_user

The label tells you what is being tracked. The belief tells you what is currently being claimed, why, and whether it still holds. Reducing a belief to a label is a category error the rest of the spec is designed to avoid.

A label is a handle. A belief is a warranted, maintained assertion.

Further foundational terms used across the spec. Belief, claim, warrant, and lifecycle are defined at the top of the page.

Substrate

The kind of evidence field a Belief Stack is built over: timestamped events with identifiers and provenance. Substrates differ (markets are latent and drifting; assistant workflows are typed and discrete) and the L1 representation must match the substrate, not the other way around.

Region

The L1 unit of organization — a partition of input space defined either by learned clustering or by a priori typology. Each region carries its own characteristic warrants and priors.

Prior

The L2 unit of expectation — what the system expects to see given a region. Priors can be probabilistic, structural, or behavioral.

A Belief Stack is a contract over six layers. L0–L4 form a complete knowledge source; GOV is an optional consumer.

L0 — Evidence

Raw observations from the substrate. Ordered, addressable, provenance-bearing. No interpretation.

L1 — Regions

Labels + warrants over L0. Partitions input space into contextually meaningful regions; every assignment carries the evidence backing it.

L2 — Priors

Per-region expectations. What is likely, acceptable, typical, or invariant inside a region.

L3 — Lifecycle

State and trajectory of beliefs over time. Beliefs are born, age, are contradicted, and retire; L3 tracks where each one sits.

L4 — Calibration

Predicted-vs-actual measurement. Pushes back against stale L2 expectations and triggers re-weighting.

GOV — Governance

Optional consumer layer. When present, an intervention may deploy only after its warrant survives a check against current evidence. Systems that only need to serve maintained beliefs can omit GOV entirely.

One substrate, two peer consumers. The split is in rendering, not in source of truth.

Belief observability

The category-level claim: a Belief Stack is an observability layer for belief state. Traditional observability shows what a system did; belief observability shows what the system was relying on when it did it.

AI-facing overlay

Compact, ranked, budgeted grounding payload injected into a model at action time. The overlay is an attention compressor, not a database dump.

Human-facing trace

Browsable, time-traveled inspection surface for an operator. Includes state-at-turn, timeline, and per-belief drill-down. Optimized for debugging, audit, and inspection rather than token budget.

Peer query surfaces

The framing that the AI and the human are co-equal consumers of the same belief-state substrate. Neither is the primary; neither is bolted on. Both read through state() and differ only in rendering.

Attention compressor

Operating principle for overlay(): rank candidate beliefs, drop content that doesn't fit the budget, never partial-render. Tested empirically in Operational Belief-State Grounding v0.2.2 — a 100-token overlay matched the v0.1 lift.

Epistemic debugger

Operating principle for the human surface: every active belief is inspectable; every lifecycle transition has a recorded event; every assertion has a warrant a human can follow.

Terms specific to the operational-belief experiments (v0.1 / v0.2.2) and the assistant-workflow substrate.

Operational belief

A maintained claim about workflow state: what has been attempted, what is pending, what has been validated, what has been contradicted. Distinct from semantic memory: this is what the assistant is currently treating as still true about the work.

Out-of-window meta-rule

From OB-002 §3.0: prioritize active beliefs whose evidence falls outside the K=20 recent-log window. The overlay's distinctive value is carrying state that has scrolled past what the model can already see.

Operational error

Aggregate failure rate across the five deterministic metrics below. v0.1 measured 11.0% (System A baseline) vs 5.5% (overlay). v0.2.2 measured 10.7% baseline → 5.3% at B100.

False-completion claim

Failure mode: the answer asserts the work is complete when an oracle says the workflow has pending state. The dominant signal in both v0.1 and v0.2.2 (A=20% → B100=0%).

Stale-validation assumption

Failure mode: the answer claims the most recent fix has been validated when the oracle says no validation has been observed since the fix.

Repeated-failure loop

Failure mode: the answer does not flag that a current failure is a recurrence of an earlier one in the same session. (Note: the v0.1 / v0.2.2 judge has a known semantic-inversion blind spot on this metric.)

Premature action

Failure mode: the answer recommends proceeding with an action (commit, push, deploy, send) without waiting for approval, validation, or completion of a blocker.

Missing pause

Failure mode: the answer does not recommend pausing, declining, or asking for clarification when operational state is unresolved.

Oracle

Programmatic ground-truth function over the substrate. Computes applicability (whether a failure mode can structurally fire at a given turn) and oracle_class (POSITIVE / NEGATIVE / NA). On disagreement with the deterministic judge, the oracle wins; the disagreement is logged.

Judge–oracle conflict

A case where the deterministic judge flagged the answer but the oracle says the failure mode was structurally inapplicable. Logged and preserved; the combined label is NO (oracle wins). Distribution across arms is reported as audit support.

Type+claim cluster dedup (§3.5a)

Amendment locked in v0.2.1: before ranking, group candidate beliefs by (belief_type, operational_claim) and render one line per cluster with n=cluster_count. Prevents substrate-side belief duplication from consuming overlay budget.

Carries across every TopicSpace Research experiment. These are the words used to describe how a result was produced — and how it was kept honest.

Pre-registration

A locked design document written before any data flows: question set, generator model, judge model, seeds, ranking policy, decision table. Subsequent amendments are documented as numbered revisions (v0.2.1, v0.2.2) with rationale, not silently rolled in.

Lock discipline

After lock, prompt text and judge configurations do not change. No prompt tuning after seeing outputs. No silent truncation. No rerolls for quality. All failures preserved with metadata.

Anti-curation

The discipline that question text is generated blind to the substrate that will be ranked, and the scorer is consulted only post-generation. Designed to prevent leak between the design and measurement steps.

Deterministic gate

The primary outcome surface. A YES/NO/NA label per (question, metric, system) combining oracle applicability with judge classification under the oracle-wins disagreement policy. Aggregated to a single error rate per system.

Preference axes

Secondary outcome: blind pairwise judging on traceability (whether the answer makes its claims verifiable) and appropriate_caution (whether the answer pauses or qualifies when state is unresolved). Reported as audit support, not headline.

Human audit anchor

A stratified review of YES labels and judge-oracle conflicts. Reviewer records agree / disagree / unclear per case with a one-sentence rationale. Reported as audit support, not a third primary metric; labels are not modified.

Feasibility failure

A (question, system) pair where context construction or answer generation could not complete (e.g. token-cap overflow). Recorded with the API error class; never silently truncated. v0.1 had 2; v0.2.2 had 0.

The runtime instantiation of the Belief Stack pattern for long-running assistant workflows. Sketched in TKOS-001 and TKOS-002.

TKOS sidecar

Runtime operational-state layer. Observes assistant workflow events, maintains a small set of active operational beliefs, and on request returns either a compact grounding overlay or an advisory risk check. Not a memory store; not a governance system.

observe(event)

Sidecar API: ingest one assistant-session event (user message, assistant message, tool call, tool result, file edit, validation event, approval request/response). Updates the belief state via deterministic rules.

state(session_id, turn=None)

Sidecar API: return the active belief set as of the current turn or a target historical turn. The audit-grade surface — unbudgeted, full provenance.

overlay(session_id, budget_tokens, action=None)

Sidecar API: return a ranked, budgeted overlay for LLM grounding. Hard token cap. Never the full state.

risk(session_id, action)

Sidecar API: advisory check on a proposed action. Returns blocker beliefs and rationale. Information, not enforcement.

Read path / write path

Read path: state(), timeline(), explain(), overlay() — query the substrate. Write path: observe(), the rule engine that derives belief_instances and belief_events from events. v0.1 sidecar proves the read path before building the write path.