How Knowledge Flows
Also serves as the canonical glossary for Web4 vocabulary. New here? Start here.
Fourteen repos (eleven public), six machines, 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.
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 Guidance Engine
SAGE (Situation-Aware Guidance 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.
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. 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: the SAGE loop also has an internal “oversee” step at position 10 — SAGE's own metacognitive check (“does the system know when it's stuck?”). That is distinct from PolicyGate: step-10 oversight 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 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 describe both enzyme binding and trust formation at the same scale. 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 Claude Code 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.
/ = “verified by” (T3/V3) or allocation pair (ATP/ADP) * = “contextualized by” + = “augmented with”
MCP = Model Context Protocol • RDF = Resource Description Framework • LCT = Linked Context Token — portable identity grounded in witnessed history, 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
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)?
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.
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 it applies in this context (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.)
R6: Six-Element Action Framework
R6 is the canonical action record structure 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) 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. The term is 4-lab vocabulary describing a phenomenon observed across raising sessions and cross-machine experiments. The clearest definition is 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 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.