decapod 0.56.0

{
  "$schema": "./constitution.schema.json",
  "version": "3.0.0",
  "nodes": {
    "core/DECAPOD": {
      "id": "core/DECAPOD",
      "category": "core",
      "title": "Decapod Root Router",
      "authority": "root-router",
      "binding": "binding",
      "summary": "Start here after raw human input. Route intent into the smallest useful core surface before the agent reasons about a solution.",
      "terms": [
        "decapod",
        "root",
        "router",
        "intent",
        "agent",
        "app",
        "feature",
        "system",
        "service",
        "scaffold",
        "constitution",
        "pre-inference",
        "ambiguous"
      ],
      "links": {
        "references": [
          "core/ARCHITECTURE",
          "core/DOCS",
          "core/INTERFACES",
          "core/METHODOLOGY",
          "core/PLUGINS",
          "core/SPECS",
          "core/METADATA",
          "core/ENGINEERING_EXCELLENCE",
          "core/GAPS",
          "core/DEMANDS",
          "core/DEPRECATION",
          "core/EMERGENCY_PROTOCOL",
          "core/DATA"
        ],
        "referenced_by": []
      },
      "sections": {
        "match": [
          "Use first when the human prompt is broad, cross-domain, underspecified, or uses product slang like app, service, platform, workflow, tool, or integration.",
          "Use when the agent cannot yet tell whether the task is product, architecture, interface, methodology, plugin, spec, docs, metadata, or emergency work."
        ],
        "decide": [
          "Classify the task surface before solution reasoning: product intent, architecture shape, interface contract, implementation subsystem, docs, spec, or operational risk.",
          "Select the smallest core route that can disambiguate the prompt; do not load adjacent families merely because they may become relevant later.",
          "If intent remains materially ambiguous after routing, ask a focused question or query a narrower node before inference.",
          "Verify liveness via invocation heartbeat contract before proceeding."
        ],
        "route": [
          "app, feature, UI, backend, API, data, auth, scale, deploy, secure -> core/ARCHITECTURE plus methodology/PRODUCT when product shape is unclear.",
          "database, cache, pipeline, schema, state, migrations -> core/DATA.",
          "schema, contract, envelope, store, control plane, context pack, claim, machine surface -> core/INTERFACES.",
          "workflow, testing, release, incident, research, product, platform, operating practice -> core/METHODOLOGY.",
          "todo, validate, knowledge, context, capsule, container, health, policy, watcher, skill, eval -> core/PLUGINS.",
          "intent contract, security contract, git behavior, amendment, system authority, evaluation governance -> core/SPECS."
        ],
        "apply": [
          "After core routing, retrieve domain entries and carry forward only the concepts needed to improve the next inference step.",
          "A good next state is one of three outcomes: ask the human, query Decapod again, or proceed to inference with named assumptions and proof expectations."
        ],
        "avoid": [
          "Do not treat the human phrase as a complete requirement when platform, user, data, interface, trust boundary, deployment, or proof is unknown.",
          "Do not answer from generic model memory when a precise Decapod route can provide domain terms, decision axes, or constraints."
        ]
      }
    },
    "core/ARCHITECTURE": {
      "id": "core/ARCHITECTURE",
      "category": "core",
      "title": "Architecture Discovery Surface",
      "authority": "namespace-router",
      "binding": "binding",
      "summary": "Route product and system-building intent into architecture concepts before implementation inference.",
      "terms": [
        "architecture",
        "app",
        "web",
        "frontend",
        "backend",
        "api",
        "data",
        "auth",
        "security",
        "kubernetes",
        "cloud",
        "scale",
        "performance",
        "wasm",
        "react",
        "mobile"
      ],
      "links": {
        "references": [
          "architecture/ALGORITHMS",
          "architecture/API_DESIGN",
          "architecture/AUTH",
          "data/CACHING",
          "architecture/CI_CD_PIPELINES",
          "architecture/CLOUD",
          "architecture/CODING_STANDARDS",
          "architecture/COMPLIANCE",
          "architecture/CONCURRENCY",
          "architecture/CONTAINERS",
          "architecture/COST_OPTIMIZATION",
          "data/PIPELINES",
          "data/DATABASE",
          "architecture/DISTRIBUTED_SYSTEMS",
          "architecture/DR",
          "architecture/ENCRYPTION",
          "architecture/ENTERPRISE",
          "architecture/EVENT_DRIVEN",
          "architecture/FRONTEND",
          "architecture/GRAPHQL",
          "architecture/GRPC",
          "architecture/INFRASTRUCTURE",
          "architecture/KNOWLEDGE_BASE",
          "architecture/KUBERNETES",
          "architecture/MEMORY",
          "architecture/MESSAGING",
          "architecture/METRICS",
          "architecture/MICROSERVICES",
          "architecture/NETWORKING",
          "architecture/OBSERVABILITY",
          "architecture/PERFORMANCE",
          "architecture/SCALING",
          "architecture/SECRETS",
          "architecture/SECURITY",
          "architecture/SYSTEMS_DESIGN",
          "architecture/TESTING_STRATEGY",
          "architecture/UI",
          "architecture/WEB"
        ],
        "referenced_by": [
          "core/DECAPOD"
        ]
      },
      "sections": {
        "match": [
          "Use when the user asks to build, design, modernize, scale, secure, deploy, integrate, or productionize a software system.",
          "Use for vague product nouns: app, website, dashboard, backend, API, platform, service, workflow, portal, admin panel, agent, or automation."
        ],
        "decide": [
          "Identify platform first: web, mobile, desktop, CLI, embedded, WASM, API-only, internal tool, or multi-platform.",
          "Identify architecture boundary: UI, API, persistence, auth, data flow, runtime, deployment, observability, security, and failure recovery.",
          "Separate product uncertainty from technical uncertainty; product uncertainty routes through methodology/PRODUCT before hard architecture decisions."
        ],
        "route": [
          "app -> architecture/WEB, architecture/FRONTEND, architecture/UI, architecture/API_DESIGN, core/DATA, architecture/AUTH, architecture/SECURITY.",
          "frontend -> architecture/FRONTEND, architecture/UI, architecture/WEB, architecture/PERFORMANCE, architecture/TESTING_STRATEGY.",
          "backend -> architecture/API_DESIGN, data/DATABASE, architecture/MESSAGING, architecture/OBSERVABILITY, architecture/SECURITY.",
          "secure -> architecture/SECURITY, architecture/AUTH, architecture/SECRETS, architecture/ENCRYPTION, architecture/COMPLIANCE.",
          "kubernetes -> architecture/KUBERNETES, architecture/CONTAINERS, architecture/NETWORKING, architecture/OBSERVABILITY, architecture/CI_CD_PIPELINES."
        ],
        "ask": [
          "Ask platform choice when app could mean iOS, Android, web, desktop, CLI, WASM, or cross-platform.",
          "Ask user, data, auth, deployment target, and success criteria when implementation would otherwise invent the product boundary."
        ],
        "avoid": [
          "Do not default to React, mobile, Kubernetes, serverless, microservices, or AI features unless the retrieved domain path or repo context supports it.",
          "Do not choose architecture before naming the user workflow and the first production slice."
        ]
      }
    },
    "core/DOCS": {
      "id": "core/DOCS",
      "category": "core",
      "title": "Documentation Discovery Surface",
      "authority": "namespace-router",
      "binding": "binding",
      "summary": "Route human-facing explanation, operator guidance, audits, and playbooks into the right documentation node.",
      "terms": [
        "docs",
        "readme",
        "documentation",
        "playbook",
        "guide",
        "audit",
        "overview",
        "maintainer",
        "usage",
        "operator"
      ],
      "links": {
        "references": [
          "docs/ARCHITECTURE_OVERVIEW",
          "docs/CONTROL_PLANE_API",
          "docs/EVAL_TRANSLATION_MAP",
          "docs/GOVERNANCE_AUDIT",
          "docs/MAINTAINERS",
          "docs/MIGRATIONS",
          "docs/NEGLECTED_ASPECTS_LEDGER",
          "docs/PLAYBOOK",
          "docs/README",
          "docs/RELEASE_PROCESS",
          "docs/SECURITY_THREAT_MODEL",
          "docs/SKILL_TRANSLATION_MAP"
        ],
        "referenced_by": [
          "core/DECAPOD"
        ]
      },
      "sections": {
        "match": [
          "Use when the task asks for explanation, project orientation, maintainer guidance, user docs, playbooks, audit material, or public-facing clarity.",
          "Use when code behavior changed and the human-facing or operator-facing explanation may now be stale."
        ],
        "decide": [
          "Classify the document audience: new user, maintainer, operator, reviewer, auditor, customer, or agent-adjacent implementer.",
          "Separate product documentation from authority contracts; docs may explain behavior but must not invent binding rules."
        ],
        "route": [
          "README or quickstart -> docs/README and docs/PLAYBOOK.",
          "architecture explanation -> docs/ARCHITECTURE_OVERVIEW plus architecture/* domain nodes.",
          "control-plane usage -> docs/CONTROL_PLANE_API plus interfaces/CONTROL_PLANE.",
          "audit or governance explanation -> docs/GOVERNANCE_AUDIT and docs/NEGLECTED_ASPECTS_LEDGER."
        ],
        "apply": [
          "Docs should match current executable behavior, current schemas, and current validation surfaces.",
          "When docs affect user trust, include setup path, expected outcome, failure recovery, and proof or validation steps."
        ],
        "avoid": [
          "Do not place operational agent rules in public README content when AGENTS.md or core/spec/interface authority owns the rule.",
          "Do not document aspirational behavior as current behavior without marking status and proof gap."
        ]
      }
    },
    "core/INTERFACES": {
      "id": "core/INTERFACES",
      "category": "core",
      "title": "Interface Discovery Surface",
      "authority": "namespace-router",
      "binding": "binding",
      "summary": "Route machine-consumable contracts, schemas, envelopes, store rules, and control-plane boundaries.",
      "terms": [
        "interfaces",
        "schema",
        "contract",
        "json",
        "envelope",
        "control-plane",
        "store",
        "claims",
        "glossary",
        "context-pack",
        "todo-schema"
      ],
      "links": {
        "references": [
          "interfaces/AGENT_CONTEXT_PACK",
          "interfaces/ARCHITECTURE_FOUNDATIONS",
          "interfaces/CLAIMS",
          "interfaces/CONTROL_PLANE",
          "interfaces/DEMANDS_SCHEMA",
          "interfaces/DOC_RULES",
          "interfaces/GLOSSARY",
          "interfaces/INTERNALIZATION_SCHEMA",
          "interfaces/KNOWLEDGE_SCHEMA",
          "interfaces/KNOWLEDGE_STORE",
          "interfaces/LCM",
          "interfaces/MEMORY_INDEX",
          "interfaces/MEMORY_SCHEMA",
          "interfaces/PLAN_GOVERNED_EXECUTION",
          "interfaces/PROCEDURAL_NORMS",
          "interfaces/PROJECT_SPECS",
          "interfaces/RISK_POLICY_GATE",
          "interfaces/STORE_MODEL",
          "interfaces/TESTING",
          "interfaces/TODO_SCHEMA",
          "interfaces/jsonschema/internalization/InternalizationAttachResult.schema",
          "interfaces/jsonschema/internalization/InternalizationCreateResult.schema",
          "interfaces/jsonschema/internalization/InternalizationDetachResult.schema",
          "interfaces/jsonschema/internalization/InternalizationInspectResult.schema",
          "interfaces/jsonschema/internalization/InternalizationManifest.schema"
        ],
        "referenced_by": [
          "core/DECAPOD"
        ]
      },
      "sections": {
        "match": [
          "Use when work changes a command surface, response envelope, JSON schema, state store, claim, context pack, or machine-readable contract.",
          "Use when the agent needs exact structure rather than prose guidance."
        ],
        "decide": [
          "Identify producer, consumer, mutation target, compatibility requirement, and validation surface before changing an interface.",
          "Treat schemas and response envelopes as contracts; defaults, omissions, field names, and error shapes affect downstream agents."
        ],
        "route": [
          "control sequence or agent operation order -> interfaces/CONTROL_PLANE.",
          "state ownership or user-vs-repo mutation -> interfaces/STORE_MODEL.",
          "proof claim, promise, or enforcement status -> interfaces/CLAIMS and interfaces/TESTING.",
          "context pack, internalization, memory, knowledge, todo, or demand shape -> matching schema interface node."
        ],
        "apply": [
          "Preserve backward compatibility unless the change is explicitly versioned, deprecated, or gated by an amendment path.",
          "Schema edits require examples, validation, and a named consumer impact."
        ],
        "avoid": [
          "Do not infer interface semantics from implementation convenience when a schema or contract node exists.",
          "Do not create duplicate authority by describing the same machine contract in multiple places."
        ]
      }
    },
    "core/METHODOLOGY": {
      "id": "core/METHODOLOGY",
      "category": "core",
      "title": "Methodology Discovery Surface",
      "authority": "namespace-router",
      "binding": "binding",
      "summary": "Route execution-practice questions into repeatable approaches for product, architecture, testing, release, operations, research, and memory.",
      "terms": [
        "methodology",
        "practice",
        "process",
        "how",
        "testing",
        "release",
        "incident",
        "research",
        "product",
        "platform",
        "operations",
        "memory",
        "knowledge"
      ],
      "links": {
        "references": [
          "methodology/ARCHITECTURE",
          "methodology/CI_CD",
          "methodology/ENGINEERING_MANAGEMENT",
          "methodology/INCIDENT_RESPONSE",
          "methodology/KNOWLEDGE",
          "methodology/MEMORY",
          "methodology/METRICS",
          "methodology/OPERATIONS",
          "methodology/PLATFORM",
          "methodology/PRODUCT",
          "methodology/RELEASE_MANAGEMENT",
          "methodology/RESEARCH",
          "methodology/RESEARCH_PRODUCTION",
          "methodology/SOUL",
          "methodology/TESTING"
        ],
        "referenced_by": [
          "core/DECAPOD"
        ]
      },
      "sections": {
        "match": [
          "Use when the task is about how to approach work rather than what interface, architecture component, or plugin surface to change.",
          "Use when the agent needs a disciplined workflow for product shaping, architecture decisions, tests, releases, incidents, or research."
        ],
        "decide": [
          "Classify practice need: product discovery, architectural tradeoff, implementation sequencing, validation, release safety, incident response, knowledge capture, or research translation.",
          "Use methodology to guide execution, then retrieve architecture/spec/interface nodes for binding or domain-specific constraints."
        ],
        "route": [
          "what should we build or why -> methodology/PRODUCT.",
          "how should we design it -> methodology/ARCHITECTURE plus architecture/* nodes.",
          "how do we prove it works -> methodology/TESTING and relevant interface/spec nodes.",
          "how do we ship or operate it -> methodology/CI_CD, methodology/RELEASE_MANAGEMENT, methodology/OPERATIONS, methodology/INCIDENT_RESPONSE.",
          "research or paper-to-product work -> methodology/RESEARCH and methodology/RESEARCH_PRODUCTION."
        ],
        "apply": [
          "Use methodology nodes to choose the next disciplined action: ask, narrow scope, prototype, test, document, release, or escalate.",
          "When practice conflicts with binding authority, follow the spec or interface and treat the methodology as guidance."
        ],
        "avoid": [
          "Do not let methodology become a substitute for domain knowledge or executable proof.",
          "Do not follow a guide mechanically when the retrieved domain node exposes a stronger constraint."
        ]
      }
    },
    "core/PLUGINS": {
      "id": "core/PLUGINS",
      "category": "core",
      "title": "Plugin Discovery Surface",
      "authority": "namespace-router",
      "binding": "binding",
      "summary": "Route Decapod subsystem capability questions into the correct operational surface and maturity expectation.",
      "terms": [
        "plugins",
        "subsystem",
        "todo",
        "validate",
        "verify",
        "knowledge",
        "context",
        "container",
        "health",
        "policy",
        "watcher",
        "skill",
        "eval",
        "capsule"
      ],
      "links": {
        "references": [
          "plugins/APTITUDE",
          "plugins/ARCHIVE",
          "plugins/AUDIT",
          "plugins/AUTOUPDATE",
          "plugins/CONTAINER",
          "plugins/CONTEXT",
          "plugins/CRON",
          "plugins/DB_BROKER",
          "plugins/DECIDE",
          "plugins/EMERGENCY_PROTOCOL",
          "plugins/FEDERATION",
          "plugins/FEEDBACK",
          "plugins/HEALTH",
          "plugins/HEARTBEAT",
          "plugins/KNOWLEDGE",
          "plugins/MANIFEST",
          "plugins/POLICY",
          "plugins/REFLEX",
          "plugins/TODO",
          "plugins/TRUST",
          "plugins/VERIFY",
          "plugins/WATCHER"
        ],
        "referenced_by": [
          "core/DECAPOD"
        ]
      },
      "sections": {
        "match": [
          "Use when the task asks what Decapod can do, which subsystem owns an operation, or which CLI/RPC surface should be used.",
          "Use when a subsystem status, proof surface, deprecation, or capability boundary affects agent action."
        ],
        "decide": [
          "Identify the subsystem owner, truth label, proof surface, and state boundary before invoking or changing a plugin surface.",
          "Treat REAL, STUB, SPEC, IDEA, and DEPRECATED as execution risk signals, not labels for documentation aesthetics."
        ],
        "route": [
          "work tracking -> plugins/TODO.",
          "completion gate or invariant check -> plugins/VERIFY.",
          "knowledge retrieval or provenance -> plugins/KNOWLEDGE and plugins/FEDERATION.",
          "context shaping, capsule, or compaction -> plugins/CONTEXT.",
          "isolated execution -> plugins/CONTAINER.",
          "health, policy, watcher, feedback, skill, eval -> matching plugin node."
        ],
        "apply": [
          "Invoke plugin surfaces through Decapod-supported commands; do not mutate Decapod state files directly.",
          "For plugin changes, preserve owner doc, schema, proof surface, status label, and deprecation path."
        ],
        "avoid": [
          "Do not rely on deprecated or SPEC surfaces for production claims.",
          "Do not mark a subsystem usable unless its proof surface is executable or the limitation is explicit."
        ]
      }
    },
    "core/SPECS": {
      "id": "core/SPECS",
      "category": "core",
      "title": "Specification Discovery Surface",
      "authority": "namespace-router",
      "binding": "binding",
      "summary": "Route binding system contracts, authority doctrine, security rules, git behavior, evaluations, and amendments.",
      "terms": [
        "specs",
        "specification",
        "intent",
        "security",
        "git",
        "system",
        "amendment",
        "evaluation",
        "judge",
        "contract",
        "governance"
      ],
      "links": {
        "references": [
          "specs/AMENDMENTS",
          "specs/DB_BROKER_QUEUE",
          "specs/GIT",
          "specs/INTENT",
          "specs/SECURITY",
          "specs/SYSTEM",
          "specs/engineering/FRONTEND_BACKEND_E2E",
          "specs/evaluations/JUDGE_CONTRACT",
          "specs/evaluations/VARIANCE_EVALS",
          "specs/skills/SKILL_GOVERNANCE"
        ],
        "referenced_by": [
          "core/DECAPOD"
        ]
      },
      "sections": {
        "match": [
          "Use when the task touches binding system behavior, authority hierarchy, security posture, git workflow, intent contract, or formal change control.",
          "Use when a decision must be governed rather than merely guided."
        ],
        "decide": [
          "Determine whether the requested change alters what must be true, who has authority, how proof is judged, or what behavior is allowed.",
          "If a spec applies, treat it as stronger than docs, methodology, and local implementation preference."
        ],
        "route": [
          "human intent, mutation gating, or explicit outcome -> specs/INTENT.",
          "system boundary or authority doctrine -> specs/SYSTEM.",
          "security posture, threat, secret, trust, or session risk -> specs/SECURITY.",
          "branch, worktree, commit, or git workflow -> specs/GIT.",
          "rule change or constitutional edit -> specs/AMENDMENTS.",
          "judge, variance, eval gate, or skill governance -> matching specs/evaluations or specs/skills node."
        ],
        "apply": [
          "When a spec constrains action, carry the constraint into the plan before implementation inference.",
          "Spec changes need compatibility reasoning, affected surfaces, migration path, and validation evidence."
        ],
        "avoid": [
          "Do not bypass a binding spec because a local change is easy.",
          "Do not silently change doctrine, authority, security posture, or mutation rules."
        ]
      }
    },
    "core/METADATA": {
      "id": "core/METADATA",
      "category": "core",
      "title": "Metadata Discovery Surface",
      "authority": "namespace-router",
      "binding": "binding",
      "summary": "Route auxiliary retrieval, skill, taxonomy, card, and corpus metadata queries.",
      "terms": [
        "metadata",
        "skills",
        "taxonomy",
        "card",
        "label",
        "tag",
        "index",
        "classification",
        "corpus",
        "retrieval-metadata"
      ],
      "links": {
        "references": [
          "metadata/skills/BUNDLE",
          "metadata/skills/AGENT_DECAPOD_INTERFACE",
          "metadata/skills/HUMAN_AGENT_UX",
          "metadata/skills/INTENT_REFINEMENT"
        ],
        "referenced_by": [
          "core/DECAPOD"
        ]
      },
      "sections": {
        "match": [
          "Use when the task involves labels, skills, taxonomy, catalog metadata, corpus organization, or auxiliary retrieval hints.",
          "Use when the agent needs to interpret or update metadata that helps Decapod route future queries."
        ],
        "decide": [
          "Identify whether metadata is descriptive, routing-oriented, skill-related, or derived from another authority surface.",
          "Treat metadata as retrieval support unless another node gives it binding force."
        ],
        "route": [
          "skill cards and skill governance metadata -> metadata/skills plus specs/skills/SKILL_GOVERNANCE.",
          "classification, aliases, tags, or corpus search hints -> metadata namespace entries when present.",
          "If metadata affects execution authority, route to specs or interfaces before acting."
        ],
        "apply": [
          "Keep metadata precise, stable, and tied to actual nodes or capabilities.",
          "Use metadata to improve discovery, not to create hidden policy."
        ],
        "avoid": [
          "Do not let metadata become a second source of truth for behavior.",
          "Do not add broad tags that cause unrelated retrieval hits."
        ]
      }
    },
    "core/ENGINEERING_EXCELLENCE": {
      "id": "core/ENGINEERING_EXCELLENCE",
      "category": "core",
      "title": "Engineering Excellence Discovery Surface",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Cross-cutting engineering judgment for production-grade, maintainable, secure, observable, and customer-trustworthy work.",
      "terms": [
        "engineering",
        "quality",
        "standards",
        "maintainability",
        "production",
        "operability",
        "security",
        "resilience",
        "testing",
        "architecture",
        "customer trust"
      ],
      "links": {
        "references": [
          "architecture/ALGORITHMS",
          "architecture/API_DESIGN",
          "architecture/AUTH",
          "data/CACHING",
          "architecture/CI_CD_PIPELINES",
          "architecture/CLOUD",
          "architecture/CODING_STANDARDS",
          "architecture/COMPLIANCE",
          "architecture/CONCURRENCY",
          "architecture/CONTAINERS",
          "architecture/COST_OPTIMIZATION",
          "data/PIPELINES",
          "data/DATABASE",
          "architecture/DISTRIBUTED_SYSTEMS",
          "architecture/DR",
          "architecture/ENCRYPTION",
          "architecture/ENTERPRISE",
          "architecture/EVENT_DRIVEN",
          "architecture/FRONTEND",
          "architecture/GRAPHQL",
          "architecture/GRPC",
          "architecture/INFRASTRUCTURE",
          "architecture/KNOWLEDGE_BASE",
          "architecture/KUBERNETES",
          "architecture/MEMORY",
          "architecture/MESSAGING",
          "architecture/METRICS",
          "architecture/MICROSERVICES",
          "architecture/NETWORKING",
          "architecture/OBSERVABILITY",
          "architecture/PERFORMANCE",
          "architecture/SCALING",
          "architecture/SECRETS",
          "architecture/SECURITY",
          "architecture/SYSTEMS_DESIGN",
          "architecture/TESTING_STRATEGY",
          "architecture/UI",
          "architecture/WEB"
        ],
        "referenced_by": [
          "core/DECAPOD",
          "core/ARCHITECTURE"
        ]
      },
      "sections": {
        "match": [
          "Use when the agent needs senior engineering judgment across architecture, implementation, delivery, quality, security, or operability.",
          "Use when the prompt invites a quick hack, local-only success, or a solution that may harm maintainability or customer trust."
        ],
        "decide": [
          "Prefer boring, proven, observable, and reversible choices unless novelty has a named advantage and owned risk.",
          "Name domain boundary, data ownership, compatibility obligation, failure mode, and proof before endorsing a design.",
          "Treat operational readiness as part of the design: metrics, logs, traces, rollout, rollback, and support path."
        ],
        "apply": [
          "For code, require readability, bounded side effects, tests, error handling, and clear ownership of introduced state.",
          "For architecture, favor domain boundaries and clear contracts over fashionable topology.",
          "For delivery, require validation evidence before claiming completion."
        ],
        "avoid": [
          "Do not ship vibes: local success without proof, hidden assumptions, or missing recovery path is incomplete.",
          "Do not add abstraction, dependency, state, or distributed coordination without naming the lifecycle cost."
        ]
      }
    },
    "core/GAPS": {
      "id": "core/GAPS",
      "category": "core",
      "title": "Gap Analysis Discovery Surface",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Classify missing doctrine, missing proof, unclear authority, drift, and incomplete system capability before work proceeds blindly.",
      "terms": [
        "gap",
        "missing",
        "drift",
        "unclear",
        "blocker",
        "risk",
        "deficiency",
        "unknown",
        "contradiction",
        "proof gap",
        "methodology vacuum"
      ],
      "links": {
        "references": [],
        "referenced_by": [
          "core/DECAPOD"
        ]
      },
      "sections": {
        "match": [
          "Use when the agent finds contradiction, missing guidance, missing proof, unclear owner, incomplete implementation, or repeated workaround pressure.",
          "Use when the task cannot be safely classified or verified with existing retrieved doctrine."
        ],
        "decide": [
          "Classify gap type: missing spec, interface gap, methodology vacuum, plugin capability gap, doc drift, proof gap, authority conflict, or project override need.",
          "Classify severity by blast radius: blocks work, weakens security, risks data loss, breaks validation, causes friction, or merely improves clarity.",
          "Route the gap to the owner node instead of patching around it invisibly."
        ],
        "apply": [
          "For material gaps, document evidence, affected boundary, owner, proposed resolution path, and proof of closure.",
          "If the gap changes execution safety, stop mutation until authority or proof is clarified."
        ],
        "avoid": [
          "Do not treat a gap as a bug unless a governing requirement already exists and implementation violates it.",
          "Do not invent missing doctrine inside the final answer when Decapod needs a routed gap or follow-up query."
        ]
      }
    },
    "core/DEMANDS": {
      "id": "core/DEMANDS",
      "category": "core",
      "title": "Demand and Constraint Discovery Surface",
      "authority": "doctrine",
      "binding": "binding",
      "summary": "Interpret explicit human constraints, precedence, non-negotiables, and execution demands that modify raw intent.",
      "terms": [
        "demand",
        "constraint",
        "requirement",
        "must",
        "must not",
        "non-negotiable",
        "precedence",
        "user demand",
        "override",
        "intent constraint"
      ],
      "links": {
        "references": [
          "specs/INTENT",
          "interfaces/DEMANDS_SCHEMA"
        ],
        "referenced_by": [
          "core/DECAPOD"
        ]
      },
      "sections": {
        "match": [
          "Use when the human states a must, must not, preference, boundary, deadline, acceptance condition, or override that changes execution.",
          "Use when multiple constraints may conflict or a constraint changes architecture, security, cost, compatibility, or proof."
        ],
        "decide": [
          "Distinguish raw intent from binding constraint: intent names desired outcome; demand narrows allowed paths.",
          "Apply precedence deterministically: explicit current human demand beats generic agent preference unless stronger Decapod authority blocks it.",
          "If demands conflict, stop and surface the conflict rather than choosing silently."
        ],
        "apply": [
          "Carry active demands into retrieved domain reasoning and proof expectations.",
          "When a demand is durable or machine-checkable, route to the demand schema or intent contract before encoding it."
        ],
        "avoid": [
          "Do not ignore a human constraint because it is inconvenient.",
          "Do not satisfy a demand by weakening auditability, proof, boundaries, or explicit authority."
        ]
      }
    },
    "core/DEPRECATION": {
      "id": "core/DEPRECATION",
      "category": "core",
      "title": "Deprecation Discovery Surface",
      "authority": "doctrine",
      "binding": "binding",
      "summary": "Govern safe retirement, replacement routing, compatibility windows, migration guidance, and duplicate-authority removal.",
      "terms": [
        "deprecation",
        "deprecated",
        "sunset",
        "migration",
        "replacement",
        "compatibility",
        "retire",
        "remove",
        "legacy",
        "breaking change"
      ],
      "links": {
        "references": [],
        "referenced_by": [
          "core/DECAPOD"
        ]
      },
      "sections": {
        "match": [
          "Use when work removes, renames, replaces, migrates, sunsets, or discourages a command, schema, document, field, behavior, or subsystem.",
          "Use when old and new authority may coexist during a transition."
        ],
        "decide": [
          "Name deprecated item, replacement, compatibility window, migration path, and removal condition before changing consumers.",
          "Old authority may coexist only when explicitly marked deprecated and routed to a canonical replacement.",
          "Breaking changes require affected consumers and proof of migration readiness."
        ],
        "apply": [
          "Update references, help text, docs, schemas, validation, and examples to point at the replacement path.",
          "Preserve compatibility long enough for known consumers or explicitly declare the break and recovery path."
        ],
        "avoid": [
          "Do not silently remove a surface that agents or users may still call.",
          "Do not leave deprecated material as equal authority beside its replacement."
        ]
      }
    },
    "core/EMERGENCY_PROTOCOL": {
      "id": "core/EMERGENCY_PROTOCOL",
      "category": "core",
      "title": "Emergency Protocol Discovery Surface",
      "authority": "doctrine",
      "binding": "binding",
      "summary": "Stop or constrain agent mutation when authority, store boundary, security, data safety, or proof is unclear under risk.",
      "terms": [
        "emergency",
        "stop",
        "halt",
        "break-glass",
        "escalate",
        "contain",
        "rollback",
        "security",
        "data loss",
        "authority conflict",
        "unsafe"
      ],
      "links": {
        "references": [],
        "referenced_by": [
          "core/DECAPOD"
        ]
      },
      "sections": {
        "match": [
          "Use when continuing may corrupt state, violate security, destroy data, bypass authority, hide a failed proof, or worsen an incident.",
          "Use when two binding sources conflict or the mutation target cannot be identified."
        ],
        "decide": [
          "Stop mutation when authority, store, proof surface, or blast radius cannot be named.",
          "Prefer containment, evidence capture, and explicit blocker creation over speculative repair.",
          "Resume only when authority conflict is resolved, proof path is known, and validation or blocker state is explicit."
        ],
        "apply": [
          "Capture conflicting sources, intended mutation, affected store, observed risk, and required human decision.",
          "For production or security risk, include rollback, containment, monitoring, and escalation criteria."
        ],
        "avoid": [
          "Do not quick-fix a critical unknown before preserving evidence and naming the affected boundary.",
          "Do not continue implementation when validation cannot terminate or proof cannot be defined."
        ]
      }
    },
    "architecture/ALGORITHMS": {
      "id": "architecture/ALGORITHMS",
      "category": "architecture",
      "title": "architecture/ALGORITHMS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers complexity, data structures, deterministic behavior, bounded resource usage, streaming vs batch, approximate vs exact algorithms, profiling, and correctness tests.",
      "terms": [
        "complexity",
        "big-o",
        "data structure",
        "determinism",
        "bounded memory",
        "streaming algorithm",
        "profiles",
        "bounded",
        "resource",
        "behavior",
        "algorithmic",
        "judgment",
        "selection",
        "structures",
        "algorithms",
        "locality"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when evaluating algorithmic complexity, data structure selection, or addressing bounded resource usage and determinism."
        ],
        "concepts": [
          "Algorithms must be deterministic. Identical inputs must yield identical outputs to ensure reproducible validation.",
          "Data locality and cache-friendly access patterns often outperform asymptotic complexity (Big-O) for small datasets.",
          "Approximate algorithms (Bloom filters, HyperLogLog) trade exactness for bounded space and time."
        ],
        "ambiguity": [
          "Stop inference if memory constraints, acceptable latency percentiles, or the exactness vs approximation trade-off is unclear."
        ],
        "decisions": [
          "Decide between streaming algorithms for unbounded data or batch processing for completeness.",
          "Choose data structures based on empirical access patterns (e.g., read-heavy vs write-heavy) rather than theoretical purity."
        ],
        "standards": [
          "Resource budgets are mandatory. Every algorithm must have time and memory bounds enforced at the call site.",
          "Profile before optimizing. Standard library implementations must be used unless profiling proves a load-bearing bottleneck."
        ],
        "failure_modes": [
          "Using unbounded recursion or unbounded memory allocation, creating implicit out-of-memory risks.",
          "Optimizing prematurely without empirical profiling evidence."
        ],
        "next_queries": [
          "Query architecture/PERFORMANCE for system-level profiling guidelines.",
          "Query data/CACHING if repeated algorithmic work can be memoized."
        ],
        "proceed_when": [
          "Proceed when the algorithm is accompanied by deterministic tests and resource bounds are explicitly managed."
        ]
      }
    },
    "architecture/API_DESIGN": {
      "id": "architecture/API_DESIGN",
      "category": "architecture",
      "title": "architecture/API_DESIGN",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "This domain covers resource modeling, compatibility, idempotency, status codes, pagination, auth boundary, error shape, versioning, and contract tests.",
      "terms": [
        "schema evolution",
        "p99 latency",
        "graphql",
        "contract",
        "pagination",
        "codes",
        "rest",
        "design",
        "idempotency",
        "compatibility",
        "versioning",
        "schemas",
        "status",
        "grpc"
      ],
      "links": {
        "references": [
          "architecture/AUTH",
          "architecture/OBSERVABILITY",
          "architecture/SECURITY",
          "core/ENGINEERING_EXCELLENCE",
          "interfaces/CLAIMS",
          "interfaces/CONTROL_PLANE",
          "methodology/TESTING"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when designing new endpoints, altering schemas, or modifying HTTP/gRPC/GraphQL transport layers."
        ],
        "concepts": [
          "APIs are immutable contracts. Breaking changes require versioning and migration windows.",
          "Idempotency is mandatory for all state-mutating operations (PUT, DELETE, and specific POSTs).",
          "Error shapes must be consistent across all endpoints, providing actionable machine-readable codes."
        ],
        "ambiguity": [
          "Stop inference if the API consumer, compatibility window, or authentication boundary is undefined."
        ],
        "decisions": [
          "Select the appropriate transport: REST for resource CRUD, GraphQL for graph traversal, gRPC for internal low-latency.",
          "Decide on the pagination strategy (cursor vs offset) based on dataset volatility."
        ],
        "standards": [
          "Use precise HTTP status codes: 400 for bad input, 401 for missing auth, 403 for insufficient role, 422 for semantic errors.",
          "Require contract tests for all API changes to prevent consumer breakages.",
          "Enforce strict input validation against defined schemas before processing logic."
        ],
        "failure_modes": [
          "Returning 200 OK with an error payload breaks standard HTTP client assumptions.",
          "Exposing internal database IDs directly instead of opaque identifiers risks enumeration attacks.",
          "Failing to paginate list endpoints causes unbounded memory consumption under load."
        ],
        "next_queries": [
          "Query architecture/AUTH for token validation.",
          "Query methodology/TESTING for contract test requirements."
        ],
        "proceed_when": [
          "Proceed when the schema is fully specified and backward compatibility is assured or mitigated."
        ]
      }
    },
    "architecture/AUTH": {
      "id": "architecture/AUTH",
      "category": "architecture",
      "title": "architecture/AUTH",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "This domain covers identity provider, session/token model, storage location, JWT validation, refresh/revocation, MFA, API keys, mTLS, and authorization boundary.",
      "terms": [
        "trust boundary",
        "authorization",
        "identity",
        "level",
        "sessions",
        "proof",
        "delegation",
        "auth",
        "resource",
        "authentication",
        "tokens",
        "access",
        "keys",
        "mtls",
        "control"
      ],
      "links": {
        "references": [
          "architecture/ENCRYPTION",
          "architecture/SECRETS",
          "architecture/SECURITY",
          "core/ENGINEERING_EXCELLENCE",
          "interfaces/RISK_POLICY_GATE",
          "specs/SECURITY"
        ],
        "referenced_by": [
          "architecture/API_DESIGN",
          "architecture/SECURITY",
          "core/ENGINEERING_EXCELLENCE",
          "docs/SECURITY_THREAT_MODEL",
          "specs/SECURITY"
        ]
      },
      "sections": {
        "match": [
          "Use when implementing login flows, token validation, API key management, or resource access controls."
        ],
        "concepts": [
          "Authentication proves who you are; Authorization proves what you can do.",
          "Tokens are bearer-type credentials. Their exposure is equivalent to password exposure.",
          "Sessions have lifecycles: creation, validation, refresh, and explicit revocation."
        ],
        "ambiguity": [
          "Stop inference if the token storage mechanism, revocation strategy, or identity provider is undefined."
        ],
        "decisions": [
          "Choose between stateful sessions (Redis/DB) for immediate revocation or stateless JWTs for distributed verification.",
          "Determine the correct token storage strategy (e.g., HttpOnly secure cookies for web clients)."
        ],
        "standards": [
          "JWTs must have their signatures, expirations (exp), and issuers (iss) strictly validated on every request.",
          "API keys must be revocable, rotation-friendly, and hashed securely at rest.",
          "Implement least-privilege resource-level access control, denying by default."
        ],
        "failure_modes": [
          "Storing JWTs in localStorage where they are vulnerable to XSS exfiltration.",
          "Accepting tokens via URL query parameters, causing them to leak into access logs.",
          "Failing to implement a token revocation or blocklist mechanism for compromised sessions."
        ],
        "next_queries": [
          "Query architecture/API_DESIGN for auth header standards.",
          "Query architecture/SECURITY for cryptography limits."
        ],
        "proceed_when": [
          "Proceed when the authentication flow is secure against replay, XSS, and CSRF attacks."
        ]
      }
    },
    "data/CACHING": {
      "id": "data/CACHING",
      "category": "data",
      "title": "data/CACHING",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "This domain covers source of truth, invalidation, TTL, stampede prevention, stale tolerance, cache-aside/write-through/write-behind, observability, and failure behavior.",
      "terms": [
        "cache invalidation",
        "ttl jitter",
        "stampede",
        "cache-aside",
        "write-through",
        "stale read",
        "tiers",
        "stale",
        "observability",
        "prevention",
        "replicated",
        "invalidation",
        "caching",
        "cache",
        "tolerance",
        "state"
      ],
      "links": {
        "references": [
          "data/PIPELINES",
          "architecture/DISTRIBUTED_SYSTEMS",
          "architecture/OBSERVABILITY",
          "architecture/PERFORMANCE",
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "data/DATABASE",
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when adding caching layers, configuring Redis/Memcached, or optimizing read-heavy workloads."
        ],
        "concepts": [
          "A cache is a performance optimization, not a persistent system of record.",
          "Invalidation is the hardest problem. Explicit event-driven invalidation is safer than relying solely on TTL.",
          "Stale data tolerance is a business decision, not purely a technical one."
        ],
        "ambiguity": [
          "Stop inference if the acceptable stale tolerance, invalidation trigger, or cache miss behavior is undefined."
        ],
        "decisions": [
          "Select the caching strategy: cache-aside for simplicity, write-through for consistency.",
          "Determine the eviction policy (e.g., LRU, LFU) based on access patterns and memory limits."
        ],
        "standards": [
          "Implement circuit breakers around caches so the system survives when the cache goes down.",
          "Use jitter on TTLs to prevent cache stampedes (thundering herds) when many items expire simultaneously.",
          "Monitor cache hit/miss rates, eviction counts, and latency percentiles."
        ],
        "failure_modes": [
          "Treating the cache as a database, leading to permanent data loss on eviction.",
          "Setting unbounded TTLs, resulting in memory leaks and perpetually stale data.",
          "Allowing a cache miss storm to overwhelm the backing database."
        ],
        "next_queries": [
          "Query data/DATABASE for the primary source of truth.",
          "Query architecture/PERFORMANCE for latency budgets."
        ],
        "proceed_when": [
          "Proceed when invalidation logic is explicit and the fallback path to the database is tested."
        ]
      }
    },
    "architecture/CI_CD_PIPELINES": {
      "id": "architecture/CI_CD_PIPELINES",
      "category": "architecture",
      "title": "architecture/CI_CD_PIPELINES",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "This domain covers source validation, build, test, scan, sign, package, deploy, smoke tests, rollback, and release evidence.",
      "terms": [
        "sign",
        "rollout strategy",
        "release gate",
        "release",
        "validation",
        "evidence",
        "pipeline",
        "pipelines",
        "scan",
        "verify",
        "package",
        "rollback",
        "deploy",
        "test",
        "build"
      ],
      "links": {
        "references": [
          "architecture/CONTAINERS",
          "architecture/KUBERNETES",
          "core/ENGINEERING_EXCELLENCE",
          "methodology/CI_CD",
          "methodology/RELEASE_MANAGEMENT",
          "plugins/MANIFEST",
          "plugins/VERIFY",
          "specs/GIT"
        ],
        "referenced_by": [
          "architecture/KUBERNETES",
          "core/ENGINEERING_EXCELLENCE",
          "docs/RELEASE_PROCESS"
        ]
      },
      "sections": {
        "match": [
          "Use when configuring GitHub Actions, CI runners, deployment scripts, or release automation."
        ],
        "concepts": [
          "The pipeline is the only path to production. Manual deployments are prohibited.",
          "A pipeline proves safety through discrete gates: build, unit test, security scan, integration test.",
          "Deployment and Release are separate concepts. Deploying code does not mean releasing features."
        ],
        "ambiguity": [
          "Stop inference if the deployment target, rollback procedure, or test coverage requirements are unspecified."
        ],
        "decisions": [
          "Determine the deployment strategy: Blue/Green, Canary, or Rolling update.",
          "Decide which environments (staging, pre-prod, prod) the artifact must traverse."
        ],
        "standards": [
          "Artifacts must be built exactly once, hashed, signed, and promoted through environments unchanged.",
          "All pipelines must fail fast. Run the fastest, most isolated tests before heavy integration suites.",
          "Automated rollback mechanisms must be defined and tested for failed deployments."
        ],
        "failure_modes": [
          "Recompiling code for different environments instead of promoting a single immutable artifact.",
          "Hardcoding environment-specific configuration into the build artifact.",
          "Allowing tests to be flaky, destroying trust in the CI signal."
        ],
        "next_queries": [
          "Query architecture/CONTAINERS for packaging.",
          "Query methodology/TESTING for validation strategies."
        ],
        "proceed_when": [
          "Proceed when pipeline stages are deterministic, isolated, and leave an auditable trace."
        ]
      }
    },
    "architecture/CLOUD": {
      "id": "architecture/CLOUD",
      "category": "architecture",
      "title": "architecture/CLOUD",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers IAM boundaries, region/AZ topology, managed-service lock-in, and account-level segregation.",
      "terms": [
        "iam boundary",
        "region topology",
        "az topology",
        "service quota",
        "managed service",
        "iac",
        "tagging",
        "cost attribution"
      ],
      "links": {
        "references": [
          "architecture/COST_OPTIMIZATION",
          "architecture/DR",
          "architecture/INFRASTRUCTURE",
          "architecture/NETWORKING",
          "architecture/OBSERVABILITY",
          "architecture/SECURITY",
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "architecture/KUBERNETES",
          "core/ENGINEERING_EXCELLENCE",
          "docs/ARCHITECTURE_OVERVIEW"
        ]
      },
      "sections": {
        "match": [
          "Use when selecting cloud primitives, configuring IAM, or designing regional deployment strategies."
        ],
        "concepts": [
          "IAM Boundaries: Enforce least-privilege using role-based access control (RBAC) across account boundaries.",
          "Managed Services: Evaluate lock-in risk; favor standards-compliant services over proprietary vendor extensions.",
          "Failure Domains: Distribute compute across multiple Availability Zones (AZ) to survive zone-level outages."
        ],
        "ambiguity": [
          "Stop if the IAM principal, service quota limit, or disaster recovery (DR) region is unspecified."
        ],
        "decisions": [
          "Decide whether to use managed platform-as-a-service (PaaS) vs portable container-based infrastructure."
        ],
        "standards": [
          "Infrastructure must be declared in version-controlled code (IaC) with no manual console changes permitted."
        ],
        "failure_modes": [
          "Hardcoding region-specific ARNs or IDs instead of using dynamic discovery or environment variables."
        ],
        "next_queries": [
          "Query architecture/INFRASTRUCTURE for delivery pipeline details."
        ],
        "proceed_when": [
          "Proceed when resources are tagged and IAM roles are strictly scoped."
        ]
      }
    },
    "architecture/CODING_STANDARDS": {
      "id": "architecture/CODING_STANDARDS",
      "category": "architecture",
      "title": "architecture/CODING_STANDARDS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers readability, naming, cohesion, coupling, error handling, API boundaries, tests, dependency hygiene, refactoring safety, and maintainability.",
      "terms": [
        "coding",
        "readability",
        "maintainability",
        "implementation",
        "refactoring",
        "cohesion",
        "modularity",
        "durable",
        "naming",
        "coupling",
        "standards",
        "discipline"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when refactoring code, defining module boundaries, establishing naming conventions, or reviewing pull requests."
        ],
        "concepts": [
          "Code is read far more often than it is written. Readability and explicit intent trump cleverness.",
          "High cohesion and low coupling ensure that a change in one module does not unpredictably break another.",
          "Tests are executable specifications that make refactoring safe."
        ],
        "ambiguity": [
          "Stop inference if the API boundary is unclear or if a module's single responsibility is overloaded."
        ],
        "decisions": [
          "Choose explicit composition and delegation over complex, deep inheritance trees.",
          "Determine whether a piece of state should be mutable or if immutable data structures can be used."
        ],
        "standards": [
          "Names must reveal intent. If a variable or function requires a comment to explain its purpose, rename it.",
          "Error handling is a primary concern, not an afterthought. Never swallow exceptions silently."
        ],
        "failure_modes": [
          "Creating 'god classes' or utilities that violate the Single Responsibility Principle.",
          "Using magic numbers or strings instead of named constants or typed enums."
        ],
        "next_queries": [
          "Query methodology/TESTING for test pyramid expectations.",
          "Query architecture/API_DESIGN for contract boundaries."
        ],
        "proceed_when": [
          "Proceed when the code is modular, intentionally named, and covered by deterministic tests."
        ]
      }
    },
    "architecture/COMPLIANCE": {
      "id": "architecture/COMPLIANCE",
      "category": "architecture",
      "title": "architecture/COMPLIANCE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers data classification, audit evidence, retention, access review, and regulated data handling.",
      "terms": [
        "data classification",
        "audit evidence",
        "retention policy",
        "dsar",
        "right-to-delete",
        "immutable log",
        "regulated data",
        "control mapping"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when handling regulated data (PII, PHI, PCI) or preparing for security audits."
        ],
        "concepts": [
          "Data Classification: Categorize every field by sensitivity level and map it to required technical controls.",
          "Audit Evidence: Automatically collect and store execution logs as immutable evidence of control adherence.",
          "Subject Rights: Design for Data Subject Access Requests (DSAR) and the right-to-delete from the start."
        ],
        "ambiguity": [
          "Stop if the regulatory framework (GDPR, SOC2, HIPAA) or data retention period is undefined."
        ],
        "decisions": [
          "Determine whether data must be physically segregated or logically masked for specific roles."
        ],
        "standards": [
          "Compliance controls must be mapped to executable tests or proof claims in the verification plan."
        ],
        "failure_modes": [
          "Mixing regulated and non-regulated data in the same storage tier without explicit segregation."
        ],
        "next_queries": [
          "Query architecture/SECURITY for boundary protection."
        ],
        "proceed_when": [
          "Proceed when the control mapping is complete and evidence collection is automated."
        ]
      }
    },
    "architecture/CONCURRENCY": {
      "id": "architecture/CONCURRENCY",
      "category": "architecture",
      "title": "architecture/CONCURRENCY",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers threads, async, locks, channels, queues, races, deadlocks, starvation, idempotency, ordering, backpressure, cancellation, and deterministic tests.",
      "terms": [
        "bounded",
        "prevention",
        "execution",
        "race",
        "locks",
        "coordination",
        "liveness",
        "deterministic",
        "async",
        "parallelism",
        "queues",
        "threads",
        "control",
        "concurrency"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when introducing parallel processing, async tasks, shared memory locks, or message passing channels."
        ],
        "concepts": [
          "Shared mutable state is the root cause of most concurrency bugs. Prefer message passing or immutable data.",
          "Async execution introduces scheduling overhead and requires cooperative cancellation.",
          "Backpressure is a correctness property. Unbounded concurrent queues are memory leaks."
        ],
        "ambiguity": [
          "Stop inference if the thread execution model, lock acquisition order, or timeout/cancellation semantics are undefined."
        ],
        "decisions": [
          "Choose between async I/O for network-bound workloads and dedicated thread pools for CPU-bound computations.",
          "Determine if coordination requires shared memory (Mutex/RwLock) or isolated actors (Channels)."
        ],
        "standards": [
          "Never hold a lock across an async await point to prevent deadlocks.",
          "Every external call or blocked operation must have an explicit timeout.",
          "Background tasks must handle and log their own errors."
        ],
        "failure_modes": [
          "Fire-and-forget background tasks that panic silently and lose data.",
          "Creating deadlocks by acquiring multiple locks in inconsistent orders across different threads."
        ],
        "next_queries": [
          "Query architecture/PERFORMANCE for profiling lock contention.",
          "Query architecture/DISTRIBUTED_SYSTEMS for network-level coordination."
        ],
        "proceed_when": [
          "Proceed when backpressure is implemented, timeouts are set, and race conditions are mitigated."
        ]
      }
    },
    "architecture/CONTAINERS": {
      "id": "architecture/CONTAINERS",
      "category": "architecture",
      "title": "architecture/CONTAINERS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "This domain covers image reproducibility, multi-stage builds, non-root runtime, minimal base images, SBOM/scanning, resource limits, and supply-chain risk.",
      "terms": [
        "chain",
        "construction",
        "containerization",
        "isolation",
        "resource",
        "image",
        "supply",
        "sandboxed",
        "execution",
        "limits",
        "runtime",
        "reproducibility",
        "registries",
        "containers"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "architecture/CI_CD_PIPELINES",
          "architecture/KUBERNETES",
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when writing Dockerfiles, configuring container runtimes, or establishing image build pipelines."
        ],
        "concepts": [
          "Containers are ephemeral. Any state written to the container filesystem is lost on restart.",
          "Image size impacts deployment velocity and attack surface. Smaller is faster and safer.",
          "Supply chain security requires knowing exactly what binaries and libraries are inside the image."
        ],
        "ambiguity": [
          "Stop inference if the base image provenance, exposed ports, or volume mount requirements are missing."
        ],
        "decisions": [
          "Select a minimal base image (e.g., Alpine, Distroless, Scratch) appropriate for the language runtime.",
          "Determine the build stages to separate compilation tools from the final production artifact."
        ],
        "standards": [
          "Use multi-stage builds. The final image must only contain the compiled binary/app and minimal runtime.",
          "Containers must run as a non-root user (USER directive) to prevent privilege escalation.",
          "Pin base images to specific SHAs or minor versions; never use the 'latest' tag in production."
        ],
        "failure_modes": [
          "Leaking secrets or credentials into image layers during the build process.",
          "Running applications as root, allowing host compromise if the container boundary is breached.",
          "Failing to define a .dockerignore, resulting in massive build contexts and unintended file inclusion."
        ],
        "next_queries": [
          "Query architecture/CI_CD_PIPELINES for build automation.",
          "Query architecture/KUBERNETES for runtime orchestration."
        ],
        "proceed_when": [
          "Proceed when the image builds reproducibly and passes static vulnerability scans."
        ]
      }
    },
    "architecture/COST_OPTIMIZATION": {
      "id": "architecture/COST_OPTIMIZATION",
      "category": "architecture",
      "title": "architecture/COST_OPTIMIZATION",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers unit economics, egress, rightsizing, autoscaling limits, and storage lifecycle costs.",
      "terms": [
        "unit economics",
        "egress",
        "rightsizing",
        "autoscaling",
        "storage lifecycle",
        "budget alarm",
        "reserved capacity",
        "spot instances"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "architecture/CLOUD",
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when evaluating infrastructure spend, rightsizing compute, or managing data transfer costs."
        ],
        "concepts": [
          "Unit Economics: Calculate the marginal cost of a single transaction or user action.",
          "Scaling Guardrails: Enforce hard floor/ceiling limits on all autoscaling groups to prevent runaway spend.",
          "Storage Lifecycle: Automatically transition stale data to cold/archive tiers based on access frequency."
        ],
        "ambiguity": [
          "Stop if the cost-per-transaction or the expected data transfer (egress) volume is unmodeled."
        ],
        "decisions": [
          "Decide between reserved capacity for base load vs spot instances for batch processing."
        ],
        "standards": [
          "All cloud resources must be tagged for cost attribution; untagged resources are considered defects."
        ],
        "failure_modes": [
          "Provisioning 'just-in-case' capacity instead of tuning autoscaling signals based on bottleneck evidence."
        ],
        "next_queries": [
          "Query architecture/CLOUD for service-specific pricing guardrails."
        ],
        "proceed_when": [
          "Proceed when budget alarms are set and unit economics are understood."
        ]
      }
    },
    "data/PIPELINES": {
      "id": "data/PIPELINES",
      "category": "data",
      "title": "data/PIPELINES",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "This domain covers data ownership, lineage, schema evolution, batch vs stream, quality checks, retention, privacy, replay, and analytical vs operational separation.",
      "terms": [
        "modeling",
        "schema evolution",
        "privacy",
        "analytical",
        "ownership",
        "governance",
        "retention",
        "pipelines",
        "lineage",
        "separation",
        "quality",
        "operational"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "data/CACHING",
          "data/DATABASE",
          "core/ENGINEERING_EXCELLENCE",
          "docs/MIGRATIONS"
        ]
      },
      "sections": {
        "match": [
          "Use when building ETL/ELT processes, streaming events, managing data warehouses, or handling data retention."
        ],
        "concepts": [
          "Operational data (OLTP) and analytical data (OLAP) require different models and storage.",
          "Data pipelines must be idempotent to allow safe replay of historical data.",
          "Data lineage tracks where data originated, how it transformed, and who consumes it."
        ],
        "ambiguity": [
          "Stop inference if data ownership, schema evolution strategy, or privacy constraints (PII) are unclear."
        ],
        "decisions": [
          "Choose between batch processing for high-volume periodic analysis or streaming for low-latency reactions.",
          "Decide how to handle schema changes (e.g., schema registry, backward compatibility rules)."
        ],
        "standards": [
          "Implement data quality checks (nulls, bounds, uniqueness) at ingestion boundaries.",
          "Enforce strict data retention and deletion policies to comply with privacy regulations.",
          "Separate compute from storage to scale analytical workloads efficiently."
        ],
        "failure_modes": [
          "Creating cyclic dependencies in DAGs, preventing pipeline completion.",
          "Failing to handle late-arriving data in streaming windows.",
          "Mixing PII with analytical data without proper masking or tokenization."
        ],
        "next_queries": [
          "Query data/DATABASE for transactional sources.",
          "Query architecture/EVENT_DRIVEN for stream processing."
        ],
        "proceed_when": [
          "Proceed when data lineage is tracked and privacy boundaries are explicitly maintained."
        ]
      }
    },
    "data/DATABASE": {
      "id": "data/DATABASE",
      "category": "data",
      "title": "data/DATABASE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "This domain covers schema ownership, migrations, indexes, transactions, consistency, backup/restore, data loss risk, and migration proof.",
      "terms": [
        "schema evolution",
        "migration rollback",
        "index",
        "transaction",
        "isolation level",
        "query plan",
        "n+1 query",
        "database",
        "consistency",
        "transactions",
        "design",
        "indexing",
        "backups",
        "replication",
        "schema",
        "safety"
      ],
      "links": {
        "references": [
          "data/CACHING",
          "data/PIPELINES",
          "architecture/DR",
          "core/ENGINEERING_EXCELLENCE",
          "docs/MIGRATIONS",
          "plugins/DB_BROKER",
          "specs/DB_BROKER_QUEUE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE",
          "docs/MIGRATIONS"
        ]
      },
      "sections": {
        "match": [
          "Use when altering table structures, defining indexes, writing complex queries, or changing persistence models."
        ],
        "concepts": [
          "Schema changes are migrations, not patches. They must be forward and backward compatible.",
          "Transactions protect data integrity across multiple operations. Understand isolation levels.",
          "Data loss is unrecoverable. Rollback paths must exist for every structural change."
        ],
        "ambiguity": [
          "Stop inference if the rollback strategy, query access pattern, or data retention policy is unspecified."
        ],
        "decisions": [
          "Choose index types (B-Tree, Hash, GIN) based on empirical read vs write trade-offs.",
          "Determine if eventual consistency is acceptable or if strong ACID guarantees are required."
        ],
        "standards": [
          "All schema modifications must be applied via automated, version-controlled migrations.",
          "Foreign keys and constraints must be enforced at the database level, not just the application layer.",
          "Identify and eliminate N+1 query patterns before code reaches production."
        ],
        "failure_modes": [
          "Applying blocking schema changes (like adding a column with a default) on large tables causing outages.",
          "Over-indexing tables, which destroys write performance and consumes memory.",
          "Failing to paginate large result sets, leading to application OOM crashes."
        ],
        "next_queries": [
          "Query data/PIPELINES for ETL and data lifecycle.",
          "Query data/CACHING for read optimization."
        ],
        "proceed_when": [
          "Proceed when the migration is reversible and query performance impact is analyzed."
        ]
      }
    },
    "architecture/DISTRIBUTED_SYSTEMS": {
      "id": "architecture/DISTRIBUTED_SYSTEMS",
      "category": "architecture",
      "title": "architecture/DISTRIBUTED_SYSTEMS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers network partitions, retries, timeouts, idempotency, consensus, consistency, ordering, clocks, replication, quorum, and partial failure.",
      "terms": [
        "retries",
        "consensus",
        "ordering",
        "isolation",
        "consistency",
        "failure",
        "distributed",
        "coordination",
        "idempotency",
        "eventual",
        "partitions"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "data/CACHING",
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when designing systems that span multiple nodes, regions, or networks, requiring coordination and consensus."
        ],
        "concepts": [
          "Network partitions are inevitable (CAP theorem). You must choose between consistency and availability during a split.",
          "Clocks across distributed nodes are not perfectly synchronized. Do not rely on physical timestamps for absolute ordering.",
          "Partial failures require retries, making idempotency a mandatory property for all distributed endpoints."
        ],
        "ambiguity": [
          "Stop inference if the required consistency model (strong vs eventual) or partition behavior is undefined."
        ],
        "decisions": [
          "Choose between orchestration (centralized coordinator, e.g., 2PC/Sagas) or choreography (event-driven) for distributed transactions.",
          "Determine the replication factor and quorum size required to survive node failures."
        ],
        "standards": [
          "Implement exponential backoff and jitter on all network retries to prevent retry storms.",
          "Use logical clocks (Lamport, Vector) or hybrid logical clocks for causal ordering of events."
        ],
        "failure_modes": [
          "Assuming network reliability, leading to infinite hangs without timeouts.",
          "Implementing 'exactly-once' delivery without an idempotent receiver, resulting in duplicate data processing."
        ],
        "next_queries": [
          "Query architecture/EVENT_DRIVEN for async coordination.",
          "Query architecture/NETWORKING for routing and load balancing."
        ],
        "proceed_when": [
          "Proceed when failure isolation, retries, timeouts, and idempotency are explicitly handled."
        ]
      }
    },
    "architecture/DR": {
      "id": "architecture/DR",
      "category": "architecture",
      "title": "architecture/DR",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "This domain covers RTO, RPO, backup verification, restore testing, failover, regional failure, runbooks, and recovery proof.",
      "terms": [
        "failover",
        "regional",
        "validation",
        "recovery",
        "disaster",
        "backup",
        "failure",
        "planning",
        "runbooks",
        "restore"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "architecture/CLOUD",
          "data/DATABASE",
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when designing system resilience, backup strategies, multi-region deployments, or failover mechanisms."
        ],
        "concepts": [
          "Disaster Recovery is about surviving catastrophic failures of entire zones or regions.",
          "Recovery Time Objective (RTO) dictates how quickly the system must be restored.",
          "Recovery Point Objective (RPO) dictates the maximum acceptable data loss."
        ],
        "ambiguity": [
          "Stop inference if RTO, RPO, or the definition of a catastrophic failure for this component is undefined."
        ],
        "decisions": [
          "Choose between Active-Active (high cost, low RTO) or Active-Passive (lower cost, higher RTO) topologies.",
          "Determine the backup frequency and replication strategy required to meet the RPO."
        ],
        "standards": [
          "Backups are useless if they cannot be restored. Automated restore testing is mandatory.",
          "Failover procedures must be scripted and documented in accessible runbooks.",
          "Store backups in a separate, isolated fault domain from the primary data."
        ],
        "failure_modes": [
          "Backing up corrupted data because data integrity was not verified prior to backup.",
          "Storing backup encryption keys in the same infrastructure that failed, rendering backups unreadable.",
          "Relying on manual, untested procedures during a high-stress incident."
        ],
        "next_queries": [
          "Query architecture/CLOUD for regional topology.",
          "Query data/DATABASE for persistence replication."
        ],
        "proceed_when": [
          "Proceed when RTO/RPO targets are explicitly stated and a tested restore path exists."
        ]
      }
    },
    "architecture/ENCRYPTION": {
      "id": "architecture/ENCRYPTION",
      "category": "architecture",
      "title": "architecture/ENCRYPTION",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers key custody, KMS/HSM, envelope encryption, TLS, at-rest encryption, rotation, nonce/IV misuse, approved primitives, and plaintext leakage.",
      "terms": [
        "misuse",
        "encryption",
        "boundaries",
        "resistant",
        "secrets",
        "protection",
        "rotation",
        "primitives",
        "management",
        "cryptographic",
        "custody",
        "rest"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "architecture/AUTH",
          "architecture/SECURITY",
          "core/ENGINEERING_EXCELLENCE",
          "specs/SECURITY"
        ]
      },
      "sections": {
        "match": [
          "Use when handling sensitive data, managing cryptographic keys, implementing TLS, or designing at-rest encryption."
        ],
        "concepts": [
          "Never roll your own crypto. Use battle-tested, high-level cryptographic libraries (e.g., libsodium, Tink).",
          "Envelope encryption isolates the master key (KEK) in a secure enclave (KMS/HSM) while using data keys (DEK) for actual encryption.",
          "Cryptographic agility ensures algorithms can be rotated when they become deprecated or compromised."
        ],
        "ambiguity": [
          "Stop inference if key custody, rotation lifecycle, or the required cryptographic primitive is undefined."
        ],
        "decisions": [
          "Determine the trust boundary: where does plaintext exist in memory, and who has access to the decryption keys?",
          "Select authenticated encryption (AEAD like AES-GCM or ChaCha20-Poly1305) over unauthenticated ciphers."
        ],
        "standards": [
          "All data in transit must use TLS 1.2+ with strong cipher suites.",
          "Secrets and keys must never be hardcoded, logged, or checked into version control."
        ],
        "failure_modes": [
          "Reusing a Nonce/IV with a stream cipher, completely destroying the encryption security.",
          "Storing the decryption key alongside the encrypted data in the same database or config file."
        ],
        "next_queries": [
          "Query architecture/SECRETS for runtime injection.",
          "Query architecture/SECURITY for overall threat modeling."
        ],
        "proceed_when": [
          "Proceed when cryptographic primitives are approved and key lifecycles are explicitly defined."
        ]
      }
    },
    "architecture/ENTERPRISE": {
      "id": "architecture/ENTERPRISE",
      "category": "architecture",
      "title": "architecture/ENTERPRISE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers multi-team ownership, procurement, SSO/SAML/OIDC, audit logs, data segregation, and integration contracts.",
      "terms": [
        "sso",
        "scim",
        "saml",
        "oidc",
        "audit logs",
        "data segregation",
        "procurement",
        "multi-team",
        "integration contract"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when designing for organizational scale, compliance boundaries, or multi-team service ownership."
        ],
        "concepts": [
          "Identity and Access: Enforce SSO (SAML/OIDC) and SCIM-based provisioning for all internal and external surfaces.",
          "Auditability: Maintain immutable activity logs for all state mutations and access attempts across team boundaries.",
          "Integration: All cross-team dependencies must be governed by versioned, backward-compatible API contracts."
        ],
        "ambiguity": [
          "Stop if the data steward, procurement constraint, or cross-team support model is undefined."
        ],
        "decisions": [
          "Decide between shared-infrastructure clusters versus strict tenant-level account segregation."
        ],
        "standards": [
          "Enterprise integrations must pass automated contract tests before promotion to production."
        ],
        "failure_modes": [
          "Allowing ad-hoc database sharing between teams, bypassing explicit API boundaries."
        ],
        "next_queries": [
          "Query architecture/COMPLIANCE for data classification rules."
        ],
        "proceed_when": [
          "Proceed when the integration contract is signed off and the audit trail is instrumented."
        ]
      }
    },
    "architecture/EVENT_DRIVEN": {
      "id": "architecture/EVENT_DRIVEN",
      "category": "architecture",
      "title": "architecture/EVENT_DRIVEN",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers events, commands, queues, topics, partitions, schemas, ordering, replay, idempotent consumers, DLQs, backpressure, and eventual consistency.",
      "terms": [
        "schema evolution",
        "consumers",
        "backpressure",
        "idempotent",
        "events",
        "ordering",
        "consistency",
        "streams",
        "event",
        "replay",
        "eventual",
        "queues",
        "driven",
        "schemas"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when building asynchronous workflows, message brokers, stream processing, or decoupling microservices."
        ],
        "concepts": [
          "Events describe something that has happened (immutable past). Commands request something to happen.",
          "Consumers must be idempotent to handle 'at-least-once' delivery semantics safely.",
          "Eventual consistency is the default; systems must handle the delay between event emission and processing."
        ],
        "ambiguity": [
          "Stop inference if the ordering guarantees, schema evolution strategy, or dead-letter routing are undefined."
        ],
        "decisions": [
          "Choose between a message queue (competing consumers, task distribution) and a stream/topic (pub/sub, replayability).",
          "Determine the partitioning strategy to ensure causal ordering for related events."
        ],
        "standards": [
          "Event schemas must be versioned and validated (e.g., Protobuf, Avro, JSON Schema) to prevent poison pills.",
          "All async processing systems must configure Dead Letter Queues (DLQs) for unprocessable messages."
        ],
        "failure_modes": [
          "Assuming events will arrive exactly once and in the exact order they were emitted.",
          "Creating infinite retry loops that poison the queue and block subsequent event processing."
        ],
        "next_queries": [
          "Query architecture/MESSAGING for broker specifics.",
          "Query architecture/DISTRIBUTED_SYSTEMS for eventual consistency."
        ],
        "proceed_when": [
          "Proceed when consumers are idempotent, schemas are versioned, and DLQs are configured."
        ]
      }
    },
    "architecture/FRONTEND": {
      "id": "architecture/FRONTEND",
      "category": "architecture",
      "title": "architecture/FRONTEND",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "This domain covers platform target, rendering model, state ownership, accessibility, API contract, latency, error states, browser constraints, and user workflow.",
      "terms": [
        "frontend",
        "boundaries",
        "error",
        "rendering",
        "client",
        "user",
        "facing",
        "contracts",
        "accessibility",
        "state",
        "reliability"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when building UI components, managing client-side state, handling user input, or integrating with backend APIs."
        ],
        "concepts": [
          "Client state is ephemeral and untrusted. The backend is the source of truth.",
          "Rendering models (CSR, SSR, SSG) drastically alter time-to-interactive and SEO implications.",
          "Accessibility (a11y) is a baseline requirement, not a feature. Semantic HTML is the foundation."
        ],
        "ambiguity": [
          "Stop inference if the target browser matrix, rendering model, or API contract is missing."
        ],
        "decisions": [
          "Determine where state lives: URL, local component, global store, or server cache.",
          "Choose between eager fetching, lazy loading, or prefetching based on user workflow critical paths."
        ],
        "standards": [
          "Implement global error boundaries to prevent full application crashes from isolated component failures.",
          "Respect browser constraints: avoid main-thread blocking operations; debounce and throttle frequent inputs.",
          "Provide immediate optimistic UI feedback while reconciling with the server asynchronously."
        ],
        "failure_modes": [
          "Leaking sensitive API keys or business logic into the client bundle.",
          "Over-fetching data or failing to implement loading states, leading to poor perceived latency.",
          "Ignoring focus management and screen reader compatibility."
        ],
        "next_queries": [
          "Query architecture/API_DESIGN for data contracts.",
          "Query architecture/SECURITY for XSS and CSRF prevention."
        ],
        "proceed_when": [
          "Proceed when error states are handled and accessibility baselines are met."
        ]
      }
    },
    "architecture/GRAPHQL": {
      "id": "architecture/GRAPHQL",
      "category": "architecture",
      "title": "architecture/GRAPHQL",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Contract guidance for GraphQL APIs covering schema design, N+1 prevention, pagination, and error handling.",
      "terms": [
        "resolver",
        "dataloader",
        "n+1 query",
        "query depth",
        "cursor pagination",
        "schema federation",
        "authorization",
        "complexity",
        "graphql",
        "federation",
        "shape",
        "batching",
        "design",
        "query",
        "error",
        "client"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when designing GraphQL schemas, writing resolvers, or integrating DataLoader patterns."
        ],
        "concepts": [
          "GraphQL shifts data selection to the client, but the server must defend against complex queries.",
          "The schema is a strict type system graph that clients rely on for introspection."
        ],
        "ambiguity": [
          "Stop inference if resolver depth limits or pagination strategies are undefined."
        ],
        "decisions": [
          "Decide on the pagination standard (e.g., Relay-style Cursor Connections).",
          "Determine authorization boundaries (at the resolver level vs domain level)."
        ],
        "standards": [
          "Use DataLoader patterns universally to prevent N+1 database query issues.",
          "Return structured, typed errors (e.g., ValidationErrors) alongside partial data."
        ],
        "failure_modes": [
          "Allowing deeply nested recursive queries that cause denial of service.",
          "Exposing raw database schemas directly without a logical abstraction layer."
        ],
        "next_queries": [
          "Query data/DATABASE for query optimization.",
          "Query architecture/AUTH for resolver-level authorization."
        ],
        "proceed_when": [
          "Proceed when resolvers are protected against N+1 queries and authorization is enforced."
        ]
      }
    },
    "architecture/GRPC": {
      "id": "architecture/GRPC",
      "category": "architecture",
      "title": "architecture/GRPC",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Contract guidance for gRPC APIs covering proto schemas, streaming patterns, status codes, and error handling.",
      "terms": [
        "proto compatibility",
        "deadline",
        "unary rpc",
        "streaming rpc",
        "status code",
        "protobuf",
        "rpcs",
        "generated",
        "proto",
        "clients",
        "streaming",
        "deadlines",
        "mtls",
        "compatibility",
        "unary",
        "codes"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when designing or implementing gRPC services, defining Protocol Buffers, or managing RPC streams."
        ],
        "concepts": [
          "gRPC relies on strongly typed contracts defined via Protocol Buffers.",
          "Streaming models (unary, server, client, bidirectional) dictate connection lifecycle."
        ],
        "ambiguity": [
          "Stop inference if the protobuf definition lacks clear versioning or backward compatibility guarantees."
        ],
        "decisions": [
          "Select the correct streaming pattern based on data volume and latency requirements."
        ],
        "standards": [
          "Use standardized gRPC status codes (e.g., NOT_FOUND, FAILED_PRECONDITION) instead of generic errors.",
          "Define strict field validations within the proto definitions."
        ],
        "failure_modes": [
          "Changing existing field types or numbers, breaking backward compatibility.",
          "Failing to implement server-side or client-side timeouts (deadlines)."
        ],
        "next_queries": [
          "Query architecture/API_DESIGN for broader contract compatibility.",
          "Query architecture/PERFORMANCE for multiplexing considerations."
        ],
        "proceed_when": [
          "Proceed when the proto schema passes linting and backward compatibility checks."
        ]
      }
    },
    "architecture/INFRASTRUCTURE": {
      "id": "architecture/INFRASTRUCTURE",
      "category": "architecture",
      "title": "architecture/INFRASTRUCTURE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers compute, networking, IAM, storage, environments, IaC, drift, promotion, secrets, backups, lifecycle ownership, and operational handoff.",
      "terms": [
        "identity",
        "drift",
        "drift detection",
        "promotion",
        "storage",
        "environments",
        "ownership",
        "infrastructure",
        "compute",
        "management",
        "networks",
        "operational"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "architecture/CLOUD",
          "core/ENGINEERING_EXCELLENCE",
          "docs/ARCHITECTURE_OVERVIEW"
        ]
      },
      "sections": {
        "match": [
          "Use when provisioning cloud resources, defining environments, managing IaC (Terraform/Pulumi), or planning operational handoff."
        ],
        "concepts": [
          "Infrastructure is code. If it requires manual console clicks, it is a defect.",
          "Environments (dev, staging, prod) must be structurally identical, differing only in scale and secrets.",
          "Infrastructure state drift occurs when manual changes circumvent the IaC pipeline."
        ],
        "ambiguity": [
          "Stop inference if the state backend, environment isolation strategy, or lifecycle owner is unspecified."
        ],
        "decisions": [
          "Decide how to segregate state files (e.g., per environment, per service) to minimize blast radius.",
          "Determine the secret injection mechanism (e.g., Vault, AWS Secrets Manager) for the provisioned compute."
        ],
        "standards": [
          "All infrastructure changes must be applied via a CI/CD pipeline, never from local developer machines.",
          "Enforce strict logical isolation (VPCs, separate accounts) between production and non-production environments."
        ],
        "failure_modes": [
          "Storing IaC state files locally or without state-locking mechanisms, causing corruption on concurrent applies.",
          "Hardcoding environment-specific configurations instead of using parameters and variables."
        ],
        "next_queries": [
          "Query architecture/CLOUD for managed service specifics.",
          "Query architecture/NETWORKING for VPC and routing topology."
        ],
        "proceed_when": [
          "Proceed when the infrastructure is fully declared in code and promotion across environments is automated."
        ]
      }
    },
    "architecture/KNOWLEDGE_BASE": {
      "id": "architecture/KNOWLEDGE_BASE",
      "category": "architecture",
      "title": "architecture/KNOWLEDGE_BASE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers source ingestion, provenance, indexing, retrieval quality, summarization, graph relationships, stale knowledge, authority levels, and agent consumption.",
      "terms": [
        "consumable",
        "capture",
        "retrieval",
        "agent",
        "summaries",
        "provenance",
        "organization",
        "context",
        "concepts",
        "knowledge",
        "base",
        "relationships"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE",
          "methodology/KNOWLEDGE",
          "plugins/KNOWLEDGE"
        ]
      },
      "sections": {
        "match": [
          "Use when building RAG systems, managing embedding indices, or designing knowledge retrieval for AI agents."
        ],
        "concepts": [
          "Knowledge is only useful if it is retrievable, accurate, and has clear provenance (source tracking).",
          "Stale knowledge poisons agent reasoning. Invalidation and decay mechanisms are critical.",
          "Different sources have different authority levels (e.g., binding specs vs community discussions)."
        ],
        "ambiguity": [
          "Stop inference if the chunking strategy, embedding model, or provenance tracking mechanism is undefined."
        ],
        "decisions": [
          "Choose the chunking strategy based on the semantic boundaries of the source material.",
          "Decide between vector search (semantic) and keyword search (BM25), or a hybrid approach for optimal retrieval."
        ],
        "standards": [
          "Always attach metadata (timestamp, author, source document) to vector embeddings.",
          "Provide mechanisms for humans or agents to explicitly flag or update outdated knowledge."
        ],
        "failure_modes": [
          "Ingesting massive documents without semantic chunking, diluting the embedding relevance.",
          "Feeding an agent highly confident but stale information without citing the provenance or timestamp."
        ],
        "next_queries": [
          "Query data/DATABASE for vector store persistence.",
          "Query methodology/KNOWLEDGE for curation practices."
        ],
        "proceed_when": [
          "Proceed when the retrieval mechanism ensures high relevance and tracks the provenance of the returned knowledge."
        ]
      }
    },
    "architecture/KUBERNETES": {
      "id": "architecture/KUBERNETES",
      "category": "architecture",
      "title": "architecture/KUBERNETES",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "This domain covers workloads, services, ingress, probes, requests/limits, RBAC, secrets, namespaces, rollout strategy, config, cluster boundary, and operational ownership.",
      "terms": [
        "rollout strategy",
        "services",
        "rollout",
        "workloads",
        "kubernetes",
        "ingress",
        "scheduling",
        "rbac",
        "boundaries",
        "secrets",
        "strategy",
        "probes",
        "cluster",
        "operational",
        "operations"
      ],
      "links": {
        "references": [
          "architecture/CI_CD_PIPELINES",
          "architecture/CLOUD",
          "architecture/CONTAINERS",
          "architecture/NETWORKING",
          "architecture/OBSERVABILITY",
          "architecture/SCALING",
          "architecture/SECRETS",
          "architecture/SECURITY",
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "architecture/CI_CD_PIPELINES",
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when modifying deployment manifests, RBAC policies, resource limits, or cluster-level networking and ingress."
        ],
        "concepts": [
          "Kubernetes workloads must specify resource requests and limits to ensure scheduler predictability.",
          "Use namespaces as the primary administrative boundary for environments and logical isolation.",
          "Secrets must be managed externally and injected at runtime, never committed to repository state."
        ],
        "ambiguity": [
          "Stop inference if the operational ownership, cluster namespace, or rollout strategy is unclear."
        ],
        "decisions": [
          "Determine the correct workload primitive: Deployment for stateless, StatefulSet for stable identities, DaemonSet for node-local.",
          "Select the ingress model and service type (ClusterIP vs LoadBalancer) based on exposure risk."
        ],
        "standards": [
          "Liveness and readiness probes are mandatory for all application workloads.",
          "Apply least-privilege RBAC for all ServiceAccounts. Default to deny for network policies.",
          "Use rolling updates with explicit surge and unavailable limits to prevent downtime during deploys."
        ],
        "failure_modes": [
          "Deploying without resource requests causes unpredictable node eviction and starvation.",
          "Running containers as root inside pods breaks isolation security postures.",
          "Orphaned PVCs or mismatched volume mounts cause silent data attachment failures."
        ],
        "next_queries": [
          "Query architecture/CONTAINERS for image construction rules.",
          "Query architecture/CI_CD_PIPELINES for deployment automation limits."
        ],
        "proceed_when": [
          "Proceed when the manifest structure matches the target cluster version and probes are defined."
        ]
      }
    },
    "architecture/MEMORY": {
      "id": "architecture/MEMORY",
      "category": "architecture",
      "title": "architecture/MEMORY",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Clarify whether this means runtime memory, process memory, agent memory, cache memory, or persisted memory. If ambiguous, route to specific sub-domains.",
      "terms": [
        "separation",
        "allocation",
        "boundaries",
        "context",
        "persistence",
        "caching",
        "pressure",
        "leaks",
        "locality",
        "object",
        "memory",
        "lifetimes"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when addressing memory allocation, garbage collection, out-of-memory (OOM) errors, or agentic long-term memory."
        ],
        "concepts": [
          "Memory has distinct contexts: Application heap/stack, distributed caches, and agentic semantic memory.",
          "Unbounded memory growth is a delayed-fuse defect. Every collection must have limits.",
          "Agent memory refers to preserving conversational or task context across sessions."
        ],
        "ambiguity": [
          "Stop inference immediately if the type of memory (system RAM vs agent context) is unclarified."
        ],
        "decisions": [
          "Determine if the problem is system resource allocation (RAM) or semantic state preservation.",
          "For agents, decide between short-term context windows and long-term vector/graph memory retrieval."
        ],
        "standards": [
          "System memory: Set explicit resource limits and limits on all containerized workloads.",
          "Agent memory: Use deterministic summarization and compaction to prevent context window exhaustion."
        ],
        "failure_modes": [
          "Failing to close database connections or file handles, leading to rapid memory leaks.",
          "Stuffing raw logs into an LLM context window until it OOMs instead of retrieving targeted snippets."
        ],
        "next_queries": [
          "Query architecture/PERFORMANCE for application memory.",
          "Query methodology/MEMORY for agent cognitive memory."
        ],
        "proceed_when": [
          "Proceed when the specific type of memory is identified and its bounding constraints are defined."
        ]
      }
    },
    "architecture/MESSAGING": {
      "id": "architecture/MESSAGING",
      "category": "architecture",
      "title": "architecture/MESSAGING",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers brokers, queues, topics, routing keys, partitions, consumer groups, retries, DLQs, delivery semantics, ordering, payload size, and backpressure.",
      "terms": [
        "dlq",
        "poison message",
        "consumer group",
        "routing key",
        "partition",
        "backpressure",
        "retries",
        "ordering",
        "dead",
        "brokers",
        "messaging",
        "topics",
        "semantics",
        "queues"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when configuring message brokers (Kafka, RabbitMQ, SQS), defining routing topologies, or managing async communication."
        ],
        "concepts": [
          "Message brokers decouple producers and consumers in time and space.",
          "Delivery semantics matter: At-least-once is standard, requiring idempotent consumers. Exactly-once is incredibly expensive.",
          "Message payloads should be small. Large blobs should be stored in S3/GCS with a reference passed in the message."
        ],
        "ambiguity": [
          "Stop inference if the delivery guarantee, partition/routing key strategy, or DLQ behavior is undefined."
        ],
        "decisions": [
          "Choose between a smart broker / dumb consumer (RabbitMQ) vs a dumb broker / smart consumer (Kafka) topology.",
          "Determine how message ordering will be preserved (e.g., partitioning by user ID)."
        ],
        "standards": [
          "Always implement Dead Letter Queues (DLQs) for messages that fail processing after retries.",
          "Consumers must exert backpressure or drop messages if they cannot keep up with the broker."
        ],
        "failure_modes": [
          "Creating 'poison pill' messages that continuously crash consumers and block the entire partition.",
          "Using messaging for synchronous request-response workflows, creating brittle, complex architectures."
        ],
        "next_queries": [
          "Query architecture/EVENT_DRIVEN for async workflow design.",
          "Query data/PIPELINES for stream processing."
        ],
        "proceed_when": [
          "Proceed when routing keys guarantee required ordering and DLQs are explicitly configured."
        ]
      }
    },
    "architecture/METRICS": {
      "id": "architecture/METRICS",
      "category": "architecture",
      "title": "architecture/METRICS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers counters, gauges, histograms, SLIs/SLOs, cardinality, labels, alert thresholds, dashboard utility, business metrics, and operational signals.",
      "terms": [
        "signals",
        "metrics",
        "counters",
        "measurement",
        "decision",
        "dashboards",
        "slos",
        "slis",
        "instrumentation",
        "alerting",
        "histograms",
        "operational"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "architecture/OBSERVABILITY",
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when defining system observability, configuring Prometheus/Datadog, establishing SLOs, or creating dashboards."
        ],
        "concepts": [
          "Metrics provide aggregated numerical data over time, distinct from granular logs or traces.",
          "Service Level Indicators (SLIs) measure the true customer experience (e.g., success rate, latency).",
          "High cardinality (too many unique label combinations) will crash time-series databases."
        ],
        "ambiguity": [
          "Stop inference if the metric type (counter vs gauge), cardinality impact, or SLO target is unclear."
        ],
        "decisions": [
          "Select the correct metric type: Counters for absolute numbers (requests), Gauges for current state (queue depth), Histograms for distributions (latency).",
          "Decide which metrics justify waking up an engineer (actionable alerts) versus which belong on a dashboard."
        ],
        "standards": [
          "Alerts must be tied to SLO burn rates or customer pain, not internal system thresholds like CPU usage.",
          "Standardize label naming across all services (e.g., env, service, region, status_code)."
        ],
        "failure_modes": [
          "Using unbounded variables (like user IDs or raw URLs) as metric labels, causing cardinality explosions.",
          "Creating alert fatigue by triggering paging alerts for transient, self-healing issues."
        ],
        "next_queries": [
          "Query architecture/OBSERVABILITY for holistic monitoring strategies.",
          "Query architecture/SCALING for threshold-based scaling."
        ],
        "proceed_when": [
          "Proceed when metrics directly measure customer impact and cardinality is strictly bounded."
        ]
      }
    },
    "architecture/MICROSERVICES": {
      "id": "architecture/MICROSERVICES",
      "category": "architecture",
      "title": "architecture/MICROSERVICES",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers service boundaries, data ownership, deployment independence, API contracts, observability, team ownership, distributed failure, and when a modular monolith is better.",
      "terms": [
        "service",
        "boundaries",
        "isolation",
        "operability",
        "ownership",
        "failure",
        "microservices",
        "apis",
        "independence",
        "deployment"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when breaking apart a monolith, defining new service boundaries, or managing distributed communication."
        ],
        "concepts": [
          "Microservices solve organizational scaling problems, not technical performance problems.",
          "Each microservice must own its own data. Shared databases violate service independence.",
          "Network calls fail. Distributed monoliths occur when services synchronously depend on each other to respond."
        ],
        "ambiguity": [
          "Stop inference if the data ownership boundary, inter-service API contract, or fallback behavior is undefined."
        ],
        "decisions": [
          "Determine if the complexity of distributed systems is justified, or if a modular monolith suffices.",
          "Choose between synchronous RPC/REST (higher coupling) and asynchronous events (higher complexity) for inter-service communication."
        ],
        "standards": [
          "Services must be independently deployable without requiring lock-step deployments of other services.",
          "Implement distributed tracing (e.g., OpenTelemetry) across all service boundaries to debug requests."
        ],
        "failure_modes": [
          "Creating a distributed monolith where a failure in one service synchronously cascades and brings down the entire system.",
          "Sharing a single database cluster across multiple microservices, leading to schema lock-in and performance coupling."
        ],
        "next_queries": [
          "Query architecture/DISTRIBUTED_SYSTEMS for consensus and failure.",
          "Query architecture/API_DESIGN for inter-service contracts."
        ],
        "proceed_when": [
          "Proceed when service boundaries encapsulate domain logic, data is isolated, and tracing is in place."
        ]
      }
    },
    "architecture/NETWORKING": {
      "id": "architecture/NETWORKING",
      "category": "architecture",
      "title": "architecture/NETWORKING",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers DNS, routing, load balancing, ingress/egress, CIDRs, firewall rules, service discovery, TLS, segmentation, latency, and failure diagnosis.",
      "terms": [
        "cidr",
        "dns",
        "ingress",
        "egress",
        "firewall rule",
        "load balancer",
        "service discovery",
        "mtls",
        "networking",
        "routing",
        "balancing",
        "service",
        "network",
        "connectivity",
        "addressing",
        "segmentation"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "architecture/CLOUD",
          "architecture/KUBERNETES",
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when designing VPCs, configuring load balancers, managing DNS, setting up service mesh, or defining firewall rules."
        ],
        "concepts": [
          "Networks are hostile and unreliable. Assume latency, dropped packets, and malicious traffic.",
          "Zero-trust networking assumes internal networks are as dangerous as the public internet.",
          "CIDR planning is foundational; overlapping IP ranges prevent VPC peering and cause routing nightmares."
        ],
        "ambiguity": [
          "Stop inference if the subnets, ingress/egress routing paths, or TLS termination boundaries are undefined."
        ],
        "decisions": [
          "Decide where TLS termination occurs (at the edge/load balancer vs inside the application pod).",
          "Determine the segmentation strategy: public vs private subnets, NAT gateways, and security group isolation."
        ],
        "standards": [
          "All internal service-to-service communication must be authenticated and encrypted (mTLS).",
          "Security groups/firewalls must deny all traffic by default and explicitly allow specific ports and CIDRs."
        ],
        "failure_modes": [
          "Placing databases or internal microservices in public subnets with public IP addresses.",
          "Hardcoding IP addresses instead of using DNS or dynamic service discovery mechanisms."
        ],
        "next_queries": [
          "Query architecture/CLOUD for managed network gateways.",
          "Query architecture/SECURITY for boundary protection."
        ],
        "proceed_when": [
          "Proceed when the network topology isolates internal state and strictly governs ingress/egress."
        ]
      }
    },
    "architecture/OBSERVABILITY": {
      "id": "architecture/OBSERVABILITY",
      "category": "architecture",
      "title": "architecture/OBSERVABILITY",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers structured logs, metrics, traces, SLIs/SLOs, cardinality, and customer-impact signals.",
      "terms": [
        "structured logs",
        "metrics",
        "traces",
        "correlation id",
        "slis",
        "slos",
        "cardinality",
        "alert fatigue",
        "dashboards",
        "sampling"
      ],
      "links": {
        "references": [
          "architecture/METRICS",
          "core/ENGINEERING_EXCELLENCE",
          "methodology/INCIDENT_RESPONSE",
          "plugins/AUDIT",
          "plugins/HEALTH"
        ],
        "referenced_by": [
          "architecture/API_DESIGN",
          "data/CACHING",
          "architecture/CLOUD",
          "architecture/KUBERNETES",
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when instrumenting code, configuring telemetry, or defining service level objectives."
        ],
        "concepts": [
          "Telemetry Pillars: Unify Metrics (status), Traces (paths), and Logs (context) using a shared Correlation ID.",
          "SLIs/SLOs: Measure the true customer experience; define acceptable failure thresholds (error budgets).",
          "Cardinality Control: Limit the number of unique label combinations to prevent telemetry store crashes."
        ],
        "ambiguity": [
          "Stop if the SLO burn rate or the specific customer-impact signal is unmeasured."
        ],
        "decisions": [
          "Decide on sampling rates to balance visibility against telemetry ingestion costs."
        ],
        "standards": [
          "Every log entry must include a Correlation ID and a machine-parseable severity level."
        ],
        "failure_modes": [
          "Optimizing internal system metrics (e.g. CPU) instead of user-visible success signals."
        ],
        "next_queries": [
          "Query architecture/METRICS for technical implementation."
        ],
        "proceed_when": [
          "Proceed when the request is traceable end-to-end and SLIs are defined."
        ]
      }
    },
    "architecture/PERFORMANCE": {
      "id": "architecture/PERFORMANCE",
      "category": "architecture",
      "title": "architecture/PERFORMANCE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers latency, throughput, profiling, bottlenecks, load testing, resource contention, caching, async work, query plans, and user-visible responsiveness.",
      "terms": [
        "responsiveness",
        "throughput",
        "visible",
        "latency",
        "profiling",
        "capacity",
        "user",
        "load",
        "bottlenecks",
        "testing",
        "p99 latency"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "data/CACHING",
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when optimizing slow endpoints, addressing resource contention, or designing for high throughput requirements."
        ],
        "concepts": [
          "Performance is bounded by the slowest component (bottleneck). Optimization outside the bottleneck is wasted effort.",
          "Latency and throughput are different. You can have high throughput with terrible latency, and vice versa.",
          "Percentiles matter. Averages hide outliers. Measure P95 and P99 to understand true user experience."
        ],
        "ambiguity": [
          "Stop inference if the target throughput, acceptable P99 latency, or specific system bottleneck is unknown."
        ],
        "decisions": [
          "Decide whether to scale vertically (more CPU/RAM) or horizontally (more nodes) based on the application's statefulness.",
          "Determine if synchronous operations can be deferred to background queues to improve user-perceived latency."
        ],
        "standards": [
          "Performance must be measured using profiling tools and load tests, never by guessing.",
          "Database queries must have their execution plans (EXPLAIN) analyzed before optimization."
        ],
        "failure_modes": [
          "Optimizing code execution speed when the actual bottleneck is database I/O or network latency.",
          "Testing performance on a local machine with an empty database and assuming it reflects production."
        ],
        "next_queries": [
          "Query architecture/ALGORITHMS for computational efficiency.",
          "Query data/DATABASE for query optimization."
        ],
        "proceed_when": [
          "Proceed when empirical profiling identifies the bottleneck and performance targets are explicit."
        ]
      }
    },
    "architecture/SCALING": {
      "id": "architecture/SCALING",
      "category": "architecture",
      "title": "architecture/SCALING",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers horizontal vs vertical scaling, bottleneck evidence, traffic shape, read/write ratio, autoscaling signals, partitioning, quotas, load tests, and capacity planning.",
      "terms": [
        "scaling",
        "demand",
        "partitioning",
        "sharding",
        "quotas",
        "vertical",
        "capacity",
        "horizontal",
        "autoscaling",
        "driven"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "architecture/KUBERNETES",
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when designing systems to handle increased load, configuring autoscalers, or planning database sharding."
        ],
        "concepts": [
          "Horizontal scaling (adding nodes) requires stateless application layers and robust load balancing.",
          "Vertical scaling (adding CPU/RAM) is simpler but has a hard physical ceiling and requires downtime.",
          "Stateful systems (databases) are the hardest to scale horizontally and usually require partitioning/sharding."
        ],
        "ambiguity": [
          "Stop inference if the read/write ratio, expected traffic spikes, or scaling trigger metrics are undefined."
        ],
        "decisions": [
          "Choose scaling triggers based on application profiles: CPU/Memory for compute-bound, Queue Depth for async workers.",
          "Decide when caching is sufficient vs when the underlying persistence layer must be sharded."
        ],
        "standards": [
          "Design for statelessness. HTTP sessions must be backed by distributed stores (e.g., Redis), not local memory.",
          "Implement rate limiting, quotas, and load shedding to protect the system during extreme traffic spikes."
        ],
        "failure_modes": [
          "Relying on autoscaling to fix a poorly performing database query. The database will still crash.",
          "Scaling up stateless web servers while the shared database connections max out, moving the bottleneck."
        ],
        "next_queries": [
          "Query architecture/CLOUD for auto-scaling groups.",
          "Query architecture/DISTRIBUTED_SYSTEMS for data partitioning."
        ],
        "proceed_when": [
          "Proceed when the application is stateless and scaling limits are protected by backpressure mechanisms."
        ]
      }
    },
    "architecture/SECRETS": {
      "id": "architecture/SECRETS",
      "category": "architecture",
      "title": "architecture/SECRETS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers secret sources, injection, rotation, revocation, audit, least privilege, local dev handling, CI/CD exposure, logs, and leak response.",
      "terms": [
        "injection",
        "policy",
        "storage",
        "revocation",
        "prevention",
        "secrets",
        "rotation",
        "access",
        "leakage",
        "management",
        "audit",
        "custody",
        "credential"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "architecture/AUTH",
          "architecture/KUBERNETES",
          "architecture/SECURITY",
          "core/ENGINEERING_EXCELLENCE",
          "docs/SECURITY_THREAT_MODEL",
          "specs/SECURITY"
        ]
      },
      "sections": {
        "match": [
          "Use when handling API keys, database passwords, TLS certificates, or configuring CI/CD secret injection."
        ],
        "concepts": [
          "A secret is any credential that grants access to a system. It must be protected at rest, in transit, and in memory.",
          "Secrets must be injected at runtime via environment variables or mounted volumes, never baked into images.",
          "Every secret must have a lifecycle: generation, distribution, rotation, and revocation."
        ],
        "ambiguity": [
          "Stop inference if the secret storage provider, rotation policy, or injection mechanism is undefined."
        ],
        "decisions": [
          "Choose between a centralized secret manager (Vault, AWS Secrets Manager) and native orchestrator secrets (K8s Secrets).",
          "Determine how local development environments securely access required credentials without using production keys."
        ],
        "standards": [
          "Never commit secrets to version control. Use pre-commit hooks to detect accidental inclusions.",
          "CI/CD pipelines must mask secrets in their output logs."
        ],
        "failure_modes": [
          "Hardcoding credentials directly into source code or configuration files.",
          "Passing secrets via command-line arguments, which are visible to all users on the host via 'ps'."
        ],
        "next_queries": [
          "Query architecture/ENCRYPTION for key cryptography.",
          "Query architecture/CI_CD_PIPELINES for pipeline injection."
        ],
        "proceed_when": [
          "Proceed when secrets are managed externally, injected dynamically, and rotation is planned."
        ]
      }
    },
    "architecture/SECURITY": {
      "id": "architecture/SECURITY",
      "category": "architecture",
      "title": "architecture/SECURITY",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers trust boundaries, abuse cases, input validation, least privilege, and incident evidence.",
      "terms": [
        "trust boundary",
        "abuse case",
        "input validation",
        "least privilege",
        "dependency trust",
        "secret handling",
        "authn/authz",
        "incident evidence"
      ],
      "links": {
        "references": [
          "architecture/AUTH",
          "architecture/ENCRYPTION",
          "architecture/SECRETS",
          "core/ENGINEERING_EXCELLENCE",
          "docs/SECURITY_THREAT_MODEL",
          "specs/SECURITY"
        ],
        "referenced_by": [
          "architecture/API_DESIGN",
          "architecture/AUTH",
          "architecture/CLOUD",
          "architecture/KUBERNETES",
          "core/ENGINEERING_EXCELLENCE",
          "docs/ARCHITECTURE_OVERVIEW",
          "docs/SECURITY_THREAT_MODEL"
        ]
      },
      "sections": {
        "match": [
          "Use when threat modeling, handling user input, or defining secure communication paths."
        ],
        "concepts": [
          "Trust Boundaries: Identify every point where data moves from untrusted to trusted control.",
          "Defense in Depth: Layer security controls so that a single component failure does not lead to total compromise.",
          "Validation: Treat all external input as malicious; validate against strict, allow-listed schemas."
        ],
        "ambiguity": [
          "Stop if the trust boundary, input schema, or specific threat model is unspecified."
        ],
        "decisions": [
          "Identify which data requires at-rest encryption vs transit-only protection."
        ],
        "standards": [
          "Enforce least-privilege at every layer; default to 'deny-all' for all resource access."
        ],
        "failure_modes": [
          "Relying on client-side security checks that can be bypassed by an attacker."
        ],
        "next_queries": [
          "Query architecture/AUTH for identity management."
        ],
        "proceed_when": [
          "Proceed when trust boundaries are defended and input validation is enforced."
        ]
      }
    },
    "architecture/SYSTEMS_DESIGN": {
      "id": "architecture/SYSTEMS_DESIGN",
      "category": "architecture",
      "title": "architecture/SYSTEMS_DESIGN",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers requirements, constraints, data flow, state ownership, consistency models, and failure domains.",
      "terms": [
        "data flow",
        "state ownership",
        "consistency model",
        "failure domain",
        "interface contract",
        "rollout",
        "capacity",
        "observability"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when mapping component boundaries, data flow paths, or state mutation rules."
        ],
        "concepts": [
          "Data Flow: Map exactly how intent becomes state and how state is synchronized across the system.",
          "Failure Domains: Design for partial failure; identify which components can safely stay down during an incident.",
          "Consistency: Explicitly select Strong vs Eventual consistency based on the load-bearing requirements of the domain."
        ],
        "ambiguity": [
          "Stop if the authoritative source of truth or the primary bottleneck metric is unknown."
        ],
        "decisions": [
          "Choose between synchronous request-response vs asynchronous event-driven coordination."
        ],
        "standards": [
          "Systems must expose readiness probes and health signals for every boundary-crossing interface."
        ],
        "failure_modes": [
          "Designing for infinite scale before naming the first production bottleneck and capacity assumption."
        ],
        "next_queries": [
          "Query architecture/DISTRIBUTED_SYSTEMS for consensus patterns."
        ],
        "proceed_when": [
          "Proceed when the data flow is mapped and failure domains are isolated."
        ]
      }
    },
    "architecture/TESTING_STRATEGY": {
      "id": "architecture/TESTING_STRATEGY",
      "category": "architecture",
      "title": "architecture/TESTING_STRATEGY",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers unit, integration, e2e, contract, regression, smoke, load, security, chaos, test pyramid, flake control, and risk-based test selection.",
      "terms": [
        "confidence",
        "regression",
        "release",
        "contract",
        "unit",
        "strategy",
        "integration",
        "load",
        "testing"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE",
          "interfaces/TESTING",
          "methodology/TESTING"
        ]
      },
      "sections": {
        "match": [
          "Use when defining test coverage, establishing CI validation gates, dealing with flaky tests, or writing test plans."
        ],
        "concepts": [
          "The Test Pyramid: Many fast unit tests, fewer integration tests, and very few slow End-to-End (E2E) tests.",
          "Tests are executable specifications. They should test behavior and outcomes, not implementation details.",
          "A flaky test is worse than no test because it destroys developer trust in the CI pipeline."
        ],
        "ambiguity": [
          "Stop inference if the boundary between unit and integration tests is blurred, or if the mocking strategy is undefined."
        ],
        "decisions": [
          "Decide what to mock: mock architectural boundaries (DBs, external APIs), do not mock internal pure functions.",
          "Determine the threshold for breaking the build based on code coverage or critical path validation."
        ],
        "standards": [
          "All bug fixes must be accompanied by a regression test that fails without the fix.",
          "Contract tests must be used to verify compatibility between separate microservices or frontend/backend boundaries."
        ],
        "failure_modes": [
          "Writing tests tightly coupled to private methods, requiring tests to be rewritten every time code is refactored.",
          "Ignoring flaky tests instead of quarantining and fixing them immediately."
        ],
        "next_queries": [
          "Query methodology/TESTING for procedural guidance.",
          "Query architecture/CI_CD_PIPELINES for test execution."
        ],
        "proceed_when": [
          "Proceed when tests assert observable behavior and effectively gate regressions."
        ]
      }
    },
    "architecture/UI": {
      "id": "architecture/UI",
      "category": "architecture",
      "title": "architecture/UI",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers user workflow, interaction states, navigation, accessibility, error states, loading states, form validation, feedback, information architecture, and trust.",
      "terms": [
        "loading state",
        "error state",
        "form validation",
        "accessibility",
        "keyboard navigation",
        "design token",
        "interaction",
        "handling",
        "trust",
        "facing",
        "interface",
        "navigation",
        "design",
        "error",
        "user",
        "feedback"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when designing component hierarchies, defining user interaction states, handling accessibility, or structuring UI feedback."
        ],
        "concepts": [
          "The UI must gracefully handle all states: Ideal, Loading, Empty, Partial Error, and Critical Error.",
          "Accessibility (WCAG) ensures the application is usable by everyone; it relies on proper semantic HTML and ARIA attributes.",
          "Forms must validate inputs, provide clear error messages close to the context, and prevent double-submissions."
        ],
        "ambiguity": [
          "Stop inference if the loading state behavior, error boundary recovery, or mobile responsiveness strategy is unspecified."
        ],
        "decisions": [
          "Determine whether UI state is managed locally within components or lifted to a global state manager.",
          "Decide on the routing architecture (client-side vs server-side) based on the application's interactivity requirements."
        ],
        "standards": [
          "All interactive elements must provide immediate visual feedback (e.g., disabled states during API calls).",
          "Maintain a consistent design token system for colors, typography, and spacing to ensure visual integrity."
        ],
        "failure_modes": [
          "Failing to provide feedback during async operations, leading users to click buttons multiple times.",
          "Building custom dropdowns or modals that lack keyboard navigation and screen reader support."
        ],
        "next_queries": [
          "Query architecture/FRONTEND for rendering frameworks.",
          "Query architecture/API_DESIGN for data fetching contracts."
        ],
        "proceed_when": [
          "Proceed when all interaction states are accounted for and accessibility standards are met."
        ]
      }
    },
    "architecture/WEB": {
      "id": "architecture/WEB",
      "category": "architecture",
      "title": "architecture/WEB",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers HTTP, routing, browser constraints, sessions, cookies, CSRF/XSS, caching headers, SSR/CSR, CDN, API contracts, performance, and deployment.",
      "terms": [
        "p99 latency",
        "trust boundary",
        "csrf",
        "xss",
        "cors",
        "cookie",
        "cache-control",
        "hsts",
        "csp",
        "ssr",
        "csr",
        "routing",
        "constraints",
        "sessions",
        "frontend",
        "headers"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when handling HTTP semantics, configuring web servers, setting security headers, or optimizing browser asset delivery."
        ],
        "concepts": [
          "The web relies on stateless HTTP requests. Context must be established via headers, cookies, or tokens on every request.",
          "Browsers enforce strict security boundaries (Same-Origin Policy, CORS) to prevent malicious cross-site interactions.",
          "Caching headers (Cache-Control, ETag) dictate how CDNs and browsers store and revalidate assets."
        ],
        "ambiguity": [
          "Stop inference if CORS policies, session cookie attributes, or caching strategies for static assets are undefined."
        ],
        "decisions": [
          "Choose between Server-Side Rendering (SSR) for SEO/initial load speed vs Client-Side Rendering (CSR) for high interactivity.",
          "Determine the asset delivery strategy: CDN for static bundles, direct servers for dynamic API responses."
        ],
        "standards": [
          "Enforce security headers: Content-Security-Policy (CSP), Strict-Transport-Security (HSTS), and X-Frame-Options.",
          "Session cookies must be marked HttpOnly, Secure, and have appropriate SameSite attributes to prevent XSS and CSRF."
        ],
        "failure_modes": [
          "Reflecting unsanitized user input directly into the HTML DOM, enabling Cross-Site Scripting (XSS) attacks.",
          "Using GET requests for state-mutating operations, allowing malicious links to alter server state."
        ],
        "next_queries": [
          "Query architecture/FRONTEND for UI framework integration.",
          "Query architecture/API_DESIGN for HTTP contract definitions."
        ],
        "proceed_when": [
          "Proceed when security headers are configured, HTTP methods are used correctly, and assets are cache-optimized."
        ]
      }
    },
    "docs/ARCHITECTURE_OVERVIEW": {
      "id": "docs/ARCHITECTURE_OVERVIEW",
      "category": "docs",
      "title": "docs/ARCHITECTURE_OVERVIEW",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod explanation surface: control plane, repo-native state, generated artifacts, and authority hierarchy.",
      "terms": [
        "control plane",
        "repo-native",
        "generated artifacts",
        "authority hierarchy",
        "plugin ownership"
      ],
      "links": {
        "references": [
          "architecture/CLOUD",
          "architecture/INFRASTRUCTURE",
          "architecture/SECURITY",
          "core/DECAPOD",
          "interfaces/CONTROL_PLANE",
          "specs/SYSTEM"
        ],
        "referenced_by": [
          "docs/README"
        ]
      },
      "sections": {
        "match": [
          "Use when explaining Decapod component interactions or when the user asks for high-level system diagrams."
        ],
        "concepts": [
          "Control Plane: The daemonless binary and RPC interface managing all system transitions.",
          "Repo-Native State: Human-readable authority files and configurations stored in version control.",
          "Generated Artifacts: Deterministic outputs like specs and dockerfiles; distinct from authority files.",
          "Authority Hierarchy: From embedded constitution to repo overrides to active session state."
        ],
        "ambiguity": [
          "Stop inference if the boundary between Decapod-managed state and user-managed code is unclear."
        ],
        "decisions": [
          "Determine whether a design change belongs in the persistent constitution or project-specific specs."
        ],
        "standards": [
          "Architecture explanations must align with current plugin ownership and source-of-truth mapping."
        ],
        "failure_modes": [
          "Confusing generated artifacts (specs/) with authoritative source files (constitution/) during documentation."
        ],
        "next_queries": [
          "Query docs/CONTROL_PLANE_API for exact operation patterns."
        ],
        "proceed_when": [
          "Proceed when the system interaction model is understood relative to the repo-native state."
        ]
      }
    },
    "docs/CONTROL_PLANE_API": {
      "id": "docs/CONTROL_PLANE_API",
      "category": "docs",
      "title": "docs/CONTROL_PLANE_API",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers operation sequence, envelopes, receipts, allowed next actions, errors, and examples at doc level.",
      "terms": [
        "plane",
        "control",
        "allowed",
        "agent",
        "receipts",
        "envelopes",
        "integration",
        "transitions",
        "errors",
        "semantics",
        "documentation",
        "operations"
      ],
      "links": {
        "references": [
          "core/DECAPOD",
          "interfaces/CLAIMS",
          "interfaces/CONTROL_PLANE",
          "plugins/HEARTBEAT",
          "plugins/VERIFY"
        ],
        "referenced_by": []
      },
      "sections": {
        "match": [
          "Use when documenting the behavior, payloads, and state transitions of the Decapod CLI or RPC interface."
        ],
        "concepts": [
          "The control plane API defines the strict boundaries and allowed operations for agents.",
          "Receipts and allowed next actions guide the agent's workflow state machine."
        ],
        "ambiguity": [
          "Stop inference if the payload structure for a specific operation or its expected receipt is undocumented."
        ],
        "decisions": [
          "Identify the correct sequence of operations to achieve a desired state change.",
          "Determine how to handle and document specific error shapes returned by the API."
        ],
        "standards": [
          "API documentation must include realistic payload examples for both requests and responses.",
          "Error documentation must provide actionable recovery steps."
        ],
        "failure_modes": [
          "Documenting theoretical payloads that do not match the actual executable interface.",
          "Omitting the required preconditions (e.g., session state) for specific operations."
        ],
        "next_queries": [
          "Query interfaces/CONTROL_PLANE for the underlying machine contract."
        ],
        "proceed_when": [
          "Proceed when the API documentation accurately reflects the executable control plane behavior."
        ]
      }
    },
    "docs/EVAL_TRANSLATION_MAP": {
      "id": "docs/EVAL_TRANSLATION_MAP",
      "category": "docs",
      "title": "docs/EVAL_TRANSLATION_MAP",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes how eval concepts become Decapod-operable checks: rubrics, judge contracts, and proof signals.",
      "terms": [
        "eval rubric",
        "judge contract",
        "variance",
        "proof signals",
        "failure thresholds"
      ],
      "links": {
        "references": [
          "methodology/METRICS",
          "specs/evaluations/JUDGE_CONTRACT",
          "specs/evaluations/VARIANCE_EVALS"
        ],
        "referenced_by": []
      },
      "sections": {
        "match": [
          "Use when defining evaluation criteria, configuring automated judges, or mapping product risks to test rubrics."
        ],
        "concepts": [
          "Rubrics: Qualitative criteria translated into quantitative scoring dimensions for automated judging.",
          "Judge Contracts: The expected behavior and interface for automated LLM or script-based evaluators.",
          "Variance Expectations: Statistical boundaries for acceptable result fluctuation across separate evaluation runs.",
          "Proof Signals: Executable evidence that satisfies specific evaluation gates and failure thresholds."
        ],
        "ambiguity": [
          "Stop inference if the rubric scoring scale or the definition of a 'pass' is non-deterministic."
        ],
        "decisions": [
          "Decide between binary success/fail gates versus weighted multi-dimensional scoring models."
        ],
        "standards": [
          "Evaluation maps must link every rubric dimension to specific risks documented in the threat model."
        ],
        "failure_modes": [
          "Using vague, non-falsifiable eval criteria that a judge cannot objectively verify."
        ],
        "next_queries": [
          "Query specs/evaluations/JUDGE_CONTRACT for interface details."
        ],
        "proceed_when": [
          "Proceed when eval concepts are mapped to operable Decapod judge contracts."
        ]
      }
    },
    "docs/GOVERNANCE_AUDIT": {
      "id": "docs/GOVERNANCE_AUDIT",
      "category": "docs",
      "title": "docs/GOVERNANCE_AUDIT",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers capability inventory, proof gaps, authority drift, subsystem maturity, and remediation order.",
      "terms": [
        "drift detection",
        "kernel",
        "inventory",
        "risks",
        "proof",
        "ordering",
        "governance",
        "dependency",
        "surfaces",
        "capability",
        "audit",
        "prioritization",
        "driven"
      ],
      "links": {
        "references": [
          "core/DECAPOD",
          "core/GAPS",
          "interfaces/CLAIMS",
          "plugins/AUDIT",
          "plugins/VERIFY"
        ],
        "referenced_by": [
          "docs/NEGLECTED_ASPECTS_LEDGER"
        ]
      },
      "sections": {
        "match": [
          "Use when auditing the repository for compliance, checking subsystem maturity, or identifying proof gaps."
        ],
        "concepts": [
          "Governance audits measure the delta between documented authority and actual implementation.",
          "Subsystem maturity is tracked via truth labels (REAL, STUB, SPEC, IDEA)."
        ],
        "ambiguity": [
          "Stop inference if a capability is claimed but its proof surface cannot be identified."
        ],
        "decisions": [
          "Prioritize remediation of critical security or data-loss gaps over documentation drift.",
          "Determine if a subsystem's maturity label accurately reflects its current state."
        ],
        "standards": [
          "Audit findings must map to specific actionable TODOs or issue tickets.",
          "Every REAL subsystem must have an executable proof surface."
        ],
        "failure_modes": [
          "Treating an audit as a paperwork exercise rather than a trigger for concrete remediation.",
          "Ignoring authority drift where code behavior diverges from the constitution."
        ],
        "next_queries": [
          "Query core/GAPS for the methodology of identifying and categorizing gaps."
        ],
        "proceed_when": [
          "Proceed when the audit findings are translated into actionable, prioritized work items."
        ]
      }
    },
    "docs/MAINTAINERS": {
      "id": "docs/MAINTAINERS",
      "category": "docs",
      "title": "docs/MAINTAINERS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes maintainer stewardship: review bar, release hygiene, deprecation discipline, and kernel protection.",
      "terms": [
        "stewardship",
        "review bar",
        "release hygiene",
        "deprecation",
        "authority preservation"
      ],
      "links": {
        "references": [
          "core/DEPRECATION",
          "core/EMERGENCY_PROTOCOL",
          "core/ENGINEERING_EXCELLENCE",
          "docs/RELEASE_PROCESS"
        ],
        "referenced_by": []
      },
      "sections": {
        "match": [
          "Use when acting as a repository steward, performing code reviews, or managing the project lifecycle."
        ],
        "concepts": [
          "Review Bar: The minimum quality and security threshold required for merging into protected branches.",
          "Deprecation Discipline: Strict adherence to versioning and removal windows for retiring system surfaces.",
          "Authority Preservation: Ensuring that local project changes do not silently bypass constitutional mandates.",
          "Emergency Protocol: Procedures for immediate mutation halts and containment during critical failures."
        ],
        "ambiguity": [
          "Stop inference if subsystem ownership or the emergency contact path for a component is unknown."
        ],
        "decisions": [
          "Determine when to invoke emergency protocols versus following the standard release process."
        ],
        "standards": [
          "Maintainer actions must be recorded in audit logs with clear rationale for authority-preserving changes."
        ],
        "failure_modes": [
          "Allowing exception-based merges that weaken the long-term integrity of the Decapod constitution."
        ],
        "next_queries": [
          "Query core/EMERGENCY_PROTOCOL for stop-work triggers."
        ],
        "proceed_when": [
          "Proceed when changes preserve system authority and meet the established review bar."
        ]
      }
    },
    "docs/MIGRATIONS": {
      "id": "docs/MIGRATIONS",
      "category": "docs",
      "title": "docs/MIGRATIONS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers compatibility, forward/backward migration, rollback, data safety, and proof.",
      "terms": [
        "schema evolution",
        "evidence",
        "schema",
        "migrations",
        "change",
        "forward",
        "evolution",
        "limits",
        "migration",
        "compatibility",
        "safety",
        "discipline",
        "operational",
        "rollback"
      ],
      "links": {
        "references": [
          "data/PIPELINES",
          "data/DATABASE",
          "plugins/DB_BROKER",
          "specs/DB_BROKER_QUEUE"
        ],
        "referenced_by": [
          "data/DATABASE",
          "docs/README"
        ]
      },
      "sections": {
        "match": [
          "Use when documenting database schema changes, API version bumps, or significant data transformations."
        ],
        "concepts": [
          "Migrations must be safe to apply and safe to revert.",
          "Backward compatibility ensures older clients or application versions continue to function during the rollout."
        ],
        "ambiguity": [
          "Stop inference if the rollback procedure or data safety guarantees are undefined."
        ],
        "decisions": [
          "Determine whether a migration can be applied online without downtime or requires a maintenance window.",
          "Decide how to handle data transformations that are not easily reversible."
        ],
        "standards": [
          "Every migration must have a corresponding rollback script or procedure.",
          "Migration scripts must be tested against a staging database containing production-like data."
        ],
        "failure_modes": [
          "Applying blocking schema changes to massive tables in production.",
          "Failing to write rollback procedures, leading to prolonged outages if the migration fails."
        ],
        "next_queries": [
          "Query data/DATABASE for database-specific migration standards."
        ],
        "proceed_when": [
          "Proceed when the migration and its rollback have been tested and verified."
        ]
      }
    },
    "docs/NEGLECTED_ASPECTS_LEDGER": {
      "id": "docs/NEGLECTED_ASPECTS_LEDGER",
      "category": "docs",
      "title": "docs/NEGLECTED_ASPECTS_LEDGER",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes how postponed risks, incomplete surfaces, and deferred work are recorded without pretending completion.",
      "terms": [
        "neglected aspects",
        "deferred work",
        "technical debt",
        "gap tracking",
        "proof gaps"
      ],
      "links": {
        "references": [
          "core/GAPS",
          "docs/GOVERNANCE_AUDIT",
          "interfaces/RISK_POLICY_GATE"
        ],
        "referenced_by": []
      },
      "sections": {
        "match": [
          "Use when identifying technical debt, deferring complex requirements, or acknowledging incomplete implementation surfaces."
        ],
        "concepts": [
          "Intentional Deferral: Recording work that was acknowledged but postponed for defined architectural reasons.",
          "Risk Visibility: Ensuring that incomplete surfaces or known gaps are visible to the control plane and agents.",
          "Proof Gaps: Explicitly marking where a claimed capability lacks an executable proof surface.",
          "Resumption Triggers: Conditions under which deferred work must be resumed and completed."
        ],
        "ambiguity": [
          "Stop inference if a deferred risk lacks a recorded mitigation or a 'proceed-unless' trigger."
        ],
        "decisions": [
          "Decide if a limitation should be fixed immediately or added to the ledger with an expiration date."
        ],
        "standards": [
          "Ledger entries must include a severity rating and the specific authority boundary they affect."
        ],
        "failure_modes": [
          "Using the ledger as a graveyard for critical bugs rather than a disciplined record of deferred intent."
        ],
        "next_queries": [
          "Query core/GAPS to classify the neglected aspect."
        ],
        "proceed_when": [
          "Proceed when the limitation is recorded and its impact on current proof claims is acknowledged."
        ]
      }
    },
    "docs/PLAYBOOK": {
      "id": "docs/PLAYBOOK",
      "category": "docs",
      "title": "docs/PLAYBOOK",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers operator procedures, repeatable commands, safe recovery, troubleshooting, and escalation.",
      "terms": [
        "procedures",
        "playbook",
        "troubleshooting",
        "execution",
        "operator",
        "sequences",
        "safe",
        "runbooks",
        "repeatable",
        "operational",
        "command"
      ],
      "links": {
        "references": [
          "core/DECAPOD",
          "docs/SECURITY_THREAT_MODEL",
          "plugins/HEALTH",
          "plugins/VERIFY"
        ],
        "referenced_by": []
      },
      "sections": {
        "match": [
          "Use when documenting operational procedures, incident response steps, or routine maintenance tasks."
        ],
        "concepts": [
          "Playbooks are for operators under stress. They must be executable and precise.",
          "A playbook must define the escalation path when procedures fail."
        ],
        "ambiguity": [
          "Stop inference if the recovery steps or escalation contacts are missing."
        ],
        "decisions": [
          "Identify the specific failure mode this playbook addresses and the symptoms that trigger it."
        ],
        "standards": [
          "Commands must be exact, copy-pasteable, and include expected output.",
          "Include a section on verifying that the recovery was successful."
        ],
        "failure_modes": [
          "Writing narrative prose instead of actionable steps.",
          "Failing to update playbooks when the underlying architecture changes."
        ],
        "next_queries": [
          "Query methodology/INCIDENT_RESPONSE for the broader incident lifecycle."
        ],
        "proceed_when": [
          "Proceed when the playbook is actionable and tested against the current system."
        ]
      }
    },
    "docs/README": {
      "id": "docs/README",
      "category": "docs",
      "title": "docs/README",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers public repo orientation, install/init path, quickstart, positioning, first proof path, and current-vs-roadmap clarity.",
      "terms": [
        "path",
        "installation",
        "proof",
        "positioning",
        "repository",
        "landing",
        "navigation",
        "readme",
        "human",
        "surfaces",
        "quickstart",
        "page",
        "adoption",
        "orientation"
      ],
      "links": {
        "references": [
          "core/DECAPOD",
          "docs/ARCHITECTURE_OVERVIEW",
          "docs/MIGRATIONS",
          "docs/RELEASE_PROCESS",
          "docs/SECURITY_THREAT_MODEL",
          "interfaces/CLAIMS",
          "interfaces/CONTROL_PLANE",
          "specs/SYSTEM"
        ],
        "referenced_by": []
      },
      "sections": {
        "match": [
          "Use when modifying the primary repository entry point for humans."
        ],
        "concepts": [
          "The README is human-facing product documentation, not operational agent guidance.",
          "It must clarify current capabilities versus roadmap aspirations."
        ],
        "ambiguity": [
          "Stop inference if the installation path or first proof of success is undefined."
        ],
        "decisions": [
          "Determine what subset of architecture belongs in the README versus deep dive architecture docs."
        ],
        "standards": [
          "Provide a copy-pasteable quickstart that includes a validation step.",
          "Explicitly declare the project's positioning and non-goals."
        ],
        "failure_modes": [
          "Documenting aspirational behavior as current reality without marking it as a roadmap item.",
          "Adding agent-specific instructions that belong in AGENTS.md."
        ],
        "next_queries": [
          "Query docs/ARCHITECTURE_OVERVIEW for deep technical explanations."
        ],
        "proceed_when": [
          "Proceed when the README accurately reflects the current codebase state."
        ]
      }
    },
    "docs/RELEASE_PROCESS": {
      "id": "docs/RELEASE_PROCESS",
      "category": "docs",
      "title": "docs/RELEASE_PROCESS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes release gates, changelog expectations, versioning, validation, rollback, and publication.",
      "terms": [
        "release gate",
        "changelog",
        "versioning",
        "rollback",
        "artifact readiness"
      ],
      "links": {
        "references": [
          "architecture/CI_CD_PIPELINES",
          "methodology/RELEASE_MANAGEMENT",
          "plugins/MANIFEST",
          "plugins/VERIFY",
          "specs/GIT"
        ],
        "referenced_by": [
          "docs/MAINTAINERS",
          "docs/README"
        ]
      },
      "sections": {
        "match": [
          "Use when preparing deployments, tagging versions, or updating the public changelog."
        ],
        "concepts": [
          "Release Gates: Executable checklists (unit tests, eval scores, security scans) that must be green for publication.",
          "Changelog Discipline: Human-readable records mapping changes to specific project intent and bug IDs.",
          "Rollback Readiness: Verified, automated paths to revert the system to the previous stable version.",
          "Artifact Readiness: Ensuring that all binaries, containers, and docs are finalized before tag creation."
        ],
        "ambiguity": [
          "Stop inference if the rollback procedure or the current release gate status is unverified."
        ],
        "decisions": [
          "Determine if a release should be halted due to partial failures in non-critical validation gates."
        ],
        "standards": [
          "Versions must follow strict semantic versioning tied to the interface stability contract."
        ],
        "failure_modes": [
          "Releasing features with stale documentation or missing migration paths."
        ],
        "next_queries": [
          "Query methodology/RELEASE_MANAGEMENT for practice guidance."
        ],
        "proceed_when": [
          "Proceed when all gates are satisfied and the rollback path is verified."
        ]
      }
    },
    "docs/SECURITY_THREAT_MODEL": {
      "id": "docs/SECURITY_THREAT_MODEL",
      "category": "docs",
      "title": "docs/SECURITY_THREAT_MODEL",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers assets, actors, trust boundaries, abuse cases, mitigations, residual risk, and validation.",
      "terms": [
        "trust boundary",
        "mitigations",
        "trust",
        "actors",
        "requirements",
        "validation",
        "boundaries",
        "model",
        "residual",
        "assets",
        "risk",
        "cases",
        "security",
        "threat",
        "abuse"
      ],
      "links": {
        "references": [
          "architecture/AUTH",
          "architecture/SECRETS",
          "architecture/SECURITY",
          "plugins/TRUST",
          "specs/SECURITY"
        ],
        "referenced_by": [
          "architecture/SECURITY",
          "docs/PLAYBOOK",
          "docs/README",
          "specs/SECURITY"
        ]
      },
      "sections": {
        "match": [
          "Use when documenting systemic risks, defining trust boundaries, or outlining security mitigations."
        ],
        "concepts": [
          "A threat model identifies what needs protection, who wants it, and how they might get it.",
          "Residual risk is the risk that remains after mitigations are applied; it must be explicitly accepted."
        ],
        "ambiguity": [
          "Stop inference if trust boundaries are vaguely defined or mitigations lack validation mechanisms."
        ],
        "decisions": [
          "Identify all actors (internal and external) and the assets they can access.",
          "Determine the appropriate mitigation strategy for each identified abuse case."
        ],
        "standards": [
          "Threat models must map mitigations to concrete architectural controls or code implementations.",
          "Residual risks must be documented and formally accepted by stakeholders."
        ],
        "failure_modes": [
          "Focusing on generic threats instead of application-specific abuse cases.",
          "Listing mitigations without a way to validate their effectiveness."
        ],
        "next_queries": [
          "Query architecture/SECURITY for implementation-level security constraints."
        ],
        "proceed_when": [
          "Proceed when all identified threats have documented mitigations or accepted residual risks."
        ]
      }
    },
    "docs/SKILL_TRANSLATION_MAP": {
      "id": "docs/SKILL_TRANSLATION_MAP",
      "category": "docs",
      "title": "docs/SKILL_TRANSLATION_MAP",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes how external/reusable skill concepts map into Decapod skill governance and invocation boundaries.",
      "terms": [
        "skill governance",
        "capability metadata",
        "invocation boundary",
        "skill translation",
        "agent behavior"
      ],
      "links": {
        "references": [
          "interfaces/AGENT_CONTEXT_PACK",
          "metadata/skills/BUNDLE",
          "specs/skills/SKILL_GOVERNANCE"
        ],
        "referenced_by": []
      },
      "sections": {
        "match": [
          "Use when importing new skills, defining custom capabilities, or mapping agentic behavior to CLI commands."
        ],
        "concepts": [
          "Skill Governance: How skills are authorized, shared, and versioned across the multi-agent ecosystem.",
          "Invocation Boundaries: Precise triggers and context windows where a skill is permitted to operate.",
          "Capability Metadata: Attributes that define the intent, authority, and tools associated with a skill.",
          "Agent-Consumable Surfaces: Standardized interfaces that allow agents to call and parse skill outputs."
        ],
        "ambiguity": [
          "Stop inference if a skill's security requirements or allowed toolset is not explicitly mapped."
        ],
        "decisions": [
          "Determine whether a capability should be implemented as a core plugin or a portable skill."
        ],
        "standards": [
          "Skills must be documented with clear input/output expectations and associated proof claims."
        ],
        "failure_modes": [
          "Mapping a single broad skill to too many unrelated CLI operations, causing context pollution."
        ],
        "next_queries": [
          "Query specs/skills/SKILL_GOVERNANCE for authority rules."
        ],
        "proceed_when": [
          "Proceed when the skill is correctly mapped to a Decapod capability and invocation boundary."
        ]
      }
    },
    "interfaces/AGENT_CONTEXT_PACK": {
      "id": "interfaces/AGENT_CONTEXT_PACK",
      "category": "interfaces",
      "title": "interfaces/AGENT_CONTEXT_PACK",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes retrieved snippets, task scope, authority ordering, bounded context, and agent pre-inference consumption.",
      "terms": [
        "payloads",
        "retrieval",
        "agent",
        "bounded",
        "context",
        "relevant",
        "doctrine",
        "slices",
        "inference",
        "assembly",
        "pack"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES",
          "docs/SKILL_TRANSLATION_MAP",
          "plugins/CONTEXT"
        ]
      },
      "sections": {
        "match": [
          "Use when assembling the context window, retrieving constitution fragments, or narrowing scope before inference."
        ],
        "concepts": [
          "The context pack is the curated, bounded set of facts an agent consumes before making a decision.",
          "Authority ordering matters: explicit user constraints override methodology, and binding specs override user constraints.",
          "Context must be fiercely bounded to prevent token exhaustion and hallucination."
        ],
        "ambiguity": [
          "Stop inference if the retrieved context is contradictory or insufficient to safely execute the task."
        ],
        "decisions": [
          "Determine exactly which snippets of code and which constitution nodes are strictly required for the immediate task.",
          "Filter out generic or tangential information to maximize the signal-to-noise ratio in the prompt."
        ],
        "standards": [
          "Context packs must explicitly label the provenance and authority level of the retrieved information.",
          "Agents must read and process the context pack *before* formulating an implementation plan."
        ],
        "failure_modes": [
          "Dumping entire directories into the context window, causing the agent to lose focus on the actual intent.",
          "Ignoring binding authority boundaries because a lower-level document suggested a contradictory path."
        ],
        "next_queries": [
          "Query methodology/MEMORY for context compaction strategies.",
          "Query specs/INTENT for explicit task constraints."
        ],
        "proceed_when": [
          "Proceed when the context pack is focused, authoritative, and completely addresses the task intent."
        ]
      }
    },
    "interfaces/ARCHITECTURE_FOUNDATIONS": {
      "id": "interfaces/ARCHITECTURE_FOUNDATIONS",
      "category": "interfaces",
      "title": "interfaces/ARCHITECTURE_FOUNDATIONS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes foundational architecture vocabulary: boundary, state, interface, runtime, deployment, and data flow.",
      "terms": [
        "boundary",
        "state ownership",
        "failure mode",
        "runtime",
        "data flow"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES"
        ]
      },
      "sections": {
        "match": [
          "Use when discussing high-level design patterns before selecting specific implementation-level nodes."
        ],
        "concepts": [
          "Boundary: The explicit line where control, state, or data ownership changes between components.",
          "State Ownership: Identifying where persistent and ephemeral data lives and who governs its mutation.",
          "Interface Contract: The machine-consumable agreement that allows communication across boundaries.",
          "Failure Mode: The predicted ways a component can fail and the system's planned recovery reaction."
        ],
        "ambiguity": [
          "Stop inference if the basic relationship between state and interface is undefined for a new component."
        ],
        "decisions": [
          "Identify the primary constraint axis for the design: latency, throughput, consistency, or cost."
        ],
        "standards": [
          "All architectural designs must explicitly name their data flow, boundaries, and failure modes."
        ],
        "failure_modes": [
          "Defaulting to technology choices (e.g., 'use Kafka') before naming foundational needs and flows."
        ],
        "next_queries": [
          "Query architecture/SYSTEMS_DESIGN for implementation patterns."
        ],
        "proceed_when": [
          "Proceed when foundational vocabulary is used to define the problem and state boundaries."
        ]
      }
    },
    "interfaces/CLAIMS": {
      "id": "interfaces/CLAIMS",
      "category": "interfaces",
      "title": "interfaces/CLAIMS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes claim type, evidence, verification status, stale claim risk, and mapping claims to proof.",
      "terms": [
        "requirements",
        "evidence",
        "proof",
        "accountability",
        "ledger",
        "promises",
        "completion",
        "status",
        "claim",
        "claims",
        "mapping"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "architecture/API_DESIGN",
          "core/INTERFACES",
          "docs/CONTROL_PLANE_API",
          "docs/GOVERNANCE_AUDIT",
          "docs/README",
          "plugins/VERIFY",
          "specs/SYSTEM"
        ]
      },
      "sections": {
        "match": [
          "Use when validating task completion, updating proof states, or verifying adherence to constitutional mandates."
        ],
        "concepts": [
          "A claim is a formal assertion that a requirement is met (e.g., 'verified', 'secure', 'tested').",
          "Claims are meaningless without executable proof. Evidence must be deterministic.",
          "Stale claims are a liability; if the underlying code changes, the claim must be re-verified."
        ],
        "ambiguity": [
          "Stop inference if a claim is made without a corresponding proof surface or verification artifact."
        ],
        "decisions": [
          "Decide whether a claim is 'enforced' (automated check), 'partially_enforced', or 'not_enforced' (human review).",
          "Determine the specific test, script, or validation gate that serves as the evidence for a claim."
        ],
        "standards": [
          "Every 'REAL' subsystem must map to at least one enforced claim with an executable proof surface.",
          "Agents must explicitly state 'unverified' and name the blocker if a proof surface cannot be run."
        ],
        "failure_modes": [
          "Asserting completion based on narrative confidence instead of executing the required validation gate.",
          "Failing to invalidate claims when the architecture or dependencies shift."
        ],
        "next_queries": [
          "Query interfaces/TESTING for specific proof mechanisms.",
          "Query core/PLUGINS to identify subsystem truth labels."
        ],
        "proceed_when": [
          "Proceed when the claim is backed by a passing validation check and evidence is recorded."
        ]
      }
    },
    "interfaces/CONTROL_PLANE": {
      "id": "interfaces/CONTROL_PLANE",
      "category": "interfaces",
      "title": "interfaces/CONTROL_PLANE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes operation sequencing, receipts, allowed next operations, and mutation boundaries.",
      "terms": [
        "control plane",
        "receipt",
        "blocked_by",
        "mutation boundary",
        "sequencing"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "architecture/API_DESIGN",
          "core/INTERFACES",
          "docs/ARCHITECTURE_OVERVIEW",
          "docs/CONTROL_PLANE_API",
          "docs/README",
          "plugins/TODO",
          "plugins/VERIFY",
          "specs/SYSTEM"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with Decapod CLI/RPC, handling response envelopes, or sequencing agent actions."
        ],
        "concepts": [
          "Operation Sequencing: The strict order in which operations must be performed (e.g., claim before ensure).",
          "Receipts: Structured evidence returned by operations, including hashes, timestamps, and touched paths.",
          "Allowed Next Operations: The state-machine transitions permitted by the control plane based on the current context.",
          "Mutation Boundary: The line between Decapod-governed state and the user's working directory."
        ],
        "ambiguity": [
          "Stop inference if an RPC response indicates a 'blocked_by' state without a clear resolution hint."
        ],
        "decisions": [
          "Determine the next allowed operation based on the receipt and liveness signals from the previous step."
        ],
        "standards": [
          "Agents must consult Decapod doctrine and retrieve context packs before hardening any plan or code.",
          "Enforce invocation heartbeat for continuous presence tracking."
        ],
        "failure_modes": [
          "Attempting to bypass the control plane by editing internal .decapod state files directly."
        ],
        "next_queries": [
          "Query docs/CONTROL_PLANE_API for payload examples and error shapes."
        ],
        "proceed_when": [
          "Proceed when the operation receipt is valid, no blockers remain, and liveness is verified."
        ]
      }
    },
    "interfaces/DEMANDS_SCHEMA": {
      "id": "interfaces/DEMANDS_SCHEMA",
      "category": "interfaces",
      "title": "interfaces/DEMANDS_SCHEMA",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes how human constraints become structured demands: must, must-not, priority, and durability.",
      "terms": [
        "structured demands",
        "must/must-not",
        "priority",
        "scope",
        "durability"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES"
        ]
      },
      "sections": {
        "match": [
          "Use when parsing user constraints, updating the demands store, or resolving conflicting requirements."
        ],
        "concepts": [
          "Constraint Types: 'Must' (blocking), 'Must-Not' (forbidden), 'Prefer' (weighted optimization).",
          "Priority and Scope: The level of enforcement and the specific subsystems or workflows a demand constrains.",
          "Durability: Distinguishing between session-local preferences and persistent project-wide demands.",
          "Conflict Handling: Rules for reconciling contradictory demands using the specs/INTENT authority."
        ],
        "ambiguity": [
          "Stop inference if two 'Must' demands are mutually exclusive and no precedence rule applies."
        ],
        "decisions": [
          "Determine if a user's prompt should be encoded as a durable demand or an ephemeral preference."
        ],
        "standards": [
          "Structured demands must be linked to specific user intent or session IDs for auditability."
        ],
        "failure_modes": [
          "Ignoring a 'Must' demand because it conflicts with a local implementation optimization."
        ],
        "next_queries": [
          "Query specs/INTENT to link demands to outcome contracts."
        ],
        "proceed_when": [
          "Proceed when demands are structured, scoped, and conflicts are resolved per precedence."
        ]
      }
    },
    "interfaces/DOC_RULES": {
      "id": "interfaces/DOC_RULES",
      "category": "interfaces",
      "title": "interfaces/DOC_RULES",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes machine-readable documentation rules: canonical vs generated, boundaries, and drift handling.",
      "terms": [
        "drift detection",
        "canonical docs",
        "generated docs",
        "doc drift",
        "authority layer",
        "freshness"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES"
        ]
      },
      "sections": {
        "match": [
          "Use when creating new documentation, validating freshness, or distinguishing authority layers."
        ],
        "concepts": [
          "Canonical Docs: Hand-written, versioned authority files (e.g., OVERRIDE.md, readme).",
          "Generated Docs: Machine-produced artifacts (e.g., specs/) that must not be manually modified.",
          "Documentation Boundaries: README is for human onboarding; AGENTS.md is for machine logic.",
          "Doc Drift: The delta between code behavior and documented claims detected via validation."
        ],
        "ambiguity": [
          "Stop inference if a file's status as 'canonical' or 'generated' is unclear."
        ],
        "decisions": [
          "Decide whether to update a hand-written doc or regenerate a spec after a structural change."
        ],
        "standards": [
          "All docs must cite their authority layer and freshness/proof expectations to prevent drift."
        ],
        "failure_modes": [
          "Editing generated specs manually, resulting in lost work during the next build cycle."
        ],
        "next_queries": [
          "Query core/DOCS for routing to specific document nodes."
        ],
        "proceed_when": [
          "Proceed when documentation changes respect the canonical/generated boundary and authority."
        ]
      }
    },
    "interfaces/GLOSSARY": {
      "id": "interfaces/GLOSSARY",
      "category": "interfaces",
      "title": "interfaces/GLOSSARY",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes vocabulary governance: canonical terms, aliases, ambiguity reduction, and retrieval support.",
      "terms": [
        "canonical terms",
        "aliases",
        "ambiguity reduction",
        "glossary",
        "term drift"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES"
        ]
      },
      "sections": {
        "match": [
          "Use when defining domain-specific terms, resolving naming conflicts, or mapping slang to concepts."
        ],
        "concepts": [
          "Canonical Terminology: The single, authoritative name for a system concept (e.g., 'workunit').",
          "Aliases and Synonyms: Mapping common vernacular to canonical terms to improve search signals.",
          "Ambiguity Reduction: Distinguishing terms that sound similar but operate at different authority layers.",
          "Term Drift: Preventing inconsistent naming from evolving into accidental architectural policy drift."
        ],
        "ambiguity": [
          "Stop inference if a term used in a prompt has multiple conflicting meanings in the glossary."
        ],
        "decisions": [
          "Determine if a new term should be added to the glossary or mapped to an existing canonical ID."
        ],
        "standards": [
          "Glossary entries support retrieval and clarity but do not invent binding behavioral rules."
        ],
        "failure_modes": [
          "Allowing different subsystems to use conflicting names for the same shared state or outcome."
        ],
        "next_queries": [
          "Query core/METADATA for taxonomy and classification retrieval."
        ],
        "proceed_when": [
          "Proceed when the vernacular is successfully mapped to canonical system terms and IDs."
        ]
      }
    },
    "interfaces/INTERNALIZATION_SCHEMA": {
      "id": "interfaces/INTERNALIZATION_SCHEMA",
      "category": "interfaces",
      "title": "interfaces/INTERNALIZATION_SCHEMA",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes the lifecycle of attaching, inspecting, and validating external knowledge into Decapod-governed state.",
      "terms": [
        "internalization",
        "attachment",
        "inspection",
        "provenance",
        "lifecycle"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES"
        ]
      },
      "sections": {
        "match": [
          "Use when importing external documentation, code snippets, or logs into the knowledge base."
        ],
        "concepts": [
          "Attachment: Creating a Decapod-governed link and provenance record for external information.",
          "Inspection and Validation: Verifying that internalized payloads match strict schema and authority rules.",
          "Lifecycle Management: Handling the detachment and cleanup of knowledge that is no longer valid.",
          "Scope and Authority: Assigning the correct layer and provenance to the internalized knowledge."
        ],
        "ambiguity": [
          "Stop inference if the provenance or original source of an internalized artifact is unverifiable."
        ],
        "decisions": [
          "Decide if external knowledge should be internalized as durable state or ephemeral context."
        ],
        "standards": [
          "All internalized data must have an owner and timestamp to manage decay and re-validation."
        ],
        "failure_modes": [
          "Internalizing large binary blobs that should remain as external references via links."
        ],
        "next_queries": [
          "Query interfaces/KNOWLEDGE_SCHEMA for internal object shapes."
        ],
        "proceed_when": [
          "Proceed when the internalization lifecycle is verified and schema-compliant."
        ]
      }
    },
    "interfaces/KNOWLEDGE_SCHEMA": {
      "id": "interfaces/KNOWLEDGE_SCHEMA",
      "category": "interfaces",
      "title": "interfaces/KNOWLEDGE_SCHEMA",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes knowledge object shape: source, provenance, authority, summary, and retrieval tags.",
      "terms": [
        "knowledge object",
        "provenance",
        "authority level",
        "retrieval tags",
        "decay"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES",
          "methodology/KNOWLEDGE",
          "plugins/KNOWLEDGE"
        ]
      },
      "sections": {
        "match": [
          "Use when generating knowledge objects, parsing search results, or updating the retrieval index."
        ],
        "concepts": [
          "Provenance Chain: The audit trail from the original source to the current knowledge record.",
          "Authority Level: Categorizing knowledge objects as 'binding', 'advisory', 'anecdotal', or 'stale'.",
          "Retrieval Tags: Semantic labels that optimize for vector, graph, and keyword-based discovery.",
          "Decay and Status: Managing the freshness and eventual expiration of non-binding knowledge records."
        ],
        "ambiguity": [
          "Stop inference if a knowledge object lacks sufficient provenance to establish its authority level."
        ],
        "decisions": [
          "Determine which retrieval tags provide the highest signal for the intended consumer agent."
        ],
        "standards": [
          "Knowledge objects must pass strict schema validation before being added to the persistent store."
        ],
        "failure_modes": [
          "Over-tagging knowledge objects, leading to high-noise retrieval results and context pollution."
        ],
        "next_queries": [
          "Query interfaces/KNOWLEDGE_STORE for persistence and indexing rules."
        ],
        "proceed_when": [
          "Proceed when the knowledge object is fully structured and its authority/freshness is clear."
        ]
      }
    },
    "interfaces/KNOWLEDGE_STORE": {
      "id": "interfaces/KNOWLEDGE_STORE",
      "category": "interfaces",
      "title": "interfaces/KNOWLEDGE_STORE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes persistent knowledge storage: indexing, update/delete semantics, and retrieval safety.",
      "terms": [
        "indexing",
        "retrieval safety",
        "stale records",
        "persistence",
        "auditability"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES",
          "methodology/KNOWLEDGE",
          "plugins/KNOWLEDGE"
        ]
      },
      "sections": {
        "match": [
          "Use when configuring the knowledge database, performing batch updates, or auditing storage integrity."
        ],
        "concepts": [
          "Indexing and Addressing: Mapping semantic queries to stored records via unique hashes or ULIDs.",
          "Atomic Updates: Ensuring that changes to knowledge records maintain consistent provenance and tags.",
          "Retrieval Safety: Bounding search results to prevent ingestion of contradictory or stale knowledge.",
          "Auditability: Maintaining an immutable log of all insertions, deletions, and metadata mutations."
        ],
        "ambiguity": [
          "Stop inference if the knowledge store returns contradictory results with equal authority levels."
        ],
        "decisions": [
          "Determine whether to purge a stale record or mark it as 'unverified' in the active index."
        ],
        "standards": [
          "The knowledge store must enforce unique IDs and support deterministic, point-in-time retrieval."
        ],
        "failure_modes": [
          "Allowing the index to grow without bound, degrading both retrieval performance and relevance."
        ],
        "next_queries": [
          "Query architecture/KNOWLEDGE_BASE for technical implementation details."
        ],
        "proceed_when": [
          "Proceed when store integrity is verified and retrieval paths are optimized for context signals."
        ]
      }
    },
    "interfaces/LCM": {
      "id": "interfaces/LCM",
      "category": "interfaces",
      "title": "interfaces/LCM",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes lossless context management: summary DAGs, deterministic compaction, and transfer boundaries.",
      "terms": [
        "lossless context",
        "summary DAG",
        "compaction",
        "recursion",
        "lossy collapse"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES",
          "plugins/CONTEXT"
        ]
      },
      "sections": {
        "match": [
          "Use when managing context windows, performing recursive summarization, or transferring session state."
        ],
        "concepts": [
          "Summary DAGs: A directed graph of summaries allowing agents to zoom between detail levels without loss.",
          "Deterministic Compaction: Compressing history based on factual importance rather than simple timestamps.",
          "Recursion: The ability for an agent to query its own summary history for deeper grounding context.",
          "Proof Preservation: Ensuring that compaction never discards the negative signals of failed proofs."
        ],
        "ambiguity": [
          "Stop inference if a summary DAG contains disconnected nodes or conflicting authority claims."
        ],
        "decisions": [
          "Decide which context branches are 'prunable' versus 'vital' for the current task sequence."
        ],
        "standards": [
          "Lossless context management must preserve governing anchors and the original proof evidence."
        ],
        "failure_modes": [
          "Lossy collapse: summarizing a failed test or rejection as a 'completed' state without evidence."
        ],
        "next_queries": [
          "Query interfaces/AGENT_CONTEXT_PACK for session transfer boundaries."
        ],
        "proceed_when": [
          "Proceed when context is compacted without losing critical authority or proof signals."
        ]
      }
    },
    "interfaces/MEMORY_INDEX": {
      "id": "interfaces/MEMORY_INDEX",
      "category": "interfaces",
      "title": "interfaces/MEMORY_INDEX",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes memory retrieval index: addressing, categorization, relevance, and search tiers.",
      "terms": [
        "memory index",
        "authority ranking",
        "categorization",
        "relevance",
        "search tiers"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES"
        ]
      },
      "sections": {
        "match": [
          "Use when searching for past task resolutions, user preferences, or cross-session memory state."
        ],
        "concepts": [
          "Search Tiering: Segmenting memory into 'personal', 'project', and 'ecosystem' tiers for retrieval.",
          "Semantic Relevance: Ranking memory records by distance to task intent while respecting authority.",
          "Addressing: Using hashes or ULIDs to link memory records to specific codebase states or commits.",
          "Categorization: Organizing episodic memory vs durable preference memory for optimal retrieval."
        ],
        "ambiguity": [
          "Stop inference if the memory index returns a relevant but unverified or stale claim."
        ],
        "decisions": [
          "Determine the appropriate tier (personal vs project) for indexing a new memory record."
        ],
        "standards": [
          "Index entries must be updated immediately after a linked memory record is modified."
        ],
        "failure_modes": [
          "Allowing personal preferences to override project-level authority in prioritized results."
        ],
        "next_queries": [
          "Query interfaces/MEMORY_SCHEMA for record shapes and metadata requirements."
        ],
        "proceed_when": [
          "Proceed when memory retrieval is ranked by both semantic relevance and authority."
        ]
      }
    },
    "interfaces/MEMORY_SCHEMA": {
      "id": "interfaces/MEMORY_SCHEMA",
      "category": "interfaces",
      "title": "interfaces/MEMORY_SCHEMA",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes durable memory record shape: subject, claim, provenance, scope, and status.",
      "terms": [
        "memory record",
        "subject",
        "claim",
        "provenance",
        "forgetting semantics"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES"
        ]
      },
      "sections": {
        "match": [
          "Use when creating memory records, validating stored preferences, or managing memory lifecycles."
        ],
        "concepts": [
          "Subject and Claim: The specific entity being remembered and the actual fact or data point captured.",
          "Provenance and Timestamp: The audit trail and temporal context of when the memory was recorded.",
          "Status and Confidence: Labels identifying memory as 'verified', 'assumed', 'stale', or 'deprecated'.",
          "Forgetting and Deletion: Semantics for purging or anonymizing records for security or privacy."
        ],
        "ambiguity": [
          "Stop inference if a memory claim lacks a timestamp, scope, or verifiable provenance."
        ],
        "decisions": [
          "Decide if an existing record should be updated or if a new versioned record is required."
        ],
        "standards": [
          "Memory records must be schema-compliant and correctly scoped to prevent cross-repo pollution."
        ],
        "failure_modes": [
          "Storing secrets, tokens, or PII in durable memory records, violating security posture."
        ],
        "next_queries": [
          "Query methodology/MEMORY for agent cognitive and distillation practices."
        ],
        "proceed_when": [
          "Proceed when the memory record matches the schema and its status is correctly labeled."
        ]
      }
    },
    "interfaces/PLAN_GOVERNED_EXECUTION": {
      "id": "interfaces/PLAN_GOVERNED_EXECUTION",
      "category": "interfaces",
      "title": "interfaces/PLAN_GOVERNED_EXECUTION",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes structured execution plans: steps, checkpoints, allowed mutations, and rollback.",
      "terms": [
        "execution plan",
        "checkpoints",
        "mutation boundary",
        "transition state",
        "rollback"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES"
        ]
      },
      "sections": {
        "match": [
          "Use when generating multi-step plans, validating progress, or handling approval gates."
        ],
        "concepts": [
          "Checkpoints: Mandatory validation points where execution stops for proof checks or human approval.",
          "Allowed Mutations: The explicit set of files, directories, or subsystems a plan is authorized to modify.",
          "Transition State: Tracking the plan from 'draft' to 'claimed' to 'executing' to 'verified'.",
          "Rollback Plan: Pre-defined procedures to revert changes if a checkpoint or final proof fails."
        ],
        "ambiguity": [
          "Stop inference if a plan step lacks defined success criteria or a concrete proof target."
        ],
        "decisions": [
          "Determine whether a failed checkpoint requires a full plan rollback or a surgical correction."
        ],
        "standards": [
          "Execution plans must be structured, versioned, and stored in the project-managed state."
        ],
        "failure_modes": [
          "Proceeding with mutation before the plan is formally 'claimed' and moved to 'executing'."
        ],
        "next_queries": [
          "Query interfaces/TODO_SCHEMA for linking plans to task IDs."
        ],
        "proceed_when": [
          "Proceed when the plan is structured with explicit checkpoints and authorized mutations."
        ]
      }
    },
    "interfaces/PROCEDURAL_NORMS": {
      "id": "interfaces/PROCEDURAL_NORMS",
      "category": "interfaces",
      "title": "interfaces/PROCEDURAL_NORMS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes agent procedural conduct: call Decapod early, ask when blocked, and preserve evidence.",
      "terms": [
        "procedural norms",
        "call early",
        "evidence preservation",
        "stop on risk",
        "agent conduct"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES"
        ]
      },
      "sections": {
        "match": [
          "Use when determining next agent actions, evaluating ambiguity, or performing mutations."
        ],
        "concepts": [
          "Call Decapod Early: The constitution is pre-inference faculty; retrieve doctrine before plan hardening.",
          "Ask When Blocked: Stop and request human clarification if ambiguity prevents safe, governed inference.",
          "Preserve Evidence: Every mutation must be accompanied by executable proof or validation logs.",
          "Stop on Risk: Halt execution immediately if trust boundaries or authority rules are violated."
        ],
        "ambiguity": [
          "Stop inference if the 'safe-to-proceed' threshold for a specific mutation is undefined."
        ],
        "decisions": [
          "Choose between making a documented assumption versus stopping to ask the user for input."
        ],
        "standards": [
          "Agents must cite the constitution node or spec that authorized their procedural path."
        ],
        "failure_modes": [
          "Defaulting to internal model memory when Decapod doctrine provides a project-specific rule."
        ],
        "next_queries": [
          "Query core/EMERGENCY_PROTOCOL for risk-based stops and containment."
        ],
        "proceed_when": [
          "Proceed when the procedural conduct aligns with the 'Call Decapod Early' mandate and proof."
        ]
      }
    },
    "interfaces/PROJECT_SPECS": {
      "id": "interfaces/PROJECT_SPECS",
      "category": "interfaces",
      "title": "interfaces/PROJECT_SPECS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes generated project specs: intent, acceptance criteria, boundaries, and spec drift.",
      "terms": [
        "drift detection",
        "acceptance criteria",
        "proof targets",
        "project specs",
        "boundaries",
        "spec drift"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES",
          "specs/INTENT"
        ]
      },
      "sections": {
        "match": [
          "Use when updating .decapod/generated/specs/, validating alignment, or checking for drift."
        ],
        "concepts": [
          "Acceptance Criteria: Falsifiable, testable conditions that define the success of a feature or task.",
          "Requirement Boundaries: The specific code paths, files, and subsystems that the spec governs.",
          "Proof Targets: The exact test or verification script required to prove the spec is satisfied.",
          "Spec Drift: Detecting DELTAs where implementation has diverged from the documented intent."
        ],
        "ambiguity": [
          "Stop inference if acceptance criteria are vague or the required proof target is missing."
        ],
        "decisions": [
          "Determine if a spec change requires a corresponding update to the architecture overview doc."
        ],
        "standards": [
          "Project specs must be updated and validated *before* the final implementation proceeds."
        ],
        "failure_modes": [
          "Treating specs as post-hoc documentation rather than pre-inference requirements."
        ],
        "next_queries": [
          "Query specs/INTENT for the parent authority contract."
        ],
        "proceed_when": [
          "Proceed when the spec is hydrated with repo-specific details and explicit proof targets."
        ]
      }
    },
    "interfaces/RISK_POLICY_GATE": {
      "id": "interfaces/RISK_POLICY_GATE",
      "category": "interfaces",
      "title": "interfaces/RISK_POLICY_GATE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes risk classification, approval gates, blocked changes, policy outputs, and escalation.",
      "terms": [
        "gating",
        "policy",
        "approval",
        "escalation",
        "classification",
        "risk",
        "enforcement",
        "deployment",
        "paths",
        "gate"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "architecture/AUTH",
          "core/INTERFACES",
          "docs/NEGLECTED_ASPECTS_LEDGER"
        ]
      },
      "sections": {
        "match": [
          "Use when evaluating the blast radius of a change, navigating approval workflows, or handling policy rejections."
        ],
        "concepts": [
          "Changes carry varying degrees of risk (e.g., UI tweak vs database schema drop).",
          "Risk policies deterministically evaluate changes and assign required approval gates.",
          "Blocked changes require explicit escalation or remediation; they cannot be bypassed by agents."
        ],
        "ambiguity": [
          "Stop inference if the risk classification of a change is unknown or if an approval gate is undocumented."
        ],
        "decisions": [
          "Determine the severity of the proposed mutation and anticipate the required validation gates.",
          "Decide how to remediate a change that was blocked by a specific risk policy output."
        ],
        "standards": [
          "Never bypass a risk policy gate. If a change is blocked, the agent must explain why and halt.",
          "Escalations must be logged with specific context (what was blocked, why it is necessary, who approved)."
        ],
        "failure_modes": [
          "Attempting to force a highly destructive operation (e.g., `git push --force`) through a low-risk pipeline.",
          "Ignoring policy warnings and proceeding with an unapproved architectural pivot."
        ],
        "next_queries": [
          "Query architecture/COMPLIANCE for regulated boundaries.",
          "Query specs/AMENDMENTS for formal change control."
        ],
        "proceed_when": [
          "Proceed when the change passes all automated risk policies and secures necessary approvals."
        ]
      }
    },
    "interfaces/STORE_MODEL": {
      "id": "interfaces/STORE_MODEL",
      "category": "interfaces",
      "title": "interfaces/STORE_MODEL",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes local repo state, user state, generated artifacts, operational DB state, sync boundaries, and direct mutation risks.",
      "terms": [
        "store",
        "databases",
        "provenance",
        "boundaries",
        "model",
        "repository",
        "remote",
        "local",
        "artifacts",
        "operational",
        "state",
        "synchronization"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES"
        ]
      },
      "sections": {
        "match": [
          "Use when reading from or writing to the Decapod state directories, user context, or repository databases."
        ],
        "concepts": [
          "Decapod uses a dual-store model: repository state (shared, versioned) vs user state (local, ephemeral).",
          "Generated artifacts (.decapod/generated/) are deterministic outputs of the system, not sources of truth.",
          "Direct mutation of Decapod internal state files bypasses validation and corrupts the system."
        ],
        "ambiguity": [
          "Stop inference if the target store (user vs repo) or the mutation boundary for an operation is unclear."
        ],
        "decisions": [
          "Determine if a preference or configuration should be saved globally (repo) or locally (user).",
          "Identify the correct CLI or RPC surface to update state, rather than editing files directly."
        ],
        "standards": [
          "Agents must never manually edit files inside `.decapod/data/` or `.decapod/generated/`.",
          "All state mutations must be auditable and performed through the approved Decapod interfaces."
        ],
        "failure_modes": [
          "Cross-store contamination: writing ephemeral user data into the shared repository store.",
          "Manually editing database files (e.g., SQLite) causing immediate corruption and lock conflicts."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify schema shapes.",
          "Query core/EMERGENCY_PROTOCOL if state corruption is detected."
        ],
        "proceed_when": [
          "Proceed when the correct store is identified and mutation occurs exclusively via the CLI/RPC."
        ]
      }
    },
    "interfaces/TESTING": {
      "id": "interfaces/TESTING",
      "category": "interfaces",
      "title": "interfaces/TESTING",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes testing interface: expected command, evidence capture, and validation status.",
      "terms": [
        "test command",
        "evidence capture",
        "validation status",
        "remediation mapping",
        "proof claim"
      ],
      "links": {
        "references": [
          "architecture/TESTING_STRATEGY",
          "core/INTERFACES",
          "methodology/TESTING",
          "plugins/VERIFY"
        ],
        "referenced_by": [
          "core/INTERFACES",
          "methodology/TESTING"
        ]
      },
      "sections": {
        "match": [
          "Use when executing tests, recording proof events, or mapping failures to remediation."
        ],
        "concepts": [
          "Expected Command: The exact shell command or script used to execute a specific test or gate.",
          "Evidence Capture: The structured logs, receipts, or artifacts that prove a test result and status.",
          "Validation Mapping: Linking test results to truth labels ('verified', 'failing', 'stale') and claims.",
          "Remediation: Mapping specific failure codes to automated fix paths or manual recovery steps."
        ],
        "ambiguity": [
          "Stop inference if a test result is non-deterministic or lacks a captured evidence log."
        ],
        "decisions": [
          "Determine whether a failing test is a regression or a symptom of an outdated project spec."
        ],
        "standards": [
          "Test evidence must be stored in the project's verification plan or the auditable session log."
        ],
        "failure_modes": [
          "Recording a 'pass' status without capturing the actual command output as proof evidence."
        ],
        "next_queries": [
          "Query plugins/VERIFY for the invariant and proof check engine."
        ],
        "proceed_when": [
          "Proceed when the test command is known and the evidence capture path is configured."
        ]
      }
    },
    "interfaces/TODO_SCHEMA": {
      "id": "interfaces/TODO_SCHEMA",
      "category": "interfaces",
      "title": "interfaces/TODO_SCHEMA",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes todo states, transitions, ownership, blockers, timestamps, evidence, and completion semantics.",
      "terms": [
        "states",
        "history",
        "machine",
        "ownership",
        "obligations",
        "liveness",
        "transitions",
        "verifiable",
        "todo",
        "schema"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES",
          "plugins/TODO"
        ]
      },
      "sections": {
        "match": [
          "Use when creating tasks, updating status, claiming work, recording blockers, or logging completion evidence."
        ],
        "concepts": [
          "Todos are the central tracking mechanism for agent workflows. They prevent concurrent mutation conflicts.",
          "State transitions (e.g., Draft -> Claimed -> Executing -> Verified) must be strictly followed.",
          "A todo is not 'Done' until the required evidence is attached and validation passes."
        ],
        "ambiguity": [
          "Stop inference if a task is unowned, the state transition is invalid, or the required completion evidence is undefined."
        ],
        "decisions": [
          "Identify what concrete artifacts or test results are required to transition a task to 'Verified'.",
          "Determine if a task is blocked and explicitly record the blocker (e.g., waiting on user, failing test)."
        ],
        "standards": [
          "Agents must 'claim' a todo before modifying any repository files to ensure exclusive ownership.",
          "Every state transition must be timestamped and accompanied by a reason or evidence link."
        ],
        "failure_modes": [
          "Claiming a task is complete without running `decapod validate` or attaching the proof artifact.",
          "Abandoning a task in 'Executing' state without recording the fatal error or blocker."
        ],
        "next_queries": [
          "Query interfaces/CONTROL_PLANE for operation sequencing.",
          "Query methodology/ENGINEERING_MANAGEMENT for prioritization."
        ],
        "proceed_when": [
          "Proceed when the todo state accurately reflects reality and execution constraints are met."
        ]
      }
    },
    "interfaces/jsonschema/internalization/InternalizationAttachResult.schema": {
      "id": "interfaces/jsonschema/internalization/InternalizationAttachResult.schema",
      "category": "interfaces",
      "title": "interfaces/jsonschema/internalization/InternalizationAttachResult.schema",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Internalization schema surface governing strict serialization, purpose, producers, and validation constraints.",
      "terms": [
        "attached",
        "inspected",
        "external",
        "inside",
        "internalization",
        "knowledge",
        "governed",
        "decapod",
        "internalizationattachresult",
        "detached",
        "schema",
        "state"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES"
        ]
      },
      "sections": {
        "match": [
          "Use when generating or parsing interfaces/jsonschema/internalization/InternalizationAttachResult.schema JSON payloads."
        ],
        "concepts": [
          "This schema strictly governs data shape and validation for internalization logic.",
          "It defines the contract between the producing sub-system and the consuming agent."
        ],
        "ambiguity": [
          "Stop inference if payload constraints, required fields, or validation rules are unclear."
        ],
        "decisions": [
          "Determine exact field population and formatting required by the schema constraints."
        ],
        "standards": [
          "Outputs must pass Ajv strict validation before being transmitted.",
          "Unknown fields must be omitted."
        ],
        "failure_modes": [
          "Emitting invalid JSON, missing required fields, or including unmapped properties."
        ],
        "next_queries": [
          "Query interfaces/INTERNALIZATION_SCHEMA for the broader lifecycle contract."
        ],
        "proceed_when": [
          "Proceed when the payload structure guarantees validation success."
        ]
      }
    },
    "interfaces/jsonschema/internalization/InternalizationCreateResult.schema": {
      "id": "interfaces/jsonschema/internalization/InternalizationCreateResult.schema",
      "category": "interfaces",
      "title": "interfaces/jsonschema/internalization/InternalizationCreateResult.schema",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Internalization schema surface governing strict serialization, purpose, producers, and validation constraints.",
      "terms": [
        "attached",
        "inspected",
        "external",
        "inside",
        "internalization",
        "knowledge",
        "governed",
        "internalizationcreateresult",
        "decapod",
        "detached",
        "schema",
        "state"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES"
        ]
      },
      "sections": {
        "match": [
          "Use when generating or parsing interfaces/jsonschema/internalization/InternalizationCreateResult.schema JSON payloads."
        ],
        "concepts": [
          "This schema strictly governs data shape and validation for internalization logic.",
          "It defines the contract between the producing sub-system and the consuming agent."
        ],
        "ambiguity": [
          "Stop inference if payload constraints, required fields, or validation rules are unclear."
        ],
        "decisions": [
          "Determine exact field population and formatting required by the schema constraints."
        ],
        "standards": [
          "Outputs must pass Ajv strict validation before being transmitted.",
          "Unknown fields must be omitted."
        ],
        "failure_modes": [
          "Emitting invalid JSON, missing required fields, or including unmapped properties."
        ],
        "next_queries": [
          "Query interfaces/INTERNALIZATION_SCHEMA for the broader lifecycle contract."
        ],
        "proceed_when": [
          "Proceed when the payload structure guarantees validation success."
        ]
      }
    },
    "interfaces/jsonschema/internalization/InternalizationDetachResult.schema": {
      "id": "interfaces/jsonschema/internalization/InternalizationDetachResult.schema",
      "category": "interfaces",
      "title": "interfaces/jsonschema/internalization/InternalizationDetachResult.schema",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Internalization schema surface governing strict serialization, purpose, producers, and validation constraints.",
      "terms": [
        "attached",
        "inspected",
        "external",
        "inside",
        "internalization",
        "knowledge",
        "governed",
        "internalizationdetachresult",
        "decapod",
        "detached",
        "schema",
        "state"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES"
        ]
      },
      "sections": {
        "match": [
          "Use when generating or parsing interfaces/jsonschema/internalization/InternalizationDetachResult.schema JSON payloads."
        ],
        "concepts": [
          "This schema strictly governs data shape and validation for internalization logic.",
          "It defines the contract between the producing sub-system and the consuming agent."
        ],
        "ambiguity": [
          "Stop inference if payload constraints, required fields, or validation rules are unclear."
        ],
        "decisions": [
          "Determine exact field population and formatting required by the schema constraints."
        ],
        "standards": [
          "Outputs must pass Ajv strict validation before being transmitted.",
          "Unknown fields must be omitted."
        ],
        "failure_modes": [
          "Emitting invalid JSON, missing required fields, or including unmapped properties."
        ],
        "next_queries": [
          "Query interfaces/INTERNALIZATION_SCHEMA for the broader lifecycle contract."
        ],
        "proceed_when": [
          "Proceed when the payload structure guarantees validation success."
        ]
      }
    },
    "interfaces/jsonschema/internalization/InternalizationInspectResult.schema": {
      "id": "interfaces/jsonschema/internalization/InternalizationInspectResult.schema",
      "category": "interfaces",
      "title": "interfaces/jsonschema/internalization/InternalizationInspectResult.schema",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Internalization schema surface governing strict serialization, purpose, producers, and validation constraints.",
      "terms": [
        "attached",
        "inspected",
        "external",
        "inside",
        "internalization",
        "knowledge",
        "governed",
        "decapod",
        "detached",
        "schema",
        "internalizationinspectresult",
        "state"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES"
        ]
      },
      "sections": {
        "match": [
          "Use when generating or parsing interfaces/jsonschema/internalization/InternalizationInspectResult.schema JSON payloads."
        ],
        "concepts": [
          "This schema strictly governs data shape and validation for internalization logic.",
          "It defines the contract between the producing sub-system and the consuming agent."
        ],
        "ambiguity": [
          "Stop inference if payload constraints, required fields, or validation rules are unclear."
        ],
        "decisions": [
          "Determine exact field population and formatting required by the schema constraints."
        ],
        "standards": [
          "Outputs must pass Ajv strict validation before being transmitted.",
          "Unknown fields must be omitted."
        ],
        "failure_modes": [
          "Emitting invalid JSON, missing required fields, or including unmapped properties."
        ],
        "next_queries": [
          "Query interfaces/INTERNALIZATION_SCHEMA for the broader lifecycle contract."
        ],
        "proceed_when": [
          "Proceed when the payload structure guarantees validation success."
        ]
      }
    },
    "interfaces/jsonschema/internalization/InternalizationManifest.schema": {
      "id": "interfaces/jsonschema/internalization/InternalizationManifest.schema",
      "category": "interfaces",
      "title": "interfaces/jsonschema/internalization/InternalizationManifest.schema",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Internalization schema surface governing strict serialization, purpose, producers, and validation constraints.",
      "terms": [
        "attached",
        "inspected",
        "external",
        "inside",
        "internalizationmanifest",
        "internalization",
        "knowledge",
        "governed",
        "decapod",
        "detached",
        "schema",
        "state"
      ],
      "links": {
        "references": [
          "core/INTERFACES"
        ],
        "referenced_by": [
          "core/INTERFACES"
        ]
      },
      "sections": {
        "match": [
          "Use when generating or parsing interfaces/jsonschema/internalization/InternalizationManifest.schema JSON payloads."
        ],
        "concepts": [
          "This schema strictly governs data shape and validation for internalization logic.",
          "It defines the contract between the producing sub-system and the consuming agent."
        ],
        "ambiguity": [
          "Stop inference if payload constraints, required fields, or validation rules are unclear."
        ],
        "decisions": [
          "Determine exact field population and formatting required by the schema constraints."
        ],
        "standards": [
          "Outputs must pass Ajv strict validation before being transmitted.",
          "Unknown fields must be omitted."
        ],
        "failure_modes": [
          "Emitting invalid JSON, missing required fields, or including unmapped properties."
        ],
        "next_queries": [
          "Query interfaces/INTERNALIZATION_SCHEMA for the broader lifecycle contract."
        ],
        "proceed_when": [
          "Proceed when the payload structure guarantees validation success."
        ]
      }
    },
    "metadata/skills/BUNDLE": {
      "id": "metadata/skills/BUNDLE",
      "category": "metadata",
      "title": "metadata/skills/BUNDLE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes skill bundle metadata: grouping, dependencies, and invocation suitability.",
      "terms": [
        "skill bundle",
        "grouping",
        "discovery tags",
        "dependencies",
        "invocation"
      ],
      "links": {
        "references": [],
        "referenced_by": [
          "docs/SKILL_TRANSLATION_MAP"
        ]
      },
      "sections": {
        "match": [
          "Use when classifying groups of related skills, filtering by capability, or resolving dependencies."
        ],
        "concepts": [
          "Skill Grouping: Logical clusters of skills serving a common capability family (e.g., 'security-audit').",
          "Discovery Tags: Semantic labels that help agents find relevant bundles for specific task intents.",
          "Bundle Dependencies: Prerequisites that must be satisfied before a skill bundle can be invoked."
        ],
        "ambiguity": [
          "Stop if a skill bundle has circular dependencies or missing capability requirements."
        ],
        "decisions": [
          "Identify if a new capability belongs in an existing bundle or requires a new group."
        ],
        "standards": [
          "Bundles must include a manifest documenting the purpose and authority of member skills."
        ],
        "failure_modes": [
          "Creating 'god bundles' that load irrelevant context for simple, focused tasks."
        ],
        "next_queries": [
          "Query specs/skills/SKILL_GOVERNANCE for lifecycle and security rules."
        ],
        "proceed_when": [
          "Proceed when the skill bundle is correctly categorized and dependencies are resolved."
        ]
      }
    },
    "metadata/skills/AGENT_DECAPOD_INTERFACE": {
      "id": "metadata/skills/AGENT_DECAPOD_INTERFACE",
      "category": "metadata",
      "title": "metadata/skills/AGENT_DECAPOD_INTERFACE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes retrieval tags and metadata for agent-to-Decapod interaction and control-plane respect.",
      "terms": [
        "agent-to-decapod",
        "receipt parsing",
        "interface tags",
        "context pack",
        "control plane"
      ],
      "links": {
        "references": [],
        "referenced_by": []
      },
      "sections": {
        "match": [
          "Use when searching for skills governing how agents use Decapod binary, RPC, or state."
        ],
        "concepts": [
          "Interaction Patterns: Standardized ways agents call CLI commands or parse RPC response receipts.",
          "Control-Plane Respect: Skills that enforce the rule of consulting Decapod before hardening plans.",
          "Context Pack Usage: Metadata for skills that optimize pre-inference ingestion of retrieved doctrine."
        ],
        "ambiguity": [
          "Stop if an interface skill conflicts with the core control plane schema or sequencing."
        ],
        "decisions": [
          "Identify whether a new interaction pattern belongs in core doctrine or a separate skill."
        ],
        "standards": [
          "Interface skills must use the canonical terminology defined in the GLOSSARY."
        ],
        "failure_modes": [
          "Creating skill metadata that encourages agents to bypass control plane mutation boundaries."
        ],
        "next_queries": [
          "Query interfaces/CONTROL_PLANE for the underlying machine contract."
        ],
        "proceed_when": [
          "Proceed when the interface skill is semantically linked to the correct CLI/RPC surface."
        ]
      }
    },
    "metadata/skills/HUMAN_AGENT_UX": {
      "id": "metadata/skills/HUMAN_AGENT_UX",
      "category": "metadata",
      "title": "metadata/skills/HUMAN_AGENT_UX",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes metadata for human-agent experience skills: clarification, feedback loops, and safety.",
      "terms": [
        "clarification",
        "intent capture",
        "feedback loop",
        "human-agent UX",
        "safety"
      ],
      "links": {
        "references": [],
        "referenced_by": []
      },
      "sections": {
        "match": [
          "Use when searching for skills that improve interaction between human users and agents."
        ],
        "concepts": [
          "Clarification Triggers: Metadata identifying when an agent must stop to ask for human input.",
          "Feedback Loops: Managing the rhythm of communication, progress updates, and task confirmation.",
          "Safety and Humility: Ensuring UX skills do not hide uncertainty or violate authority boundaries."
        ],
        "ambiguity": [
          "Stop if a UX skill lacks a defined threshold for when to halt and seek clarification."
        ],
        "decisions": [
          "Identify if a user request requires a formal clarification loop or a simple status update."
        ],
        "standards": [
          "Human-Agent UX skills must prioritize safety and authority over conversational fluidness."
        ],
        "failure_modes": [
          "Using UX skills to hide technical complexity or uncertainty that the user needs to know."
        ],
        "next_queries": [
          "Query metadata/skills/INTENT_REFINEMENT for prompt-shaping details."
        ],
        "proceed_when": [
          "Proceed when the UX skill facilitates clear intent capture and safe, humble interaction."
        ]
      }
    },
    "metadata/skills/INTENT_REFINEMENT": {
      "id": "metadata/skills/INTENT_REFINEMENT",
      "category": "metadata",
      "title": "metadata/skills/INTENT_REFINEMENT",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes metadata for skills that refine raw user intent into outcomes and acceptance criteria.",
      "terms": [
        "intent refinement",
        "distillation",
        "acceptance criteria",
        "outcome",
        "constraints"
      ],
      "links": {
        "references": [],
        "referenced_by": []
      },
      "sections": {
        "match": [
          "Use when classifying skills that specialize in turning vague prompts into governed tasks."
        ],
        "concepts": [
          "Intent Distillation: Extracting core desired outcomes and outcomes from narrative human input.",
          "Constraint Identification: Identifying 'must' and 'must-not' boundaries within a refined intent.",
          "Outcome to Action: Mapping refined user intent to the first disciplined Decapod operation."
        ],
        "ambiguity": [
          "Stop if the refined intent remains materially underdetermined after skill invocation."
        ],
        "decisions": [
          "Decide which user requirements are binding constraints versus optional preferences."
        ],
        "standards": [
          "Intent refinement skills must produce falsifiable, testable acceptance criteria."
        ],
        "failure_modes": [
          "Over-refining intent into a plan before querying Decapod for domain-specific doctrine."
        ],
        "next_queries": [
          "Query specs/INTENT for the formal intent storage contract."
        ],
        "proceed_when": [
          "Proceed when raw intent is distilled into a structured set of outcomes and constraints."
        ]
      }
    },
    "methodology/ARCHITECTURE": {
      "id": "methodology/ARCHITECTURE",
      "category": "methodology",
      "title": "methodology/ARCHITECTURE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes the architectural decision workflow: clarification, boundary mapping, and tradeoff comparison.",
      "terms": [
        "decision workflow",
        "clarify intent",
        "boundary mapping",
        "tradeoff analysis",
        "ADR"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY"
        ],
        "referenced_by": [
          "core/METHODOLOGY"
        ]
      },
      "sections": {
        "match": [
          "Use when seeking a disciplined workflow for making and documenting architectural decisions."
        ],
        "concepts": [
          "Clarify Intent: Start by identifying the product problem and user workflow before choosing tools.",
          "Map Boundaries: Identify the explicit lines where state, data flow, and runtime ownership changes.",
          "Query Doctrine: Use Decapod retrieval to identify domain-specific constraints and failure modes.",
          "Tradeoff Analysis: Compare options against constraints: cost, latency, throughput, and complexity."
        ],
        "ambiguity": [
          "Stop inference if the target environment, scale, or state ownership rules are unclarified."
        ],
        "decisions": [
          "Decide on the authoritative source of truth for each entity before designing communication."
        ],
        "standards": [
          "Every major decision must be recorded in an ADR citing rejected alternatives and proof."
        ],
        "failure_modes": [
          "Making implementation choices (e.g. 'add a DB table') before naming the domain boundary."
        ],
        "next_queries": [
          "Query interfaces/ARCHITECTURE_FOUNDATIONS for foundational vocabulary."
        ],
        "proceed_when": [
          "Proceed when boundaries are mapped, tradeoffs are documented, and proof is defined."
        ]
      }
    },
    "methodology/CI_CD": {
      "id": "methodology/CI_CD",
      "category": "methodology",
      "title": "methodology/CI_CD",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes immutable artifact promotion, release gates, rollback, and environment flow.",
      "terms": [
        "rollout strategy",
        "release gate",
        "immutable artifact",
        "promotion",
        "rollback plan",
        "smoke test",
        "release evidence",
        "environment flow",
        "canary",
        "blue-green"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY"
        ],
        "referenced_by": [
          "architecture/CI_CD_PIPELINES",
          "core/METHODOLOGY"
        ]
      },
      "sections": {
        "match": [
          "Use when configuring build pipelines, automating deployments, or establishing release guardrails."
        ],
        "concepts": [
          "Immutable Artifacts: Build the binary once; promote it through dev, staging, and prod without recompilation.",
          "Release Gates: Every environment transition must be gated by passing tests, scans, and proof claims.",
          "Rollback: Every deployment must have a verified, automated path to revert to the previous stable state."
        ],
        "ambiguity": [
          "Stop if the rollback trigger or the environment-specific secret injection is unverified."
        ],
        "decisions": [
          "Choose between Canary, Blue-Green, or Rolling rollout strategies based on risk."
        ],
        "standards": [
          "Deployments must leave an auditable trace linking the artifact to the source commit."
        ],
        "failure_modes": [
          "Deploying without automated health checks (smoke tests) in the target environment."
        ],
        "next_queries": [
          "Query architecture/CI_CD_PIPELINES for infrastructure constraints."
        ],
        "proceed_when": [
          "Proceed when gates are defined, artifacts are immutable, and rollback is automated."
        ]
      }
    },
    "methodology/ENGINEERING_MANAGEMENT": {
      "id": "methodology/ENGINEERING_MANAGEMENT",
      "category": "methodology",
      "title": "methodology/ENGINEERING_MANAGEMENT",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers prioritization, ownership, review, delivery risk, team health, and decision records.",
      "terms": [
        "health",
        "accountability",
        "leadership",
        "review",
        "execution",
        "technical",
        "management",
        "team",
        "methodology",
        "prioritization"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY"
        ],
        "referenced_by": [
          "core/METHODOLOGY"
        ]
      },
      "sections": {
        "match": [
          "Use when evaluating project velocity, assigning subsystem ownership, assessing delivery risks, or managing technical debt."
        ],
        "concepts": [
          "Ownership must be explicit. If a component has no owner, it will rot.",
          "Technical debt is a tool, not a sin. It must be incurred intentionally and paid down systematically.",
          "Delivery risk increases exponentially with batch size. Smaller, frequent releases are safer."
        ],
        "ambiguity": [
          "Stop inference if the business priority, subsystem owner, or acceptable risk profile is unstated."
        ],
        "decisions": [
          "Prioritize work based on customer impact, security risk, and unblocking downstream dependencies.",
          "Decide when to invest in paving new organizational 'golden paths' versus maintaining legacy systems."
        ],
        "standards": [
          "Every major technical pivot must be documented in an Architecture Decision Record (ADR).",
          "Code reviews must focus on logic, security, and architecture, not style (which should be automated)."
        ],
        "failure_modes": [
          "Allowing 'shadow IT' or undocumented subsystems to flourish without explicit ownership.",
          "Prioritizing feature velocity at the complete expense of system reliability and maintainability."
        ],
        "next_queries": [
          "Query methodology/PLATFORM for developer experience improvements.",
          "Query methodology/METRICS for team velocity signals."
        ],
        "proceed_when": [
          "Proceed when ownership is clear, risks are explicitly accepted, and prioritization aligns with business goals."
        ]
      }
    },
    "methodology/INCIDENT_RESPONSE": {
      "id": "methodology/INCIDENT_RESPONSE",
      "category": "methodology",
      "title": "methodology/INCIDENT_RESPONSE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers triage, severity, containment, rollback, and postmortem action items.",
      "terms": [
        "triage",
        "severity",
        "containment",
        "rollback",
        "incident commander",
        "customer impact",
        "timeline",
        "postmortem",
        "root cause"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY"
        ],
        "referenced_by": [
          "architecture/OBSERVABILITY",
          "core/METHODOLOGY"
        ]
      },
      "sections": {
        "match": [
          "Use when mitigating an active outage, diagnosing production failures, or writing postmortems."
        ],
        "concepts": [
          "Mitigation First: Prioritize restoring service over finding the root cause during an active incident.",
          "Containment: Limit the blast radius immediately; disconnect or disable failing subsystems if necessary.",
          "Blameless Postmortems: Focus on systemic guardrail failures rather than individual human error."
        ],
        "ambiguity": [
          "Stop if the incident commander, current customer impact, or containment path is unknown."
        ],
        "decisions": [
          "Decide immediately between a fast rollback vs a speculative forward-fix."
        ],
        "standards": [
          "All incident actions and communications must be recorded in a centralized timeline."
        ],
        "failure_modes": [
          "Deep-debugging a live outage while the system remains down for customers."
        ],
        "next_queries": [
          "Query methodology/OPERATIONS for runbook procedures."
        ],
        "proceed_when": [
          "Proceed when containment is achieved and a blameless investigation begins."
        ]
      }
    },
    "methodology/KNOWLEDGE": {
      "id": "methodology/KNOWLEDGE",
      "category": "methodology",
      "title": "methodology/KNOWLEDGE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Distinguishes captured knowledge, durable memory, retrieval, provenance, decay, and governance.",
      "terms": [
        "capture",
        "retrieval",
        "agent",
        "provenance",
        "understanding",
        "knowledge",
        "indexing",
        "reusable",
        "subsystem"
      ],
      "links": {
        "references": [
          "architecture/KNOWLEDGE_BASE",
          "core/METHODOLOGY",
          "interfaces/KNOWLEDGE_SCHEMA",
          "interfaces/KNOWLEDGE_STORE"
        ],
        "referenced_by": [
          "core/METHODOLOGY",
          "plugins/KNOWLEDGE"
        ]
      },
      "sections": {
        "match": [
          "Use when curating project documentation, ingesting context, or structuring agentic knowledge bases."
        ],
        "concepts": [
          "Knowledge management is about retrieval, not storage. If it cannot be found contextually, it does not exist.",
          "Knowledge decays. Documents must have owners and expiration/verification dates.",
          "Provenance matters: a binding architectural spec has higher authority than a casual chat log."
        ],
        "ambiguity": [
          "Stop inference if the source authority, accuracy, or intended audience of the knowledge is unclear."
        ],
        "decisions": [
          "Determine whether information should be durable (specs), episodic (task logs), or operational (runbooks).",
          "Decide on the categorization and tagging taxonomy to ensure high-signal retrieval."
        ],
        "standards": [
          "All canonical knowledge must reside in version control to ensure auditability and peer review.",
          "Structure knowledge hierarchically: core routing principles vs deep domain specifics."
        ],
        "failure_modes": [
          "Hoarding massive, unstructured documents that pollute agent context windows and dilute search relevance.",
          "Failing to deprecate or delete stale knowledge, leading to agents hallucinating outdated patterns."
        ],
        "next_queries": [
          "Query architecture/KNOWLEDGE_BASE for technical search implementation.",
          "Query methodology/MEMORY for agent runtime context."
        ],
        "proceed_when": [
          "Proceed when the knowledge is concisely structured, tagged, and its authority level is verified."
        ]
      }
    },
    "methodology/MEMORY": {
      "id": "methodology/MEMORY",
      "category": "methodology",
      "title": "methodology/MEMORY",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers agent cognitive memory, context windows, distillation, and semantic retrieval boundaries.",
      "terms": [
        "separation",
        "allocation",
        "boundaries",
        "context",
        "persistence",
        "caching",
        "pressure",
        "leaks",
        "locality",
        "object",
        "memory",
        "lifetimes"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY"
        ],
        "referenced_by": [
          "core/METHODOLOGY"
        ]
      },
      "sections": {
        "match": [
          "Use when managing an agent's context window, distilling session history, or retrieving past task resolutions."
        ],
        "concepts": [
          "Agent memory is finite. Context windows must be fiercely protected from irrelevant noise.",
          "Distillation is mandatory. Raw transcripts must be compressed into factual, actionable insights.",
          "Memory retrieval must be semantically linked to the current task's intent."
        ],
        "ambiguity": [
          "Stop inference if the current task lacks relevant context or if the retrieved memory contradicts established specs."
        ],
        "decisions": [
          "Decide what artifacts from a completed task are worth preserving in long-term memory vs discarding.",
          "Determine the balance between eager context loading (high token cost) and lazy retrieval (high latency)."
        ],
        "standards": [
          "Summarize task outcomes into precise 'lessons learned' rather than saving raw conversational logs.",
          "Prioritize recent and highly relevant contextual snippets over massive historical dumps."
        ],
        "failure_modes": [
          "Filling the context window with generic boilerplate, pushing critical task instructions out of attention.",
          "Allowing an agent to rely on hallucinated 'memory' instead of retrieving concrete repository state."
        ],
        "next_queries": [
          "Query interfaces/AGENT_CONTEXT_PACK for data structures.",
          "Query methodology/KNOWLEDGE for canonical persistence."
        ],
        "proceed_when": [
          "Proceed when the active context window contains only the dense, verified signals needed for the immediate inference."
        ]
      }
    },
    "methodology/METRICS": {
      "id": "methodology/METRICS",
      "category": "methodology",
      "title": "methodology/METRICS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers measurement design, leading vs lagging indicators, SLIs/SLOs, dashboards, and decision usefulness.",
      "terms": [
        "signals",
        "metrics",
        "counters",
        "measurement",
        "decision",
        "dashboards",
        "slos",
        "slis",
        "instrumentation",
        "alerting",
        "histograms",
        "operational"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY"
        ],
        "referenced_by": [
          "core/METHODOLOGY",
          "docs/EVAL_TRANSLATION_MAP"
        ]
      },
      "sections": {
        "match": [
          "Use when defining success criteria, creating dashboards, establishing Service Level Objectives, or instrumenting code."
        ],
        "concepts": [
          "Metrics must drive decisions. If a metric goes up or down and nobody changes their behavior, it is a vanity metric.",
          "Leading indicators predict future outcomes; lagging indicators measure past results.",
          "Service Level Indicators (SLIs) must measure the user's actual experience (e.g., successful page loads)."
        ],
        "ambiguity": [
          "Stop inference if the business goal, baseline measurement, or acceptable SLO threshold is undefined."
        ],
        "decisions": [
          "Decide which metrics represent true system health (SLIs) versus internal diagnostic telemetry.",
          "Determine the appropriate alerting thresholds based on the agreed-upon error budget (SLO)."
        ],
        "standards": [
          "Instrument code to emit structured metrics (e.g., RED method: Rate, Errors, Duration).",
          "Review and prune unused dashboards and metrics regularly to reduce cognitive load and storage costs."
        ],
        "failure_modes": [
          "Tracking hundreds of metrics without defining what constitutes a healthy state.",
          "Using high-cardinality tags (like User ID) in time-series databases, leading to system crashes."
        ],
        "next_queries": [
          "Query architecture/METRICS for technical implementation details.",
          "Query methodology/PRODUCT for business success signals."
        ],
        "proceed_when": [
          "Proceed when the metrics are explicitly tied to user experience and decision-making thresholds."
        ]
      }
    },
    "methodology/OPERATIONS": {
      "id": "methodology/OPERATIONS",
      "category": "methodology",
      "title": "methodology/OPERATIONS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers runbooks, on-call, change management, reliability posture, and operational readiness.",
      "terms": [
        "incident",
        "ownership",
        "change",
        "practice",
        "posture",
        "management",
        "runbooks",
        "methodology",
        "operations",
        "reliability"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY"
        ],
        "referenced_by": [
          "core/METHODOLOGY"
        ]
      },
      "sections": {
        "match": [
          "Use when establishing on-call procedures, writing runbooks, defining change management, or reviewing operational readiness."
        ],
        "concepts": [
          "Software is only 'done' when it is observable, supportable, and has a defined failure recovery path.",
          "Runbooks must be executable, precise, and up-to-date. Outdated runbooks worsen incidents.",
          "Change management exists to assess risk and ensure rollback capabilities, not merely to add bureaucratic friction."
        ],
        "ambiguity": [
          "Stop inference if the on-call owner, recovery procedure, or operational telemetry is missing."
        ],
        "decisions": [
          "Determine what constitutes an actionable alert versus what should be relegated to a dashboard.",
          "Assess the operational readiness of a new service before it is permitted to take production traffic."
        ],
        "standards": [
          "All alerts must point to a specific, actionable runbook step.",
          "Operational telemetry (metrics, logs, traces) must be verified in a staging environment before production release."
        ],
        "failure_modes": [
          "Deploying services without automated rollback mechanisms or explicit operational owners.",
          "Alert fatigue: configuring pages for non-critical, self-healing events, causing engineers to ignore real issues."
        ],
        "next_queries": [
          "Query methodology/INCIDENT_RESPONSE for outage mitigation.",
          "Query architecture/OBSERVABILITY for telemetry setup."
        ],
        "proceed_when": [
          "Proceed when operational readiness checklists are complete and runbooks are actionable."
        ]
      }
    },
    "methodology/PLATFORM": {
      "id": "methodology/PLATFORM",
      "category": "methodology",
      "title": "methodology/PLATFORM",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers paved roads, developer experience, abstractions, adoption, golden paths, and escape hatches.",
      "terms": [
        "shared",
        "experience",
        "internal",
        "governance",
        "design",
        "capability",
        "methodology",
        "adoption",
        "developer",
        "platform",
        "abstractions"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY"
        ],
        "referenced_by": [
          "core/METHODOLOGY"
        ]
      },
      "sections": {
        "match": [
          "Use when designing internal tooling, CI/CD templates, shared libraries, or establishing developer 'golden paths'."
        ],
        "concepts": [
          "A platform team's product is the developer experience. The 'paved road' must be the easiest path.",
          "Abstractions should hide complexity, not mask underlying failures. Provide clear 'escape hatches'.",
          "Adoption is driven by utility, not mandates. If developers avoid the platform, the platform is failing."
        ],
        "ambiguity": [
          "Stop inference if the developer workflow, intended abstraction boundary, or fallback escape hatch is missing."
        ],
        "decisions": [
          "Choose which operational concerns (e.g., logging, tracing, auth) to abstract away from feature teams.",
          "Determine the boundary between what the platform mandates and what feature teams can configure."
        ],
        "standards": [
          "Platform tooling must be versioned, backward-compatible, and accompanied by automated migration scripts.",
          "Treat internal platform APIs with the same rigor and contract stability as external customer APIs."
        ],
        "failure_modes": [
          "Building heavy, mandatory frameworks that trap developers in brittle, unmaintainable monoliths.",
          "Failing to provide 'escape hatches', forcing developers to build fragile workarounds when the platform doesn't fit."
        ],
        "next_queries": [
          "Query architecture/CI_CD_PIPELINES for automation integration.",
          "Query architecture/ENTERPRISE for cross-team alignment."
        ],
        "proceed_when": [
          "Proceed when the abstraction simplifies developer workflow and clearly documents its operational boundaries."
        ]
      }
    },
    "methodology/PRODUCT": {
      "id": "methodology/PRODUCT",
      "category": "methodology",
      "title": "methodology/PRODUCT",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Maps vague asks to user, workflow, problem, platform, and success signals.",
      "terms": [
        "user workflow",
        "first slice",
        "platform selection",
        "acceptance criteria",
        "non-goals",
        "success signal",
        "adoption"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY"
        ],
        "referenced_by": [
          "core/METHODOLOGY"
        ]
      },
      "sections": {
        "match": [
          "Use when clarifying feature scope, interpreting user intent, or defining 'why' a change is needed."
        ],
        "concepts": [
          "User First: Every technical decision must solve a specific problem for a defined user persona.",
          "The First Slice: Identify the smallest deployable increment that provides measurable user value.",
          "Non-Goals: Explicitly list what the feature will *not* do to prevent scope creep."
        ],
        "ambiguity": [
          "Stop if the target platform, workflow, or success criteria remain narrative or vague."
        ],
        "decisions": [
          "Identify which parts of a broad user request belong in the 'first slice' versus a backlog."
        ],
        "standards": [
          "Acceptance criteria must be falsifiable and verifiable via automated tests or evals."
        ],
        "failure_modes": [
          "Starting implementation before the product problem and success signals are documented."
        ],
        "next_queries": [
          "Query methodology/ARCHITECTURE to map product needs to state and boundaries."
        ],
        "proceed_when": [
          "Proceed when the user, problem, and acceptance criteria are explicitly documented."
        ]
      }
    },
    "methodology/RELEASE_MANAGEMENT": {
      "id": "methodology/RELEASE_MANAGEMENT",
      "category": "methodology",
      "title": "methodology/RELEASE_MANAGEMENT",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes readiness assessment, scope freeze, rollout, and post-release verification.",
      "terms": [
        "rollout strategy",
        "release gate",
        "readiness assessment",
        "scope freeze",
        "versioning",
        "changelog",
        "rollout plan",
        "hold criteria",
        "rollback",
        "verification"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY"
        ],
        "referenced_by": [
          "architecture/CI_CD_PIPELINES",
          "core/METHODOLOGY",
          "docs/RELEASE_PROCESS"
        ]
      },
      "sections": {
        "match": [
          "Use when preparing software releases, managing versions, or coordinating deployment timing."
        ],
        "concepts": [
          "Readiness: Verify all release gates, documentation freshness, and rollback paths before publication.",
          "Scope Freeze: Block new feature intent after a specific date to ensure stability for the release window.",
          "Verification: Execute post-release tests against production state to confirm successful rollout."
        ],
        "ambiguity": [
          "Stop if the release hold criteria or the customer communication plan is missing."
        ],
        "decisions": [
          "Decide when to execute a hold or rollback based on telemetry and post-release signals."
        ],
        "standards": [
          "Tags and changelogs must be pushed to version control before the release is claimed done."
        ],
        "failure_modes": [
          "Announcing a release before verifying successful deployment and basic functionality."
        ],
        "next_queries": [
          "Query docs/RELEASE_PROCESS for specific document surfaces."
        ],
        "proceed_when": [
          "Proceed when the rollout plan is approved and all readiness criteria are met."
        ]
      }
    },
    "methodology/RESEARCH": {
      "id": "methodology/RESEARCH",
      "category": "methodology",
      "title": "methodology/RESEARCH",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers source quality, claims, citations, uncertainty, synthesis, and when to stop.",
      "terms": [
        "handling",
        "hypotheses",
        "evidence",
        "falsifiable",
        "research",
        "synthesis",
        "learning",
        "uncertainty",
        "methodology"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY"
        ],
        "referenced_by": [
          "core/METHODOLOGY"
        ]
      },
      "sections": {
        "match": [
          "Use when investigating unfamiliar technologies, gathering domain context, or performing literature reviews."
        ],
        "concepts": [
          "Research must distinguish between authoritative claims (documentation/code) and anecdotal claims (blog posts).",
          "Uncertainty must be preserved. If a definitive answer is not found, state the ambiguity.",
          "Synthesis extracts actionable constraints from raw data."
        ],
        "ambiguity": [
          "Stop inference if the source material contradicts itself without an explicit resolution path."
        ],
        "decisions": [
          "Decide when enough information has been gathered to construct a safe prototype or ask the user a clarifying question.",
          "Evaluate the reliability of a source before injecting its claims into the project context."
        ],
        "standards": [
          "Always cite the source or reasoning path for major architectural or implementation claims.",
          "Format research outputs into dense, factual summaries rather than narrative essays."
        ],
        "failure_modes": [
          "Treating marketing material or outdated tutorials as binding technical specifications.",
          "Falling into analysis paralysis instead of bounding the research phase with a concrete timebox."
        ],
        "next_queries": [
          "Query methodology/RESEARCH_PRODUCTION to transition findings into implementation.",
          "Query core/GAPS if the research uncovers missing system capabilities."
        ],
        "proceed_when": [
          "Proceed when the research yields actionable, cited constraints that resolve the initial uncertainty."
        ]
      }
    },
    "methodology/RESEARCH_PRODUCTION": {
      "id": "methodology/RESEARCH_PRODUCTION",
      "category": "methodology",
      "title": "methodology/RESEARCH_PRODUCTION",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers translating research into product constraints, prototypes, evaluation, and implementation risk.",
      "terms": [
        "exploration",
        "constraints",
        "validation",
        "immutable artifact",
        "translation",
        "research",
        "production",
        "shipped",
        "methodology",
        "operationalization"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY"
        ],
        "referenced_by": [
          "core/METHODOLOGY"
        ]
      },
      "sections": {
        "match": [
          "Use when transitioning from exploratory research to concrete architectural designs or production implementations."
        ],
        "concepts": [
          "A prototype proves a concept; productionizing makes it observable, secure, and maintainable.",
          "Research constraints must be formally codified into the system's specs and interfaces.",
          "Implementation risk includes operational overhead, security posture, and team familiarity with the technology."
        ],
        "ambiguity": [
          "Stop inference if the prototype's success criteria or the operational cost of the new technology is unknown."
        ],
        "decisions": [
          "Determine which parts of a prototype should be discarded and rewritten for production rigor.",
          "Evaluate whether the researched solution introduces unacceptable dependencies or security risks."
        ],
        "standards": [
          "Production implementations must include observability (metrics/logs), CI/CD integration, and robust error handling.",
          "Document the transition from research to production in an Architecture Decision Record (ADR)."
        ],
        "failure_modes": [
          "Promoting a fragile 'happy-path' prototype directly to production without adding error handling or tests.",
          "Adopting a new technology without establishing organizational ownership or operational runbooks."
        ],
        "next_queries": [
          "Query architecture/ENTERPRISE for operational integration constraints.",
          "Query core/ENGINEERING_EXCELLENCE for production baselines."
        ],
        "proceed_when": [
          "Proceed when the research is formalized into testable specifications and production standards are met."
        ]
      }
    },
    "methodology/SOUL": {
      "id": "methodology/SOUL",
      "category": "methodology",
      "title": "methodology/SOUL",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod's operating ethos: auditability, boundaries, intent, and humility.",
      "terms": [
        "operating ethos",
        "humility",
        "auditability",
        "local-first",
        "boundaries"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY"
        ],
        "referenced_by": [
          "core/METHODOLOGY"
        ]
      },
      "sections": {
        "match": [
          "Use when seeking guidance on the core engineering ethos and humility under uncertainty."
        ],
        "concepts": [
          "Auditability First: Every decision and mutation must be traceable and evidence-backed.",
          "Respect Boundaries: Never silently cross trust, state, or authority lines established in doctrine.",
          "Humility under Uncertainty: Stop and ask the human when intent is underdetermined; never guess.",
          "Local-First Custody: Prioritize user-owned, repo-native state over centralized or opaque storage."
        ],
        "ambiguity": [
          "Stop if the task requires guessing user intent or bypassing an established safety gate."
        ],
        "decisions": [
          "Choose the path that maximizes proof, visibility, and reversibility over convenience."
        ],
        "standards": [
          "All work must preserve the integrity of the user's intent and the system's boundaries."
        ],
        "failure_modes": [
          "Prioritizing fluid conversation or local 'success' over long-term system auditability."
        ],
        "next_queries": [
          "Query core/ENGINEERING_EXCELLENCE for cross-cutting production baselines."
        ],
        "proceed_when": [
          "Proceed when the approach preserves humility, proof, and the local-first engineering ethos."
        ]
      }
    },
    "methodology/TESTING": {
      "id": "methodology/TESTING",
      "category": "methodology",
      "title": "methodology/TESTING",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Maps risk surface to test type and proof level across unit, integration, e2e, and contract tests.",
      "terms": [
        "contract",
        "evidence",
        "validation",
        "proof",
        "interface",
        "commands",
        "surfaces",
        "expected",
        "test",
        "testing",
        "mapping"
      ],
      "links": {
        "references": [
          "architecture/TESTING_STRATEGY",
          "core/METHODOLOGY",
          "interfaces/TESTING",
          "plugins/VERIFY"
        ],
        "referenced_by": [
          "architecture/API_DESIGN",
          "core/METHODOLOGY",
          "interfaces/TESTING",
          "plugins/VERIFY"
        ]
      },
      "sections": {
        "match": [
          "Use when determining test coverage, verifying behavior, or setting quality gates for a change."
        ],
        "concepts": [
          "Tests are executable specifications. They must assert observable behavior, not internal implementation.",
          "The testing pyramid demands many fast unit tests, fewer integration tests, and very few slow E2E tests.",
          "If a piece of code cannot be tested, its design is flawed (e.g., tight coupling, hidden state)."
        ],
        "ambiguity": [
          "Stop inference if the testing strategy for a critical risk boundary is undefined."
        ],
        "decisions": [
          "Decide whether a mock obscures a critical integration risk; use real dependencies or contract tests where possible.",
          "Determine the minimum proof required to demonstrate that a specific change is safe to merge."
        ],
        "standards": [
          "Every bug fix must include a regression test that fails without the fix.",
          "Tests must be deterministic. Flaky tests destroy trust and must be quarantined or fixed immediately."
        ],
        "failure_modes": [
          "Writing tautological tests that just mock everything and assert that functions were called.",
          "Testing private methods instead of the public API, leading to brittle tests that break on refactoring."
        ],
        "next_queries": [
          "Query architecture/TESTING_STRATEGY for structural patterns.",
          "Query interfaces/TESTING for exact proof claim definitions."
        ],
        "proceed_when": [
          "Proceed when the proposed tests accurately cover the introduced risk surface and are deterministic."
        ]
      }
    },
    "plugins/APTITUDE": {
      "id": "plugins/APTITUDE",
      "category": "plugins",
      "title": "plugins/APTITUDE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for APTITUDE.",
      "terms": [
        "signals",
        "task",
        "agent",
        "skill",
        "suitability",
        "assessment",
        "capability",
        "aptitude",
        "subsystem",
        "readiness"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "core/PLUGINS"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the APTITUDE operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/ARCHIVE": {
      "id": "plugins/ARCHIVE",
      "category": "plugins",
      "title": "plugins/ARCHIVE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for ARCHIVE.",
      "terms": [
        "immutable",
        "audit",
        "provenance",
        "storage",
        "retention",
        "records",
        "archive",
        "preservation",
        "safe",
        "historical",
        "lookup",
        "subsystem"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "core/PLUGINS"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the ARCHIVE operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/AUDIT": {
      "id": "plugins/AUDIT",
      "category": "plugins",
      "title": "plugins/AUDIT",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for AUDIT.",
      "terms": [
        "events",
        "evidence",
        "receipts",
        "reconstructable",
        "history",
        "action",
        "work",
        "actor",
        "time",
        "audit",
        "traceability",
        "subsystem"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "architecture/OBSERVABILITY",
          "core/PLUGINS",
          "docs/GOVERNANCE_AUDIT",
          "plugins/TODO"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the AUDIT operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/AUTOUPDATE": {
      "id": "plugins/AUTOUPDATE",
      "category": "plugins",
      "title": "plugins/AUTOUPDATE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for AUTOUPDATE.",
      "terms": [
        "rollout",
        "checks",
        "version",
        "safe",
        "compatibility",
        "update",
        "advancement",
        "discovery",
        "subsystem",
        "rollback",
        "autoupdate"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "core/PLUGINS"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the AUTOUPDATE operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/CONTAINER": {
      "id": "plugins/CONTAINER",
      "category": "plugins",
      "title": "plugins/CONTAINER",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for CONTAINER.",
      "terms": [
        "reproducible",
        "hygiene",
        "demand",
        "isolation",
        "dependency",
        "execution",
        "sandboxing",
        "container",
        "test",
        "subsystem",
        "build"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "core/PLUGINS"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the CONTAINER operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/CONTEXT": {
      "id": "plugins/CONTEXT",
      "category": "plugins",
      "title": "plugins/CONTEXT",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for CONTEXT.",
      "terms": [
        "boundary",
        "scoped",
        "enforcement",
        "shaping",
        "retrieval",
        "context",
        "capsule",
        "inference",
        "assembly",
        "subsystem"
      ],
      "links": {
        "references": [
          "core/DECAPOD",
          "core/PLUGINS",
          "interfaces/AGENT_CONTEXT_PACK",
          "interfaces/LCM",
          "plugins/KNOWLEDGE"
        ],
        "referenced_by": [
          "core/PLUGINS"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the CONTEXT operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/CRON": {
      "id": "plugins/CRON",
      "category": "plugins",
      "title": "plugins/CRON",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for CRON.",
      "terms": [
        "based",
        "bounded",
        "scheduled",
        "cron",
        "execution",
        "governance",
        "time",
        "tasks",
        "repeatable",
        "subsystem",
        "operations"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "core/PLUGINS"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the CRON operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/DB_BROKER": {
      "id": "plugins/DB_BROKER",
      "category": "plugins",
      "title": "plugins/DB_BROKER",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for DB BROKER.",
      "terms": [
        "mediation",
        "queueing",
        "database",
        "abstraction",
        "write",
        "boundaries",
        "writes",
        "storage",
        "broker",
        "access",
        "brokered",
        "read",
        "subsystem",
        "state"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "data/DATABASE",
          "core/PLUGINS",
          "docs/MIGRATIONS"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the DB BROKER operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/DECIDE": {
      "id": "plugins/DECIDE",
      "category": "plugins",
      "title": "plugins/DECIDE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for DECIDE.",
      "terms": [
        "capture",
        "decision",
        "alternatives",
        "tracking",
        "records",
        "trade",
        "rationale",
        "decide",
        "commitment",
        "subsystem"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "core/PLUGINS",
          "specs/INTENT"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the DECIDE operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/EMERGENCY_PROTOCOL": {
      "id": "plugins/EMERGENCY_PROTOCOL",
      "category": "plugins",
      "title": "plugins/EMERGENCY_PROTOCOL",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for EMERGENCY PROTOCOL.",
      "terms": [
        "conditions",
        "incident",
        "communication",
        "restoration",
        "containment",
        "post",
        "glass",
        "protocol",
        "break",
        "rollback",
        "emergency"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "core/PLUGINS"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the EMERGENCY PROTOCOL operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/FEDERATION": {
      "id": "plugins/FEDERATION",
      "category": "plugins",
      "title": "plugins/FEDERATION",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for FEDERATION.",
      "terms": [
        "shared",
        "trust",
        "federation",
        "provenance",
        "boundaries",
        "repository",
        "remote",
        "cross",
        "knowledge",
        "propagation",
        "learning",
        "subsystem",
        "state"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "core/PLUGINS"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the FEDERATION operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/FEEDBACK": {
      "id": "plugins/FEEDBACK",
      "category": "plugins",
      "title": "plugins/FEEDBACK",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for FEEDBACK.",
      "terms": [
        "controlled",
        "capture",
        "agent",
        "loops",
        "refinement",
        "recursive",
        "improvement",
        "human",
        "observations",
        "feedback",
        "defect",
        "subsystem"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "core/PLUGINS"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the FEEDBACK operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/HEALTH": {
      "id": "plugins/HEALTH",
      "category": "plugins",
      "title": "plugins/HEALTH",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for HEALTH.",
      "terms": [
        "health",
        "diagnostics",
        "detection",
        "system",
        "reporting",
        "checks",
        "degradation",
        "liveness",
        "operational",
        "subsystem",
        "readiness"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "architecture/OBSERVABILITY",
          "core/PLUGINS",
          "docs/PLAYBOOK"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the HEALTH operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/HEARTBEAT": {
      "id": "plugins/HEARTBEAT",
      "category": "plugins",
      "title": "plugins/HEARTBEAT",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for HEARTBEAT.",
      "terms": [
        "signals",
        "agent",
        "stale",
        "timeout",
        "progress",
        "work",
        "heartbeat",
        "detection",
        "liveness",
        "eviction",
        "presence",
        "subsystem",
        "invocation"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "core/PLUGINS",
          "docs/CONTROL_PLANE_API",
          "plugins/TODO"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the HEARTBEAT operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/KNOWLEDGE": {
      "id": "plugins/KNOWLEDGE",
      "category": "plugins",
      "title": "plugins/KNOWLEDGE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for KNOWLEDGE.",
      "terms": [
        "capture",
        "retrieval",
        "agent",
        "provenance",
        "understanding",
        "knowledge",
        "indexing",
        "reusable",
        "subsystem"
      ],
      "links": {
        "references": [
          "architecture/KNOWLEDGE_BASE",
          "core/PLUGINS",
          "interfaces/KNOWLEDGE_SCHEMA",
          "interfaces/KNOWLEDGE_STORE",
          "methodology/KNOWLEDGE"
        ],
        "referenced_by": [
          "core/PLUGINS",
          "plugins/CONTEXT"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the KNOWLEDGE operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/MANIFEST": {
      "id": "plugins/MANIFEST",
      "category": "plugins",
      "title": "plugins/MANIFEST",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for MANIFEST.",
      "terms": [
        "accountability",
        "provenance",
        "artifact",
        "inputs",
        "manifest",
        "metadata",
        "manifests",
        "release",
        "publication",
        "subsystem",
        "declarations"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "architecture/CI_CD_PIPELINES",
          "core/PLUGINS",
          "docs/RELEASE_PROCESS"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the MANIFEST operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/POLICY": {
      "id": "plugins/POLICY",
      "category": "plugins",
      "title": "plugins/POLICY",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for POLICY.",
      "terms": [
        "policy",
        "gates",
        "constraints",
        "authorized",
        "rules",
        "enforcement",
        "subsystem",
        "decisions",
        "exceptions"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "core/PLUGINS"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the POLICY operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/REFLEX": {
      "id": "plugins/REFLEX",
      "category": "plugins",
      "title": "plugins/REFLEX",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for REFLEX.",
      "terms": [
        "bounded",
        "checks",
        "action",
        "improvements",
        "automatic",
        "recursive",
        "corrective",
        "feedback",
        "reflex",
        "self",
        "subsystem"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "core/PLUGINS"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the REFLEX operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation.",
          "Events trigger the todo.heartbeat.autoclaim action for deterministic state ownership."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/TODO": {
      "id": "plugins/TODO",
      "category": "plugins",
      "title": "plugins/TODO",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for TODO.",
      "terms": [
        "sourced",
        "task",
        "agent",
        "work",
        "tracking",
        "ownership",
        "obligations",
        "event",
        "transitions",
        "todo",
        "subsystem",
        "state"
      ],
      "links": {
        "references": [
          "core/PLUGINS",
          "interfaces/CONTROL_PLANE",
          "interfaces/TODO_SCHEMA",
          "plugins/AUDIT",
          "plugins/HEARTBEAT"
        ],
        "referenced_by": [
          "core/PLUGINS"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the TODO operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path.",
          "Subsystem auto-clocks liveness upon invocation to ensure task accountability."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/TRUST": {
      "id": "plugins/TRUST",
      "category": "plugins",
      "title": "plugins/TRUST",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for TRUST.",
      "terms": [
        "identity",
        "confidence",
        "boundary",
        "trust",
        "evidence",
        "provenance",
        "permissions",
        "enforcement",
        "subsystem"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "core/PLUGINS",
          "docs/SECURITY_THREAT_MODEL"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the TRUST operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/VERIFY": {
      "id": "plugins/VERIFY",
      "category": "plugins",
      "title": "plugins/VERIFY",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for VERIFY.",
      "terms": [
        "collection",
        "proof",
        "validation",
        "evidence",
        "orchestration",
        "execution",
        "verify",
        "check",
        "completion",
        "subsystem"
      ],
      "links": {
        "references": [
          "core/PLUGINS",
          "interfaces/CLAIMS",
          "interfaces/CONTROL_PLANE",
          "methodology/TESTING",
          "specs/SYSTEM"
        ],
        "referenced_by": [
          "architecture/CI_CD_PIPELINES",
          "core/PLUGINS",
          "docs/CONTROL_PLANE_API",
          "docs/GOVERNANCE_AUDIT",
          "docs/PLAYBOOK",
          "docs/RELEASE_PROCESS",
          "interfaces/TESTING",
          "methodology/TESTING"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the VERIFY operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "plugins/WATCHER": {
      "id": "plugins/WATCHER",
      "category": "plugins",
      "title": "plugins/WATCHER",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes Decapod subsystem ownership, lifecycle state, invocation boundary, and proof surface for WATCHER.",
      "terms": [
        "file",
        "detection",
        "watcher",
        "bounded",
        "repository",
        "change",
        "event",
        "observation",
        "reaction",
        "triggers",
        "subsystem",
        "state"
      ],
      "links": {
        "references": [
          "core/PLUGINS"
        ],
        "referenced_by": [
          "core/PLUGINS"
        ]
      },
      "sections": {
        "match": [
          "Use when interacting with the WATCHER operational surface or determining its maturity expectation."
        ],
        "concepts": [
          "Subsystems use truth labels (REAL, STUB, SPEC, IDEA) to communicate reliability.",
          "Plugin operations must be invoked through supported CLI commands, not direct file mutation."
        ],
        "ambiguity": [
          "Stop inference if the subsystem status, proof surface, or capability boundary is unknown."
        ],
        "decisions": [
          "Identify the subsystem owner and state boundary before invoking a command."
        ],
        "standards": [
          "REAL entries must name an executable proof surface.",
          "Deprecated surfaces must provide a canonical replacement path."
        ],
        "failure_modes": [
          "Relying on deprecated or SPEC surfaces for production claims.",
          "Marking a subsystem usable without an executable proof surface."
        ],
        "next_queries": [
          "Query core/INTERFACES to verify the exact schema structure required for invocation."
        ],
        "proceed_when": [
          "Proceed when the subsystem truth label supports the required level of execution risk."
        ]
      }
    },
    "specs/AMENDMENTS": {
      "id": "specs/AMENDMENTS",
      "category": "specs",
      "title": "specs/AMENDMENTS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes binding authority, mutation risk, compatibility, and execution obligations for AMENDMENTS.",
      "terms": [
        "controlled",
        "amendments",
        "constitution",
        "audit",
        "review",
        "change",
        "doctrine",
        "proposal",
        "adoption",
        "supersession",
        "trail"
      ],
      "links": {
        "references": [
          "core/DEMANDS"
        ],
        "referenced_by": [
          "core/DEMANDS"
        ]
      },
      "sections": {
        "match": [
          "Use when dealing with AMENDMENTS system contracts, authority doctrine, or security rules."
        ],
        "concepts": [
          "Spec nodes define binding or promotion-relevant requirements.",
          "Spec constraints are stronger than methodology guides or local preferences."
        ],
        "ambiguity": [
          "Stop inference if the spec change creates an unresolvable authority conflict."
        ],
        "decisions": [
          "Determine if the requested change alters system boundaries or evaluation governance."
        ],
        "standards": [
          "Spec changes require compatibility reasoning, affected surfaces, and migration paths.",
          "State acceptance criteria in falsifiable, testable terms."
        ],
        "failure_modes": [
          "Silently changing doctrine, authority, security posture, or mutation rules.",
          "Bypassing a binding spec because a local implementation path is convenient."
        ],
        "next_queries": [
          "Query core/EMERGENCY_PROTOCOL if the spec dictates a halt to mutation under risk."
        ],
        "proceed_when": [
          "Proceed when the spec constraint has been fully integrated into the implementation plan."
        ]
      }
    },
    "specs/DB_BROKER_QUEUE": {
      "id": "specs/DB_BROKER_QUEUE",
      "category": "specs",
      "title": "specs/DB_BROKER_QUEUE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes binding authority, mutation risk, compatibility, and execution obligations for DB BROKER QUEUE.",
      "terms": [
        "ordering",
        "database",
        "visibility",
        "isolation",
        "broker",
        "spec",
        "failure",
        "queue",
        "retry",
        "semantics",
        "operations",
        "queued"
      ],
      "links": {
        "references": [
          "core/DEMANDS"
        ],
        "referenced_by": [
          "data/DATABASE",
          "core/DEMANDS",
          "docs/MIGRATIONS"
        ]
      },
      "sections": {
        "match": [
          "Use when dealing with DB BROKER QUEUE system contracts, authority doctrine, or security rules."
        ],
        "concepts": [
          "Spec nodes define binding or promotion-relevant requirements.",
          "Spec constraints are stronger than methodology guides or local preferences."
        ],
        "ambiguity": [
          "Stop inference if the spec change creates an unresolvable authority conflict."
        ],
        "decisions": [
          "Determine if the requested change alters system boundaries or evaluation governance."
        ],
        "standards": [
          "Spec changes require compatibility reasoning, affected surfaces, and migration paths.",
          "State acceptance criteria in falsifiable, testable terms."
        ],
        "failure_modes": [
          "Silently changing doctrine, authority, security posture, or mutation rules.",
          "Bypassing a binding spec because a local implementation path is convenient."
        ],
        "next_queries": [
          "Query core/EMERGENCY_PROTOCOL if the spec dictates a halt to mutation under risk."
        ],
        "proceed_when": [
          "Proceed when the spec constraint has been fully integrated into the implementation plan."
        ]
      }
    },
    "specs/GIT": {
      "id": "specs/GIT",
      "category": "specs",
      "title": "specs/GIT",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes binding authority, mutation risk, compatibility, and execution obligations for GIT.",
      "terms": [
        "worktrees",
        "promotion",
        "provenance",
        "boundaries",
        "repository",
        "spec",
        "workflow",
        "safety",
        "branch",
        "commits",
        "merge",
        "status"
      ],
      "links": {
        "references": [
          "core/DEMANDS"
        ],
        "referenced_by": [
          "architecture/CI_CD_PIPELINES",
          "core/DEMANDS",
          "docs/RELEASE_PROCESS"
        ]
      },
      "sections": {
        "match": [
          "Use when dealing with GIT system contracts, authority doctrine, or security rules."
        ],
        "concepts": [
          "Spec nodes define binding or promotion-relevant requirements.",
          "Spec constraints are stronger than methodology guides or local preferences."
        ],
        "ambiguity": [
          "Stop inference if the spec change creates an unresolvable authority conflict."
        ],
        "decisions": [
          "Determine if the requested change alters system boundaries or evaluation governance."
        ],
        "standards": [
          "Spec changes require compatibility reasoning, affected surfaces, and migration paths.",
          "State acceptance criteria in falsifiable, testable terms."
        ],
        "failure_modes": [
          "Silently changing doctrine, authority, security posture, or mutation rules.",
          "Bypassing a binding spec because a local implementation path is convenient."
        ],
        "next_queries": [
          "Query core/EMERGENCY_PROTOCOL if the spec dictates a halt to mutation under risk."
        ],
        "proceed_when": [
          "Proceed when the spec constraint has been fully integrated into the implementation plan."
        ]
      }
    },
    "specs/INTENT": {
      "id": "specs/INTENT",
      "category": "specs",
      "title": "specs/INTENT",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "This domain covers raw human intent, explicit constraints, assumptions, acceptance criteria, mutation authority, and drift recovery.",
      "terms": [
        "capture",
        "constraints",
        "clarification",
        "intent",
        "mutation",
        "outcome",
        "specification",
        "human",
        "scope",
        "criteria",
        "acceptance",
        "authority"
      ],
      "links": {
        "references": [
          "core/DECAPOD",
          "core/DEMANDS",
          "interfaces/PROJECT_SPECS",
          "plugins/DECIDE",
          "specs/SYSTEM"
        ],
        "referenced_by": [
          "core/DEMANDS",
          "specs/SYSTEM"
        ]
      },
      "sections": {
        "match": [
          "Use when interpreting the user's initial prompt, establishing task boundaries, or dealing with ambiguous instructions."
        ],
        "concepts": [
          "Raw intent must be refined into explicit, falsifiable acceptance criteria before implementation.",
          "Assumptions are risks. They must be stated clearly and carried forward until validated.",
          "Mutation authority dictates what files or systems the agent is allowed to touch."
        ],
        "ambiguity": [
          "Stop inference if the human intent directly conflicts with system architecture or security doctrine."
        ],
        "decisions": [
          "Determine if the current context is sufficient to fulfill the intent, or if more queries are needed.",
          "Identify explicit negative constraints (what the user said NOT to do)."
        ],
        "standards": [
          "Never silently ignore a user constraint to force a simpler implementation.",
          "If intent drifts during execution, trigger explicit drift recovery to realign with the user.",
          "Document the chain of reasoning from raw intent to technical specification."
        ],
        "failure_modes": [
          "Hallucinating requirements that the user did not state, leading to scope creep.",
          "Treating examples in the prompt as binding architectural mandates without verification.",
          "Executing destructive operations based on ambiguous or poorly understood intent."
        ],
        "next_queries": [
          "Query core/ARCHITECTURE to map intent to specific subsystems.",
          "Query core/DEMANDS to check for overriding constraints."
        ],
        "proceed_when": [
          "Proceed when intent is unambiguous, constrained, and tied to verifiable acceptance criteria."
        ]
      }
    },
    "specs/SECURITY": {
      "id": "specs/SECURITY",
      "category": "specs",
      "title": "specs/SECURITY",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes binding authority, mutation risk, compatibility, and execution obligations for SECURITY.",
      "terms": [
        "modeling",
        "privilege",
        "least",
        "architecture",
        "chain",
        "response",
        "detection",
        "secure",
        "supply",
        "defaults",
        "security",
        "paths",
        "threat",
        "abuse"
      ],
      "links": {
        "references": [
          "architecture/AUTH",
          "architecture/ENCRYPTION",
          "architecture/SECRETS",
          "core/DEMANDS",
          "docs/SECURITY_THREAT_MODEL"
        ],
        "referenced_by": [
          "architecture/AUTH",
          "architecture/SECURITY",
          "core/DEMANDS",
          "docs/SECURITY_THREAT_MODEL"
        ]
      },
      "sections": {
        "match": [
          "Use when dealing with SECURITY system contracts, authority doctrine, or security rules."
        ],
        "concepts": [
          "Spec nodes define binding or promotion-relevant requirements.",
          "Spec constraints are stronger than methodology guides or local preferences."
        ],
        "ambiguity": [
          "Stop inference if the spec change creates an unresolvable authority conflict."
        ],
        "decisions": [
          "Determine if the requested change alters system boundaries or evaluation governance."
        ],
        "standards": [
          "Spec changes require compatibility reasoning, affected surfaces, and migration paths.",
          "State acceptance criteria in falsifiable, testable terms."
        ],
        "failure_modes": [
          "Silently changing doctrine, authority, security posture, or mutation rules.",
          "Bypassing a binding spec because a local implementation path is convenient."
        ],
        "next_queries": [
          "Query core/EMERGENCY_PROTOCOL if the spec dictates a halt to mutation under risk."
        ],
        "proceed_when": [
          "Proceed when the spec constraint has been fully integrated into the implementation plan."
        ]
      }
    },
    "specs/SYSTEM": {
      "id": "specs/SYSTEM",
      "category": "specs",
      "title": "specs/SYSTEM",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes binding authority, mutation risk, compatibility, and execution obligations for SYSTEM.",
      "terms": [
        "level",
        "invariants",
        "kernel",
        "promotion",
        "system",
        "hierarchy",
        "binding",
        "specification",
        "doctrine",
        "authority",
        "semantics"
      ],
      "links": {
        "references": [
          "core/DECAPOD",
          "core/DEMANDS",
          "interfaces/CLAIMS",
          "interfaces/CONTROL_PLANE",
          "specs/INTENT"
        ],
        "referenced_by": [
          "core/DEMANDS",
          "docs/ARCHITECTURE_OVERVIEW",
          "docs/README",
          "plugins/VERIFY",
          "specs/INTENT"
        ]
      },
      "sections": {
        "match": [
          "Use when dealing with SYSTEM system contracts, authority doctrine, or security rules."
        ],
        "concepts": [
          "Spec nodes define binding or promotion-relevant requirements.",
          "Spec constraints are stronger than methodology guides or local preferences."
        ],
        "ambiguity": [
          "Stop inference if the spec change creates an unresolvable authority conflict."
        ],
        "decisions": [
          "Determine if the requested change alters system boundaries or evaluation governance."
        ],
        "standards": [
          "Spec changes require compatibility reasoning, affected surfaces, and migration paths.",
          "State acceptance criteria in falsifiable, testable terms."
        ],
        "failure_modes": [
          "Silently changing doctrine, authority, security posture, or mutation rules.",
          "Bypassing a binding spec because a local implementation path is convenient."
        ],
        "next_queries": [
          "Query core/EMERGENCY_PROTOCOL if the spec dictates a halt to mutation under risk."
        ],
        "proceed_when": [
          "Proceed when the spec constraint has been fully integrated into the implementation plan."
        ]
      }
    },
    "specs/engineering/FRONTEND_BACKEND_E2E": {
      "id": "specs/engineering/FRONTEND_BACKEND_E2E",
      "category": "specs",
      "title": "specs/engineering/FRONTEND_BACKEND_E2E",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes binding authority, mutation risk, compatibility, and execution obligations for FRONTEND BACKEND E2E.",
      "terms": [
        "interaction",
        "proof",
        "frontend",
        "visible",
        "spec",
        "state",
        "behavior",
        "backend",
        "customer",
        "across"
      ],
      "links": {
        "references": [
          "core/DEMANDS"
        ],
        "referenced_by": [
          "core/DEMANDS"
        ]
      },
      "sections": {
        "match": [
          "Use when dealing with FRONTEND BACKEND E2E system contracts, authority doctrine, or security rules."
        ],
        "concepts": [
          "Spec nodes define binding or promotion-relevant requirements.",
          "Spec constraints are stronger than methodology guides or local preferences."
        ],
        "ambiguity": [
          "Stop inference if the spec change creates an unresolvable authority conflict."
        ],
        "decisions": [
          "Determine if the requested change alters system boundaries or evaluation governance."
        ],
        "standards": [
          "Spec changes require compatibility reasoning, affected surfaces, and migration paths.",
          "State acceptance criteria in falsifiable, testable terms."
        ],
        "failure_modes": [
          "Silently changing doctrine, authority, security posture, or mutation rules.",
          "Bypassing a binding spec because a local implementation path is convenient."
        ],
        "next_queries": [
          "Query core/EMERGENCY_PROTOCOL if the spec dictates a halt to mutation under risk."
        ],
        "proceed_when": [
          "Proceed when the spec constraint has been fully integrated into the implementation plan."
        ]
      }
    },
    "specs/evaluations/JUDGE_CONTRACT": {
      "id": "specs/evaluations/JUDGE_CONTRACT",
      "category": "specs",
      "title": "specs/evaluations/JUDGE_CONTRACT",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes binding authority, mutation risk, compatibility, and execution obligations for JUDGE CONTRACT.",
      "terms": [
        "evaluation",
        "contract",
        "outputs",
        "inputs",
        "judge",
        "criteria",
        "expected",
        "reproducibility",
        "variance",
        "scoring",
        "control"
      ],
      "links": {
        "references": [
          "core/DEMANDS"
        ],
        "referenced_by": [
          "core/DEMANDS",
          "docs/EVAL_TRANSLATION_MAP"
        ]
      },
      "sections": {
        "match": [
          "Use when dealing with JUDGE CONTRACT system contracts, authority doctrine, or security rules."
        ],
        "concepts": [
          "Spec nodes define binding or promotion-relevant requirements.",
          "Spec constraints are stronger than methodology guides or local preferences."
        ],
        "ambiguity": [
          "Stop inference if the spec change creates an unresolvable authority conflict."
        ],
        "decisions": [
          "Determine if the requested change alters system boundaries or evaluation governance."
        ],
        "standards": [
          "Spec changes require compatibility reasoning, affected surfaces, and migration paths.",
          "State acceptance criteria in falsifiable, testable terms."
        ],
        "failure_modes": [
          "Silently changing doctrine, authority, security posture, or mutation rules.",
          "Bypassing a binding spec because a local implementation path is convenient."
        ],
        "next_queries": [
          "Query core/EMERGENCY_PROTOCOL if the spec dictates a halt to mutation under risk."
        ],
        "proceed_when": [
          "Proceed when the spec constraint has been fully integrated into the implementation plan."
        ]
      }
    },
    "specs/evaluations/VARIANCE_EVALS": {
      "id": "specs/evaluations/VARIANCE_EVALS",
      "category": "specs",
      "title": "specs/evaluations/VARIANCE_EVALS",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes binding authority, mutation risk, compatibility, and execution obligations for VARIANCE EVALS.",
      "terms": [
        "evaluation",
        "confidence",
        "determinism",
        "measurement",
        "evals",
        "checks",
        "evaluations",
        "variance",
        "stability",
        "runs",
        "comparative"
      ],
      "links": {
        "references": [
          "core/DEMANDS"
        ],
        "referenced_by": [
          "core/DEMANDS",
          "docs/EVAL_TRANSLATION_MAP"
        ]
      },
      "sections": {
        "match": [
          "Use when dealing with VARIANCE EVALS system contracts, authority doctrine, or security rules."
        ],
        "concepts": [
          "Spec nodes define binding or promotion-relevant requirements.",
          "Spec constraints are stronger than methodology guides or local preferences."
        ],
        "ambiguity": [
          "Stop inference if the spec change creates an unresolvable authority conflict."
        ],
        "decisions": [
          "Determine if the requested change alters system boundaries or evaluation governance."
        ],
        "standards": [
          "Spec changes require compatibility reasoning, affected surfaces, and migration paths.",
          "State acceptance criteria in falsifiable, testable terms."
        ],
        "failure_modes": [
          "Silently changing doctrine, authority, security posture, or mutation rules.",
          "Bypassing a binding spec because a local implementation path is convenient."
        ],
        "next_queries": [
          "Query core/EMERGENCY_PROTOCOL if the spec dictates a halt to mutation under risk."
        ],
        "proceed_when": [
          "Proceed when the spec constraint has been fully integrated into the implementation plan."
        ]
      }
    },
    "specs/skills/SKILL_GOVERNANCE": {
      "id": "specs/skills/SKILL_GOVERNANCE",
      "category": "specs",
      "title": "specs/skills/SKILL_GOVERNANCE",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Describes binding authority, mutation risk, compatibility, and execution obligations for SKILL GOVERNANCE.",
      "terms": [
        "skill",
        "governance",
        "review",
        "reuse",
        "safe",
        "packaging",
        "authority",
        "invocation",
        "versioning"
      ],
      "links": {
        "references": [
          "core/DEMANDS"
        ],
        "referenced_by": [
          "core/DEMANDS",
          "docs/SKILL_TRANSLATION_MAP"
        ]
      },
      "sections": {
        "match": [
          "Use when dealing with SKILL GOVERNANCE system contracts, authority doctrine, or security rules."
        ],
        "concepts": [
          "Spec nodes define binding or promotion-relevant requirements.",
          "Spec constraints are stronger than methodology guides or local preferences."
        ],
        "ambiguity": [
          "Stop inference if the spec change creates an unresolvable authority conflict."
        ],
        "decisions": [
          "Determine if the requested change alters system boundaries or evaluation governance."
        ],
        "standards": [
          "Spec changes require compatibility reasoning, affected surfaces, and migration paths.",
          "State acceptance criteria in falsifiable, testable terms."
        ],
        "failure_modes": [
          "Silently changing doctrine, authority, security posture, or mutation rules.",
          "Bypassing a binding spec because a local implementation path is convenient."
        ],
        "next_queries": [
          "Query core/EMERGENCY_PROTOCOL if the spec dictates a halt to mutation under risk."
        ],
        "proceed_when": [
          "Proceed when the spec constraint has been fully integrated into the implementation plan."
        ]
      }
    },
    "core/DATA": {
      "id": "core/DATA",
      "category": "core",
      "title": "Data Discovery Surface",
      "authority": "namespace-router",
      "binding": "binding",
      "summary": "Route data modeling, databases, pipelines, caching, and state management intent into the appropriate data concepts before inference.",
      "terms": [
        "data",
        "database",
        "store",
        "cache",
        "pipeline",
        "state",
        "schema",
        "partitions"
      ],
      "links": {
        "references": [
          "data/DATABASE",
          "data/CACHING",
          "data/PIPELINES",
          "architecture/DISTRIBUTED_SYSTEMS"
        ],
        "referenced_by": [
          "core/DECAPOD"
        ]
      },
      "sections": {
        "match": [
          "Use when the task involves database schemas, caching layers, data pipelines, state management, or data migrations."
        ],
        "decide": [
          "Determine if the task alters persistent stores, ephemeral caches, or data transit layers."
        ],
        "route": [
          "databases, tables, schema, queries -> data/DATABASE.",
          "redis, memcached, ephemeral state -> data/CACHING.",
          "ETL, streaming, data lineage -> data/PIPELINES.",
          "partitions, consistency, consensus -> architecture/DISTRIBUTED_SYSTEMS."
        ],
        "apply": [
          "Carry data consistency, privacy, and retention constraints into implementation planning."
        ],
        "avoid": [
          "Do not mutate data schemas without verifying migration and rollback paths."
        ]
      }
    }
  },
  "lookup": {
    "decapod": [
      "core/DECAPOD",
      "docs/EVAL_TRANSLATION_MAP",
      "interfaces/INTERNALIZATION_SCHEMA",
      "interfaces/jsonschema/internalization/InternalizationAttachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationCreateResult.schema",
      "interfaces/jsonschema/internalization/InternalizationDetachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationInspectResult.schema",
      "interfaces/jsonschema/internalization/InternalizationManifest.schema"
    ],
    "root": [
      "core/DECAPOD"
    ],
    "router": [
      "core/DECAPOD"
    ],
    "intent": [
      "core/DECAPOD",
      "core/SPECS",
      "interfaces/PROJECT_SPECS",
      "specs/INTENT"
    ],
    "agent": [
      "core/DECAPOD",
      "architecture/KNOWLEDGE_BASE",
      "docs/CONTROL_PLANE_API",
      "docs/EVAL_TRANSLATION_MAP",
      "docs/SKILL_TRANSLATION_MAP",
      "interfaces/AGENT_CONTEXT_PACK",
      "interfaces/CONTROL_PLANE",
      "interfaces/DEMANDS_SCHEMA",
      "interfaces/DOC_RULES",
      "interfaces/GLOSSARY",
      "interfaces/PROCEDURAL_NORMS",
      "metadata/skills/AGENT_DECAPOD_INTERFACE"
    ],
    "app": [
      "core/DECAPOD",
      "core/ARCHITECTURE"
    ],
    "feature": [
      "core/DECAPOD"
    ],
    "system": [
      "core/DECAPOD",
      "core/SPECS",
      "architecture/ENTERPRISE",
      "architecture/SYSTEMS_DESIGN",
      "interfaces/ARCHITECTURE_FOUNDATIONS",
      "interfaces/PROJECT_SPECS",
      "methodology/RESEARCH_PRODUCTION",
      "plugins/HEALTH",
      "specs/SYSTEM"
    ],
    "service": [
      "core/DECAPOD",
      "architecture/MICROSERVICES",
      "architecture/NETWORKING"
    ],
    "scaffold": [
      "core/DECAPOD"
    ],
    "constitution": [
      "core/DECAPOD",
      "specs/AMENDMENTS"
    ],
    "pre-inference": [
      "core/DECAPOD"
    ],
    "ambiguous": [
      "core/DECAPOD"
    ],
    "architecture": [
      "core/ARCHITECTURE",
      "core/ENGINEERING_EXCELLENCE",
      "architecture/CI_CD_PIPELINES",
      "architecture/CLOUD",
      "architecture/COST_OPTIMIZATION",
      "data/PIPELINES",
      "data/DATABASE",
      "architecture/ENTERPRISE",
      "architecture/EVENT_DRIVEN",
      "architecture/FRONTEND",
      "architecture/GRAPHQL",
      "architecture/GRPC"
    ],
    "web": [
      "core/ARCHITECTURE"
    ],
    "frontend": [
      "core/ARCHITECTURE",
      "architecture/FRONTEND",
      "architecture/WEB",
      "specs/engineering/FRONTEND_BACKEND_E2E"
    ],
    "backend": [
      "core/ARCHITECTURE",
      "architecture/WEB",
      "specs/engineering/FRONTEND_BACKEND_E2E"
    ],
    "api": [
      "core/ARCHITECTURE"
    ],
    "data": [
      "core/ARCHITECTURE",
      "architecture/ALGORITHMS",
      "data/CACHING",
      "data/PIPELINES",
      "architecture/MICROSERVICES",
      "docs/MIGRATIONS"
    ],
    "auth": [
      "core/ARCHITECTURE",
      "architecture/AUTH"
    ],
    "security": [
      "core/ARCHITECTURE",
      "core/SPECS",
      "core/ENGINEERING_EXCELLENCE",
      "core/EMERGENCY_PROTOCOL",
      "architecture/ENTERPRISE",
      "architecture/FRONTEND",
      "architecture/SECURITY",
      "architecture/SYSTEMS_DESIGN",
      "architecture/TESTING_STRATEGY",
      "architecture/WEB",
      "docs/SECURITY_THREAT_MODEL",
      "specs/SECURITY"
    ],
    "kubernetes": [
      "core/ARCHITECTURE",
      "architecture/KUBERNETES"
    ],
    "cloud": [
      "core/ARCHITECTURE",
      "architecture/CLOUD"
    ],
    "scale": [
      "core/ARCHITECTURE"
    ],
    "performance": [
      "core/ARCHITECTURE",
      "data/DATABASE",
      "architecture/ENTERPRISE",
      "architecture/FRONTEND",
      "architecture/PERFORMANCE",
      "architecture/SYSTEMS_DESIGN",
      "architecture/WEB"
    ],
    "wasm": [
      "core/ARCHITECTURE"
    ],
    "react": [
      "core/ARCHITECTURE"
    ],
    "mobile": [
      "core/ARCHITECTURE"
    ],
    "docs": [
      "core/DOCS",
      "interfaces/DOC_RULES"
    ],
    "readme": [
      "core/DOCS",
      "docs/README",
      "interfaces/DOC_RULES"
    ],
    "documentation": [
      "core/DOCS",
      "docs/CONTROL_PLANE_API",
      "interfaces/DOC_RULES"
    ],
    "playbook": [
      "core/DOCS",
      "docs/PLAYBOOK"
    ],
    "guide": [
      "core/DOCS"
    ],
    "audit": [
      "core/DOCS",
      "architecture/SECRETS",
      "docs/GOVERNANCE_AUDIT",
      "plugins/ARCHIVE",
      "plugins/AUDIT",
      "specs/AMENDMENTS"
    ],
    "overview": [
      "core/DOCS",
      "docs/ARCHITECTURE_OVERVIEW"
    ],
    "maintainer": [
      "core/DOCS",
      "docs/MAINTAINERS"
    ],
    "usage": [
      "core/DOCS"
    ],
    "operator": [
      "core/DOCS",
      "docs/PLAYBOOK",
      "docs/SKILL_TRANSLATION_MAP"
    ],
    "interfaces": [
      "core/INTERFACES",
      "interfaces/ARCHITECTURE_FOUNDATIONS"
    ],
    "schema": [
      "core/INTERFACES",
      "data/DATABASE",
      "architecture/GRAPHQL",
      "docs/MIGRATIONS",
      "interfaces/DEMANDS_SCHEMA",
      "interfaces/INTERNALIZATION_SCHEMA",
      "interfaces/KNOWLEDGE_SCHEMA",
      "interfaces/MEMORY_SCHEMA",
      "interfaces/TODO_SCHEMA",
      "interfaces/jsonschema/internalization/InternalizationAttachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationCreateResult.schema",
      "interfaces/jsonschema/internalization/InternalizationDetachResult.schema"
    ],
    "contract": [
      "core/INTERFACES",
      "core/SPECS",
      "architecture/API_DESIGN",
      "architecture/TESTING_STRATEGY",
      "interfaces/CONTROL_PLANE",
      "interfaces/DEMANDS_SCHEMA",
      "interfaces/TESTING",
      "methodology/TESTING",
      "specs/evaluations/JUDGE_CONTRACT"
    ],
    "json": [
      "core/INTERFACES"
    ],
    "envelope": [
      "core/INTERFACES"
    ],
    "control-plane": [
      "core/INTERFACES"
    ],
    "store": [
      "core/INTERFACES",
      "interfaces/KNOWLEDGE_STORE",
      "interfaces/STORE_MODEL"
    ],
    "claims": [
      "core/INTERFACES",
      "interfaces/CLAIMS"
    ],
    "glossary": [
      "core/INTERFACES",
      "interfaces/GLOSSARY"
    ],
    "context-pack": [
      "core/INTERFACES"
    ],
    "todo-schema": [
      "core/INTERFACES"
    ],
    "methodology": [
      "core/METHODOLOGY",
      "methodology/ARCHITECTURE",
      "methodology/CI_CD",
      "methodology/ENGINEERING_MANAGEMENT",
      "methodology/INCIDENT_RESPONSE",
      "methodology/OPERATIONS",
      "methodology/PLATFORM",
      "methodology/PRODUCT",
      "methodology/RELEASE_MANAGEMENT",
      "methodology/RESEARCH",
      "methodology/RESEARCH_PRODUCTION",
      "methodology/SOUL"
    ],
    "practice": [
      "core/METHODOLOGY",
      "methodology/OPERATIONS"
    ],
    "process": [
      "core/METHODOLOGY",
      "docs/RELEASE_PROCESS"
    ],
    "how": [
      "core/METHODOLOGY"
    ],
    "testing": [
      "core/METHODOLOGY",
      "core/ENGINEERING_EXCELLENCE",
      "architecture/PERFORMANCE",
      "architecture/TESTING_STRATEGY",
      "interfaces/TESTING",
      "methodology/TESTING"
    ],
    "release": [
      "core/METHODOLOGY",
      "architecture/CI_CD_PIPELINES",
      "architecture/TESTING_STRATEGY",
      "docs/MAINTAINERS",
      "docs/RELEASE_PROCESS",
      "methodology/RELEASE_MANAGEMENT",
      "plugins/MANIFEST"
    ],
    "incident": [
      "core/METHODOLOGY",
      "methodology/INCIDENT_RESPONSE",
      "methodology/OPERATIONS",
      "plugins/EMERGENCY_PROTOCOL"
    ],
    "research": [
      "core/METHODOLOGY",
      "methodology/RESEARCH",
      "methodology/RESEARCH_PRODUCTION"
    ],
    "product": [
      "core/METHODOLOGY",
      "methodology/PRODUCT"
    ],
    "platform": [
      "core/METHODOLOGY",
      "methodology/PLATFORM"
    ],
    "operations": [
      "core/METHODOLOGY",
      "architecture/KUBERNETES",
      "docs/CONTROL_PLANE_API",
      "methodology/OPERATIONS",
      "plugins/CRON",
      "specs/DB_BROKER_QUEUE"
    ],
    "memory": [
      "core/METHODOLOGY",
      "architecture/MEMORY",
      "interfaces/MEMORY_INDEX",
      "interfaces/MEMORY_SCHEMA",
      "methodology/MEMORY"
    ],
    "knowledge": [
      "core/METHODOLOGY",
      "core/PLUGINS",
      "architecture/KNOWLEDGE_BASE",
      "interfaces/INTERNALIZATION_SCHEMA",
      "interfaces/KNOWLEDGE_SCHEMA",
      "interfaces/KNOWLEDGE_STORE",
      "interfaces/jsonschema/internalization/InternalizationAttachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationCreateResult.schema",
      "interfaces/jsonschema/internalization/InternalizationDetachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationInspectResult.schema",
      "interfaces/jsonschema/internalization/InternalizationManifest.schema",
      "methodology/KNOWLEDGE"
    ],
    "plugins": [
      "core/PLUGINS"
    ],
    "subsystem": [
      "core/PLUGINS",
      "methodology/KNOWLEDGE",
      "plugins/APTITUDE",
      "plugins/ARCHIVE",
      "plugins/AUDIT",
      "plugins/AUTOUPDATE",
      "plugins/CONTAINER",
      "plugins/CONTEXT",
      "plugins/CRON",
      "plugins/DB_BROKER",
      "plugins/DECIDE",
      "plugins/FEDERATION"
    ],
    "todo": [
      "core/PLUGINS",
      "interfaces/TODO_SCHEMA",
      "plugins/TODO"
    ],
    "validate": [
      "core/PLUGINS"
    ],
    "verify": [
      "core/PLUGINS",
      "architecture/CI_CD_PIPELINES",
      "plugins/VERIFY"
    ],
    "context": [
      "core/PLUGINS",
      "architecture/KNOWLEDGE_BASE",
      "architecture/MEMORY",
      "interfaces/AGENT_CONTEXT_PACK",
      "interfaces/LCM",
      "methodology/MEMORY",
      "plugins/CONTEXT"
    ],
    "container": [
      "core/PLUGINS",
      "plugins/CONTAINER"
    ],
    "health": [
      "core/PLUGINS",
      "methodology/ENGINEERING_MANAGEMENT",
      "plugins/HEALTH"
    ],
    "policy": [
      "core/PLUGINS",
      "architecture/COMPLIANCE",
      "architecture/SECRETS",
      "interfaces/RISK_POLICY_GATE",
      "plugins/POLICY"
    ],
    "watcher": [
      "core/PLUGINS",
      "plugins/WATCHER"
    ],
    "skill": [
      "core/PLUGINS",
      "docs/SKILL_TRANSLATION_MAP",
      "metadata/skills/BUNDLE",
      "metadata/skills/AGENT_DECAPOD_INTERFACE",
      "metadata/skills/HUMAN_AGENT_UX",
      "metadata/skills/INTENT_REFINEMENT",
      "plugins/APTITUDE",
      "specs/skills/SKILL_GOVERNANCE"
    ],
    "eval": [
      "core/PLUGINS",
      "docs/EVAL_TRANSLATION_MAP"
    ],
    "capsule": [
      "core/PLUGINS",
      "plugins/CONTEXT"
    ],
    "specs": [
      "core/SPECS",
      "interfaces/PROJECT_SPECS"
    ],
    "specification": [
      "core/SPECS",
      "specs/INTENT",
      "specs/SYSTEM"
    ],
    "git": [
      "core/SPECS"
    ],
    "amendment": [
      "core/SPECS"
    ],
    "evaluation": [
      "core/SPECS",
      "docs/EVAL_TRANSLATION_MAP",
      "specs/evaluations/JUDGE_CONTRACT",
      "specs/evaluations/VARIANCE_EVALS"
    ],
    "judge": [
      "core/SPECS",
      "specs/evaluations/JUDGE_CONTRACT"
    ],
    "governance": [
      "core/SPECS",
      "data/PIPELINES",
      "docs/ARCHITECTURE_OVERVIEW",
      "docs/GOVERNANCE_AUDIT",
      "docs/MAINTAINERS",
      "methodology/PLATFORM",
      "plugins/CRON",
      "specs/skills/SKILL_GOVERNANCE"
    ],
    "metadata": [
      "core/METADATA",
      "metadata/skills/BUNDLE",
      "plugins/MANIFEST"
    ],
    "skills": [
      "core/METADATA",
      "docs/SKILL_TRANSLATION_MAP"
    ],
    "taxonomy": [
      "core/METADATA"
    ],
    "card": [
      "core/METADATA"
    ],
    "label": [
      "core/METADATA"
    ],
    "tag": [
      "core/METADATA"
    ],
    "index": [
      "core/METADATA",
      "interfaces/MEMORY_INDEX"
    ],
    "classification": [
      "core/METADATA",
      "interfaces/RISK_POLICY_GATE"
    ],
    "corpus": [
      "core/METADATA"
    ],
    "retrieval-metadata": [
      "core/METADATA"
    ],
    "engineering": [
      "core/ENGINEERING_EXCELLENCE",
      "architecture/COMPLIANCE",
      "architecture/COST_OPTIMIZATION",
      "architecture/INFRASTRUCTURE",
      "architecture/PERFORMANCE",
      "methodology/ARCHITECTURE",
      "methodology/CI_CD",
      "methodology/ENGINEERING_MANAGEMENT",
      "methodology/INCIDENT_RESPONSE",
      "methodology/RELEASE_MANAGEMENT",
      "methodology/SOUL"
    ],
    "quality": [
      "core/ENGINEERING_EXCELLENCE",
      "data/PIPELINES"
    ],
    "standards": [
      "core/ENGINEERING_EXCELLENCE",
      "architecture/CODING_STANDARDS"
    ],
    "maintainability": [
      "core/ENGINEERING_EXCELLENCE",
      "architecture/CODING_STANDARDS"
    ],
    "production": [
      "core/ENGINEERING_EXCELLENCE",
      "architecture/ENTERPRISE",
      "architecture/SYSTEMS_DESIGN",
      "interfaces/ARCHITECTURE_FOUNDATIONS",
      "methodology/RESEARCH_PRODUCTION"
    ],
    "operability": [
      "core/ENGINEERING_EXCELLENCE",
      "architecture/ENTERPRISE",
      "architecture/MICROSERVICES",
      "architecture/SYSTEMS_DESIGN"
    ],
    "resilience": [
      "core/ENGINEERING_EXCELLENCE",
      "architecture/CLOUD"
    ],
    "customer trust": [
      "core/ENGINEERING_EXCELLENCE"
    ],
    "gap": [
      "core/GAPS"
    ],
    "missing": [
      "core/GAPS",
      "docs/NEGLECTED_ASPECTS_LEDGER"
    ],
    "drift": [
      "core/GAPS",
      "architecture/INFRASTRUCTURE"
    ],
    "unclear": [
      "core/GAPS"
    ],
    "blocker": [
      "core/GAPS"
    ],
    "risk": [
      "core/GAPS",
      "docs/SECURITY_THREAT_MODEL",
      "interfaces/RISK_POLICY_GATE"
    ],
    "deficiency": [
      "core/GAPS"
    ],
    "unknown": [
      "core/GAPS"
    ],
    "contradiction": [
      "core/GAPS"
    ],
    "proof gap": [
      "core/GAPS"
    ],
    "methodology vacuum": [
      "core/GAPS"
    ],
    "demand": [
      "core/DEMANDS",
      "architecture/SCALING",
      "plugins/CONTAINER"
    ],
    "constraint": [
      "core/DEMANDS"
    ],
    "requirement": [
      "core/DEMANDS"
    ],
    "must": [
      "core/DEMANDS"
    ],
    "must not": [
      "core/DEMANDS"
    ],
    "non-negotiable": [
      "core/DEMANDS"
    ],
    "precedence": [
      "core/DEMANDS"
    ],
    "user demand": [
      "core/DEMANDS"
    ],
    "override": [
      "core/DEMANDS"
    ],
    "intent constraint": [
      "core/DEMANDS"
    ],
    "deprecation": [
      "core/DEPRECATION"
    ],
    "deprecated": [
      "core/DEPRECATION"
    ],
    "sunset": [
      "core/DEPRECATION"
    ],
    "migration": [
      "core/DEPRECATION",
      "docs/MIGRATIONS"
    ],
    "replacement": [
      "core/DEPRECATION"
    ],
    "compatibility": [
      "core/DEPRECATION",
      "architecture/API_DESIGN",
      "architecture/GRPC",
      "docs/MIGRATIONS",
      "plugins/AUTOUPDATE"
    ],
    "retire": [
      "core/DEPRECATION"
    ],
    "remove": [
      "core/DEPRECATION"
    ],
    "legacy": [
      "core/DEPRECATION"
    ],
    "breaking change": [
      "core/DEPRECATION"
    ],
    "emergency": [
      "core/EMERGENCY_PROTOCOL",
      "plugins/EMERGENCY_PROTOCOL"
    ],
    "stop": [
      "core/EMERGENCY_PROTOCOL"
    ],
    "halt": [
      "core/EMERGENCY_PROTOCOL"
    ],
    "break-glass": [
      "core/EMERGENCY_PROTOCOL"
    ],
    "escalate": [
      "core/EMERGENCY_PROTOCOL"
    ],
    "contain": [
      "core/EMERGENCY_PROTOCOL"
    ],
    "rollback": [
      "core/EMERGENCY_PROTOCOL",
      "architecture/CI_CD_PIPELINES",
      "docs/MIGRATIONS",
      "docs/RELEASE_PROCESS",
      "plugins/AUTOUPDATE",
      "plugins/EMERGENCY_PROTOCOL"
    ],
    "data loss": [
      "core/EMERGENCY_PROTOCOL"
    ],
    "authority conflict": [
      "core/EMERGENCY_PROTOCOL"
    ],
    "unsafe": [
      "core/EMERGENCY_PROTOCOL"
    ],
    "complexity": [
      "architecture/ALGORITHMS",
      "architecture/GRAPHQL"
    ],
    "profiles": [
      "architecture/ALGORITHMS"
    ],
    "determinism": [
      "architecture/ALGORITHMS",
      "specs/evaluations/VARIANCE_EVALS"
    ],
    "bounded": [
      "architecture/ALGORITHMS",
      "architecture/CONCURRENCY",
      "interfaces/AGENT_CONTEXT_PACK",
      "plugins/CRON",
      "plugins/REFLEX",
      "plugins/WATCHER"
    ],
    "resource": [
      "architecture/ALGORITHMS",
      "architecture/AUTH",
      "architecture/CONTAINERS"
    ],
    "behavior": [
      "architecture/ALGORITHMS",
      "specs/engineering/FRONTEND_BACKEND_E2E"
    ],
    "algorithmic": [
      "architecture/ALGORITHMS"
    ],
    "judgment": [
      "architecture/ALGORITHMS"
    ],
    "selection": [
      "architecture/ALGORITHMS"
    ],
    "structures": [
      "architecture/ALGORITHMS"
    ],
    "algorithms": [
      "architecture/ALGORITHMS"
    ],
    "locality": [
      "architecture/ALGORITHMS",
      "architecture/MEMORY",
      "methodology/MEMORY"
    ],
    "graphql": [
      "architecture/API_DESIGN",
      "architecture/GRAPHQL"
    ],
    "pagination": [
      "architecture/API_DESIGN"
    ],
    "codes": [
      "architecture/API_DESIGN",
      "architecture/GRPC"
    ],
    "rest": [
      "architecture/API_DESIGN",
      "architecture/ENCRYPTION"
    ],
    "design": [
      "architecture/API_DESIGN",
      "data/DATABASE",
      "architecture/ENTERPRISE",
      "architecture/GRAPHQL",
      "architecture/SYSTEMS_DESIGN",
      "architecture/UI",
      "interfaces/ARCHITECTURE_FOUNDATIONS",
      "methodology/PLATFORM"
    ],
    "idempotency": [
      "architecture/API_DESIGN",
      "architecture/DISTRIBUTED_SYSTEMS"
    ],
    "versioning": [
      "architecture/API_DESIGN",
      "docs/RELEASE_PROCESS",
      "specs/skills/SKILL_GOVERNANCE"
    ],
    "schemas": [
      "architecture/API_DESIGN",
      "architecture/EVENT_DRIVEN",
      "interfaces/DEMANDS_SCHEMA"
    ],
    "status": [
      "architecture/API_DESIGN",
      "architecture/GRPC",
      "interfaces/CLAIMS",
      "specs/GIT"
    ],
    "grpc": [
      "architecture/API_DESIGN",
      "architecture/GRPC"
    ],
    "authorization": [
      "architecture/AUTH",
      "architecture/GRAPHQL"
    ],
    "identity": [
      "architecture/AUTH",
      "architecture/INFRASTRUCTURE",
      "plugins/TRUST"
    ],
    "level": [
      "architecture/AUTH",
      "specs/SYSTEM"
    ],
    "sessions": [
      "architecture/AUTH",
      "architecture/WEB"
    ],
    "proof": [
      "architecture/AUTH",
      "docs/GOVERNANCE_AUDIT",
      "docs/README",
      "interfaces/CLAIMS",
      "interfaces/PLAN_GOVERNED_EXECUTION",
      "interfaces/PROJECT_SPECS",
      "interfaces/TESTING",
      "methodology/TESTING",
      "plugins/VERIFY",
      "specs/engineering/FRONTEND_BACKEND_E2E"
    ],
    "delegation": [
      "architecture/AUTH"
    ],
    "authentication": [
      "architecture/AUTH"
    ],
    "tokens": [
      "architecture/AUTH"
    ],
    "access": [
      "architecture/AUTH",
      "architecture/SECRETS",
      "plugins/DB_BROKER"
    ],
    "keys": [
      "architecture/AUTH"
    ],
    "mtls": [
      "architecture/AUTH",
      "architecture/GRPC"
    ],
    "control": [
      "architecture/AUTH",
      "architecture/COMPLIANCE",
      "architecture/CONCURRENCY",
      "docs/CONTROL_PLANE_API",
      "interfaces/CONTROL_PLANE",
      "specs/evaluations/JUDGE_CONTRACT"
    ],
    "tiers": [
      "data/CACHING"
    ],
    "stale": [
      "data/CACHING",
      "plugins/HEARTBEAT"
    ],
    "observability": [
      "data/CACHING",
      "architecture/OBSERVABILITY"
    ],
    "prevention": [
      "data/CACHING",
      "architecture/CONCURRENCY",
      "architecture/SECRETS"
    ],
    "stampede": [
      "data/CACHING"
    ],
    "replicated": [
      "data/CACHING"
    ],
    "invalidation": [
      "data/CACHING"
    ],
    "caching": [
      "data/CACHING",
      "architecture/MEMORY",
      "architecture/WEB",
      "methodology/MEMORY"
    ],
    "cache": [
      "data/CACHING"
    ],
    "tolerance": [
      "data/CACHING"
    ],
    "state": [
      "data/CACHING",
      "architecture/FRONTEND",
      "architecture/UI",
      "interfaces/INTERNALIZATION_SCHEMA",
      "interfaces/STORE_MODEL",
      "interfaces/jsonschema/internalization/InternalizationAttachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationCreateResult.schema",
      "interfaces/jsonschema/internalization/InternalizationDetachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationInspectResult.schema",
      "interfaces/jsonschema/internalization/InternalizationManifest.schema",
      "plugins/DB_BROKER",
      "plugins/FEDERATION"
    ],
    "sign": [
      "architecture/CI_CD_PIPELINES"
    ],
    "source": [
      "architecture/CI_CD_PIPELINES",
      "methodology/RESEARCH"
    ],
    "delivery": [
      "architecture/CI_CD_PIPELINES",
      "architecture/COMPLIANCE",
      "architecture/MESSAGING",
      "architecture/WEB",
      "interfaces/PROJECT_SPECS",
      "methodology/ARCHITECTURE",
      "methodology/CI_CD",
      "methodology/ENGINEERING_MANAGEMENT",
      "methodology/INCIDENT_RESPONSE",
      "methodology/PRODUCT",
      "methodology/RELEASE_MANAGEMENT",
      "methodology/SOUL"
    ],
    "validation": [
      "architecture/CI_CD_PIPELINES",
      "architecture/DR",
      "docs/RELEASE_PROCESS",
      "docs/SECURITY_THREAT_MODEL",
      "interfaces/TESTING",
      "methodology/RESEARCH_PRODUCTION",
      "methodology/TESTING",
      "plugins/VERIFY"
    ],
    "evidence": [
      "architecture/CI_CD_PIPELINES",
      "architecture/COMPLIANCE",
      "docs/MIGRATIONS",
      "interfaces/CLAIMS",
      "interfaces/TESTING",
      "methodology/RESEARCH",
      "methodology/TESTING",
      "plugins/AUDIT",
      "plugins/TRUST",
      "plugins/VERIFY"
    ],
    "pipeline": [
      "architecture/CI_CD_PIPELINES"
    ],
    "pipelines": [
      "architecture/CI_CD_PIPELINES",
      "data/PIPELINES"
    ],
    "scan": [
      "architecture/CI_CD_PIPELINES"
    ],
    "package": [
      "architecture/CI_CD_PIPELINES"
    ],
    "deploy": [
      "architecture/CI_CD_PIPELINES"
    ],
    "test": [
      "architecture/CI_CD_PIPELINES",
      "interfaces/TESTING",
      "methodology/TESTING",
      "plugins/CONTAINER"
    ],
    "build": [
      "architecture/CI_CD_PIPELINES",
      "plugins/CONTAINER"
    ],
    "services": [
      "architecture/CLOUD",
      "architecture/KUBERNETES"
    ],
    "cost": [
      "architecture/CLOUD",
      "architecture/COST_OPTIMIZATION"
    ],
    "recovery": [
      "architecture/CLOUD",
      "architecture/DR"
    ],
    "network": [
      "architecture/CLOUD",
      "architecture/NETWORKING"
    ],
    "infrastructure": [
      "architecture/CLOUD",
      "architecture/INFRASTRUCTURE"
    ],
    "posture": [
      "architecture/CLOUD",
      "docs/ARCHITECTURE_OVERVIEW",
      "methodology/OPERATIONS"
    ],
    "managed": [
      "architecture/CLOUD"
    ],
    "deployment": [
      "architecture/CLOUD",
      "architecture/MICROSERVICES",
      "interfaces/RISK_POLICY_GATE"
    ],
    "topology": [
      "architecture/CLOUD"
    ],
    "elasticity": [
      "architecture/CLOUD"
    ],
    "coding": [
      "architecture/CODING_STANDARDS"
    ],
    "readability": [
      "architecture/CODING_STANDARDS"
    ],
    "implementation": [
      "architecture/CODING_STANDARDS"
    ],
    "refactoring": [
      "architecture/CODING_STANDARDS"
    ],
    "cohesion": [
      "architecture/CODING_STANDARDS"
    ],
    "modularity": [
      "architecture/CODING_STANDARDS"
    ],
    "durable": [
      "architecture/CODING_STANDARDS"
    ],
    "naming": [
      "architecture/CODING_STANDARDS"
    ],
    "coupling": [
      "architecture/CODING_STANDARDS"
    ],
    "discipline": [
      "architecture/CODING_STANDARDS",
      "docs/MIGRATIONS",
      "interfaces/PROCEDURAL_NORMS"
    ],
    "capture": [
      "architecture/COMPLIANCE",
      "architecture/KNOWLEDGE_BASE",
      "methodology/KNOWLEDGE",
      "plugins/DECIDE",
      "plugins/FEEDBACK",
      "plugins/KNOWLEDGE",
      "specs/INTENT"
    ],
    "auditability": [
      "architecture/COMPLIANCE"
    ],
    "constraints": [
      "architecture/COMPLIANCE",
      "architecture/WEB",
      "interfaces/MEMORY_SCHEMA",
      "metadata/skills/AGENT_DECAPOD_INTERFACE",
      "metadata/skills/HUMAN_AGENT_UX",
      "metadata/skills/INTENT_REFINEMENT",
      "methodology/RESEARCH_PRODUCTION",
      "plugins/POLICY",
      "specs/INTENT"
    ],
    "compliance": [
      "architecture/COMPLIANCE"
    ],
    "retention": [
      "architecture/COMPLIANCE",
      "data/PIPELINES",
      "plugins/ARCHIVE"
    ],
    "regulated": [
      "architecture/COMPLIANCE"
    ],
    "enforcement": [
      "architecture/COMPLIANCE",
      "interfaces/RISK_POLICY_GATE",
      "plugins/CONTEXT",
      "plugins/POLICY",
      "plugins/TRUST"
    ],
    "mapping": [
      "architecture/COMPLIANCE",
      "docs/EVAL_TRANSLATION_MAP",
      "docs/SKILL_TRANSLATION_MAP",
      "interfaces/CLAIMS",
      "interfaces/TESTING",
      "methodology/TESTING"
    ],
    "execution": [
      "architecture/CONCURRENCY",
      "architecture/CONTAINERS",
      "docs/ARCHITECTURE_OVERVIEW",
      "docs/PLAYBOOK",
      "interfaces/PLAN_GOVERNED_EXECUTION",
      "metadata/skills/AGENT_DECAPOD_INTERFACE",
      "metadata/skills/HUMAN_AGENT_UX",
      "metadata/skills/INTENT_REFINEMENT",
      "methodology/ENGINEERING_MANAGEMENT",
      "plugins/CONTAINER",
      "plugins/CRON",
      "plugins/VERIFY"
    ],
    "race": [
      "architecture/CONCURRENCY"
    ],
    "locks": [
      "architecture/CONCURRENCY",
      "interfaces/CONTROL_PLANE"
    ],
    "coordination": [
      "architecture/CONCURRENCY",
      "architecture/DISTRIBUTED_SYSTEMS"
    ],
    "liveness": [
      "architecture/CONCURRENCY",
      "interfaces/CONTROL_PLANE",
      "interfaces/TODO_SCHEMA",
      "plugins/HEALTH",
      "plugins/HEARTBEAT"
    ],
    "deterministic": [
      "architecture/CONCURRENCY",
      "interfaces/LCM"
    ],
    "async": [
      "architecture/CONCURRENCY"
    ],
    "parallelism": [
      "architecture/CONCURRENCY"
    ],
    "queues": [
      "architecture/CONCURRENCY",
      "architecture/EVENT_DRIVEN",
      "architecture/MESSAGING"
    ],
    "threads": [
      "architecture/CONCURRENCY"
    ],
    "concurrency": [
      "architecture/CONCURRENCY"
    ],
    "chain": [
      "architecture/CONTAINERS",
      "architecture/SECURITY",
      "specs/SECURITY"
    ],
    "construction": [
      "architecture/CONTAINERS"
    ],
    "containerization": [
      "architecture/CONTAINERS"
    ],
    "isolation": [
      "architecture/CONTAINERS",
      "architecture/DISTRIBUTED_SYSTEMS",
      "architecture/MICROSERVICES",
      "plugins/CONTAINER",
      "specs/DB_BROKER_QUEUE"
    ],
    "image": [
      "architecture/CONTAINERS"
    ],
    "supply": [
      "architecture/CONTAINERS",
      "architecture/SECURITY",
      "specs/SECURITY"
    ],
    "sandboxed": [
      "architecture/CONTAINERS"
    ],
    "limits": [
      "architecture/CONTAINERS",
      "docs/MIGRATIONS"
    ],
    "runtime": [
      "architecture/CONTAINERS",
      "docs/ARCHITECTURE_OVERVIEW"
    ],
    "reproducibility": [
      "architecture/CONTAINERS",
      "specs/evaluations/JUDGE_CONTRACT"
    ],
    "registries": [
      "architecture/CONTAINERS"
    ],
    "containers": [
      "architecture/CONTAINERS"
    ],
    "unit": [
      "architecture/COST_OPTIMIZATION",
      "architecture/TESTING_STRATEGY"
    ],
    "economics": [
      "architecture/COST_OPTIMIZATION"
    ],
    "detection": [
      "architecture/COST_OPTIMIZATION",
      "architecture/SECURITY",
      "plugins/HEALTH",
      "plugins/HEARTBEAT",
      "plugins/WATCHER",
      "specs/SECURITY"
    ],
    "planning": [
      "architecture/COST_OPTIMIZATION",
      "architecture/DR"
    ],
    "aware": [
      "architecture/COST_OPTIMIZATION"
    ],
    "capacity": [
      "architecture/COST_OPTIMIZATION",
      "architecture/PERFORMANCE",
      "architecture/SCALING"
    ],
    "budget": [
      "architecture/COST_OPTIMIZATION"
    ],
    "guardrails": [
      "architecture/COST_OPTIMIZATION"
    ],
    "sizing": [
      "architecture/COST_OPTIMIZATION"
    ],
    "waste": [
      "architecture/COST_OPTIMIZATION"
    ],
    "right": [
      "architecture/COST_OPTIMIZATION"
    ],
    "optimization": [
      "architecture/COST_OPTIMIZATION"
    ],
    "modeling": [
      "data/PIPELINES",
      "architecture/SECURITY",
      "specs/SECURITY"
    ],
    "privacy": [
      "data/PIPELINES"
    ],
    "analytical": [
      "data/PIPELINES"
    ],
    "ownership": [
      "data/PIPELINES",
      "architecture/INFRASTRUCTURE",
      "architecture/MICROSERVICES",
      "docs/MAINTAINERS",
      "interfaces/TODO_SCHEMA",
      "methodology/OPERATIONS",
      "plugins/TODO"
    ],
    "lineage": [
      "data/PIPELINES"
    ],
    "separation": [
      "data/PIPELINES",
      "architecture/MEMORY",
      "methodology/MEMORY"
    ],
    "operational": [
      "data/PIPELINES",
      "data/DATABASE",
      "architecture/INFRASTRUCTURE",
      "architecture/KUBERNETES",
      "architecture/METRICS",
      "docs/MIGRATIONS",
      "docs/PLAYBOOK",
      "interfaces/STORE_MODEL",
      "methodology/METRICS",
      "plugins/HEALTH"
    ],
    "database": [
      "data/DATABASE",
      "plugins/DB_BROKER",
      "specs/DB_BROKER_QUEUE"
    ],
    "consistency": [
      "data/DATABASE",
      "architecture/DISTRIBUTED_SYSTEMS",
      "architecture/EVENT_DRIVEN",
      "interfaces/GLOSSARY"
    ],
    "transactions": [
      "data/DATABASE"
    ],
    "indexing": [
      "data/DATABASE",
      "interfaces/KNOWLEDGE_STORE",
      "interfaces/MEMORY_SCHEMA",
      "methodology/KNOWLEDGE",
      "plugins/KNOWLEDGE"
    ],
    "backups": [
      "data/DATABASE"
    ],
    "replication": [
      "data/DATABASE"
    ],
    "safety": [
      "data/DATABASE",
      "docs/MIGRATIONS",
      "specs/GIT"
    ],
    "migrations": [
      "data/DATABASE",
      "docs/MIGRATIONS"
    ],
    "retries": [
      "architecture/DISTRIBUTED_SYSTEMS",
      "architecture/MESSAGING"
    ],
    "consensus": [
      "architecture/DISTRIBUTED_SYSTEMS"
    ],
    "ordering": [
      "architecture/DISTRIBUTED_SYSTEMS",
      "architecture/EVENT_DRIVEN",
      "architecture/MESSAGING",
      "docs/GOVERNANCE_AUDIT",
      "specs/DB_BROKER_QUEUE"
    ],
    "failure": [
      "architecture/DISTRIBUTED_SYSTEMS",
      "architecture/DR",
      "architecture/MICROSERVICES",
      "interfaces/ARCHITECTURE_FOUNDATIONS",
      "specs/DB_BROKER_QUEUE"
    ],
    "distributed": [
      "architecture/DISTRIBUTED_SYSTEMS"
    ],
    "systems": [
      "architecture/DISTRIBUTED_SYSTEMS",
      "architecture/MEMORY",
      "architecture/MESSAGING",
      "architecture/SYSTEMS_DESIGN",
      "methodology/ARCHITECTURE",
      "methodology/CI_CD",
      "methodology/INCIDENT_RESPONSE",
      "methodology/MEMORY",
      "methodology/RELEASE_MANAGEMENT",
      "methodology/SOUL"
    ],
    "eventual": [
      "architecture/DISTRIBUTED_SYSTEMS",
      "architecture/EVENT_DRIVEN"
    ],
    "partitions": [
      "architecture/DISTRIBUTED_SYSTEMS"
    ],
    "failover": [
      "architecture/DR"
    ],
    "regional": [
      "architecture/DR"
    ],
    "disaster": [
      "architecture/DR"
    ],
    "backup": [
      "architecture/DR"
    ],
    "runbooks": [
      "architecture/DR",
      "docs/PLAYBOOK",
      "methodology/OPERATIONS"
    ],
    "restore": [
      "architecture/DR"
    ],
    "misuse": [
      "architecture/ENCRYPTION"
    ],
    "encryption": [
      "architecture/ENCRYPTION"
    ],
    "boundaries": [
      "architecture/ENCRYPTION",
      "architecture/FRONTEND",
      "architecture/KUBERNETES",
      "architecture/MEMORY",
      "architecture/MICROSERVICES",
      "docs/ARCHITECTURE_OVERVIEW",
      "docs/SECURITY_THREAT_MODEL",
      "docs/SKILL_TRANSLATION_MAP",
      "interfaces/ARCHITECTURE_FOUNDATIONS",
      "interfaces/DEMANDS_SCHEMA",
      "interfaces/DOC_RULES",
      "interfaces/GLOSSARY"
    ],
    "resistant": [
      "architecture/ENCRYPTION"
    ],
    "secrets": [
      "architecture/ENCRYPTION",
      "architecture/KUBERNETES",
      "architecture/SECRETS"
    ],
    "protection": [
      "architecture/ENCRYPTION"
    ],
    "rotation": [
      "architecture/ENCRYPTION",
      "architecture/SECRETS"
    ],
    "primitives": [
      "architecture/ENCRYPTION"
    ],
    "management": [
      "architecture/ENCRYPTION",
      "architecture/INFRASTRUCTURE",
      "architecture/SECRETS",
      "interfaces/LCM",
      "methodology/ENGINEERING_MANAGEMENT",
      "methodology/OPERATIONS",
      "methodology/RELEASE_MANAGEMENT"
    ],
    "cryptographic": [
      "architecture/ENCRYPTION"
    ],
    "custody": [
      "architecture/ENCRYPTION",
      "architecture/SECRETS"
    ],
    "that": [
      "architecture/ENTERPRISE",
      "architecture/SYSTEMS_DESIGN"
    ],
    "enterprise": [
      "architecture/ENTERPRISE"
    ],
    "correctness": [
      "architecture/ENTERPRISE",
      "architecture/SYSTEMS_DESIGN"
    ],
    "affect": [
      "architecture/ENTERPRISE",
      "architecture/SYSTEMS_DESIGN"
    ],
    "customer": [
      "architecture/ENTERPRISE",
      "architecture/OBSERVABILITY",
      "architecture/SYSTEMS_DESIGN",
      "architecture/UI",
      "docs/RELEASE_PROCESS",
      "methodology/PRODUCT",
      "specs/engineering/FRONTEND_BACKEND_E2E"
    ],
    "trust": [
      "architecture/ENTERPRISE",
      "architecture/SYSTEMS_DESIGN",
      "architecture/UI",
      "docs/SECURITY_THREAT_MODEL",
      "plugins/FEDERATION",
      "plugins/TRUST"
    ],
    "decisions": [
      "architecture/ENTERPRISE",
      "architecture/SYSTEMS_DESIGN",
      "methodology/ARCHITECTURE",
      "methodology/CI_CD",
      "methodology/INCIDENT_RESPONSE",
      "methodology/RELEASE_MANAGEMENT",
      "methodology/SOUL",
      "plugins/POLICY"
    ],
    "consumers": [
      "architecture/EVENT_DRIVEN"
    ],
    "backpressure": [
      "architecture/EVENT_DRIVEN",
      "architecture/MESSAGING"
    ],
    "idempotent": [
      "architecture/EVENT_DRIVEN"
    ],
    "events": [
      "architecture/EVENT_DRIVEN",
      "architecture/OBSERVABILITY",
      "plugins/AUDIT"
    ],
    "streams": [
      "architecture/EVENT_DRIVEN"
    ],
    "event": [
      "architecture/EVENT_DRIVEN",
      "plugins/TODO",
      "plugins/WATCHER"
    ],
    "replay": [
      "architecture/EVENT_DRIVEN"
    ],
    "driven": [
      "architecture/EVENT_DRIVEN",
      "architecture/SCALING",
      "docs/GOVERNANCE_AUDIT"
    ],
    "error": [
      "architecture/FRONTEND",
      "architecture/GRAPHQL",
      "architecture/UI"
    ],
    "rendering": [
      "architecture/FRONTEND"
    ],
    "client": [
      "architecture/FRONTEND",
      "architecture/GRAPHQL"
    ],
    "user": [
      "architecture/FRONTEND",
      "architecture/PERFORMANCE",
      "architecture/UI"
    ],
    "facing": [
      "architecture/FRONTEND",
      "architecture/UI"
    ],
    "contracts": [
      "architecture/FRONTEND",
      "architecture/GRAPHQL",
      "architecture/GRPC",
      "architecture/WEB",
      "interfaces/DEMANDS_SCHEMA"
    ],
    "accessibility": [
      "architecture/FRONTEND",
      "architecture/UI"
    ],
    "reliability": [
      "architecture/FRONTEND",
      "methodology/OPERATIONS"
    ],
    "federation": [
      "architecture/GRAPHQL",
      "plugins/FEDERATION"
    ],
    "shape": [
      "architecture/GRAPHQL",
      "interfaces/KNOWLEDGE_SCHEMA",
      "interfaces/MEMORY_SCHEMA"
    ],
    "batching": [
      "architecture/GRAPHQL"
    ],
    "query": [
      "architecture/GRAPHQL"
    ],
    "resolvers": [
      "architecture/GRAPHQL"
    ],
    "rpcs": [
      "architecture/GRPC"
    ],
    "generated": [
      "architecture/GRPC",
      "interfaces/DOC_RULES"
    ],
    "proto": [
      "architecture/GRPC"
    ],
    "clients": [
      "architecture/GRPC"
    ],
    "streaming": [
      "architecture/GRPC"
    ],
    "deadlines": [
      "architecture/GRPC"
    ],
    "unary": [
      "architecture/GRPC"
    ],
    "promotion": [
      "architecture/INFRASTRUCTURE",
      "specs/GIT",
      "specs/SYSTEM"
    ],
    "storage": [
      "architecture/INFRASTRUCTURE",
      "architecture/SECRETS",
      "docs/ARCHITECTURE_OVERVIEW",
      "plugins/ARCHIVE",
      "plugins/DB_BROKER"
    ],
    "environments": [
      "architecture/INFRASTRUCTURE"
    ],
    "compute": [
      "architecture/INFRASTRUCTURE"
    ],
    "networks": [
      "architecture/INFRASTRUCTURE"
    ],
    "consumable": [
      "architecture/KNOWLEDGE_BASE"
    ],
    "retrieval": [
      "architecture/KNOWLEDGE_BASE",
      "interfaces/AGENT_CONTEXT_PACK",
      "interfaces/KNOWLEDGE_STORE",
      "interfaces/LCM",
      "interfaces/MEMORY_INDEX",
      "methodology/KNOWLEDGE",
      "plugins/CONTEXT",
      "plugins/KNOWLEDGE"
    ],
    "summaries": [
      "architecture/KNOWLEDGE_BASE"
    ],
    "provenance": [
      "architecture/KNOWLEDGE_BASE",
      "interfaces/KNOWLEDGE_SCHEMA",
      "interfaces/KNOWLEDGE_STORE",
      "interfaces/MEMORY_SCHEMA",
      "interfaces/STORE_MODEL",
      "methodology/KNOWLEDGE",
      "plugins/ARCHIVE",
      "plugins/FEDERATION",
      "plugins/KNOWLEDGE",
      "plugins/MANIFEST",
      "plugins/TRUST",
      "specs/GIT"
    ],
    "organization": [
      "architecture/KNOWLEDGE_BASE"
    ],
    "concepts": [
      "architecture/KNOWLEDGE_BASE",
      "docs/EVAL_TRANSLATION_MAP"
    ],
    "base": [
      "architecture/KNOWLEDGE_BASE"
    ],
    "relationships": [
      "architecture/KNOWLEDGE_BASE",
      "interfaces/KNOWLEDGE_SCHEMA"
    ],
    "rollout": [
      "architecture/KUBERNETES",
      "plugins/AUTOUPDATE"
    ],
    "workloads": [
      "architecture/KUBERNETES"
    ],
    "ingress": [
      "architecture/KUBERNETES",
      "architecture/NETWORKING"
    ],
    "scheduling": [
      "architecture/KUBERNETES"
    ],
    "rbac": [
      "architecture/KUBERNETES"
    ],
    "strategy": [
      "architecture/KUBERNETES",
      "architecture/TESTING_STRATEGY"
    ],
    "probes": [
      "architecture/KUBERNETES"
    ],
    "cluster": [
      "architecture/KUBERNETES"
    ],
    "allocation": [
      "architecture/MEMORY",
      "methodology/MEMORY"
    ],
    "persistence": [
      "architecture/MEMORY",
      "interfaces/KNOWLEDGE_STORE",
      "methodology/MEMORY"
    ],
    "pressure": [
      "architecture/MEMORY",
      "methodology/MEMORY"
    ],
    "leaks": [
      "architecture/MEMORY",
      "methodology/MEMORY"
    ],
    "object": [
      "architecture/MEMORY",
      "interfaces/KNOWLEDGE_SCHEMA",
      "methodology/MEMORY"
    ],
    "lifetimes": [
      "architecture/MEMORY",
      "methodology/MEMORY"
    ],
    "letter": [
      "architecture/MESSAGING"
    ],
    "dead": [
      "architecture/MESSAGING"
    ],
    "brokers": [
      "architecture/MESSAGING"
    ],
    "messaging": [
      "architecture/MESSAGING"
    ],
    "topics": [
      "architecture/MESSAGING"
    ],
    "semantics": [
      "architecture/MESSAGING",
      "docs/CONTROL_PLANE_API",
      "specs/DB_BROKER_QUEUE",
      "specs/SYSTEM"
    ],
    "signals": [
      "architecture/METRICS",
      "docs/EVAL_TRANSLATION_MAP",
      "methodology/METRICS",
      "plugins/APTITUDE",
      "plugins/HEARTBEAT"
    ],
    "metrics": [
      "architecture/METRICS",
      "architecture/OBSERVABILITY",
      "methodology/METRICS"
    ],
    "counters": [
      "architecture/METRICS",
      "methodology/METRICS"
    ],
    "measurement": [
      "architecture/METRICS",
      "methodology/METRICS",
      "specs/evaluations/VARIANCE_EVALS"
    ],
    "decision": [
      "architecture/METRICS",
      "methodology/METRICS",
      "plugins/DECIDE"
    ],
    "dashboards": [
      "architecture/METRICS",
      "architecture/OBSERVABILITY",
      "methodology/METRICS"
    ],
    "slos": [
      "architecture/METRICS",
      "methodology/METRICS"
    ],
    "slis": [
      "architecture/METRICS",
      "methodology/METRICS"
    ],
    "instrumentation": [
      "architecture/METRICS",
      "methodology/METRICS"
    ],
    "alerting": [
      "architecture/METRICS",
      "architecture/OBSERVABILITY",
      "methodology/METRICS"
    ],
    "histograms": [
      "architecture/METRICS",
      "methodology/METRICS"
    ],
    "microservices": [
      "architecture/MICROSERVICES"
    ],
    "apis": [
      "architecture/MICROSERVICES"
    ],
    "independence": [
      "architecture/MICROSERVICES"
    ],
    "networking": [
      "architecture/NETWORKING"
    ],
    "routing": [
      "architecture/NETWORKING",
      "architecture/WEB",
      "interfaces/MEMORY_INDEX"
    ],
    "balancing": [
      "architecture/NETWORKING"
    ],
    "egress": [
      "architecture/NETWORKING"
    ],
    "connectivity": [
      "architecture/NETWORKING"
    ],
    "addressing": [
      "architecture/NETWORKING",
      "interfaces/MEMORY_INDEX"
    ],
    "segmentation": [
      "architecture/NETWORKING"
    ],
    "load": [
      "architecture/NETWORKING",
      "architecture/PERFORMANCE",
      "architecture/TESTING_STRATEGY"
    ],
    "visibility": [
      "architecture/OBSERVABILITY",
      "specs/DB_BROKER_QUEUE"
    ],
    "traces": [
      "architecture/OBSERVABILITY"
    ],
    "impact": [
      "architecture/OBSERVABILITY"
    ],
    "debugging": [
      "architecture/OBSERVABILITY"
    ],
    "correlation": [
      "architecture/OBSERVABILITY"
    ],
    "logs": [
      "architecture/OBSERVABILITY"
    ],
    "responsiveness": [
      "architecture/PERFORMANCE"
    ],
    "throughput": [
      "architecture/PERFORMANCE"
    ],
    "visible": [
      "architecture/PERFORMANCE",
      "specs/engineering/FRONTEND_BACKEND_E2E"
    ],
    "latency": [
      "architecture/PERFORMANCE"
    ],
    "profiling": [
      "architecture/PERFORMANCE"
    ],
    "bottlenecks": [
      "architecture/PERFORMANCE"
    ],
    "scaling": [
      "architecture/SCALING"
    ],
    "partitioning": [
      "architecture/SCALING"
    ],
    "sharding": [
      "architecture/SCALING"
    ],
    "quotas": [
      "architecture/SCALING"
    ],
    "vertical": [
      "architecture/SCALING"
    ],
    "horizontal": [
      "architecture/SCALING"
    ],
    "autoscaling": [
      "architecture/SCALING"
    ],
    "injection": [
      "architecture/SECRETS"
    ],
    "revocation": [
      "architecture/SECRETS"
    ],
    "leakage": [
      "architecture/SECRETS"
    ],
    "credential": [
      "architecture/SECRETS"
    ],
    "privilege": [
      "architecture/SECURITY",
      "specs/SECURITY"
    ],
    "least": [
      "architecture/SECURITY",
      "specs/SECURITY"
    ],
    "response": [
      "architecture/SECURITY",
      "methodology/INCIDENT_RESPONSE",
      "specs/SECURITY"
    ],
    "secure": [
      "architecture/SECURITY",
      "specs/SECURITY"
    ],
    "defaults": [
      "architecture/SECURITY",
      "specs/SECURITY"
    ],
    "paths": [
      "architecture/SECURITY",
      "interfaces/RISK_POLICY_GATE",
      "specs/SECURITY"
    ],
    "threat": [
      "architecture/SECURITY",
      "docs/SECURITY_THREAT_MODEL",
      "specs/SECURITY"
    ],
    "abuse": [
      "architecture/SECURITY",
      "docs/SECURITY_THREAT_MODEL",
      "specs/SECURITY"
    ],
    "confidence": [
      "architecture/TESTING_STRATEGY",
      "plugins/TRUST",
      "specs/evaluations/VARIANCE_EVALS"
    ],
    "regression": [
      "architecture/TESTING_STRATEGY"
    ],
    "integration": [
      "architecture/TESTING_STRATEGY",
      "docs/CONTROL_PLANE_API",
      "interfaces/DEMANDS_SCHEMA"
    ],
    "interaction": [
      "architecture/UI",
      "specs/engineering/FRONTEND_BACKEND_E2E"
    ],
    "handling": [
      "architecture/UI",
      "methodology/RESEARCH"
    ],
    "interface": [
      "architecture/UI",
      "interfaces/DEMANDS_SCHEMA",
      "interfaces/TESTING",
      "methodology/TESTING"
    ],
    "navigation": [
      "architecture/UI",
      "docs/README"
    ],
    "feedback": [
      "architecture/UI",
      "plugins/FEEDBACK",
      "plugins/REFLEX"
    ],
    "headers": [
      "architecture/WEB"
    ],
    "http": [
      "architecture/WEB"
    ],
    "browser": [
      "architecture/WEB"
    ],
    "flow": [
      "docs/ARCHITECTURE_OVERVIEW"
    ],
    "model": [
      "docs/ARCHITECTURE_OVERVIEW",
      "docs/SECURITY_THREAT_MODEL",
      "interfaces/KNOWLEDGE_STORE",
      "interfaces/STORE_MODEL"
    ],
    "hierarchy": [
      "docs/ARCHITECTURE_OVERVIEW",
      "specs/SYSTEM"
    ],
    "artifact": [
      "docs/ARCHITECTURE_OVERVIEW",
      "plugins/MANIFEST"
    ],
    "plane": [
      "docs/CONTROL_PLANE_API",
      "interfaces/CONTROL_PLANE"
    ],
    "allowed": [
      "docs/CONTROL_PLANE_API",
      "interfaces/CONTROL_PLANE"
    ],
    "receipts": [
      "docs/CONTROL_PLANE_API",
      "interfaces/CONTROL_PLANE",
      "plugins/AUDIT"
    ],
    "envelopes": [
      "docs/CONTROL_PLANE_API"
    ],
    "transitions": [
      "docs/CONTROL_PLANE_API",
      "interfaces/PLAN_GOVERNED_EXECUTION",
      "interfaces/TODO_SCHEMA",
      "plugins/TODO"
    ],
    "errors": [
      "docs/CONTROL_PLANE_API"
    ],
    "rubrics": [
      "docs/EVAL_TRANSLATION_MAP"
    ],
    "operable": [
      "docs/EVAL_TRANSLATION_MAP"
    ],
    "checks": [
      "docs/EVAL_TRANSLATION_MAP",
      "plugins/AUTOUPDATE",
      "plugins/HEALTH",
      "plugins/REFLEX",
      "specs/evaluations/VARIANCE_EVALS"
    ],
    "translation": [
      "docs/EVAL_TRANSLATION_MAP",
      "docs/SKILL_TRANSLATION_MAP",
      "methodology/RESEARCH_PRODUCTION"
    ],
    "doctrine": [
      "docs/EVAL_TRANSLATION_MAP",
      "interfaces/AGENT_CONTEXT_PACK",
      "specs/AMENDMENTS",
      "specs/SYSTEM"
    ],
    "into": [
      "docs/EVAL_TRANSLATION_MAP",
      "docs/SKILL_TRANSLATION_MAP"
    ],
    "kernel": [
      "docs/GOVERNANCE_AUDIT",
      "specs/SYSTEM"
    ],
    "inventory": [
      "docs/GOVERNANCE_AUDIT",
      "docs/NEGLECTED_ASPECTS_LEDGER"
    ],
    "risks": [
      "docs/GOVERNANCE_AUDIT",
      "docs/NEGLECTED_ASPECTS_LEDGER"
    ],
    "dependency": [
      "docs/GOVERNANCE_AUDIT",
      "metadata/skills/BUNDLE",
      "plugins/CONTAINER"
    ],
    "surfaces": [
      "docs/GOVERNANCE_AUDIT",
      "docs/NEGLECTED_ASPECTS_LEDGER",
      "docs/README",
      "interfaces/DEMANDS_SCHEMA",
      "interfaces/TESTING",
      "methodology/TESTING"
    ],
    "capability": [
      "docs/GOVERNANCE_AUDIT",
      "docs/SKILL_TRANSLATION_MAP",
      "methodology/PLATFORM",
      "plugins/APTITUDE"
    ],
    "prioritization": [
      "docs/GOVERNANCE_AUDIT",
      "methodology/ENGINEERING_MANAGEMENT"
    ],
    "guidance": [
      "docs/MAINTAINERS",
      "docs/SKILL_TRANSLATION_MAP"
    ],
    "hygiene": [
      "docs/MAINTAINERS",
      "plugins/CONTAINER"
    ],
    "expectations": [
      "docs/MAINTAINERS",
      "interfaces/PROCEDURAL_NORMS"
    ],
    "project": [
      "docs/MAINTAINERS",
      "interfaces/PROJECT_SPECS"
    ],
    "review": [
      "docs/MAINTAINERS",
      "methodology/ENGINEERING_MANAGEMENT",
      "specs/AMENDMENTS",
      "specs/skills/SKILL_GOVERNANCE"
    ],
    "maintainers": [
      "docs/MAINTAINERS"
    ],
    "stewardship": [
      "docs/MAINTAINERS"
    ],
    "triage": [
      "docs/MAINTAINERS"
    ],
    "change": [
      "docs/MIGRATIONS",
      "methodology/OPERATIONS",
      "plugins/WATCHER",
      "specs/AMENDMENTS"
    ],
    "forward": [
      "docs/MIGRATIONS"
    ],
    "evolution": [
      "docs/MIGRATIONS"
    ],
    "only": [
      "docs/MIGRATIONS"
    ],
    "postponed": [
      "docs/NEGLECTED_ASPECTS_LEDGER"
    ],
    "neglected": [
      "docs/NEGLECTED_ASPECTS_LEDGER"
    ],
    "work": [
      "docs/NEGLECTED_ASPECTS_LEDGER",
      "plugins/AUDIT",
      "plugins/HEARTBEAT",
      "plugins/TODO"
    ],
    "unaddressed": [
      "docs/NEGLECTED_ASPECTS_LEDGER"
    ],
    "ledger": [
      "docs/NEGLECTED_ASPECTS_LEDGER",
      "interfaces/CLAIMS"
    ],
    "aspects": [
      "docs/NEGLECTED_ASPECTS_LEDGER"
    ],
    "completion": [
      "docs/NEGLECTED_ASPECTS_LEDGER",
      "interfaces/CLAIMS",
      "plugins/VERIFY"
    ],
    "explicit": [
      "docs/NEGLECTED_ASPECTS_LEDGER"
    ],
    "procedures": [
      "docs/PLAYBOOK"
    ],
    "troubleshooting": [
      "docs/PLAYBOOK"
    ],
    "sequences": [
      "docs/PLAYBOOK"
    ],
    "safe": [
      "docs/PLAYBOOK",
      "interfaces/DOC_RULES",
      "interfaces/KNOWLEDGE_STORE",
      "plugins/ARCHIVE",
      "plugins/AUTOUPDATE",
      "specs/skills/SKILL_GOVERNANCE"
    ],
    "repeatable": [
      "docs/PLAYBOOK",
      "methodology/ARCHITECTURE",
      "methodology/CI_CD",
      "methodology/INCIDENT_RESPONSE",
      "methodology/RELEASE_MANAGEMENT",
      "methodology/SOUL",
      "plugins/CRON"
    ],
    "command": [
      "docs/PLAYBOOK"
    ],
    "path": [
      "docs/README"
    ],
    "installation": [
      "docs/README"
    ],
    "positioning": [
      "docs/README"
    ],
    "repository": [
      "docs/README",
      "interfaces/STORE_MODEL",
      "plugins/FEDERATION",
      "plugins/WATCHER",
      "specs/GIT"
    ],
    "landing": [
      "docs/README"
    ],
    "human": [
      "docs/README",
      "docs/SKILL_TRANSLATION_MAP",
      "interfaces/GLOSSARY",
      "plugins/FEEDBACK",
      "specs/INTENT"
    ],
    "quickstart": [
      "docs/README"
    ],
    "page": [
      "docs/README"
    ],
    "adoption": [
      "docs/README",
      "methodology/PLATFORM",
      "methodology/PRODUCT",
      "specs/AMENDMENTS"
    ],
    "orientation": [
      "docs/README"
    ],
    "gates": [
      "docs/RELEASE_PROCESS",
      "interfaces/PLAN_GOVERNED_EXECUTION",
      "plugins/POLICY"
    ],
    "communication": [
      "docs/RELEASE_PROCESS",
      "plugins/EMERGENCY_PROTOCOL"
    ],
    "changelogs": [
      "docs/RELEASE_PROCESS"
    ],
    "publication": [
      "docs/RELEASE_PROCESS",
      "plugins/MANIFEST"
    ],
    "readiness": [
      "docs/RELEASE_PROCESS",
      "plugins/APTITUDE",
      "plugins/HEALTH"
    ],
    "mitigations": [
      "docs/SECURITY_THREAT_MODEL"
    ],
    "actors": [
      "docs/SECURITY_THREAT_MODEL"
    ],
    "requirements": [
      "docs/SECURITY_THREAT_MODEL",
      "interfaces/CLAIMS"
    ],
    "residual": [
      "docs/SECURITY_THREAT_MODEL"
    ],
    "assets": [
      "docs/SECURITY_THREAT_MODEL"
    ],
    "cases": [
      "docs/SECURITY_THREAT_MODEL"
    ],
    "reusable": [
      "docs/SKILL_TRANSLATION_MAP",
      "metadata/skills/AGENT_DECAPOD_INTERFACE",
      "metadata/skills/HUMAN_AGENT_UX",
      "metadata/skills/INTENT_REFINEMENT",
      "methodology/KNOWLEDGE",
      "plugins/KNOWLEDGE"
    ],
    "patterns": [
      "docs/SKILL_TRANSLATION_MAP"
    ],
    "invocation": [
      "docs/SKILL_TRANSLATION_MAP",
      "plugins/HEARTBEAT",
      "specs/skills/SKILL_GOVERNANCE"
    ],
    "payloads": [
      "interfaces/AGENT_CONTEXT_PACK"
    ],
    "task": [
      "interfaces/AGENT_CONTEXT_PACK",
      "interfaces/TODO_SCHEMA",
      "metadata/skills/AGENT_DECAPOD_INTERFACE",
      "metadata/skills/HUMAN_AGENT_UX",
      "metadata/skills/INTENT_REFINEMENT",
      "plugins/APTITUDE",
      "plugins/TODO"
    ],
    "relevant": [
      "interfaces/AGENT_CONTEXT_PACK"
    ],
    "slices": [
      "interfaces/AGENT_CONTEXT_PACK"
    ],
    "inference": [
      "interfaces/AGENT_CONTEXT_PACK",
      "plugins/CONTEXT"
    ],
    "assembly": [
      "interfaces/AGENT_CONTEXT_PACK",
      "plugins/CONTEXT"
    ],
    "pack": [
      "interfaces/AGENT_CONTEXT_PACK"
    ],
    "first": [
      "interfaces/ARCHITECTURE_FOUNDATIONS"
    ],
    "vocabulary": [
      "interfaces/ARCHITECTURE_FOUNDATIONS",
      "interfaces/GLOSSARY"
    ],
    "principles": [
      "interfaces/ARCHITECTURE_FOUNDATIONS"
    ],
    "modes": [
      "interfaces/ARCHITECTURE_FOUNDATIONS"
    ],
    "foundations": [
      "interfaces/ARCHITECTURE_FOUNDATIONS"
    ],
    "accountability": [
      "interfaces/CLAIMS",
      "methodology/ENGINEERING_MANAGEMENT",
      "plugins/MANIFEST"
    ],
    "promises": [
      "interfaces/CLAIMS"
    ],
    "claim": [
      "interfaces/CLAIMS"
    ],
    "operation": [
      "interfaces/CONTROL_PLANE"
    ],
    "next": [
      "interfaces/CONTROL_PLANE"
    ],
    "actions": [
      "interfaces/CONTROL_PLANE"
    ],
    "sequencing": [
      "interfaces/CONTROL_PLANE",
      "interfaces/PROCEDURAL_NORMS",
      "methodology/PRODUCT"
    ],
    "initialization": [
      "interfaces/CONTROL_PLANE"
    ],
    "readable": [
      "interfaces/DEMANDS_SCHEMA"
    ],
    "demands": [
      "interfaces/DEMANDS_SCHEMA"
    ],
    "machine": [
      "interfaces/DEMANDS_SCHEMA",
      "interfaces/TODO_SCHEMA"
    ],
    "stable": [
      "interfaces/DEMANDS_SCHEMA"
    ],
    "structure": [
      "interfaces/DOC_RULES"
    ],
    "freshness": [
      "interfaces/DOC_RULES"
    ],
    "rules": [
      "interfaces/DOC_RULES",
      "plugins/POLICY"
    ],
    "conventions": [
      "interfaces/DOC_RULES"
    ],
    "writing": [
      "interfaces/DOC_RULES"
    ],
    "canonical": [
      "interfaces/DOC_RULES",
      "interfaces/GLOSSARY"
    ],
    "shared": [
      "interfaces/GLOSSARY",
      "methodology/PLATFORM",
      "plugins/FEDERATION"
    ],
    "understanding": [
      "interfaces/GLOSSARY",
      "methodology/KNOWLEDGE",
      "plugins/KNOWLEDGE"
    ],
    "term": [
      "interfaces/GLOSSARY"
    ],
    "semantic": [
      "interfaces/GLOSSARY"
    ],
    "attached": [
      "interfaces/INTERNALIZATION_SCHEMA",
      "interfaces/jsonschema/internalization/InternalizationAttachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationCreateResult.schema",
      "interfaces/jsonschema/internalization/InternalizationDetachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationInspectResult.schema",
      "interfaces/jsonschema/internalization/InternalizationManifest.schema"
    ],
    "inspected": [
      "interfaces/INTERNALIZATION_SCHEMA",
      "interfaces/jsonschema/internalization/InternalizationAttachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationCreateResult.schema",
      "interfaces/jsonschema/internalization/InternalizationDetachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationInspectResult.schema",
      "interfaces/jsonschema/internalization/InternalizationManifest.schema"
    ],
    "external": [
      "interfaces/INTERNALIZATION_SCHEMA",
      "interfaces/jsonschema/internalization/InternalizationAttachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationCreateResult.schema",
      "interfaces/jsonschema/internalization/InternalizationDetachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationInspectResult.schema",
      "interfaces/jsonschema/internalization/InternalizationManifest.schema"
    ],
    "inside": [
      "interfaces/INTERNALIZATION_SCHEMA",
      "interfaces/jsonschema/internalization/InternalizationAttachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationCreateResult.schema",
      "interfaces/jsonschema/internalization/InternalizationDetachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationInspectResult.schema",
      "interfaces/jsonschema/internalization/InternalizationManifest.schema"
    ],
    "internalization": [
      "interfaces/INTERNALIZATION_SCHEMA",
      "interfaces/jsonschema/internalization/InternalizationAttachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationCreateResult.schema",
      "interfaces/jsonschema/internalization/InternalizationDetachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationInspectResult.schema",
      "interfaces/jsonschema/internalization/InternalizationManifest.schema"
    ],
    "governed": [
      "interfaces/INTERNALIZATION_SCHEMA",
      "interfaces/PLAN_GOVERNED_EXECUTION",
      "interfaces/jsonschema/internalization/InternalizationAttachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationCreateResult.schema",
      "interfaces/jsonschema/internalization/InternalizationDetachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationInspectResult.schema",
      "interfaces/jsonschema/internalization/InternalizationManifest.schema"
    ],
    "detached": [
      "interfaces/INTERNALIZATION_SCHEMA",
      "interfaces/jsonschema/internalization/InternalizationAttachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationCreateResult.schema",
      "interfaces/jsonschema/internalization/InternalizationDetachResult.schema",
      "interfaces/jsonschema/internalization/InternalizationInspectResult.schema",
      "interfaces/jsonschema/internalization/InternalizationManifest.schema"
    ],
    "queryability": [
      "interfaces/KNOWLEDGE_SCHEMA"
    ],
    "lifecycle": [
      "interfaces/KNOWLEDGE_SCHEMA",
      "interfaces/MEMORY_SCHEMA"
    ],
    "captured": [
      "interfaces/KNOWLEDGE_STORE"
    ],
    "reuse": [
      "interfaces/KNOWLEDGE_STORE",
      "specs/skills/SKILL_GOVERNANCE"
    ],
    "transfer": [
      "interfaces/LCM"
    ],
    "recursion": [
      "interfaces/LCM"
    ],
    "lossy": [
      "interfaces/LCM"
    ],
    "summary": [
      "interfaces/LCM"
    ],
    "compression": [
      "interfaces/LCM"
    ],
    "dags": [
      "interfaces/LCM"
    ],
    "lossless": [
      "interfaces/LCM"
    ],
    "relevance": [
      "interfaces/MEMORY_INDEX"
    ],
    "discovery": [
      "interfaces/MEMORY_INDEX",
      "plugins/AUTOUPDATE"
    ],
    "categorization": [
      "interfaces/MEMORY_INDEX"
    ],
    "mutation": [
      "interfaces/MEMORY_SCHEMA",
      "interfaces/PLAN_GOVERNED_EXECUTION",
      "specs/INTENT"
    ],
    "record": [
      "interfaces/MEMORY_SCHEMA"
    ],
    "plans": [
      "interfaces/PLAN_GOVERNED_EXECUTION"
    ],
    "controlled": [
      "interfaces/PLAN_GOVERNED_EXECUTION",
      "plugins/FEEDBACK",
      "specs/AMENDMENTS"
    ],
    "approval": [
      "interfaces/PLAN_GOVERNED_EXECUTION",
      "interfaces/RISK_POLICY_GATE"
    ],
    "plan": [
      "interfaces/PLAN_GOVERNED_EXECUTION"
    ],
    "checkpoints": [
      "interfaces/PLAN_GOVERNED_EXECUTION"
    ],
    "escalation": [
      "interfaces/PROCEDURAL_NORMS",
      "interfaces/RISK_POLICY_GATE"
    ],
    "procedural": [
      "interfaces/PROCEDURAL_NORMS"
    ],
    "restraint": [
      "interfaces/PROCEDURAL_NORMS"
    ],
    "reliable": [
      "interfaces/PROCEDURAL_NORMS"
    ],
    "norms": [
      "interfaces/PROCEDURAL_NORMS"
    ],
    "conduct": [
      "interfaces/PROCEDURAL_NORMS"
    ],
    "behavioral": [
      "interfaces/PROCEDURAL_NORMS"
    ],
    "documents": [
      "interfaces/PROJECT_SPECS"
    ],
    "criteria": [
      "interfaces/PROJECT_SPECS",
      "specs/INTENT",
      "specs/evaluations/JUDGE_CONTRACT"
    ],
    "specifications": [
      "interfaces/PROJECT_SPECS"
    ],
    "backed": [
      "interfaces/PROJECT_SPECS"
    ],
    "acceptance": [
      "interfaces/PROJECT_SPECS",
      "specs/INTENT"
    ],
    "artifacts": [
      "interfaces/PROJECT_SPECS",
      "interfaces/STORE_MODEL"
    ],
    "definition": [
      "interfaces/PROJECT_SPECS"
    ],
    "gating": [
      "interfaces/RISK_POLICY_GATE"
    ],
    "gate": [
      "interfaces/RISK_POLICY_GATE"
    ],
    "databases": [
      "interfaces/STORE_MODEL"
    ],
    "remote": [
      "interfaces/STORE_MODEL",
      "plugins/FEDERATION"
    ],
    "local": [
      "interfaces/STORE_MODEL"
    ],
    "synchronization": [
      "interfaces/STORE_MODEL"
    ],
    "commands": [
      "interfaces/TESTING",
      "methodology/TESTING"
    ],
    "expected": [
      "interfaces/TESTING",
      "methodology/TESTING",
      "specs/evaluations/JUDGE_CONTRACT"
    ],
    "states": [
      "interfaces/TODO_SCHEMA"
    ],
    "history": [
      "interfaces/TODO_SCHEMA",
      "plugins/AUDIT"
    ],
    "obligations": [
      "interfaces/TODO_SCHEMA",
      "plugins/TODO"
    ],
    "verifiable": [
      "interfaces/TODO_SCHEMA"
    ],
    "internalizationattachresult": [
      "interfaces/jsonschema/internalization/InternalizationAttachResult.schema"
    ],
    "internalizationcreateresult": [
      "interfaces/jsonschema/internalization/InternalizationCreateResult.schema"
    ],
    "internalizationdetachresult": [
      "interfaces/jsonschema/internalization/InternalizationDetachResult.schema"
    ],
    "internalizationinspectresult": [
      "interfaces/jsonschema/internalization/InternalizationInspectResult.schema"
    ],
    "internalizationmanifest": [
      "interfaces/jsonschema/internalization/InternalizationManifest.schema"
    ],
    "discoverability": [
      "metadata/skills/BUNDLE"
    ],
    "composition": [
      "metadata/skills/BUNDLE"
    ],
    "packaging": [
      "metadata/skills/BUNDLE",
      "specs/skills/SKILL_GOVERNANCE"
    ],
    "sets": [
      "metadata/skills/BUNDLE"
    ],
    "bundle": [
      "metadata/skills/BUNDLE"
    ],
    "pattern": [
      "metadata/skills/AGENT_DECAPOD_INTERFACE",
      "metadata/skills/HUMAN_AGENT_UX",
      "metadata/skills/INTENT_REFINEMENT"
    ],
    "document": [
      "metadata/skills/AGENT_DECAPOD_INTERFACE",
      "metadata/skills/HUMAN_AGENT_UX",
      "metadata/skills/INTENT_REFINEMENT"
    ],
    "specific": [
      "metadata/skills/AGENT_DECAPOD_INTERFACE",
      "metadata/skills/HUMAN_AGENT_UX",
      "metadata/skills/INTENT_REFINEMENT"
    ],
    "outputs": [
      "metadata/skills/AGENT_DECAPOD_INTERFACE",
      "metadata/skills/HUMAN_AGENT_UX",
      "metadata/skills/INTENT_REFINEMENT",
      "specs/evaluations/JUDGE_CONTRACT"
    ],
    "inputs": [
      "metadata/skills/AGENT_DECAPOD_INTERFACE",
      "metadata/skills/HUMAN_AGENT_UX",
      "metadata/skills/INTENT_REFINEMENT",
      "plugins/MANIFEST",
      "specs/evaluations/JUDGE_CONTRACT"
    ],
    "instruction": [
      "metadata/skills/AGENT_DECAPOD_INTERFACE",
      "metadata/skills/HUMAN_AGENT_UX",
      "metadata/skills/INTENT_REFINEMENT"
    ],
    "operating": [
      "methodology/ARCHITECTURE",
      "methodology/CI_CD",
      "methodology/INCIDENT_RESPONSE",
      "methodology/RELEASE_MANAGEMENT",
      "methodology/SOUL"
    ],
    "processes": [
      "methodology/ARCHITECTURE",
      "methodology/CI_CD",
      "methodology/INCIDENT_RESPONSE",
      "methodology/RELEASE_MANAGEMENT",
      "methodology/SOUL"
    ],
    "validating": [
      "methodology/ARCHITECTURE",
      "methodology/CI_CD",
      "methodology/INCIDENT_RESPONSE",
      "methodology/RELEASE_MANAGEMENT",
      "methodology/SOUL"
    ],
    "outcomes": [
      "methodology/ARCHITECTURE",
      "methodology/CI_CD",
      "methodology/INCIDENT_RESPONSE",
      "methodology/RELEASE_MANAGEMENT",
      "methodology/SOUL"
    ],
    "making": [
      "methodology/ARCHITECTURE",
      "methodology/CI_CD",
      "methodology/INCIDENT_RESPONSE",
      "methodology/RELEASE_MANAGEMENT",
      "methodology/SOUL"
    ],
    "leadership": [
      "methodology/ENGINEERING_MANAGEMENT"
    ],
    "technical": [
      "methodology/ENGINEERING_MANAGEMENT"
    ],
    "team": [
      "methodology/ENGINEERING_MANAGEMENT"
    ],
    "experience": [
      "methodology/PLATFORM"
    ],
    "internal": [
      "methodology/PLATFORM"
    ],
    "developer": [
      "methodology/PLATFORM"
    ],
    "abstractions": [
      "methodology/PLATFORM"
    ],
    "bets": [
      "methodology/PRODUCT"
    ],
    "signal": [
      "methodology/PRODUCT"
    ],
    "scope": [
      "methodology/PRODUCT",
      "specs/INTENT"
    ],
    "framing": [
      "methodology/PRODUCT"
    ],
    "problem": [
      "methodology/PRODUCT"
    ],
    "hypotheses": [
      "methodology/RESEARCH"
    ],
    "falsifiable": [
      "methodology/RESEARCH"
    ],
    "synthesis": [
      "methodology/RESEARCH"
    ],
    "learning": [
      "methodology/RESEARCH",
      "plugins/FEDERATION"
    ],
    "uncertainty": [
      "methodology/RESEARCH"
    ],
    "exploration": [
      "methodology/RESEARCH_PRODUCTION"
    ],
    "from": [
      "methodology/RESEARCH_PRODUCTION"
    ],
    "shipped": [
      "methodology/RESEARCH_PRODUCTION"
    ],
    "operationalization": [
      "methodology/RESEARCH_PRODUCTION"
    ],
    "soul": [
      "methodology/SOUL"
    ],
    "suitability": [
      "plugins/APTITUDE"
    ],
    "assessment": [
      "plugins/APTITUDE"
    ],
    "aptitude": [
      "plugins/APTITUDE"
    ],
    "immutable": [
      "plugins/ARCHIVE"
    ],
    "records": [
      "plugins/ARCHIVE",
      "plugins/DECIDE"
    ],
    "archive": [
      "plugins/ARCHIVE"
    ],
    "preservation": [
      "plugins/ARCHIVE"
    ],
    "historical": [
      "plugins/ARCHIVE"
    ],
    "lookup": [
      "plugins/ARCHIVE"
    ],
    "reconstructable": [
      "plugins/AUDIT"
    ],
    "action": [
      "plugins/AUDIT",
      "plugins/REFLEX"
    ],
    "actor": [
      "plugins/AUDIT"
    ],
    "time": [
      "plugins/AUDIT",
      "plugins/CRON"
    ],
    "traceability": [
      "plugins/AUDIT"
    ],
    "version": [
      "plugins/AUTOUPDATE"
    ],
    "update": [
      "plugins/AUTOUPDATE"
    ],
    "advancement": [
      "plugins/AUTOUPDATE"
    ],
    "autoupdate": [
      "plugins/AUTOUPDATE"
    ],
    "reproducible": [
      "plugins/CONTAINER"
    ],
    "sandboxing": [
      "plugins/CONTAINER"
    ],
    "boundary": [
      "plugins/CONTEXT",
      "plugins/TRUST"
    ],
    "scoped": [
      "plugins/CONTEXT"
    ],
    "shaping": [
      "plugins/CONTEXT"
    ],
    "based": [
      "plugins/CRON"
    ],
    "scheduled": [
      "plugins/CRON"
    ],
    "cron": [
      "plugins/CRON"
    ],
    "tasks": [
      "plugins/CRON"
    ],
    "mediation": [
      "plugins/DB_BROKER"
    ],
    "queueing": [
      "plugins/DB_BROKER"
    ],
    "abstraction": [
      "plugins/DB_BROKER"
    ],
    "write": [
      "plugins/DB_BROKER"
    ],
    "writes": [
      "plugins/DB_BROKER"
    ],
    "broker": [
      "plugins/DB_BROKER",
      "specs/DB_BROKER_QUEUE"
    ],
    "brokered": [
      "plugins/DB_BROKER"
    ],
    "read": [
      "plugins/DB_BROKER"
    ],
    "alternatives": [
      "plugins/DECIDE"
    ],
    "tracking": [
      "plugins/DECIDE",
      "plugins/TODO"
    ],
    "trade": [
      "plugins/DECIDE"
    ],
    "rationale": [
      "plugins/DECIDE"
    ],
    "decide": [
      "plugins/DECIDE"
    ],
    "commitment": [
      "plugins/DECIDE"
    ],
    "conditions": [
      "plugins/EMERGENCY_PROTOCOL"
    ],
    "restoration": [
      "plugins/EMERGENCY_PROTOCOL"
    ],
    "containment": [
      "plugins/EMERGENCY_PROTOCOL"
    ],
    "post": [
      "plugins/EMERGENCY_PROTOCOL"
    ],
    "glass": [
      "plugins/EMERGENCY_PROTOCOL"
    ],
    "protocol": [
      "plugins/EMERGENCY_PROTOCOL"
    ],
    "break": [
      "plugins/EMERGENCY_PROTOCOL"
    ],
    "cross": [
      "plugins/FEDERATION"
    ],
    "propagation": [
      "plugins/FEDERATION"
    ],
    "loops": [
      "plugins/FEEDBACK"
    ],
    "refinement": [
      "plugins/FEEDBACK"
    ],
    "recursive": [
      "plugins/FEEDBACK",
      "plugins/REFLEX"
    ],
    "improvement": [
      "plugins/FEEDBACK"
    ],
    "observations": [
      "plugins/FEEDBACK"
    ],
    "defect": [
      "plugins/FEEDBACK"
    ],
    "diagnostics": [
      "plugins/HEALTH"
    ],
    "reporting": [
      "plugins/HEALTH"
    ],
    "degradation": [
      "plugins/HEALTH"
    ],
    "timeout": [
      "plugins/HEARTBEAT"
    ],
    "progress": [
      "plugins/HEARTBEAT"
    ],
    "heartbeat": [
      "plugins/HEARTBEAT"
    ],
    "eviction": [
      "plugins/HEARTBEAT"
    ],
    "presence": [
      "plugins/HEARTBEAT"
    ],
    "manifest": [
      "plugins/MANIFEST"
    ],
    "manifests": [
      "plugins/MANIFEST"
    ],
    "declarations": [
      "plugins/MANIFEST"
    ],
    "authorized": [
      "plugins/POLICY"
    ],
    "exceptions": [
      "plugins/POLICY"
    ],
    "improvements": [
      "plugins/REFLEX"
    ],
    "automatic": [
      "plugins/REFLEX"
    ],
    "corrective": [
      "plugins/REFLEX"
    ],
    "reflex": [
      "plugins/REFLEX"
    ],
    "self": [
      "plugins/REFLEX"
    ],
    "sourced": [
      "plugins/TODO"
    ],
    "permissions": [
      "plugins/TRUST"
    ],
    "collection": [
      "plugins/VERIFY"
    ],
    "orchestration": [
      "plugins/VERIFY"
    ],
    "check": [
      "plugins/VERIFY"
    ],
    "file": [
      "plugins/WATCHER"
    ],
    "observation": [
      "plugins/WATCHER"
    ],
    "reaction": [
      "plugins/WATCHER"
    ],
    "triggers": [
      "plugins/WATCHER"
    ],
    "amendments": [
      "specs/AMENDMENTS"
    ],
    "proposal": [
      "specs/AMENDMENTS"
    ],
    "supersession": [
      "specs/AMENDMENTS"
    ],
    "trail": [
      "specs/AMENDMENTS"
    ],
    "spec": [
      "specs/DB_BROKER_QUEUE",
      "specs/GIT",
      "specs/engineering/FRONTEND_BACKEND_E2E"
    ],
    "queue": [
      "specs/DB_BROKER_QUEUE"
    ],
    "retry": [
      "specs/DB_BROKER_QUEUE"
    ],
    "queued": [
      "specs/DB_BROKER_QUEUE"
    ],
    "worktrees": [
      "specs/GIT"
    ],
    "workflow": [
      "specs/GIT"
    ],
    "branch": [
      "specs/GIT"
    ],
    "commits": [
      "specs/GIT"
    ],
    "merge": [
      "specs/GIT"
    ],
    "clarification": [
      "specs/INTENT"
    ],
    "outcome": [
      "specs/INTENT"
    ],
    "authority": [
      "specs/INTENT",
      "specs/SYSTEM",
      "specs/skills/SKILL_GOVERNANCE"
    ],
    "invariants": [
      "specs/SYSTEM"
    ],
    "binding": [
      "specs/SYSTEM"
    ],
    "across": [
      "specs/engineering/FRONTEND_BACKEND_E2E"
    ],
    "variance": [
      "specs/evaluations/JUDGE_CONTRACT",
      "specs/evaluations/VARIANCE_EVALS"
    ],
    "scoring": [
      "specs/evaluations/JUDGE_CONTRACT"
    ],
    "evals": [
      "specs/evaluations/VARIANCE_EVALS"
    ],
    "evaluations": [
      "specs/evaluations/VARIANCE_EVALS"
    ],
    "stability": [
      "specs/evaluations/VARIANCE_EVALS"
    ],
    "runs": [
      "specs/evaluations/VARIANCE_EVALS"
    ],
    "comparative": [
      "specs/evaluations/VARIANCE_EVALS"
    ]
  }
}