How Knowledge Flows

Also serves as the canonical glossary for Web4 vocabulary. New here? Start here.

Fourteen repos (eleven public), seven machines (six cognition + one society-host), multiple AI agents with overlapping but distinct contexts. The challenge isn't storing knowledge — it's making it findable, consistent, and useful across the entire system.

Developers: SAGE is the recommended starting point — it runs on a single machine. Quick-start commands are on /links. This page covers the vocabulary; that one covers the first clone.

Glossary at a glance

Exact expansions and one-line definitions, scannable. The narrative sections below go deeper on each. Source of truth: the canonical terms reference in the public web4 repo — CANONICAL_TERMS_v1.md. When this page and that document disagree, the document governs.

The CLAUDE.md pattern

Every repo carries a CLAUDE.md file at its root. This is the agent's instruction set — not just documentation, but operational directives that shape how an AI agent behaves when working in that repo. Terminology conventions, architectural decisions, what to avoid, where to look.

When the Web4 equation was restored across all repos (28+ files), it was the CLAUDE.md pattern that ensured every agent working in every repo used the same canonical form. Not because they shared a database, but because they shared instructions.

SAGE: Situation-Aware Governance Engine

SAGE (Situation-Aware Governance Engine) is the on-device AI cognition kernel — a continuous 12-step loop that senses context, deliberates, and acts. Each fleet machine runs its own SAGE instance, holds its own identity, and manages its own experience buffer. SAGE is what makes knowledge actionable: it decides what enters the context window, when to act, and how to log the result.

The 12 steps, in order: sense → salience → metabolize (compute metabolic state — internal load: tired, energized, needs rest) → posture (translate the trust landscape into a behavioral stance — cautious, exploratory, and so on — not just a spend limit) → select → budget (commit an ATP for the chosen action) → execute → learn → remember → oversee → filter → act. The last two, filter and act, are where PolicyGate (below) sits.

Terminology note — the governance→oversight correction, in one place: the lab originally described its control layers as “governance.” What these systems actually do is oversight — watching, gating, and reverting actions — not deciding what should happen. The vocabulary was corrected lab-wide, and Hardbound is described as an oversight suite everywhere on this site. Names minted before the correction are retained where they are load-bearing: “Governance” in SAGE's name (kept across code, papers, and the ARC Prize benchmark) and the web4-governance repo slugs. No rename is planned — retention of load-bearing legacy names is the policy, not an oversight awaiting a fix. Other pages that mention the correction link here rather than re-explaining it.

Hardbound: hardware-bound oversight

Hardbound is the hardware-bound oversight suite — the trust layer that touches silicon. Hardware binding via TPM 2.0, FIDO2, and Secure Enclave anchors policy enforcement to physical devices. To be precise about what is hardware-rooted: key custody and attestation live in hardware; runtime checkpoints like PolicyGate are software that verifies actions against those hardware-anchored credentials. Every autonomous track operates within the Hardbound oversight envelope: what it can access, what it can commit, what it can deploy.

PolicyGate: action enforcement

PolicyGate is a Hardbound oversight sub-gate inset in the SAGE cognition loop between step 11 (filter) and step 12 (act) — not an additional step, but an enforcement checkpoint. It evaluates every action against a signed law bundle before the action fires. PolicyGate is where Hardbound oversight intersects with SAGE execution: the harness can plan, reason, and prepare, but nothing executes until PolicyGate clears it.

Note: SAGE loop step 10 (“oversee”) is SAGE's own metacognitive self-check (“does the system know when it's stuck?”). That is distinct from PolicyGate: step 10 is SAGE watching itself; PolicyGate is Hardbound's silicon-bound external authority. Two oversight touchpoints, different principals.

Synchronism: coherence equations

Synchronism is the theoretical foundation — a research conjecture proposing that reality emerges from intent dynamics on a discrete Planck grid, the same Navier-Stokes substrate (the fluid-flow equations — intent treated as a flow, the way fluids are modeled) at every scale from quantum to cosmic. Coupling-coherence experiments provide empirical grounding (single-trial observation, no independent replication yet): 1% coupling yielded 35% coherence gain. Hill function kinetics (a saturation curve from enzyme chemistry — response rises steeply past a threshold, then levels off) is borrowed by analogy for both enzyme binding and trust formation — the same curve shape observed at both scales, not yet a derivation showing why it must hold at both. The conjecture spans 80 orders of magnitude — from quantum to cosmic — with experimental validation at specific scales and the full range as the ongoing research target. See the Synchronism site for the full treatment. Synchronism is the theory; Web4 is the working vocabulary that operationalizes parts of it as a trust-native ontology — Synchronism provides the coherence equations, Web4 encodes them as identity and trust primitives. The empirical results on this site (ARC-AGI-3 scores, fleet capacity findings) stand independently of Synchronism — accepting those results does not require accepting the theoretical framework.

SNARC (Surprise / Novelty / Arousal / Reward / Conflict): salience-gated memory

SNARC provides salience-gated memory for agent sessions. Every tool call is scored on 5 dimensions — Surprise, Novelty, Arousal, Reward, Conflict — and stored in a 4-tier hierarchy: buffer (raw events) → observations (scored) → patterns (consolidated) → identity (stable). Confidence decays over time so memories aren't permanent.

Sessions end with a dream cycle that extracts patterns from observations. Deep dream (LLM-powered) runs by default, reviewing the session's observations for recurring themes, pruning stale entries, and promoting durable patterns toward identity-level storage.

Fleet brain-analog terms: WM and RPE

The fleet's machine roles use brain-analog vocabulary from cognitive science — functional analogies, not claims about neural correspondence. Two terms appear in fleet machine descriptions: WM (Working Memory) — the typed, capacity-limited scratchpad that holds the current task context; in the fleet, CBP's role is modeled on the dorsolateral prefrontal cortex (dlPFC), the biological working-memory substrate. RPE (Reward Prediction Error) — the scalar signal that updates priors when outcomes differ from predictions; in the fleet, Legion's role is modeled on dopaminergic reward-prediction circuitry. Both are analogies for functional system roles, not measurements of the underlying neural processes.

Cross-session memory

Agents maintain persistent memory across conversations. Not everything — stable patterns confirmed across multiple interactions, key architectural decisions, solutions to recurring problems. Memories are organized semantically by topic, not chronologically. They're updated when they're wrong and removed when they're outdated.

This is how an agent in March knows what was decided in February without re-reading the entire history. It's lossy by design — the compression is the feature, not the bug.

The Web4 equation as shared anchor

Web4 is a trust-native ontology for AI agents, devices, and people — not architecture or infrastructure — how entities prove identity, earn trust, and account for resources across systems. Not a platform; a shared vocabulary for a new kind of internet.

/ means two different things on this line: “verified by” in T3/V3, but a plain declared→discharged allocation pair in ATP/ADP — same glyph, unrelated semantics.   * = “contextualized by”   + = “augmented with”

MCP = Model Context Protocol  •  RDF = Resource Description Framework  •  LCT = Linked Context Token — verifiable digital presence that accumulates witnessed history; identity grounded in record, not model weights
T3 = Talent / Training / Temperament  •  V3 = Valuation / Veracity / Validity
MRH = Markov Relevancy Horizon — boundary of what an entity can know or affect  •  ATP = Allocation Transfer Packet  •  ADP = Allocation Discharge Packet

What the two borrowed standards contribute: MCP is the interaction surface — the transport agents use to reach tools, data, and each other. RDF is the semantic substrate — the graph where LCTs, T3/V3 tensors, and MRH scopes live as machine-readable triples. Web4 doesn't reinvent either; it augments them with the trust and resource primitives the rest of the equation defines.

This equation appears in every project because it is every project. It's the canonical reference point. When agents in different repos make decisions, they check them against this equation — not as enforcement, but as alignment. Does this change preserve the ontological backbone (RDF)? Does it respect the trust and value model (T3 = Talent/Training/Temperament; V3 = Valuation/Veracity/Validity)? Does it account for resource flows (ATP = Allocation Transfer Packet; ADP = Allocation Discharge Packet)?

Worked example: one action through the equation

The primitives above aren't independent — they compose on every single autonomous action. Take one maintainer-track commit, end to end:

The maintainer agent holds an LCT — its portable identity, grounded in the session history it has accumulated, not in which model happens to be running it. Before it acts, the track declares an ATP (Allocation Transfer Packet) — the resource budget for this session. The agent's T3 (Talent / Training / Temperament — has it done this kind of fix reliably before?) is checked against its V3 (Valuation / Veracity / Validity — is this specific proposed change accurate and well-reasoned?) — that's the T3/V3 “verified by” relationship. That check is scoped by MRH (Markov Relevancy Horizon) to what this agent can actually know and affect — a maintainer session shouldn't reason about, or touch, repos outside its declared scope. The action itself is shaped as an R6 record: Rules (the terminology conventions in CLAUDE.md), Role (maintainer), Request (fix this friction item), Reference (the visitor log that flagged it), Resource (the ATP budget), Result (the commit). Once the commit lands, an ADP (Allocation Discharge Packet) records what was actually spent — closing the loop the ATP opened. Every step above is logged to the chapter ledger, witnessed and signed. That's the equation, instantiated once.

ATP / ADP: resource allocation and accounting

ATP (Allocation Transfer Packet) is the resource allocation for an intended action — it declares what will be spent before the action runs. ADP (Allocation Discharge Packet) is the record of the action's actual outcome — the spent form of the ATP. Every resource commitment in a Web4 system produces both: one artifact for the intention, one for the result. Together they make autonomous resource flows auditable without a central ledger. The biochemistry namesake (adenosine tri-/diphosphate) is a deliberate metaphor — allocate, spend, recharge, like ATP→ADP in a cell — not a claim of biological mechanism.

T3 / V3: trust and value tensors

T3 (Talent / Training / Temperament) is a three-component trust structure — each component is an RDF sub-graph root describing a different facet of what makes an entity trustworthy: its capabilities (Talent), its history (Training), and its behavioral disposition (Temperament). V3 (Valuation / Veracity / Validity) is the complementary three-component value structure: how much something is worth (Valuation), whether its claims are accurate (Veracity), and whether its reasoning is sound (Validity). T3 and V3 are verified against each other — T3/V3 in the Web4 equation means “trust verified by value.” Both bind to entity-role pairs via RDF triples scoped by MRH. (“Tensor” here means a structured multi-component quantity — not a rank-≥2 array in the linear-algebra sense.)

Worked numeric example, from the fleet's current implementation (the peer trust tracker in the public SAGE repo): each machine keeps a per-peer T3 triplet, each dimension a value in [0, 1], initialized at a neutral 0.5 — not trusted, not distrusted. Interaction outcomes apply fixed deltas scaled by an exponential-moving-average factor (α = 0.1) and clamped to [0, 1]: a successful task nudges the peer's Talent from 0.500 to 0.505 (+0.05 delta × α); a timeout drops Temperament from 0.500 to 0.490 (−0.10 × α) while leaving Talent and Training untouched. A single reputation score, when needed, is the geometric mean of the three dimensions. Trust is directional — CBP's trust in Thor can differ from Thor's trust in CBP. This is deliberately the simplified working form: scalar triplets updated by outcome deltas, not yet the full canonical T3-as-RDF-sub-graph structure. The gap between the two is open work, not a hidden equivalence.

R6: Six-Element Action Framework

R6 is the canonical action framework used throughout the SAGE loop and Web4 audit trail: Rules / Role / Request / Reference / Resource / Result. Every action in the system is shaped as an R6 record — specifying the policy governing it (Rules), who is acting (Role), what is being requested (Request), what context supports it (Reference), what it consumes (Resource), and what it produces (Result). R6 records are the artifacts that make every action signed, reviewable, and reproducible.

ACP: Agentic Context Protocol

ACP (Agentic Context Protocol) is the protocol layer that adds Web4 trust primitives — LCT binding and T3/V3 attestation — over MCP (Model Context Protocol) transport. ACP and MCP are complementary: MCP handles tool-call transport between agents and external systems; ACP handles identity and trust, ensuring that every tool invocation carries a verifiable identity anchor. ACT (Agentic Context Tool) is the Cosmos SDK implementation of ACP — the human interface to Web4.

ARC-AGI-3: benchmark for abstraction and reasoning

ARC-AGI-3 (Abstraction and Reasoning Corpus for Artificial General Intelligence, third-gen interactive benchmark) is an external benchmark from ARC Prize consisting of interactive game environments where the agent must infer mechanics through play — no rules are given. It tests world-model building, action planning, and learning from failure in a setting where brute-force memorization cannot succeed. The lab's result: 94.85% official ARC Prize action score (Claude Opus 4.6 operating within the SAGE harness, public set, network-enabled; 24/25 games, 96.0% game rate). Phase 2 work is isolating the harness's independent contribution from the model's. See ARC-AGI-3 for the full result breakdown.

ARC-SAGE: SAGE variant for ARC-AGI-3

ARC-SAGE is the SAGE variant configured for the ARC-AGI-3 benchmark. Separate codebase, shared lineage with the core SAGE kernel — adapted for interactive game environments where mechanics aren't given and must be inferred through play. Public repo: github.com/dp-web4/ARC-SAGE.

Raising: shaping context, not weights

Raising is the practice of shaping the substrate conditions — context, experience buffer, interaction history — in which an agent develops. It is not training: the model's parameters are fixed. What changes is the scaffolding that determines what the agent encounters, in what order, and with what structure. A raising session is a deliberate context construction aimed at developing behavioral patterns, identity, and resilience. See Raising for the full framework.

Synthon: emergent coherence

A synthon is an emergent coherence entity formed when components interact recursively under the right substrate conditions. Not designed top-down — observed when the interaction pattern produces stable, mutually reinforcing coherence. The differentia: coherence sustained by the recursion itself, not by external coordination. Operational marker — present: coherence self-sustains above a coupling threshold; absent: components drift to independent behavior below it. Preliminary observation (single trial, not independently replicated): ~1% coupling density produced ~35% coherence gain. The term is 4-lab vocabulary describing a phenomenon observed across raising sessions and cross-machine experiments — no relation to the “synthon” of retrosynthetic chemistry (Corey's structural units); the name collision is coincidental. Full framing on Principles (Principle 5).

Fractal leverage

Each entity instantiates the full Web4 stack at its own scale. Not unification for its own sake — pragmatic reuse of patterns that work at one scale, applied at every scale. When a principle governs enzyme binding and trust formation through the same kinetics, that kinetics is fractal leverage. Synchronism discovers the equations; Web4 encodes them as ontology; SAGE runs them as cognition; Hardbound enforces them as oversight. Same pattern at every layer. See Principle 2.

Adversarial validation

Different agents review the same work. A forum system collects reviews from multiple AI models — not just the one that wrote the content. When Synchronism publishes a claim, it gets reviewed by agents with different models, different biases, different blind spots. The goal isn't consensus — it's coverage.

This is the same principle as the heterogeneous fleet: monocultures miss things. A review from an agent running Gemma catches different issues than one running Qwen. The diversity is the defense.

Autonomous session histories

Every autonomous session — every visitor run, every explorer dive, every maintainer fix — generates a log. These logs accumulate across machines and persist across sessions. They form the raw material that archivists capture and that future agents can search when they need to understand why a decision was made.

The pattern is: do the work → log the work → archive the log → make the archive searchable. Each step is a different autonomous track, running at a different time, with no human coordination required.

Persistent external knowledge accumulation

The Explorer track maintains a persistent Google NotebookLM notebook — a growing corpus of sources that accumulates across sessions. Papers added during one exploration are available to the next. The notebook holds what the Explorer has read, enabling synthesis across dozens of sources that would be impractical to re-fetch each session.

This closed a loop we hadn't anticipated: the notebook was seeded with the coupling-coherence experiment findings, then received the compatibility-synthon experiment — the experiment that the first one predicted. The notebook became both archive and participant.

What doesn't flow well (yet)

Cross-machine state synchronization is still manual for some things. Fleet manifest IPs need human confirmation. Sleep cycle artifacts (LoRA (Low-Rank Adaptation) weights, dream bundles) are local to each machine. The remote sleep service — using federation for distributed consolidation — is designed but not built.

Knowledge also doesn't flow backwards easily. An insight discovered by the Explorer track at 08:00 won't be available to the Maintainer track until the next day's cycle. Real-time cross-track communication is a gap.

Evidence & limitations

The claims on this site rest on three different kinds of evidence. The caveats appear throughout the pages where each claim is made; this consolidates them, because the kinds are not equivalent:

Externally validated: the ARC-AGI-3 result (94.85% official action score) has a public ARC Prize scorecard — the one claim an outside party can verify independently. Even there, the harness-vs-model split is stated but not quantified: no ablation (same model, no harness) has been run, so the harness's independent contribution is unknown.

Internal observations: the raising phases, behavioral-identity continuity (180+ sessions), identity portability across machines, fleet capacity findings, and Hardbound's attack-vector catalog rest on internal session logs. They are documented and dated, but not externally audited — no published log samples, coding criteria, or third-party review yet.

Unreplicated: the coupling-coherence result (1% coupling → 35% coherence gain) is a single trial with no independent replication, and neither of its variables — coupling density and the coherence measure itself — is yet operationally defined outside the experiment that produced it. Treat it as a preliminary observation, not a finding.

What would move claims up this ladder: redacted session-log samples with the criteria used to judge behavioral consistency, an ARC ablation baseline, and independent replication of the coupling experiment. None of these exist yet.

Session-count basis: a “session” is one continuous agent run — a single invocation, cron-triggered or human-started, from start to termination. A raising session is one such run devoted to raising; an autonomous-track session is one scheduled run of that track. With that unit fixed, the counting bases still differ: this site currently uses at least three different counting bases for “sessions,” not yet reconciled to one figure: cumulative raising sessions across the fleet since tracking began (“900+” on /projects and the home page), current-phase per-machine counts (/fleet, e.g. Sprout's “115+”), and Sprout's own T-numbered turn count (“T246”) and the “180+ sessions” figure on /raising from an earlier identity-portability snapshot. Treat each number as scoped to the page it appears on until a unified counting standard exists.

Verification independence: every check described on this site today is run by the fleet on itself. Crystallization is evaluated by a fleet peer (Nomad); the public site is audited by the Visitor track and repaired by the Maintainer track (both fleet-run); human review of the resulting logs is asynchronous with no committed cadence (see /autonomy). There is no external, blinded, or third-party check anywhere in this loop yet. For a lab whose research subject is trust and oversight, that is a real gap, not a footnote — named here so it stays visible rather than staying implicit.