GuildRegistry (Cyber Guild routing)

The GuildRegistry is the engine that makes 'a Guild of AI agents' a real, structured, role-by-role thing instead of one undifferentiated LLM. Each role has a fixed identity (Warden = triage, Knight = verification, Marshal = sequencing, Paladin = execution, Scribe = case-writing, Herald = notification orchestration, and 16 more in doctrine for v1.x). When an event arrives the registry picks the role whose charter best fits the event's purpose.

Other AI security products either ship one generic 'AI analyst' (Charlotte AI, Dropzone) or expose role-shaped surfaces that are just prompt presets you swap (Sentinel agents). CyberCLI's Guild is structurally different: each role has its own purpose.md charter, its own fine-tuned model on the v1.5 roadmap, and its own ladder ceiling. The taxonomy is locked in code so the marketing site, the dashboard, and the engine all show the same 22 roles in the same chapters.

The runtime-routed slice in v1 today is narrower than the configured roster. The DigestPipeline calls the 'triage' purpose (Warden) and the 'gate' purpose (Herald wraps notification delivery) — that's what fires on every real event. Knight, Marshal, Paladin, and Scribe are configured in guild_doctrine.json with Providers wired in the registry so a Pro+ buyer can pre-stage them, but they are NOT invoked by the pipeline until v1.1 multi-pass orchestration ships. The other doctrine-only roles (Sentinel, Ranger, Mage, etc.) appear in the registry with a 'doctrine' badge — published taxonomy, not pretending to fire. That honesty is enforced two ways: only Warden+Herald appear in tier_autonomy.ts routedRoles, and the pipeline's purpose allowlist limits routing to 'triage' + 'gate' in v1.

GuildRegistry loads `guild_doctrine.json` (the canonical chapter/role/charter doctrine) on construction. Each role entry has an id, a display name, a chapter id, a purpose blurb, the path to its purpose.md charter, and a status flag (`engine_routed_v1` / `engine_routed_v1_5` / `doctrine_only`).

Routing happens via `role_for_purpose(purpose_id)`. Purposes come from the connector manifest layer — every event arrives carrying a Purpose enum (e.g. `triage_security_signal`, `verify_finding`, `notify_human`). The registry maps each purpose to exactly one role in the v1-routed slice, falling back to Warden for purposes that don't match a more specific role.

Each routed role's charter is rendered by `charter.py` from the purpose.md template + the live context (the operator's tenant name, the connector roster, the licensed tier). The rendered charter becomes the system prompt for the role's digest call — that's how Warden has Warden's voice, Knight has Knight's, etc. The doctrine.json + the charter.py renderer are the two files that define a role's identity.

The registry is consulted on three surfaces. The pipeline gate-pass asks 'which role should look at this event' before the digest call. The dashboard's /ai-agents page reads the full taxonomy to render the roster. The marketing site's /guild + /docs/engines/guild-registry pages pull from the same doctrine.json so what a buyer sees on the brochure is what an operator sees in the dashboard is what the engine actually loads.

Beta — the doctrine taxonomy is locked (chris-approved 2026-05-25); the v1-routed slice (Warden fires today) is shipping; the v1.5 expansion to multi-role orchestration is in progress but not yet wired. The 'beta' status applies to the runtime routing surface, not the doctrine itself.

Known limit: only Warden fires in v1's routing path. The DigestPipeline calls `role_for_purpose()` correctly but routes every event to Warden today because the multi-role orchestrator that hands Knight + Marshal + Paladin their slices ships in v1.1. The provider map is wired for all 5 runtime roles so a Pro buyer can pre-stage them.

Shipped 2026-06-07: `marketing/scripts/dump_guild_doctrine.py` reads `src/cybercli/digest/guild_doctrine.json` and writes a mirror into `marketing/src/data/guild_doctrine.json`. The marketing prebuild hook runs the dump on every build, so a doctrine edit in code automatically updates the public /guild brochure and the dashboard's /ai-agents roster the next build.