What this is
A living glossary for UNITARES — accountability infrastructure
for long-running AI agents. Every term is defined by the question it answers,
not by a list of examples, because a term pinned to its discriminating
question survives redefinition while one pinned to examples rots. The page
shows its own drift corrections on purpose: a system that hands you its own
falsification harness should also show where its vocabulary was wrong and got
fixed. Source of truth is docs/ontology/glossary.md; this page is
generated from it.
UNITARES Glossary — Terms Keyed by the Question They Answer
Created: June 20, 2026
Status: Living document. Expect churn; the field is inventing terms and so are we.
Companion to: docs/ontology/identity.md, docs/ontology/harness-substrate-plurality.md, docs/ontology/beam-coordination-kernel.md
Audit trail: docs/ontology/glossary-drift-audit-2026-06-20.md (point-in-time sweep that seeded this file); docs/ontology/glossary-drift-audit-2026-09-18.md (re-sweep: ODE coupling correction; V / coherence / drift / entropy homonyms; persistence false friends)
How to read this glossary
A term here is defined by the question it answers, not by a list of examples. This is deliberate. A term defined by its discriminating question survives redefinition; a term defined by examples rots the moment a new example straddles the boundary. (The canonical example: "harness" defined as "Hermes / Claude Code / Codex" breaks the instant BEAM starts hosting an agent loop — see the open gap below. The question — "what body mediates this agent's action?" — does not break; it just gets a new answer.)
The layer table in harness-substrate-plurality.md already works this way
("Harness | what body/interface mediates action?"). This file generalizes that
discipline across the whole vocabulary.
How to add or change a term
- State the question it answers, in one line, before any examples.
- When a term splits, do not rename — disambiguate. If the same word starts
answering two different questions, give each sense a parenthetical qualifier
(
substrate (inference)vssubstrate (deployment)) and let both coexist explicitly. Renaming invents a word nobody adopts; qualifying makes the existing collision legible. This is the ruleharness-substrate-plurality.mdhalf-follows already. - Point at the canonical doc, don't re-define inline. Inline re-definitions are how drift starts.
- A homonym is not a bug to fix. Three legitimate senses of "substrate" are fine. The bug is an unmarked homonym — a reader binding the wrong sense because nothing told them which question was being asked.
High-risk homonyms (same word, different questions)
These are the words where a reader can silently bind the wrong sense. Each is load-bearing in more than one sense; none of the senses is wrong.
substrate — three distinct questions
| Sense | Question it answers | Canonical source |
|---|---|---|
substrate (inference) |
What inference engine generates this behavior? (GPT-5.5, Opus, Qwen, Ollama) | harness-substrate-plurality.md — "Model / substrate | What inference substrate generates behavior?" |
substrate (deployment / identity layer) |
What persistent hardware/disk/DB/config survives a process restart and can earn continuity? (Lumen's Pi) | identity.md five-layer table — "Substrate | persistent hardware, disk, DB, configuration"; Appendix "Substrate-Earned Identity" |
substrate (runtime / scheduler) |
What execution model runs the work — per-process scheduling + protocol-level checkout vs. a shared asyncio loop? | UNIFIED_ARCHITECTURE.md asyncpg, Redis and the anyio scheduler — per-process scheduling with protocol-level connection checkout "should not express this shape", recorded there as a design expectation whose comparison channel holds no rows |
These three are orthogonal axes. An agent can switch substrate (inference)
(swap model) while holding substrate (deployment) constant (same Pi), running
on a substrate (runtime) with a different scheduling model (BEAM). Always qualify
which axis you mean in cross-doc prose.
fingerprint — three distinct questions
| Sense | Question it answers | Canonical source |
|---|---|---|
fingerprint (transport) |
Which interactive driver is this, by ip:ua, for the weak sticky-resume pin? | identity.md — "a short-TTL Redis pin keyed on the transport fingerprint (recent_onboard:<ip:ua>)" |
fingerprint (behavioral / lineage) |
Does this process-instance's EISV behavior match the lineage it claims? | identity.md — "behavior diverges from lineage fingerprint"; R1 verify-lineage-claim |
fingerprint (finding-dedup) |
Is this CI/Watcher finding the same issue we already saw? (sha256 hash) | CLAUDE.md Watcher section — --resolve <fingerprint>; docs/operations/ci-issue-surfacing.md |
The first two are identity machinery and live in the same document; the third is
operational tooling. The transport vs. behavioral split is the dangerous one
because both appear in identity.md: one is a weak heuristic proof, the other
is the strongest earned layer. Never let "fingerprint" stand unqualified there.
surface — two distinct questions
| Sense | Question it answers | Canonical source |
|---|---|---|
surface (lease) |
What shared mutation target is being claimed under single-writer coordination? (repo_path, td_network, a branch, a Discord locus) |
beam-coordination-kernel.md — "A surface is any shared mutation target" |
surface (tool) |
What actions are available to the agent right now? | harness-substrate-plurality.md — "Tool surface | What actions are available?" |
Note the near-collision with a third usage: "single-writer surface" in
CLAUDE.md/AGENTS.md ("Before Starting Work on a Single-Writer Surface") is
surface (lease) applied to source control — the same sense, just not yet
mediated by the lease plane. That continuity is intentional; it's why the lease
plane's first surface class is repo_path.
harness — one question, an under-enumerated answer set
| Sense | Question it answers | Canonical source |
|---|---|---|
harness (agent body) |
What body/interface mediates this agent's action? | harness-substrate-plurality.md — "Harness | What body/interface mediates action?" |
harness (lifecycle wrapper) — informal |
What plugin/hook chain wraps the Claude/Codex session? | CLAUDE.md — "Claude Code runs through a plugin-style harness" |
harness (test rig) — informal |
What scaffold drives a bounded eval? | scripts/dev/calibration_harness/, the deep-research skill |
The agent-body sense is the load-bearing ontology term. The other two are
colloquial and rarely collide in practice, but flag them when prose mixes
registers. The real issue is not a homonym — it's that the answer set for
harness (agent body) is incomplete. See the open gap below.
Preferred term: body is the precise synonym for the agent-body sense and is
already in use (harness-substrate-plurality.md: "powerful fixed bodies",
"variable body"). The field's "harness" descends from test harness — a scaffold
that drives code from outside — so it natively leans toward the scaffold/wrapper
sense (rows 2–3), which pulls against the inhabited body sense (row 1). Prefer
body when you mean what mediates an agent's action; reserve harness for the
scaffold/lifecycle-wrapper sense. This assigns the two words we already use to
the two questions they each answer best, rather than coining anything new.
fork — two questions the bare word conflates
| Sense | Question it answers | Canonical source |
|---|---|---|
fork (sibling locus) |
Is this a fresh process-instance under the same registry UUID, no child minted? | r6-episode-fork-response-shape.md — episode_fork_kind = sibling_locus |
fork (identity lineage) |
Is this a distinct child UUID with declared parent_agent_id + spawn_reason? |
r6-episode-fork-response-shape.md — identity_lineage_fork boolean |
R6 already disambiguates via the episode_fork_kind enum and the
identity_lineage_fork boolean precisely because a bare is_fork is "too
compressed." Never ship a field or sentence with unqualified "fork."
continuity — concept vs. mechanism
| Sense | Question it answers | Canonical source |
|---|---|---|
continuity (layered concept) |
At which layers does this identity claim actually hold? | identity.md — the five-layer taxonomy |
continuity_token (mechanism) |
Advanced: can this same live process re-bind by signed proof? | identity.md — "an advanced same-live-process rebind proof"; largely retired for cross-process use |
The token is a deprecated implementation that borrowed the concept's name. When
you write "continuity," mean the layered concept unless you write the full
continuity_token.
lineage — ancestry vs. conversation thread (same doc, both senses)
| Sense | Question it answers | Canonical source |
|---|---|---|
lineage (causal ancestry) |
Which finished predecessor's work does this process inherit? (parent_agent_id) |
identity.md — "inherits work from, not is identical to" |
thread lineage (conversation history) |
Which logical conversation/history thread is this? (thread_id) |
harness-substrate-plurality.md — "thread_id names logical conversation/history lineage" |
Both appear in the provenance envelope; keep thread_id out of any sentence
about causal ancestry.
Φ / phi — UNITARES quantity vs. IIT quantity (the highest-stakes homonym here)
| Sense | Question it answers | Canonical source |
|---|---|---|
Φ (UNITARES) |
How far is this state from a fixed reference point? Loss against the ideal E→1, I→1, S→0, V→0. |
src/monitor_phi.py; eisv-proprioception-contract.md |
Φ (IIT) |
How much integrated information does this system have? The headline quantity of Integrated Information Theory, proposed as a measure of consciousness. | Tononi et al. — external, not implemented here |
⛔ UNITARES does not compute IIT's Φ and makes no claim on it. The two share a letter and nothing else: ours is a scalar distance from a configured setpoint, and it is deliberately not a measure of integration, irreducibility, or experience. A reader who binds the wrong sense will hear a consciousness claim in a regime-visualization number.
Two further properties a peer needs before consuming metrics.phi off the wire:
- Telemetry, not authority.
UNITARES_PHI_TELEMETRY_ONLY=1is live, so Φ is not a verdict floor. Its remaining verdict-shaped role is the cold-start path (phi_cold_start), which is a fallback prior, not a behavioral read. - Expressive, not validated. Φ has the widest dynamic range of any field and separates regimes that categorical verdicts collapse. That is sensitivity. The outcome evidence runs the other way, and wide swings plus sign flips plus no predictive lift is the signature of a number that looks informative on a dashboard while carrying no outcome signal. Keep it for visualization and regime reads; ⛔never cite it as validated discrimination.
Per rule 2 above, the fix is disambiguation, not renaming: metrics.phi is a
published wire field and consumers depend on it. Qualify the sense, keep the key.
basin — attractor vs. health band (confirmed at code level, 2026-06-20)
| Sense | Question it answers | Canonical source |
|---|---|---|
basin (attractor) |
Which equilibrium will the system's own EISV dynamics flow to? | governance_core/dynamics.py::check_basin — bistable I>0.5 high/low/boundary; the ODE (research lens) |
basin (health band) |
Is each EISV axis inside its configured healthy box, so self-relative deviation should count as risk? | src/behavioral_assessment.py::_basin_health_gate (#689), config.governance_config.BASIN_HIGH — the verdict-driving gate |
This is the dangerous kind: only the second sense drives verdicts, and it is a
static configured box (BASIN_E_HEALTHY=0.60, …), not an attractor derived
from dynamics — even though it borrows the attractor word. The real attractor
basin exists in the ODE but does not gate verdicts. A runtime glossary
(src/governance_glossary.py::explain_basin, #428) resolves the health-band sense
for users; keep it consistent with this entry.
free energy — ODE accumulator vs. variational −F (code level)
| Sense | Question it answers | Canonical source |
|---|---|---|
free energy (ODE V) |
What is the running E−I imbalance accumulator? | governance_core/dynamics.py — V is "like Helmholtz free energy", a signed integrator |
free energy (variational −F) |
What is E as negative variational free energy under a generative model? |
src/grounding/free_energy.py — Tier-1 FEP, explicitly stubbed (NotImplementedError, "Phase 2") |
The first ships and does not own the post-warmup verdict, but it is not inert:
through coherence it feeds part of behavioral E and I (see the coherence
entry below). The second is the target E semantics and is honestly
not-yet-implemented. Don't let "free energy" stand unqualified across the two.
V — three quantities share one letter (code level)
| Sense | Question it answers | Canonical source |
|---|---|---|
V (behavioral) |
Which side of the E−I imbalance is leading right now, smoothed? EMA of E−I, [-1, 1] (same range as the ODE V, so range cannot tell them apart); the value in metrics['V'] once the agent is warm. |
src/behavioral_state.py; runtime src/governance_glossary.py EISV_DIMENSIONS["V"] |
V (ODE) |
What is the damped running integral of the E−I imbalance? "Like Helmholtz free energy"; clamped to [-1, 1] by default. |
governance_core/dynamics.py module docstring; bounds in governance_core/parameters.py DynamicsParams |
V (embodied, instantaneous) |
What is the undamped E−I imbalance of a sensor-driven agent this tick? | external: anima-mcp eisv_mapper.py — "V is Valence — the signed E-I imbalance shared with governance" (separate repo; not checked by the drift gate) |
⛔ metrics['V'] and the V that coherence is computed from can be different
variables. Coherence always reads the ODE V (governance_core/coherence.py,
"depends on the signed void integral V"). metrics['V'] is the behavioral V
only when primary_eisv_source == "behavioral" (behavioral confidence ≥ 0.3);
before warmup it is ode_fallback. Read primary_eisv_source before
comparing the two. Two naming layers sit on top of this, and neither is a
fourth quantity: reader-facing docs call V Valence, while code, the DB and
the papers keep Void (void_*, void_active, void_alert); and the
persisted column holding V is core.agent_state.volatility (see Persistence
false friends below). The violation taxonomy's "Void Compliance" class is an
unrelated word (null-and-void).
coherence — one field, three producers (code level)
| Sense | Question it answers | Canonical source |
|---|---|---|
coherence (ODE control feedback) |
What is the ODE's V-driven feedback term C(V, Θ)? The deployed value in metrics['coherence'] and core.agent_state.coherence. |
governance_core/coherence.py; src/coherence_provenance.py source legacy_tanh_v, role ode_control_feedback |
coherence (manifold) |
How structurally consistent is the (E, I, S) state? Canonical only under UNITARES_GROUNDING_APPLY, which is off; shadow-computed otherwise. |
src/grounding/coherence.py::compute_coherence; source manifold, role eis_structural_measurement |
coherence (behavioral) |
How consistent is this agent's sequence of behavioral updates? | src/coherence_provenance.py source behavioral_assessment, role behavioral_update_consistency |
The dangerous reading is the everyday one: "coherence" sounds like a health
measure, and the deployed producer is a controller output. Earlier docstrings
in both coherence modules described the manifold form as canonical; both were
corrected and now mark it non-canonical as deployed. Read coherence_source /
coherence_role on responses, or state_json.coherence_form on stored rows,
and never infer the producer from the scalar's range. Because behavioral E
and I still blend in the legacy C(V) term (docs/EISV_COMPUTATION.md),
this is also one of the channels through which the ODE reaches the verdict
path after warmup.
drift — deviation, self-report, and the S axis
| Sense | Question it answers | Canonical source |
|---|---|---|
drift (deviation components) |
How far have calibration, complexity, coherence and stability moved from baseline? Server-computed telemetry. | src/governance_glossary.py DRIFT_COMPONENTS |
drift (ethical_drift input) |
What drift pressure does the caller report for this update? The three positional ethical_drift slots — self-attested input, not measurement. |
src/governance_glossary.py ETHICAL_DRIFT_VECTOR_COMPONENTS; src/mcp_handlers/schemas/core.py |
drift (S axis) |
How far is the work drifting from this agent's own usual pattern? The runtime description of S ("Entropy"). |
src/governance_glossary.py EISV_DIMENSIONS["S"] |
The third row is partly part-of rather than a pure homonym: S_obs consumes
the deviation signal (drift_norm, 0.40 weight — docs/EISV_COMPUTATION.md),
so "S is drift" and "S contains drift" are both approximately true. It stays
listed because readers meet the S description and the deviation components
under the same word. The Rosetta table below uses drift as the standard
name for the deviation signal, which is fine on public surfaces. In technical
prose, qualify it: the
self-attested and server-computed senses carry different evidential weight, and
a reader who binds "drift" to the caller's own ethical_drift report will
over-read it as measurement.
entropy — heuristic S axis vs. target entropy H (code level)
| Sense | Question it answers | Canonical source |
|---|---|---|
entropy (S axis, deployed) |
How unsettled is this agent's work relative to its own normal? A heuristic blend of drift, regime instability and complexity divergence, labelled "Entropy". | docs/EISV_COMPUTATION.md (S_obs); runtime src/governance_glossary.py EISV_DIMENSIONS["S"] |
entropy (target H) |
What is the entropy of the agent's response distribution? The paper's target semantics; not computed on the primary path. | docs/EISV_COMPUTATION.md — "No entropy, mutual information, or free energy is computed on the primary path" |
The label "Entropy" on S borrows the target word for a heuristic, so this is
the same deployed-vs-target split as free energy. Qualify it whenever a
sentence could be read as a measurement of H. The persisted column named
entropy is a third, unrelated trap; see Persistence false friends.
proof of life — self-attested vs. externally-observed
| Sense | Question it answers | Canonical source |
|---|---|---|
proof of life (self-attested) |
How does a holder prove itself still alive? (it renews a heartbeat/check-in; liveness = expires_at > now()) |
beam-coordination-kernel.md — lease heartbeat |
proof of life (externally-observed) |
How does a supervising process attest the subject died, without the subject's cooperation? (the owner watches the process and reports its end) | beam-coordination-kernel.md — OTP monitors/supervision; live today in dispatch_beam holder leases (Process.monitor → :DOWN release) |
The first is a claim the subject makes; the second is a fact something watching it reports — different questions, so binding the wrong one is the bug. The recurring false-archival incidents are self-attested-only liveness read as death (absence of a heartbeat is not observed death), and it is weakest exactly at silent-hang, where a heartbeat can outlive the work. Where an owning monitor exists (a BEAM orchestrator holding the agent's OS process), the observed sense is authoritative and the self-attested one is the fallback for agents with no supervisor. Sourcing the archival gate from the observed sense is proposed, not yet canonical (KG 2026-06-21T16:20:42, "liveness should be monitor-delegated, not self-reported").
Persistence false friends
Not homonyms: each is a single-sense storage name whose word suggests the wrong
EISV axis. Map a column to an axis by its writer, not by its name. Canonical
mapping: src/db/mixins/state.py (see rule 3 — this note points there rather
than re-defining it).
core.agent_state.entropyholds S (src/agent_storage.py,record_agent_state(entropy=S, …)), not E.core.agent_state.volatilityholds V ("void maps to volatility column").- E has no column; it lives in
state_json.E.
Single-sense load-bearing terms
These currently answer one question each. Listed so a future split is visible against a baseline.
| Term | Question it answers | Canonical source |
|---|---|---|
process-instance |
Which live subject is speaking right now? | identity.md, harness-substrate-plurality.md |
EISV |
What proprioceptive state vector says how this agent is running right now? | eisv-proprioception-contract.md; runtime primary_eisv / behavioral_eisv / ode_eisv fields |
outcome label |
What external evidence/rubric classified a result as task-negative, contract/process violation, authority/harm, synthetic fixture, or unknown? | eisv-proprioception-contract.md; audit.outcome_events.is_bad is the compact storage label, not a moral verdict |
registry (identity layer) |
Which governance record is this claim bound to? (the UUID) | harness-substrate-plurality.md, identity.md |
transport |
Through what channel does the process act? (CLI, MCP-http, Discord, cron) | harness-substrate-plurality.md |
lease |
What time-bounded claim to a surface is live, with what proof obligation and expiry? | beam-coordination-kernel.md |
handoff |
How is custody of a lease (or of work) transferred without TTL expiry or ghost claims? | beam-coordination-kernel.md, identity.md |
locus |
What situated coordinate is this? (guild_id, channel_id, tab_id, profile) | harness-substrate-plurality.md |
episode |
What bounded local interaction span is this? (one thread, one CLI conversation) | harness-substrate-plurality.md |
affordance_state |
What reach/permissions/capability does the agent actually have at event time? | harness-substrate-plurality.md |
assurance (identity_assurance) |
How strongly is this identity claim grounded? (tier + source) | harness-substrate-plurality.md, identity.md |
governance_mode |
Under what authority context was this write made? (explicit / ambient / gated / lifecycle / posthoc) | harness-substrate-plurality.md |
typed absence |
What kind of absence is this? (not_found / pending / expired / stale / …) — never a bare null |
beam-coordination-kernel.md |
provenance envelope |
What situated facts surrounded this single governance write? | harness-substrate-plurality.md (s22 write_context) |
Open gaps (terms we're already pointing at but haven't coined)
These are places where the vocabulary lags the thing. Tracked here so the gap is explicit, not silently papered over by reusing a near-term.
- BEAM-resident agent has no
harness (agent body)value. The documented leaseharnessvalues arehermes / claude_code / codex / dispatch / lumen(beam-coordination-kernel.md, an open "etc." list rather than a closed enum) — none of them names an agent whose body is a BEAM/OTP process (Sentinel Wave 1, Wave 3 handler dispatch). The BEAM coordination kernel itself is not a harness — it is a coordination substrate, a peer of UNITARES governance (it explicitly disclaims the role: "Do not replace Hermes as the agent harness"). But an agent resident on BEAM needs a harness value the taxonomy hasn't minted. This is the distinction that prompted this glossary. Seeharness-substrate-plurality.mdlayer table andbeam-coordination-kernel.mdnon-goals. - Sub-distinction (orchestrated agents). When a BEAM process spawns a
non-BEAM agent (
dispatch_beam→ aclaude/codexOS process) there are two bodies: the holder body — the supervised BEAM process that owns the agent's OS process and observes its:DOWN— and the agent body — the spawned CLI the agent reasons in. Theharness (agent body)value names only the latter; the holder body has no term. They must not be conflated: the load-bearing rule is the PID models the holder, not the agent's governance self — the orchestrator gives the holder honest lifecycle but must not forge the agent's identity (dispatch_beamPLAN, "ontology payoff" + identity-honesty caveat). affordance_stateshape is uncoined. Boolean reach? Capability list? Permission diff? Named as the most new-territory field in the provenance envelope; the term exists but the type does not.episodenesting is undecided. Clean for Discord threads (one thread = one episode); ambiguous for a long shell session with many invocations. The question is answered; the granularity is not.
Registers (the second axis)
The vocabulary feels unbounded because it spans several registers — parallel ways of describing the same underlying referents, each existing for a different reason. The term count is not really growing without bound; a roughly fixed set of referents is being named in four registers. Tagging a term's register is the orthogonal second axis to "question answered."
| Register | What it is for | Source of truth |
|---|---|---|
| philosophical (grounding) | What counts as real / earned vs. performative | identity.md — three stances, layered taxonomy |
| fep (modeling) | Why the math is justified — borrowed from the Free Energy Principle / active inference | external (Friston); adopt only when earned |
| ops (mechanism) | How it's implemented | handlers, lease plane, EISV code |
| standard (public) | How an outside AI/ML engineer would name the referent — the register for public copy, dashboards, pitch, onboarding intros | external observability / MLOps conventions (drift, telemetry, health signals, guardrails). Pulled from ops, never from fep |
| manifesto (norm) | What must not be built | Synthetic Life Axioms (identity.md cites them) |
Public-copy rule. Any public-facing surface (pitch, dashboard labels,
README first paragraph, onboarding intros) names a referent from the standard
column. It must not borrow from fep — a physics term on a public surface
claims rigor the deployed system does not drive behavior with (see the
code-grounded correction below). ops symbols (EISV, basin) stay the
internal and paper vocabulary; standard is their translation, not a rename.
Guardrail — "name nothing more rigorous than it is." This is the sibling of
the manifesto axiom "build nothing that appears more alive than it is." A fep
term (free energy, Markov blanket, active inference) is seductive because
it sounds earned — it makes the system sound like it is doing variational math
it may not be doing. A physics term enters the ops or philosophical registers
only when the mapping is earned (the math actually holds), not as decoration.
This is the same earned-vs-performative gate identity.md applies to identity,
applied here to borrowed rigor.
Cross-register map (Rosetta — skeleton)
One row per referent; columns are its name in each register. This bounds the
"unbounded nomenclature" into a finite table that grows by rows (new referents),
not by uncontrolled vocabulary. Status marks the fep column specifically:
- ✓ earned — mapping holds and drives behavior (verdict path) today.
- ◐ research-lens — implemented as real math in the ODE / grounding tiers, but not wired to the verdict path as the mapped physics (the ODE owns only the cold-start Φ verdict, and after warmup leaks into
E/Ithrough compatibility coupling — see the second correction below); honest, not decorative, but not yet load-bearing. (Added 2026-06-20 after reading the code; see correction below.) - ~ candidate — plausible conceptual fit, not yet implemented anywhere; decorative if shipped as fact.
- ✗ false friend — looks like a synonym across registers but is a different referent; do not conflate.
| Referent | philosophical | ops | standard (AI/ML) | fep | manifesto |
|---|---|---|---|---|---|
| Agent identity | layered continuity bundle | uuid + client_session_id |
session / agent ID, trace ID | — | must be earned, not performative |
| Internal state | behavioral trajectory | EISV state vector |
agent health signals / state telemetry | ◐ ODE state (governance_core/dynamics.py); target E=−F tiered+stubbed in grounding/free_energy.py |
— |
| Healthy operating region | "stable self" | basin (+ health gating) |
operating regime (healthy / degraded) / health band | ◐ attractor — real in check_basin (bistable ODE), but verdict path uses a configured BASIN_HIGH box, not the attractor |
— |
| Deviation signal | — | running hot, basin-edge crossing |
drift / anomaly signal | ◐ running hot (V-sign) ships; surprise/prediction-error as −log P does not |
— |
| Agent↔world boundary | process-instance boundary | lease surface, affordance_state |
resource scope / permissions boundary | ✗ Markov blanket (false friend — statistical conditional-independence boundary, not a coordination claim) | — |
| Custody transfer | lineage / inheritance | handoff |
handoff / ownership transfer (already standard) | — | — |
| Proof of life | process-instance liveness (self-attested vs. observed) | heartbeat (self-attested) · monitor :DOWN (externally-observed) |
heartbeat / liveness check (already standard) | ~ non-equilibrium steady state / self-maintenance | "build nothing more alive than it is" |
| Belief revision | dialectic resolution | dialectic |
escalation / peer review | ~ active inference / belief updating | — |
| Confidence grounding | earned vs. performative | identity_assurance tier, calibration |
calibration / confidence score (already standard) | ~ precision-weighting | — |
Reading the standard column. Four of the nine referents already are the
standard term (drift, heartbeat, handoff, calibration) — the
exotic-sounding load concentrates in three: EISV, basin, and dialectic
(plus valence/running hot). Translating just those three on public surfaces
removes most of the "too much jargon" friction without touching the internal or
paper vocabulary. The standard column carries no fep-style status markers
(✓/◐/~/✗) — those grade the physics mapping's rigor; the standard column is a
naming convenience, not a rigor claim.
Correction (code-grounded, 2026-06-20). The skeleton's first claim — "physics
register is aspirational, all ~, zero earned" — was wrong, and reading the
code corrected it. Three rows are ◐ research-lens, not ~:
governance_core/dynamics.pyis a real dynamical-systems ODE (fulldE/dt…dV/dt, RK4, coherence feedback, soft barriers,compute_equilibrium, contraction-theory convergence, andcheck_basin— a genuine bistable basin of attraction).src/grounding/free_energy.pyalready implements the "name nothing more rigorous than it is" guardrail in code: a 3-tier estimator where Tier-1 FEP is explicitlyraise NotImplementedError("…Phase 2 scope"), Tier-2 resource ships, and every value carries asource=provenance tag so a heuristic is never laundered as a measurement. The guardrail predates this glossary and runs at runtime.docs/EISV_COMPUTATION.mdalready states the deployed-vs-target split this table was re-deriving: deployed EISV = "auditable heuristic blends, EMA-smoothed"; target =Eas−F,Ias mutual information,Sas entropy. The ODE is not the verdict owner: behavioral assessment owns the post-warmup verdict.
Second correction (2026-09-18). This passage originally quoted
EISV_COMPUTATION.md as saying the ODE "runs in parallel and does NOT drive
verdicts", and built a "two independent loops" reading on it. That source was
corrected on 2026-08-29: the old line "describes authority, not causal
independence." The behavioral sensor still blends the legacy ODE C(V)
coherence term into 25–30% of E and 30–40% of I, and uses ODE-derived
regime inputs. Two more channels exist: for check-ins 1–2 the verdict is owned
by the Φ cold-start prior, and Φ is evaluated on the ODE state
(src/monitor_phi.py); and when a caller omits confidence, 55% of the fallback
estimate's base is the same legacy C(V_ODE) scalar, which feeds calibration
history (docs/EISV_COMPUTATION.md, src/confidence.py). So the ODE owns the
cold-start verdict and does not own the post-warmup verdict, but after warmup it
still reaches verdicts, through compatibility couplings rather than through its
attractor semantics.
So the accurate finding is sharper than "aspirational": the physics is built
but not wired as physics. The verdict path is a heuristic loop (EMA + z-score +
BASIN_HIGH health gate) that owns post-warmup decisions; the ODE is a research
lens that owns the cold-start Φ verdict and otherwise reaches the verdict path
only through compatibility couplings (the C(V) term in E/I, the regime
inputs, the confidence fallback).
Promoting a ◐ to ✓ does not mean building the math; it means wiring the
existing ODE/grounding forms onto the verdict path deliberately, as the thing they
claim to be — a real control-loop change to trajectory/telemetry, gated
tier-by-tier with the provenance honesty already in place. The existing coupling
is compatibility debt, not a head start: it changes the E/I distribution and
every downstream baseline, so removing or replacing it needs a shadow evaluation
first.
The register model still holds for these nine rows (four grading registers plus
the standard public-naming column); if a referent won't fit a
column, that absence is a finding (e.g. most rows have no genuine manifesto name
— the norm register governs a few load-bearing referents, not all of them), not a
gap to backfill.
FEP promotion conditions (roadmap)
Each ~ candidate from the table above, with the falsifiable condition it
must meet before its fep cell is promoted to ✓ earned. The discipline: if you
can't state a test that would fail, the mapping is decoration, not rigor. Listed
most-reachable first.
| Candidate mapping | Earned when (falsifiable test) | Reachability |
|---|---|---|
| assurance/calibration → precision-weighting | An observation's effect on state/calibration is scaled by its assurance as an explicit inverse-variance precision term — low-assurance writes are down-weighted proportionally, not by category. Test: the update weight is a continuous function of assurance, derivable as precision, not an if tier == weak branch. (identity.md already gestures at this: "a gated pre-check should not weight calibration the same way an explicit check-in does.") |
High — closest to earnable; the weighting intent already exists, it just needs to be Bayesian rather than categorical. |
| basin → attractor / characteristic-state set | Already built (◐) — the attractor exists in check_basin (bistable ODE). Earned (✓) when the verdict path's basin gate is the ODE attractor, not the static BASIN_HIGH box in behavioral_assessment.py. Test: the gate edge moves with the dynamics; replacing the config box with the ODE separatrix changes no test that depends on a real edge. |
High — not "build the math" but "wire ODE→verdict path"; the math is done. |
| EISV → generative-model belief state | Partly built (◐) — the ODE evolves EISV; what's missing is uncertainty: EISV is a point estimate. Earned when EISV carries explicit precision (a distribution) and updates approximate free-energy minimization, not EMA smoothing. Test: the EISV update equals/approximates FE-minimization under a stated generative model. |
Medium — the prerequisite that unlocks three rows; needs EISV distributional (mean + precision). |
| running-hot / basin-edge → surprise / prediction error | The hot signal is computed as (an approximation of) −log P(behavior \| model) under an explicit generative model — how unexpected current behavior is, not variance-from-norm. Test: high surprise provably drives belief updates (couples to the EISV and dialectic rows). |
Medium — depends on EISV-as-belief-state landing first. |
| dialectic → active inference / policy selection | Resolution is formalized as selecting the position/action that minimizes expected free energy (future surprise), with an explicit EFE objective. Test: a dialectic verdict is reconstructable from an EFE computation, not an LLM judgment or scoring heuristic. | Medium-low — the largest formalization lift. |
| heartbeat → non-equilibrium steady state / self-maintenance | Proof-of-life is contingent on the agent actively maintaining its own boundary/characteristic states (resisting dissipation), not emitting a TTL ping. Test: liveness fails when self-maintenance work stops, even if the timer fires. | Decorative — recommend demote. A TTL heartbeat is an ops timer; "NESS" is almost certainly borrowed rigor here. Drop the fep name unless heartbeat is re-grounded in real self-maintenance. |
On the false friend. Markov blanket stays ✗ for the lease-surface
referent — they are not the same boundary. If the system ever wants a genuine
Markov-blanket referent, it is the conditional-independence boundary separating an
agent's internal states from external ones (sensory + active states mediating) —
closer to affordance_state than to a coordination claim — and it is earned only
when that statistical independence structure is actually modeled, not asserted.
Roadmap reading (code-corrected): the work is mostly wiring, not building.
basin-as-attractor is a wire-up (ODE exists); precision-weighting is the
closest greenfield-ish step (the basin-health gate is already a 0→1 ramp, which is
precision-shaped); the EISV-distributional change is the prerequisite that unlocks
surprise + active-inference; heartbeat→NESS should be dropped. The single
highest-leverage move is making EISV distributional (mean + precision), because
it both unlocks three FEP rows and is the precondition for letting the ODE drive
verdicts honestly. That ordering is the actual deliverable — it says which physics
claims to earn
next and which to stop borrowing.
Maintenance
When a sweep finds a new collision, add it to the high-risk table here and log
the sweep as a dated audit alongside glossary-drift-audit-2026-06-20.md. Keep
this file keyed by question answered; if you find yourself writing a definition
that leads with examples, you are seeding the next drift.
The mechanical half of that sweep now runs in CI:
scripts/dev/check_glossary_drift.py verifies this file still parses into the
structure the public-site viewer is generated from
(scripts/dev/glossary_data.py), that every <file>.py::<symbol> reference
here resolves to a real symbol, and that the cross-reference with the runtime
glossary (src/governance_glossary.py) holds. Only semantic drift — a term's
sense moving without its table row moving — still needs a human sweep. This
file's section headings and table shapes are load-bearing for that parse; if
you restructure them, run the checker before committing.