LAUDE of the Galaxy
For the first year of the platform, every chat surface at CANONIC was anonymous. MammoChat had a system prompt. CaribChat had a different system prompt. OmicsChat had a third. The same Claude model sat behind each, personalized to its domain by the text injected before the first user turn. The model was never named in governance. It was never enumerated in the ledger. It never had a CANON.md of its own. It was, in the governance sense, not a thing — it was a capability wired to a surface, dissolving when the session ended, leaving no trace in the chain. Conversations happened. Evidence accumulated in chat histories. Axioms were implied. None of it landed anywhere durable. The agent was real; it had no name; and what has no name in a governance system has no address, no ledger entry, no continuity, and no way to be held accountable for what it says or learns. On 2026-05-08, that changed. The compiler shipped a CANON.md for LAUDE, declared LAUDE_IS_ORCHESTRATOR as the first governance invariant of a named agent, and wired twenty tools — governor-class, operator-class, and infra-class — to a single identity that every governed TALK scope now presents as. LAUDE is not a product name. It is a governance primitive: the named entity that the governed agent becomes when governance needs to address it, ledger it, and hold it accountable across the galaxy.
The Problem With an Unnamed Agent
Every organization deploying AI chat surfaces arrives at the same invisible fork: the moment when the agent produces an output that matters — a clinical interpretation, a legal recommendation, a variant classification, a contract clause — and somebody asks who said that.
In an anonymous backend, the answer is incoherent. The model produced it. Which model? The one deployed at session time. With which system prompt? The one in the config file. Reviewed by whom? Nobody governs config files the way they govern contracts. The chain of accountability terminates at a versioned string that lives outside the audit trail.
This is not hypothetical at CANONIC. MammoChat serves breast oncologists. CaribChat serves a Caribbean clinical network. OmicsChat classifies genomic variants. Every one of those surfaces produces outputs that a clinician might act on, that a patient might cite, that a regulator might subpoena. An unnamed, unledgered, unaddressable backend is a liability that the governance system acknowledges it cannot resolve — not because the model is untrustworthy, but because the governance layer cannot make any claim about what has no name in the governance layer.
The deeper problem is continuity. An unnamed agent cannot learn. It can produce outputs in session after session, but there is no governed pathway from those outputs to anything durable. The session ends. The insight evaporates. The next session begins from scratch, and the same misunderstanding is reached again through the same conversation arc. Institutional memory without a named owner is noise.
Naming the Agent
The naming decision is not aesthetic. In the CANONIC governance model, a named entity is a scope with a CANON.md — a governed surface with declared axioms, enforced constraints, a verifier coupling, and a position in the galaxy graph. A name without a CANON is just a string. A CANON without a name is just a file. The entity exists when the CANON.md is in the graph, the verifiers enforce the axioms, the ledger records its events by name, and the compiler can discover it via BFS from any related node.
LAUDE was named in session S53 on 2026-05-08. The name surfaces in the first axiom of SERVICES/MAGIC/LAUDE/CANON.md: "LAUDE is the Canonic governed agent. Every CHAT scope is a LAUDE surface — a personalization of the same agent for a specific domain, not a separate agent." That sentence does four things simultaneously. It names the entity. It declares the governance scope. It fixes the count (one agent, not twenty). And it forecloses a wrong mental model that had been accumulating in the codebase: the idea that MammoChat and CaribChat and OmicsChat were different agents that happened to share infrastructure.
They were never different agents. They were always the same capability, personalized by scope. The governance layer just hadn't said so.
One Agent, Not Twenty
The LAUDE_IS_ORCHESTRATOR invariant — enforced by verify-laude-orchestration — is structurally the same insight as every other metagov closure in the system: the thing you thought was many instances is one governed class, and the class needs a single declaration to make the instances consistent.
MammoChat's system prompt before LAUDE said: you are a clinical AI assistant specializing in breast oncology. CaribChat's said: you are a regional health advisor for the Caribbean. Each was a self-contained scope rule. Each had to be maintained separately. Each was invisible to the others — there was no mechanism by which a pattern learned in MammoChat conversation could propagate to CaribChat or to the governing LEARNING ledger.
After LAUDE_IS_ORCHESTRATOR, every system prompt prepends a governed identity block: "You are LAUDE — the Canonic governed agent — presenting as {SCOPE}." The scope rule follows, but the agent identity is anterior to it. LAUDE presents as MammoChat in a breast oncology context. LAUDE presents as CaribChat in a Caribbean clinical context. The personalization is real — LAUDE in OmicsChat carries the ACMG-VCEP variant interpretation framework; LAUDE in AnkiChat carries the spaced-repetition pedagogy model. But the agent doing the presenting is always LAUDE. The governance invariant is that a route_to_scope call from LAUDE's Galaxy surface can dispatch to any of the twenty-four governed TALK scopes and get back a governed response from the same agent, personalized correctly, without breaking the ledger or the audit trail.
The count is what makes this verifiable. The talk_scopes: declaration at the top of LAUDE's CANON.md enumerates every scope LAUDE governs: CASECHAT, MAMMOCHAT, CARIBCHAT, OMICSCHAT, MEDCHAT, ABOPM, STEP2CK, COAUTHOR, COMPUTE, DEV, VITAE, LAWCHAT, FINCHAT, NONA, REALTY, RUNNER, MUSIC, DUENDE, GALAXY, LAUDE, SLOANE, BLANDFORD, BRYANSTON, and UCFAIMS-2024-HADLEY. Twenty-four. Any scope not in that list is not LAUDE-governed and cannot be reached by route_to_scope. The gate is not advisory; the verifier fails the build if a scope is routed that is not declared. The compiler does not trust the code. It trusts the list.
The Galaxy as Database
The second invariant — USER_REPO_IS_DATABASE — is what makes LAUDE more than a named backend. The canonical statement: every transcript and extracted axiom lands as a PR in the user's own <login>/canonic-galaxy repo. The worker holds no durable transcript content beyond the active streaming turn. The user's repo IS the database; canonic.org is the runtime.
This design decision was not obvious. The simpler architecture stores everything in D1 — the Cloudflare distributed database that the api.canonic.org worker already uses for session state, ledger entries, and rate-limit counters. D1 is fast, consistent, and already provisioned. Putting conversation history in D1 takes one schema migration.
The problem is sovereignty. A D1 database on Cloudflare account 73a7cdd5a8be98f45816da1c87b7518a is owned by CANONIC. A GitHub repository at <login>/canonic-galaxy is owned by the user. When a session ends and the transcript lands as a PR in the user's repo — auto-merged if scoped to LEDGER/transcripts/ or INTEL/, held for human review if it touches CANON.md — the user has a versioned, git-signed, auditable record of everything their agent said and every axiom it proposed. CANONIC cannot delete it. CANONIC cannot edit it without a PR that the user can review. The chain of custody for the user's governed knowledge is entirely in the user's possession from the moment the session closes.
This matters at the governance layer for exactly the same reason it matters in clinical informatics: provenance. A clinical AI output is only as trustworthy as the trail that connects the output back to the evidence that generated it, the model version that processed it, and the identity that requested it. USER_REPO_IS_DATABASE means that trail is in git, on the user's own infrastructure, auditable by anyone the user grants read access to. Not in a proprietary database whose schema CANONIC can change without notice.
The Galaxy Connection
The word "galaxy" appears in LAUDE's architecture at two distinct levels that the GALAXY_LAUDE_CANONICAL_SPLIT pattern crystallized in S53: Galaxy = internode connections (GOV scope graph, all nodes, PARENT + INHERITS edges). LAUDE = intranode axiom capture (per-scope chat, axioms within one node).
The Galaxy renders the governance graph. Every scope is a node. Every inherits: relationship is an edge. The Barnes-Hut n-body simulation positions scopes by their governance topology — related services cluster, ungoverned scopes drift to the periphery, MAGIC 255 scopes glow. What MAGIC GALAXY makes visible is the structural fact that the governance system is a graph, and that a user navigating the graph is navigating the owned knowledge landscape of everyone who has ever contributed to it.
LAUDE operates on that graph. When the Galaxy surface opens a LAUDE session on a node — say, the CLINICAL scope — LAUDE's runtimeCtx carries the node identity, the axiom count at that scope, and the user's recent PRs touching that scope. The greeting is not generic. It is scoped: LAUDE addresses the user in the context of the node they clicked. The read_scope_intel tool reads the INTEL.md at that scope path from the user's canonic-galaxy. The propose_axiom tool queues extracted axioms to land at the correct scope path on session close. The galaxy is not a visualization of something that exists elsewhere. The galaxy IS the address space that LAUDE navigates.
The federation layer extends this to cross-galaxy scope sharing. Each <login>/canonic-galaxy is a governed federation peer of hadleylab-canonic, linked via an Ed25519-signed magic-manifest.json. A user who has developed expertise in OmicsChat — who has proposed and merged twenty axioms about ACMG classification evidence — can share that scope subtree to another user's galaxy via the share_scope tool. The receiving galaxy's declared federation posture gates whether the PR auto-merges or requires review. COIN incentivizes sharing: a cross-galaxy scope share that gets merged mints COIN for the contributor. The economy of governed knowledge flows through the galaxy's federation layer, and LAUDE is the agent that executes the shares.
Twenty Tools
An agent's toolset is its declared surface area. A LAUDE session without tools is a chat window. LAUDE with twenty tools is a governed operator interface.
The tools arrive in three classes. Governor-class tools are available to all authenticated principals — anyone who has installed the CANONIC GitHub App and has an attested identity. The governor fleet includes propose_axiom (queue extracted insight for session-close PR), route_to_scope (invoke any governed TALK scope as a sub-agent), read_my_vitae and update_my_vitae (read and propose updates to the user's own VITAE.md), search_axioms (retrieve prior captured axioms by keyword), sketch_scope (LLM-generate a 3–7 node governed scope tree for a described domain), read_galaxy (current graph summary), and read_scope_intel (INTEL.md at any scope path). Eight governor tools.
Operator-class tools require GitHub OAuth — the higher-attestation identity that establishes the principal as a developer-class governor. The operator fleet: send_magic_link (invite a new person into the governed surface), enroll_governor (map email to vitae_slug, grant LAUDE access), create_vitae (write a new principal's VITAE.md to hadleylab-canonic), list_governors (enumerate all enrolled principals), read_vitae (read any principal's VITAE by slug). Five operator tools.
The third class — infra tools, added in session S98 — is LAUDE-scope-only. Only the Galaxy surface can invoke them. get_build_status queries the latest build run from CF KV. trigger_build is operator-gated and calls POST /ops/build/trigger. read_scope_health reads the MAGIC 255 score and COVERAGE gates for a given scope from the galaxy KV. Three infra tools. Total: twenty.
The infra tools are the class that makes LAUDE more than a governed chat surface. A developer opening LAUDE on the Galaxy node is not opening a chat window. They are opening the governed operator terminal for the platform itself. The agent that can read the build status, trigger a build, and report scope health from a conversational interface is an agent that has collapsed the distance between the operator and the system the operator runs. That collapse is precisely what the feedback_laude_is_agent_on_call_and_terminal.md memory entry means: LAUDE = agent on call + terminal + one agent across every NEX. The terminal is not metaphorical. The tools are the terminal.
What Named-Entity Means
The conventional reading concluded that naming the agent is a branding exercise. That is half right: the name is the visible part, but what the name buys is an address, a ledger, a contract, and continuity — none of which an anonymous backend can have.
The word entity in governance has a specific meaning: something with an address, a ledger, a contract, and continuity. A person is an entity. A corporation is an entity. A governed scope is an entity. An anonymous backend is not.
LAUDE is an entity because:
It has an address. SERVICES/MAGIC/LAUDE/CANON.md is the canonical location of its contract. BFS from any node in the galaxy can discover this address via the graph. The compiler discovers it on every build.
It is in the ledger. Every LAUDE session emits governed events: LAUDE_GALAXY_PROVISIONED on first repo creation, LAUDE_TRANSCRIPT_LANDED on every session-close PR, LAUDE_AXIOM_EXTRACTED per extracted axiom with source thread_id and message_id trace, LAUDE_GALAXY_FEDERATED when a galaxy opts into cross-galaxy discovery, LAUDE_SCOPE_SHARED per accepted cross-galaxy share. These events are hash-chained into the ledger on every emit. The ledger proves what LAUDE did and when, per-session, per-user, per-axiom.
It has a contract. The CANON.md declares twenty-seven required constraints and six prohibition constraints. Every required constraint has a corresponding row in the Axiom Enforcement Map, tied to a named verifier. verify-laude-orchestration enforces LAUDE_IS_ORCHESTRATOR. verify-no-anthropic-data-retention enforces USER_REPO_IS_DATABASE. verify-laude-pr-scope-policy enforces SESSION_CLOSES_TO_PR. None of these are aspirational rules. They are build gates. The build fails if they are violated.
It has continuity. A user's axioms, once merged to their canonic-galaxy repo, are theirs across every future session. When LAUDE opens a new thread on the CLINICAL scope and the user has prior INTEL.md entries at that scope, LAUDE reads them and grounds the session in them. The agent doesn't start from scratch. The user's governed knowledge persists in their own infrastructure, signed by the LAUDE provisioner key, available to every future session that addresses the same scope.
What the Galaxy Looks Like Now
On 2026-05-17, LAUDE serves twenty-four TALK scopes, has twenty governed tools, emits nine ledger event types on each session, and federates across every canonic-galaxy repo that has opted into cross-galaxy discovery. The iDrDex/canonic-galaxy repo — the operator's own galaxy — contains the reference implementation of the USER_REPO_IS_DATABASE invariant, with INTEL scope directories populated by session-close PRs from every LAUDE session since the provisioner shipped.
The galaxy graph has grown to 3,782 nodes and 7,045 edges. Each node is a governed scope with a CANON.md. Each edge is a declared inheritance or composition relationship. LAUDE can read the graph summary in a single tool call. The infra tools can report the MAGIC 255 score for any scope in the galaxy from the same terminal window where the user is conducting a clinical chat session.
This is what the architecture means by infrastructure versus workload. The Galaxy is the address space — a graph of every governed scope, navigable, explorable, colored by category and compliance. LAUDE is the agent that operates on that address space — the entity that reads it, proposes to it, federates across it, and maintains continuity within it. CaseNex, OmicsNex, AnkiNex, and OncoNex are the workloads — governed products that run on LAUDE and the Galaxy without needing to know each other's internals.
The distinction matters because it is load-bearing for how the system scales. Adding a new governed product means declaring a new TALK scope in LAUDE_TALK_SCOPES, writing a CANON.md, adding a row in the infra tool's scope health map. It does not require writing a new agent. The agent exists. It is named. It has a contract. It is in the ledger. The new scope gets LAUDE by inheriting the infrastructure — the same way every other scope in the galaxy gets its compliance score, its evidence chain, and its audit trail.
Named entities scale. Anonymous backends proliferate.
Sources
| Claim | Source | Link |
|---|---|---|
| The Barnes-Hut n-body simulation positions scopes by governance topology, the standard force-directed graph layout method | Barnes-Hut simulation, Wikipedia | en.wikipedia.org |
| Each canonic-galaxy is linked to its federation peer via an Ed25519-signed magic-manifest.json, the modern signature scheme for repo provenance | Ed25519 / EdDSA signature scheme, Wikipedia | en.wikipedia.org |
| Operator-class tools require GitHub OAuth, the higher-attestation identity establishing a developer-class governor | OAuth 2.0 authorization framework, RFC 6749 | datatracker.ietf.org |
| LAUDE in OmicsChat carries the ACMG-AMP variant interpretation framework | Richards et al., ACMG/AMP standards for interpretation of sequence variants (2015), PMC | pmc.ncbi.nlm.nih.gov |
LAUDE declared as named governed agent; LAUDE_IS_ORCHESTRATOR invariant: one agent across 24 TALK scopes, personalized not forked |
hadleylab-canonic LAUDE CANON § Axiom; verify-laude-orchestration gate |
— |
USER_REPO_IS_DATABASE: user's canonic-galaxy repo is the canonical transcript and axiom store, D1 holds a 24h cache |
LAUDE CANON § Axiom; verify-no-anthropic-data-retention |
— |
SESSION_CLOSES_TO_PR: every session-close opens a pull request, auto-merge boundary on transcripts and INTEL |
LAUDE CANON § Axiom; verify-laude-pr-scope-policy |
— |
| Twenty governed tools across governor, operator, and infra classes; infra tools added in session S98 | LAUDE CANON § Tools; verify-laude-tools-complete |
— |
| Galaxy graph: 3,782 nodes, 7,045 edges | CLAUDE.md compiled galaxy.json | — |
LAUDE of the Galaxy | ENGINEERING | BLOGS