decapod 0.60.6

{
  "$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",
          "core/RESEARCH"
        ],
        "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, product, platform, operating practice -> core/METHODOLOGY.",
          "research, papers, seminal, theory, academic -> core/RESEARCH.",
          "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 CAP, PACELC, consensus, consistency, ordering, clocks, and distributed transactions.",
      "terms": [
        "cap",
        "pacelc",
        "consensus",
        "raft",
        "paxos",
        "crdt",
        "hlc",
        "saga",
        "2pc",
        "idempotency",
        "distributed",
        "consistency"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE",
          "architecture/CONCURRENCY"
        ],
        "referenced_by": [
          "data/DATABASE",
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when designing multi-node systems requiring consensus, distributed transactions, or specific consistency models."
        ],
        "concepts": [
          "CAP Theorem: Partitions are unavoidable; choose between Consistency (CP) or Availability (AP) during split.",
          "PACELC: If no partition, choose between Latency (L) or Consistency (C).",
          "CRDTs enable eventual consistency without coordination; consensus (Raft/Paxos) provides strong ordering."
        ],
        "ambiguity": [
          "Stop if the partition behavior (AP vs CP) or required isolation level for cross-service transactions is unspecified."
        ],
        "decisions": [
          "Choose Saga pattern for long-running workflows vs 2PC for short-lived atomic distributed transactions.",
          "Select clock model: HLC for approximate global order vs Vector Clocks for strict causality tracking."
        ],
        "standards": [
          "Idempotency is mandatory for all state-mutating distributed operations to enable safe retries.",
          "Quorum configurations (N/2 + 1) must be explicitly tuned for the required fault tolerance."
        ],
        "failure_modes": [
          "Assuming synchronized wall-clocks for ordering, leading to lost updates or incorrect causality.",
          "Implementing blocking distributed transactions without a recovery coordinator, risking cluster-wide hangs."
        ],
        "next_queries": [
          "Query architecture/EVENT_DRIVEN for async coordination patterns.",
          "Query data/DATABASE for persistence consistency models."
        ],
        "proceed_when": [
          "Proceed when the consistency model is explicit and idempotency is implemented at the receiver."
        ]
      }
    },
    "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 TOGAF, DDD, Bounded Contexts, microservices, and cross-team governance.",
      "terms": [
        "togaf",
        "ddd",
        "bounded context",
        "ubiquitous language",
        "microservices",
        "sso",
        "audit",
        "compliance",
        "governance",
        "enterprise"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE",
          "architecture/API_DESIGN",
          "architecture/COMPLIANCE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when designing large-scale systems, mapping domain boundaries (DDD), or establishing enterprise governance."
        ],
        "concepts": [
          "Bounded Context: Define explicit boundaries where a specific domain model is valid to prevent semantic drift.",
          "Strategic DDD: Use context mapping to visualize relationships (upstream/downstream) between teams.",
          "Buy vs Build: Favor standardized enterprise solutions for non-core capabilities; build core competitive advantages."
        ],
        "ambiguity": [
          "Stop if the domain owner, ubiquitous language, or cross-team integration contract is undefined."
        ],
        "decisions": [
          "Identify Aggregate Roots to enforce consistency boundaries within a single domain service.",
          "Decide between shared database patterns (anti-pattern) vs database-per-service for microservices."
        ],
        "standards": [
          "Maintain an Architecture Decision Record (ADR) for all major enterprise-level structural choices.",
          "Enforce SSO (SAML/OIDC) and immutable audit logging for all cross-boundary state mutations."
        ],
        "failure_modes": [
          "Allowing 'god models' that span multiple bounded contexts, creating tight coupling and deployment bottlenecks.",
          "Bypassing API boundaries via direct database access or shared memory across team domains."
        ],
        "next_queries": [
          "Query architecture/COMPLIANCE for regulated data handling.",
          "Query architecture/API_DESIGN for contract versioning."
        ],
        "proceed_when": [
          "Proceed when domain boundaries are clear and the integration contract is signed off by all stakeholders."
        ]
      }
    },
    "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 IaC, networking, compute, IAM, storage, and cloud-native patterns.",
      "terms": [
        "iac",
        "terraform",
        "vpc",
        "subnet",
        "sg",
        "iam",
        "drift",
        "promotion",
        "cloud",
        "infrastructure",
        "compute",
        "networking"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE",
          "architecture/CLOUD",
          "architecture/NETWORKING"
        ],
        "referenced_by": [
          "architecture/CLOUD",
          "core/ENGINEERING_EXCELLENCE"
        ]
      },
      "sections": {
        "match": [
          "Use when provisioning cloud resources, defining VPCs/Subnets, or establishing IaC pipelines."
        ],
        "concepts": [
          "Infrastructure as Code (IaC): Manual console changes are prohibited. The repository is the source of truth.",
          "Immutable Infrastructure: Replace rather than patch; use images (AMIs/Containers) for repeatable deployments.",
          "Logical Isolation: Enforce strict separation (VPCs, separate accounts) between production and non-production environments."
        ],
        "ambiguity": [
          "Stop if the environment-specific CIDR block, state-locking backend, or IAM principal is unknown."
        ],
        "decisions": [
          "Decide between regional vs multi-regional deployments based on availability requirements and data residency laws.",
          "Choose between managed platform services vs self-hosted infrastructure based on operational cost and control."
        ],
        "standards": [
          "All infrastructure state must be stored in a remote, encrypted backend with mandatory state-locking.",
          "Security Groups and IAM policies must follow least-privilege principles, denying all traffic by default."
        ],
        "failure_modes": [
          "Hardcoding ARNs, IDs, or secrets in IaC code instead of using dynamic lookups or external secret stores.",
          "Neglecting drift detection, allowing production state to diverge from the declared code."
        ],
        "next_queries": [
          "Query architecture/CLOUD for service-specific quotas.",
          "Query architecture/SECURITY for boundary protection."
        ],
        "proceed_when": [
          "Proceed when the VPC topology is defined and IAM roles are strictly scoped to the workload."
        ]
      }
    },
    "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 incident response, chaos engineering, runbooks, and operational readiness.",
      "terms": [
        "incident response",
        "chaos engineering",
        "runbooks",
        "on-call",
        "postmortem",
        "mitigation",
        "reliability",
        "recovery",
        "operations",
        "incident"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY",
          "methodology/INCIDENT_RESPONSE",
          "methodology/PLATFORM"
        ],
        "referenced_by": [
          "core/METHODOLOGY"
        ]
      },
      "sections": {
        "match": [
          "Use when managing outages, planning chaos experiments, or defining operational health standards."
        ],
        "concepts": [
          "Mitigation First: During an incident, prioritize service restoration over root cause analysis.",
          "Chaos Engineering: Proactively inject failure into production-like environments to verify resilience.",
          "Blameless Postmortems: Focus on systemic guardrail deficiencies rather than individual human error."
        ],
        "ambiguity": [
          "Stop if the incident commander, current customer impact, or recovery path is unknown."
        ],
        "decisions": [
          "Decide immediately between a fast rollback vs a speculative forward-fix during an active outage.",
          "Determine which failure modes (e.g., region outage, database split-brain) are high-priority for chaos testing."
        ],
        "standards": [
          "Every production alert must link to an actionable, version-controlled runbook.",
          "Incident timelines and remediations must be documented and shared for organization-wide learning."
        ],
        "failure_modes": [
          "Accepting 'flaky' infrastructure as normal instead of automating resilience or fixing root causes.",
          "Deploying services without automated rollback mechanisms or verified health checks."
        ],
        "next_queries": [
          "Query methodology/INCIDENT_RESPONSE for tactical triage.",
          "Query methodology/PLATFORM for SRE and SLO alignment."
        ],
        "proceed_when": [
          "Proceed when the system is observable and a recovery path is verified."
        ]
      }
    },
    "methodology/PLATFORM": {
      "id": "methodology/PLATFORM",
      "category": "methodology",
      "title": "methodology/PLATFORM",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers paved roads, SRE, SLIs/SLOs, error budgets, developer experience, and golden paths.",
      "terms": [
        "sre",
        "sli",
        "slo",
        "error budget",
        "on-call",
        "toil",
        "runbooks",
        "paved road",
        "golden path",
        "experience",
        "developer",
        "platform"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY",
          "methodology/OPERATIONS",
          "methodology/METRICS",
          "architecture/OBSERVABILITY"
        ],
        "referenced_by": [
          "core/METHODOLOGY"
        ]
      },
      "sections": {
        "match": [
          "Use when designing internal tooling, establishing SRE practices, or defining SLIs/SLOs and error budgets."
        ],
        "concepts": [
          "SRE is operations as an engineering problem. Automate toil and manage systems through software.",
          "SLIs/SLOs: Measure the true customer experience; define acceptable failure thresholds (error budgets).",
          "The 'paved road' must be the easiest path. Adoption is driven by utility, not mandates."
        ],
        "ambiguity": [
          "Stop if the user persona, intended abstraction boundary, or target SLO is undefined."
        ],
        "decisions": [
          "Determine the boundary between platform-mandated configuration and feature-team flexibility.",
          "Decide which metrics represent true system health (SLIs) versus internal diagnostic telemetry."
        ],
        "standards": [
          "Platform tooling must be versioned, backward-compatible, and treated with API-level contract rigor.",
          "Error budgets align incentives: exhaust the budget to freeze deployments until reliability is restored."
        ],
        "failure_modes": [
          "Building heavy, mandatory frameworks that trap developers in brittle, unmaintainable monoliths.",
          "Failing to provide 'escape hatches', forcing fragile workarounds when the platform doesn't fit."
        ],
        "next_queries": [
          "Query architecture/OBSERVABILITY for telemetry standards.",
          "Query methodology/OPERATIONS for incident response procedures."
        ],
        "proceed_when": [
          "Proceed when the abstraction simplifies workflow and SLIs are defined for the service."
        ]
      }
    },
    "methodology/PRODUCT": {
      "id": "methodology/PRODUCT",
      "category": "methodology",
      "title": "methodology/PRODUCT",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers OKRs, RICE prioritization, feature flags, beta rollouts, and success signals.",
      "terms": [
        "okr",
        "rice",
        "moscow",
        "feature flag",
        "beta",
        "experiment",
        "prioritization",
        "product",
        "workflow",
        "adoption"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY",
          "methodology/ARCHITECTURE"
        ],
        "referenced_by": [
          "core/METHODOLOGY"
        ]
      },
      "sections": {
        "match": [
          "Use when defining feature roadmap, prioritizing tasks via RICE, or planning gradual rollouts."
        ],
        "concepts": [
          "OKRs: Inspirational Objectives paired with measurable, outcome-based Key Results.",
          "Decouple Deployment from Release: Use feature flags to ship code safely before enabling it for users.",
          "The First Slice: Deliver the smallest increment that provides measurable user value (MVP)."
        ],
        "ambiguity": [
          "Stop if the target audience, success metric, or prioritization confidence is missing."
        ],
        "decisions": [
          "Use RICE (Reach, Impact, Confidence, Effort) to objectively rank competing features.",
          "Decide between private beta, public beta, or GA based on technical risk and feedback needs."
        ],
        "standards": [
          "Feature flags must be temporary; schedule cleanup after full rollout to prevent technical debt.",
          "Acceptance criteria must be falsifiable and verifiable via automated tests or product evals."
        ],
        "failure_modes": [
          "Focusing on output (shipping features) instead of outcomes (solving user problems).",
          "Allowing permanent feature flags to clutter the codebase and create hidden logic paths."
        ],
        "next_queries": [
          "Query methodology/ARCHITECTURE for implementation boundaries.",
          "Query methodology/TESTING for validation of acceptance criteria."
        ],
        "proceed_when": [
          "Proceed when the user problem, RICE score, and success signals 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, seminal papers, citations, uncertainty, and synthesis.",
      "terms": [
        "seminal papers",
        "whitepapers",
        "literature review",
        "citations",
        "hypotheses",
        "evidence",
        "synthesis",
        "uncertainty",
        "research",
        "methodology"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY",
          "methodology/RESEARCH_PRODUCTION",
          "core/RESEARCH"
        ],
        "referenced_by": [
          "core/METHODOLOGY"
        ]
      },
      "sections": {
        "match": [
          "Use when performing literature reviews, investigating new domains, or gathering evidence from whitepapers."
        ],
        "concepts": [
          "Cite Seminal Papers: Ground architectural decisions in peer-reviewed industry research (e.g., CAP, Paxos, Spanner).",
          "Epistemic Humility: Preserve uncertainty; if research is inconclusive, name the unknowns instead of compressing them.",
          "Actionable Synthesis: Convert raw research into concrete constraints for the technical design."
        ],
        "ambiguity": [
          "Stop if source material is outdated, non-authoritative (marketing), or lacks reproducible evidence."
        ],
        "decisions": [
          "Determine when a 'research spike' has yielded enough signal to stop and begin implementation.",
          "Judge the authority of a source: favor original specifications and benchmarks over secondary blog posts."
        ],
        "standards": [
          "Citations are mandatory for all research-backed architectural claims.",
          "Format summaries as dense, factual decision matrices rather than narrative prose."
        ],
        "failure_modes": [
          "Relying on outdated tutorials as binding specifications for current-version technologies.",
          "Analysis paralysis: failing to bound research with a concrete decision gate."
        ],
        "next_queries": [
          "Query methodology/RESEARCH_PRODUCTION for implementation path.",
          "Query core/GAPS for missing doctrine discovered during research."
        ],
        "proceed_when": [
          "Proceed when the research yields actionable, cited constraints that resolve the target 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": "Covers testing pyramid, TDD/BDD, regression, performance, and proof-based delivery.",
      "terms": [
        "tdd",
        "bdd",
        "pyramid",
        "contract tests",
        "e2e",
        "performance tests",
        "fuzzing",
        "flaky",
        "validation",
        "quality",
        "testing"
      ],
      "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 designing test suites, setting quality gates, or performing QA-level validation."
        ],
        "concepts": [
          "Tests are executable specifications. Proving invariants is better than measuring line coverage.",
          "Shift Left: Catch security, performance, and logic failures as early as possible in the dev cycle.",
          "Flaky tests are broken tests; quarantine them to maintain trust in the CI signal."
        ],
        "ambiguity": [
          "Stop if the acceptance criteria are narrative (untestable) or the failure mode of a new feature is unmapped."
        ],
        "decisions": [
          "Determine if a behavior requires a slow integration test or if its logic can be isolated for a fast unit test.",
          "Choose between state-based testing vs interaction-based testing (mocks) based on risk."
        ],
        "standards": [
          "Every bug fix must include a regression test. Hard-to-test code signals poor architectural design.",
          "Tests must own their state; never depend on execution order or shared mutable global state."
        ],
        "failure_modes": [
          "Mocking everything and asserting calls (tautology), missing real integration and boundary risks.",
          "Treating testing as a post-hoc activity rather than an integral part of implementation design."
        ],
        "next_queries": [
          "Query methodology/QA for high-level strategy.",
          "Query architecture/TESTING_STRATEGY for platform-specific tools."
        ],
        "proceed_when": [
          "Proceed when the change is covered by deterministic, falsifiable proof."
        ]
      }
    },
    "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."
        ]
      }
    },
    "data/DATA_ENGINEERING": {
      "id": "data/DATA_ENGINEERING",
      "category": "data",
      "title": "data/DATA_ENGINEERING",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers pipelines, lineage, quality, governance, and analytical/operational separation.",
      "terms": [
        "etl",
        "elt",
        "lineage",
        "governance",
        "olap",
        "oltp",
        "quality",
        "retention",
        "privacy",
        "pipelines",
        "data"
      ],
      "links": {
        "references": [
          "core/ENGINEERING_EXCELLENCE",
          "data/PIPELINES",
          "data/DATABASE"
        ],
        "referenced_by": [
          "core/ENGINEERING_EXCELLENCE",
          "data/PIPELINES"
        ]
      },
      "sections": {
        "match": [
          "Use when building data lakes, warehouses, or processing pipelines (ETL/ELT)."
        ],
        "concepts": [
          "Separation of Concerns: Keep analytical (OLAP) and operational (OLTP) workloads physically isolated.",
          "Data Lineage: Maintain an auditable trace from source ingestion to final analytical report.",
          "Quality Gates: Implement automated checks for schema drift, nulls, and business logic at each pipeline stage."
        ],
        "ambiguity": [
          "Stop if the data owner, retention policy, or sensitivity level (PII/PHI) is undefined."
        ],
        "decisions": [
          "Decide between Batch (periodic completeness) vs Streaming (low-latency reaction) for the workload.",
          "Choose between Schema-on-Write (validation at source) vs Schema-on-Read (flexibility in analysis)."
        ],
        "standards": [
          "All data transformations must be idempotent to allow safe replay and recovery from failure.",
          "PII data must be masked or tokenized before entering analytical environments."
        ],
        "failure_modes": [
          "Creating cyclic DAGs that prevent pipeline completion or cause infinite loops.",
          "Neglecting data retention policies, leading to liability and excessive storage costs."
        ],
        "next_queries": [
          "Query data/DATABASE for transactional source details.",
          "Query architecture/COMPLIANCE for data classification."
        ],
        "proceed_when": [
          "Proceed when the data lineage is tracked and quality checks are instrumented."
        ]
      }
    },
    "methodology/QA": {
      "id": "methodology/QA",
      "category": "methodology",
      "title": "methodology/QA",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Covers quality strategy, TDD, BDD, automation, and overall delivery confidence.",
      "terms": [
        "qa",
        "quality assurance",
        "tdd",
        "bdd",
        "automation",
        "acceptance",
        "criteria",
        "strategy",
        "methodology"
      ],
      "links": {
        "references": [
          "core/METHODOLOGY",
          "methodology/TESTING"
        ],
        "referenced_by": [
          "core/METHODOLOGY"
        ]
      },
      "sections": {
        "match": [
          "Use when defining overall quality strategy, establishing TDD/BDD workflows, or setting up release gates."
        ],
        "concepts": [
          "Quality is a shared responsibility, not a downstream phase. Build it in from the start.",
          "Automation-First: Manual testing is for exploration; regressions and invariants must be automated.",
          "Continuous Verification: Run tests on every commit, every PR, and every deployment."
        ],
        "ambiguity": [
          "Stop if success criteria are vague or if the 'definition of done' excludes automated proof."
        ],
        "decisions": [
          "Determine the right balance of unit vs integration tests for the current project phase.",
          "Decide which quality gates are blocking (must pass) vs advisory (warn only)."
        ],
        "standards": [
          "Acceptance criteria must be documented *before* implementation and used as the basis for BDD scenarios.",
          "Maintain a stable, reproducible test environment that mirrors production as closely as possible."
        ],
        "failure_modes": [
          "Relying on manual QA as a safety net for poor automated test coverage.",
          "Setting vanity metrics (like 100% coverage) over actual behavior verification."
        ],
        "next_queries": [
          "Query methodology/TESTING for tactical execution.",
          "Query methodology/CI_CD for automated pipeline integration."
        ],
        "proceed_when": [
          "Proceed when the quality strategy is defined and automation is the default path."
        ]
      }
    },
    "research/TURING_1936": {
      "id": "research/TURING_1936",
      "category": "research",
      "title": "On Computable Numbers, with an Application to the Entscheidungsproblem (1936)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Alan Turing introduced the Turing Machine, providing a formal definition of an algorithm and proving the existence of undecidable problems.",
      "terms": [
        "turing machine",
        "computability",
        "algorithm",
        "halting problem",
        "decidability",
        "foundations"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Foundational work in computer science, written to address Hilbert's decision problem.",
          "Established the mathematical limits of what can be computed by a machine."
        ],
        "concepts": [
          "The Turing Machine: A theoretical model of computation using a tape and a head.",
          "Universal Turing Machine: A machine capable of simulating any other Turing machine."
        ],
        "impact": [
          "Defined the formal boundaries of computation.",
          "Provided the theoretical basis for the modern stored-program computer."
        ],
        "relevance": [
          "Essential for understanding algorithmic complexity and the theoretical limits of software."
        ]
      }
    },
    "research/SHANNON_1948": {
      "id": "research/SHANNON_1948",
      "category": "research",
      "title": "A Mathematical Theory of Communication (1948)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Claude Shannon established the field of information theory, introducing the bit as a unit of information and defining entropy.",
      "terms": [
        "information theory",
        "entropy",
        "bit",
        "communication",
        "bandwidth",
        "signal-to-noise"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Written at Bell Labs to address the problem of transmitting information over noisy channels.",
          "Transformed communication from a qualitative problem into a rigorous mathematical one."
        ],
        "concepts": [
          "Information Entropy: A measure of the uncertainty or information content in a message.",
          "Channel Capacity: The maximum rate at which information can be transmitted reliably."
        ],
        "impact": [
          "Enabled the development of modern digital communications, including the internet and mobile phones.",
          "Foundational for data compression and error correction algorithms."
        ],
        "relevance": [
          "Guides the design of efficient encoding schemes and communication protocols."
        ]
      }
    },
    "research/DIJKSTRA_1959": {
      "id": "research/DIJKSTRA_1959",
      "category": "research",
      "title": "A Note on Two Problems in Connexion with Graphs (1959)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Edsger Dijkstra introduced the shortest path algorithm and the minimum spanning tree algorithm.",
      "terms": [
        "dijkstra algorithm",
        "shortest path",
        "graph theory",
        "minimum spanning tree",
        "optimization",
        "routing"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Addressed foundational problems in graph theory related to finding efficient connections and paths.",
          "Focused on minimizing computational steps for pathfinding."
        ],
        "concepts": [
          "Shortest Path: An iterative algorithm for finding the lowest-cost path between nodes in a weighted graph.",
          "Minimum Spanning Tree: Connecting all nodes with the minimum total edge weight."
        ],
        "impact": [
          "Widely used in network routing protocols (like OSPF and IS-IS).",
          "Essential for GPS navigation systems and logistics optimization."
        ],
        "relevance": [
          "Core algorithm for any developer working with networked or spatial data structures."
        ]
      }
    },
    "research/HOARE_1969": {
      "id": "research/HOARE_1969",
      "category": "research",
      "title": "An Axiomatic Basis for Computer Programming (1969)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Tony Hoare introduced Hoare logic, a formal system for reasoning about the correctness of computer programs.",
      "terms": [
        "hoare logic",
        "formal verification",
        "precondition",
        "postcondition",
        "correctness",
        "invariant"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Proposed a method to mathematically prove that a program meets its specification.",
          "Introduced the concept of 'Hoare Triples' {P} C {Q}."
        ],
        "concepts": [
          "Preconditions (P): Conditions that must hold before execution.",
          "Postconditions (Q): Conditions that must hold after successful execution.",
          "Loop Invariants: Properties that remain true throughout an iterative process."
        ],
        "impact": [
          "Laid the groundwork for formal verification and modern static analysis tools.",
          "Influenced the design of safe programming languages and assertion-based testing."
        ],
        "relevance": [
          "Crucial for building high-assurance systems where correctness is paramount."
        ]
      }
    },
    "research/CODD_1970": {
      "id": "research/CODD_1970",
      "category": "research",
      "title": "A Relational Model of Data for Large Shared Data Banks (1970)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "E.F. Codd proposed the relational database model, separating logical data structure from physical storage.",
      "terms": [
        "relational model",
        "database",
        "sql",
        "normalization",
        "data independence",
        "algebra"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Written to solve the rigidity and complexity of hierarchical and network data models used at the time.",
          "Aimed at providing data independence from physical hardware changes."
        ],
        "concepts": [
          "Relations (Tables): Data organized into tuples and attributes.",
          "Normalization: Reducing data redundancy and improving integrity.",
          "Relational Algebra: Mathematical operations for querying data."
        ],
        "impact": [
          "Led to the development of SQL and the multi-billion dollar RDBMS industry.",
          "Became the dominant standard for data management for over 50 years."
        ],
        "relevance": [
          "The theoretical foundation for all relational databases (PostgreSQL, MySQL, Oracle)."
        ]
      }
    },
    "research/COOK_1971": {
      "id": "research/COOK_1971",
      "category": "research",
      "title": "The Complexity of Theorem-Proving Procedures (1971)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Stephen Cook introduced the concept of NP-completeness and proved that the Boolean satisfiability problem (SAT) is NP-complete.",
      "terms": [
        "np-complete",
        "complexity classes",
        "sat",
        "p vs np",
        "reductions",
        "computational complexity"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Investigated the relative difficulty of solving different types of computational problems.",
          "Established the P vs NP problem, one of the most famous unsolved problems in CS."
        ],
        "concepts": [
          "NP-Completeness: A class of problems that are as hard as any problem in NP.",
          "Polynomial-time reduction: Converting one problem into another to compare their difficulty."
        ],
        "impact": [
          "Enabled computer scientists to classify problems by their inherent hardness.",
          "Transformed algorithm design by showing which problems are likely intractable."
        ],
        "relevance": [
          "Helps engineers recognize when a problem they are facing is NP-hard, requiring heuristic approaches."
        ]
      }
    },
    "research/DIFFIE_HELLMAN_1976": {
      "id": "research/DIFFIE_HELLMAN_1976",
      "category": "research",
      "title": "New Directions in Cryptography (1976)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Diffie and Hellman introduced public-key cryptography and the key exchange protocol, enabling secure communication.",
      "terms": [
        "public-key",
        "cryptography",
        "key exchange",
        "asymmetric",
        "security",
        "privacy"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Published at a time when cryptography required pre-shared secret keys.",
          "Solved the 'key distribution problem' for secure communication between strangers."
        ],
        "concepts": [
          "Public-Key Cryptography: Using a public key for encryption and a private key for decryption.",
          "One-way Functions: Mathematical operations that are easy to compute but hard to invert."
        ],
        "impact": [
          "The basis for all secure communication on the internet (SSL/TLS, HTTPS).",
          "Revolutionized digital privacy and identity verification."
        ],
        "relevance": [
          "Fundamental for understanding how modern secure protocols work."
        ]
      }
    },
    "research/RSA_1978": {
      "id": "research/RSA_1978",
      "category": "research",
      "title": "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems (1978)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Rivest, Shamir, and Adleman implemented the first practical public-key cryptosystem based on prime factorization.",
      "terms": [
        "rsa",
        "encryption",
        "digital signatures",
        "prime numbers",
        "asymmetric",
        "security"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Practical implementation of the concepts proposed by Diffie and Hellman.",
          "Utilized the computational difficulty of factoring large integers."
        ],
        "concepts": [
          "Modular Exponentiation: The core mathematical operation of RSA.",
          "Public/Private Key Pair: Generated from two large distinct prime numbers.",
          "Digital Signatures: Providing authenticity and non-repudiation."
        ],
        "impact": [
          "Became the most widely used public-key encryption algorithm in history.",
          "Enabled secure e-commerce, software updates, and encrypted messaging."
        ],
        "relevance": [
          "Foundational knowledge for anyone working with certificates, JWTs, and secure APIs."
        ]
      }
    },
    "research/LAMPORT_1978": {
      "id": "research/LAMPORT_1978",
      "category": "research",
      "title": "Time, Clocks, and the Ordering of Events in a Distributed System (1978)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Leslie Lamport introduced logical clocks to order events in distributed systems without synchronized physical clocks.",
      "terms": [
        "logical clocks",
        "distributed systems",
        "event ordering",
        "causality",
        "synchronization",
        "concurrency"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Addressed the challenge of determining the order of events across multiple machines in a network.",
          "Recognized that physical clocks cannot be perfectly synchronized."
        ],
        "concepts": [
          "Happened-before relation: A partial ordering of events based on causality.",
          "Lamport Timestamps: Simple counters that track causal relationships between events.",
          "Total Ordering: Extending logical clocks to order all events in a system."
        ],
        "impact": [
          "Foundational for all distributed systems research and implementation.",
          "Led to the development of vector clocks and consistency models in distributed databases."
        ],
        "relevance": [
          "Critical for designing systems that require consensus or causal consistency."
        ]
      }
    },
    "research/SALTZER_SCHROEDER_1975": {
      "id": "research/SALTZER_SCHROEDER_1975",
      "category": "research",
      "title": "The Protection of Information in Computer Systems (1975)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Defined foundational security principles like Least Privilege, Open Design, and Economy of Mechanism.",
      "terms": [
        "security",
        "least privilege",
        "protection",
        "access control",
        "defense in depth",
        "open design"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Comprehensive survey of information protection techniques in multi-user systems.",
          "Established the 'Eight Principles' of secure system design."
        ],
        "concepts": [
          "Least Privilege: Every user and process should operate with the minimum set of permissions required.",
          "Fail-safe Defaults: Access decisions should be based on permission rather than exclusion.",
          "Complete Mediation: Every access must be checked against the protection policy."
        ],
        "impact": [
          "The standard reference for secure system design for decades.",
          "Influenced the development of RBAC, SELinux, and modern cloud IAM policies."
        ],
        "relevance": [
          "The bible of security engineering; its principles are still valid and essential today."
        ]
      }
    },
    "research/GRAY_1981": {
      "id": "research/GRAY_1981",
      "category": "research",
      "title": "The Transaction Concept: Virtues and Limitations (1981)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Jim Gray formalized the concept of ACID transactions, ensuring reliability and consistency in database systems.",
      "terms": [
        "acid",
        "transactions",
        "consistency",
        "atomicity",
        "durability",
        "isolation",
        "recovery"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Formalized the abstractions used in mainframe transaction processing systems (like IMS and CICS).",
          "Aimed at providing a simple, reliable interface for complex data operations."
        ],
        "concepts": [
          "Atomicity: All-or-nothing execution.",
          "Consistency: Preserving system invariants.",
          "Isolation: Concurrent transactions do not interfere.",
          "Durability: Changes persist after a crash."
        ],
        "impact": [
          "Standardized the way databases handle concurrency and failure.",
          "Enabled the creation of robust financial and enterprise applications."
        ],
        "relevance": [
          "Fundamental for anyone building systems that manage state or handle financial transactions."
        ]
      }
    },
    "research/LISKOV_1974": {
      "id": "research/LISKOV_1974",
      "category": "research",
      "title": "Programming with Abstract Data Types (1974)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Barbara Liskov introduced the concept of data abstraction and encapsulation, central to object-oriented programming.",
      "terms": [
        "abstract data types",
        "encapsulation",
        "abstraction",
        "modular",
        "interface",
        "liskov substitution"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Addressed the problem of managing large, complex software systems.",
          "Proposed separating the behavior of data from its internal implementation."
        ],
        "concepts": [
          "Encapsulation: Hiding implementation details behind a stable interface.",
          "Data Abstraction: Defining types by the operations that can be performed on them.",
          "Type Invariants: Ensuring objects remain in a valid state."
        ],
        "impact": [
          "Directly influenced the design of languages like CLU, Ada, and Java.",
          "Formed the basis for modern Object-Oriented Analysis and Design (OOAD)."
        ],
        "relevance": [
          "Teaches the core principles of modularity and maintainable software architecture."
        ]
      }
    },
    "research/BROOKS_1986": {
      "id": "research/BROOKS_1986",
      "category": "research",
      "title": "No Silver Bullet - Essence and Accident in Software Engineering (1986)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Fred Brooks argued that no single technological or management innovation could provide an order-of-magnitude improvement in productivity.",
      "terms": [
        "software engineering",
        "productivity",
        "complexity",
        "mythical man-month",
        "management",
        "silver bullet"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Written as a retrospective on software development challenges after the era of high-level languages.",
          "Distinguished between 'Essential' and 'Accidental' complexity."
        ],
        "concepts": [
          "Essential Complexity: The inherent difficulty of the problem itself.",
          "Accidental Complexity: Difficulties caused by our tools, languages, and processes.",
          "The invisibility, changeability, and conformity of software."
        ],
        "impact": [
          "Tempered expectations for new technologies as cure-alls for software project failures.",
          "Shifted focus towards better requirements gathering and rapid prototyping."
        ],
        "relevance": [
          "Reminds engineers that complexity is the primary challenge in software development."
        ]
      }
    },
    "research/LAMPSON_1983": {
      "id": "research/LAMPSON_1983",
      "category": "research",
      "title": "Hints for Computer System Design (1983)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Butler Lampson provided practical advice for building robust systems, including 'keep it simple' and 'use end-to-end arguments'.",
      "terms": [
        "system design",
        "heuristics",
        "simplicity",
        "robustness",
        "hints",
        "engineering"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "A collection of wisdom from the design and implementation of early interactive systems at Xerox PARC.",
          "Focuses on the trade-offs and 'rules of thumb' that lead to successful systems."
        ],
        "concepts": [
          "Keep it simple: Avoid complex solutions to simple problems.",
          "Plan to throw one away: You never understand a problem until you've tried to solve it once.",
          "Use end-to-end arguments: Correctness belongs at the highest level."
        ],
        "impact": [
          "Became a legendary checklist for systems engineers.",
          "Guided the design of networking protocols, operating systems, and distributed databases."
        ],
        "relevance": [
          "Invaluable set of heuristics for making architectural decisions under uncertainty."
        ]
      }
    },
    "research/FLP_1985": {
      "id": "research/FLP_1985",
      "category": "research",
      "title": "Impossibility of Distributed Consensus with One Faulty Process (1985)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Proved that it is impossible to reach consensus in an asynchronous distributed system if even one process can fail.",
      "terms": [
        "consensus",
        "impossibility",
        "distributed systems",
        "asynchronous",
        "fault tolerance",
        "liveness"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Known as the 'FLP Impossibility', this paper defined a major theoretical constraint on distributed computing.",
          "Challenged the assumption that perfect consensus could always be achieved."
        ],
        "concepts": [
          "Asynchronous System: A system with no bounds on message delay or processing time.",
          "Consensus: All non-faulty processes agreeing on a single value.",
          "Non-termination: Showing that an adversarial scheduler can prevent consensus forever."
        ],
        "impact": [
          "Forces systems designers to make trade-offs between consistency, availability, and termination.",
          "Led researchers to explore randomized algorithms and failure detectors."
        ],
        "relevance": [
          "Explains why consensus protocols like Raft and Paxos require timeouts and leader election."
        ]
      }
    },
    "research/PAXOS_1998": {
      "id": "research/PAXOS_1998",
      "category": "research",
      "title": "The Part-Time Parliament (1998)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Leslie Lamport introduced the Paxos algorithm, a foundational consensus protocol for distributed systems.",
      "terms": [
        "paxos",
        "consensus",
        "distributed systems",
        "fault tolerance",
        "replication",
        "quorum"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Introduced the most famous and difficult-to-understand algorithm in distributed systems.",
          "Framed as a parable about a fictional ancient parliament."
        ],
        "concepts": [
          "Proposers, Acceptors, and Learners: The three roles in the Paxos protocol.",
          "Two-Phase Commit: Prepare/Promise and Accept/Accepted phases.",
          "Quorums: Ensuring agreement by involving a majority of participants."
        ],
        "impact": [
          "The standard for building consistent, replicated state machines (databases, lock services).",
          "Directly influenced Google's Chubby, Apache ZooKeeper, and many others."
        ],
        "relevance": [
          "The 'gold standard' for distributed consistency; essential for senior systems engineers."
        ]
      }
    },
    "research/THOMPSON_1984": {
      "id": "research/THOMPSON_1984",
      "category": "research",
      "title": "Reflections on Trusting Trust (1984)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Ken Thompson demonstrated a security vulnerability where a compiler can be subverted to inject backdoors into any program it compiles.",
      "terms": [
        "security",
        "trust",
        "compiler",
        "backdoor",
        "trojan horse",
        "binary",
        "source code"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Thompson's Turing Award lecture, highlighting the limits of trusting software based on source code alone.",
          "Demonstrated a self-replicating backdoor that leaves no trace in the source."
        ],
        "concepts": [
          "Compiler subversion: Modifying the compiler to recognize it's compiling itself and inject the malicious code.",
          "Binary trust: You cannot trust a program if you didn't create the compiler yourself."
        ],
        "impact": [
          "Raised fundamental questions about software supply chain security.",
          "Led to research in 'bootstrapping' trust and reproducible builds."
        ],
        "relevance": [
          "A stark warning about the invisible trust we place in our development toolchains."
        ]
      }
    },
    "research/CHORD_2001": {
      "id": "research/CHORD_2001",
      "category": "research",
      "title": "Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications (2001)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced a distributed hash table (DHT) for efficient resource location in large-scale P2P networks.",
      "terms": [
        "dht",
        "peer-to-peer",
        "consistent hashing",
        "lookup",
        "scalability",
        "network"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Designed to solve the resource location problem in massive, decentralized peer-to-peer systems.",
          "Addressed the instability caused by nodes frequently joining and leaving (churn)."
        ],
        "concepts": [
          "Consistent Hashing: Maps keys to nodes in a way that minimizes movement when nodes change.",
          "Finger Tables: Routing tables that allow lookups in O(log N) steps.",
          "Self-organization: Automatic repair of the DHT as nodes join/leave."
        ],
        "impact": [
          "The basis for many P2P systems and distributed key-value stores.",
          "Influenced the design of Dynamo, Cassandra, and IPFS."
        ],
        "relevance": [
          "Key algorithm for building highly scalable, decentralized indexing and storage."
        ]
      }
    },
    "research/GFS_2003": {
      "id": "research/GFS_2003",
      "category": "research",
      "title": "The Google File System (2003)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "GFS described a scalable, fault-tolerant distributed file system designed for thousands of inexpensive nodes.",
      "terms": [
        "gfs",
        "distributed file system",
        "google",
        "scalability",
        "fault tolerance",
        "streaming"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Built to meet the storage needs of Google's indexing and search pipelines.",
          "Assumed that component failures are the norm rather than the exception."
        ],
        "concepts": [
          "Master/Chunkserver Architecture: Centralized metadata management with decentralized data storage.",
          "Chunk size: Large 64MB chunks to minimize master interaction.",
          "Append-only focus: Optimized for large streaming reads and sequential appends."
        ],
        "impact": [
          "Proved that petabyte-scale storage was possible on commodity hardware.",
          "Inspired the creation of Apache Hadoop HDFS."
        ],
        "relevance": [
          "Classic example of designing for massive scale and inevitable hardware failure."
        ]
      }
    },
    "research/MAPREDUCE_2004": {
      "id": "research/MAPREDUCE_2004",
      "category": "research",
      "title": "MapReduce: Simplified Data Processing on Large Clusters (2004)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced a programming model and execution environment for processing massive datasets in parallel.",
      "terms": [
        "mapreduce",
        "data processing",
        "parallel",
        "distributed",
        "google",
        "scalability"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Designed at Google to handle petabytes of data on commodity hardware where failures are common.",
          "Simplified distributed programming by hiding details of parallelization and fault-tolerance."
        ],
        "concepts": [
          "Map: Processes key/value pairs to generate intermediate sets.",
          "Reduce: Merges all intermediate values associated with the same intermediate key.",
          "Fault tolerance via re-execution of failed tasks."
        ],
        "impact": [
          "Enabled massive scalability for data processing tasks.",
          "Inspired Apache Hadoop and the entire Big Data ecosystem."
        ],
        "relevance": [
          "Foundation for modern batch processing pipelines; teaches functional primitives in distributed systems."
        ]
      }
    },
    "research/BIGTABLE_2006": {
      "id": "research/BIGTABLE_2006",
      "category": "research",
      "title": "Bigtable: A Distributed Storage System for Structured Data (2006)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Described a sparse, distributed, multi-dimensional sorted map designed to scale to petabytes.",
      "terms": [
        "bigtable",
        "nosql",
        "distributed storage",
        "structured data",
        "scalability",
        "google"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Created to store massive amounts of data for Google Earth, Google Analytics, and web indexing.",
          "Sat between GFS and application logic, providing structured access to data."
        ],
        "concepts": [
          "Row/Column/Timestamp: Data is indexed by a row key, column key, and a timestamp.",
          "Tablets: Horizontal partitions of the table distributed across machines.",
          "LSM-Trees: Optimized for high-throughput writes using sorted strings on disk."
        ],
        "impact": [
          "Defined the 'Wide-Column' NoSQL database category.",
          "Inspired Apache HBase and Apache Cassandra."
        ],
        "relevance": [
          "Crucial for understanding how to design storage for extremely high write volumes and large datasets."
        ]
      }
    },
    "research/DYNAMO_2007": {
      "id": "research/DYNAMO_2007",
      "category": "research",
      "title": "Dynamo: Amazon's Highly Available Key-value Store (2007)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced a highly available, eventually consistent storage system using consistent hashing and vector clocks.",
      "terms": [
        "dynamo",
        "availability",
        "eventual consistency",
        "nosql",
        "consistent hashing",
        "amazon"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Built for Amazon's shopping cart and order services where 'always writable' was a core requirement.",
          "Focused on the 'A' in CAP, sacrificing strong consistency for extreme availability."
        ],
        "concepts": [
          "Sloppy Quorums: Allowing writes to any available nodes during a partition.",
          "Vector Clocks: Tracking causal versioning to detect and resolve write conflicts.",
          "Hinted Handoff: Ensuring durability when the target node is temporarily unavailable."
        ],
        "impact": [
          "Popularized the 'Eventually Consistent' model and the Dynamo-style architecture.",
          "Led to the creation of DynamoDB, Cassandra, and Riak."
        ],
        "relevance": [
          "Teaches the trade-offs between availability and consistency in distributed systems."
        ]
      }
    },
    "research/SPANNER_2012": {
      "id": "research/SPANNER_2012",
      "category": "research",
      "title": "Spanner: Google's Globally-Distributed Database (2012)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Spanner described the first database to provide both global scale and external consistency using atomic clocks.",
      "terms": [
        "spanner",
        "distributed database",
        "external consistency",
        "truetime",
        "google",
        "sql"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Google's evolution from Bigtable to a database that supports semi-structured data and ACID transactions.",
          "Aimed at providing global scalability without the pain of eventual consistency."
        ],
        "concepts": [
          "TrueTime API: Uses GPS and atomic clocks to bound clock uncertainty globally.",
          "Snapshot Isolation: Providing consistent reads without locking.",
          "Paxog-groups: Replicating data across regions while maintaining strong consistency."
        ],
        "impact": [
          "Proved that global strong consistency is possible at scale.",
          "Inspired CockroachDB, YugabyteDB, and the 'NewSQL' movement."
        ],
        "relevance": [
          "The state-of-the-art in distributed database design; critical for global system architecture."
        ]
      }
    },
    "research/RAFT_2014": {
      "id": "research/RAFT_2014",
      "category": "research",
      "title": "In Search of an Understandable Consensus Algorithm (2014)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced Raft, a consensus protocol designed as a more understandable alternative to Paxos.",
      "terms": [
        "raft",
        "consensus",
        "log replication",
        "leader election",
        "distributed systems",
        "understandable"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Designed specifically for education and ease of implementation, while providing the same safety as Paxos.",
          "Addressed the 'Paxos is too hard' problem in the systems community."
        ],
        "concepts": [
          "Leader Election: A randomized timeout mechanism to select a central coordinator.",
          "Log Replication: Ensuring all nodes agree on the sequence of operations.",
          "Safety: Ensuring that committed entries are never lost or overwritten."
        ],
        "impact": [
          "Became the preferred choice for new distributed systems (etcd, Consul, CockroachDB).",
          "Significantly lowered the barrier for engineers to implement consistent replication."
        ],
        "relevance": [
          "The most practical consensus algorithm for modern developers; essential for building distributed control planes."
        ]
      }
    },
    "research/TRANSFORMER_2017": {
      "id": "research/TRANSFORMER_2017",
      "category": "research",
      "title": "Attention Is All You Need (2017)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced the Transformer architecture, relying entirely on self-attention mechanisms, enabling large language models.",
      "terms": [
        "transformer",
        "attention",
        "nlp",
        "llm",
        "neural networks",
        "machine learning"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Addressed the limitations of recurrent neural networks (RNNs) in processing long-range dependencies in text.",
          "Aimed at improving translation quality and training speed through parallelization."
        ],
        "concepts": [
          "Self-Attention: Allowing the model to weigh the importance of different words in a sequence regardless of distance.",
          "Multi-Head Attention: Attending to information from different representation subspaces.",
          "Positional Encoding: Injecting information about the order of words without using recursion."
        ],
        "impact": [
          "The foundation for GPT, BERT, and almost all modern AI breakthroughs.",
          "Transformed the entire field of Natural Language Processing and beyond."
        ],
        "relevance": [
          "Critical for understanding the architecture behind the very agents and AI systems we use today."
        ]
      }
    },
    "research/BITCOIN_2008": {
      "id": "research/BITCOIN_2008",
      "category": "research",
      "title": "Bitcoin: A Peer-to-Peer Electronic Cash System (2008)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Satoshi Nakamoto introduced the blockchain and proof-of-work consensus for decentralized financial systems.",
      "terms": [
        "bitcoin",
        "blockchain",
        "proof-of-work",
        "decentralized",
        "cryptocurrency",
        "consensus"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Proposed as a solution to the 'double-spending problem' in digital currency without a central authority.",
          "Published in the wake of the 2008 financial crisis."
        ],
        "concepts": [
          "Blockchain: A chain of hashed blocks providing an immutable ledger.",
          "Proof-of-Work: A computational challenge that secures the network against manipulation.",
          "Nodes: Participants who verify transactions and mine blocks."
        ],
        "impact": [
          "Created the entire cryptocurrency and blockchain industry.",
          "Introduced the world to decentralized finance (DeFi) and trustless systems."
        ],
        "relevance": [
          "Essential for understanding decentralized consensus and the security of distributed ledgers."
        ]
      }
    },
    "research/MCCULLOCH_PITTS_1943": {
      "id": "research/MCCULLOCH_PITTS_1943",
      "category": "research",
      "title": "A Logical Calculus of the Ideas Immanent in Nervous Activity (1943)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Provided the first mathematical model of a biological neuron, laying the groundwork for artificial neural networks.",
      "terms": [
        "neural networks",
        "ai",
        "neuron",
        "mathematical model",
        "logic",
        "cybernetics"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Early attempt to bridge the gap between biology and logic/computation.",
          "Aimed at understanding how the brain produces complex behavior from simple units."
        ],
        "concepts": [
          "Threshold Logic: A model where a neuron fires if its inputs exceed a certain value.",
          "Logic Gates: Showed that networks of simple neurons could represent ANY logical function."
        ],
        "impact": [
          "The absolute starting point for the field of Artificial Intelligence.",
          "Guided the design of the first computers and early AI research."
        ],
        "relevance": [
          "Historical foundation that reminds us that modern AI is rooted in simple mathematical logic."
        ]
      }
    },
    "research/MINSKY_1961": {
      "id": "research/MINSKY_1961",
      "category": "research",
      "title": "Steps Toward Artificial Intelligence (1961)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Marvin Minsky surveyed early progress in AI and identified key challenges in search, pattern recognition, and learning.",
      "terms": [
        "ai",
        "search",
        "pattern recognition",
        "learning",
        "heuristics",
        "problem solving"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "A comprehensive roadmap for the AI field written during its optimistic early years.",
          "Categorized the diverse approaches to machine intelligence at the time."
        ],
        "concepts": [
          "Search: Navigating complex state spaces efficiently.",
          "Heuristic Programming: Using 'rules of thumb' to solve intractable problems.",
          "Pattern Recognition: Extracting meaning from raw data."
        ],
        "impact": [
          "Defined the research agenda for AI for the next several decades.",
          "Identified the core problems that modern AI is still tackling today."
        ],
        "relevance": [
          "Provides historical context for the current 'scaling' vs 'symbolic' AI debates."
        ]
      }
    },
    "research/BACKPROP_1986": {
      "id": "research/BACKPROP_1986",
      "category": "research",
      "title": "Learning representations by back-propagating errors (1986)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Rumelhart et al. described the backpropagation algorithm for training multi-layer neural networks.",
      "terms": [
        "backpropagation",
        "neural networks",
        "gradient descent",
        "deep learning",
        "optimization",
        "weights"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Solved the problem of how to efficiently train neural networks with hidden layers.",
          "Brought neural networks out of the 'AI winter' of the 70s."
        ],
        "concepts": [
          "Chain Rule: Using calculus to propagate the error signal backwards through the network.",
          "Gradient Descent: Adjusting weights to minimize the error function.",
          "Hidden Layers: Enabling the learning of complex, non-linear representations."
        ],
        "impact": [
          "The engine that powers almost all modern deep learning systems.",
          "Enabled the training of networks for speech recognition, vision, and language."
        ],
        "relevance": [
          "The core algorithm for anyone developing or optimizing neural network models."
        ]
      }
    },
    "research/LECUN_1998": {
      "id": "research/LECUN_1998",
      "category": "research",
      "title": "Gradient-based learning applied to document recognition (1998)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced Convolutional Neural Networks (CNNs) and demonstrated their effectiveness in image recognition.",
      "terms": [
        "cnn",
        "computer vision",
        "lenet",
        "image recognition",
        "convolutions",
        "deep learning"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Applied backpropagation and convolutions to the practical problem of digit recognition (checks/mail).",
          "Developed at Bell Labs by Yann LeCun and colleagues."
        ],
        "concepts": [
          "Convolutional Layers: Automatically learning spatial hierarchies of features from images.",
          "Subsampling (Pooling): Reducing dimensionality while preserving important features.",
          "Weight Sharing: Significantly reducing the number of parameters to learn."
        ],
        "impact": [
          "Led to the development of modern computer vision systems.",
          "LeNet-5 became the standard for handwriting recognition."
        ],
        "relevance": [
          "Foundational for understanding how machines process visual information."
        ]
      }
    },
    "research/ALEXNET_2012": {
      "id": "research/ALEXNET_2012",
      "category": "research",
      "title": "ImageNet Classification with Deep Convolutional Neural Networks (2012)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Utilized GPUs to train a large CNN, significantly outperforming prior methods and igniting the deep learning era.",
      "terms": [
        "deep learning",
        "alexnet",
        "gpu",
        "imagenet",
        "computer vision",
        "cnn"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Entered the ImageNet competition and crushed the previous state-of-the-art results.",
          "Proved that deep networks + large datasets + GPUs = super-human performance."
        ],
        "concepts": [
          "GPU Acceleration: Using parallel hardware to train massive models efficiently.",
          "ReLU Activation: Enabling faster training and better gradients.",
          "Dropout: A regularization technique to prevent overfitting in deep models."
        ],
        "impact": [
          "Triggered the global 'Deep Learning' revolution.",
          "Shifted the AI field towards massive scale and hardware-intensive training."
        ],
        "relevance": [
          "The paper that started the modern AI era; teaches the power of scale."
        ]
      }
    },
    "research/ALPHAGO_2016": {
      "id": "research/ALPHAGO_2016",
      "category": "research",
      "title": "Mastering the game of Go with deep neural networks and tree search (2016)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Described how AlphaGo defeated a world champion by combining deep learning with Monte Carlo tree search.",
      "terms": [
        "alphago",
        "reinforcement learning",
        "mcts",
        "go",
        "deep learning",
        "game theory"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Solved a problem (the game of Go) that was previously thought to be decades away from a machine solution.",
          "Developed by DeepMind using reinforcement learning."
        ],
        "concepts": [
          "Policy Networks: Predicting the next move.",
          "Value Networks: Evaluating the strength of a game position.",
          "Monte Carlo Tree Search (MCTS): Simulating future moves to find the best path."
        ],
        "impact": [
          "A landmark achievement in artificial intelligence and game theory.",
          "Demonstrated the power of combining search with learned intuition."
        ],
        "relevance": [
          "Teaches how to combine multiple AI techniques to solve complex, high-dimensional problems."
        ]
      }
    },
    "research/RESNET_2015": {
      "id": "research/RESNET_2015",
      "category": "research",
      "title": "Deep Residual Learning for Image Recognition (2015)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced residual connections, allowing the training of extremely deep neural networks (100+ layers).",
      "terms": [
        "resnet",
        "residual learning",
        "deep networks",
        "computer vision",
        "gradients",
        "skip connections"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Addressed the 'vanishing gradient' problem where deeper networks performed worse than shallower ones.",
          "Winner of ILSVRC and COCO competitions in 2015."
        ],
        "concepts": [
          "Residual Blocks: Learning the difference (residual) from the input instead of a direct mapping.",
          "Skip Connections: Bypassing layers to allow gradients to flow through deep networks unimpeded."
        ],
        "impact": [
          "Enabled the use of much deeper and more powerful models in all AI domains.",
          "Became the standard backbone for computer vision and many other architectures."
        ],
        "relevance": [
          "Essential concept for building deep, stable, and high-performance neural networks."
        ]
      }
    },
    "research/GPT3_2020": {
      "id": "research/GPT3_2020",
      "category": "research",
      "title": "Language Models are Few-Shot Learners (2020)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Demonstrated that massive language models can perform diverse tasks with minimal examples, showing emergent capabilities.",
      "terms": [
        "gpt-3",
        "few-shot learning",
        "llm",
        "emergence",
        "zero-shot",
        "nlp"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Published by OpenAI, exploring the scaling laws of Transformer-based language models.",
          "Used a model with 175 billion parameters, the largest at the time."
        ],
        "concepts": [
          "Few-Shot Learning: Performing a task by seeing just a few examples in the prompt.",
          "In-Context Learning: Adapting to tasks without updating the model weights.",
          "Scaling Laws: The relationship between model size, data, and performance."
        ],
        "impact": [
          "Changed the AI paradigm from task-specific fine-tuning to prompt engineering and foundation models.",
          "Paved the way for ChatGPT and the current wave of generative AI."
        ],
        "relevance": [
          "The primary reference for how modern LLMs (like the ones we use) function and scale."
        ]
      }
    },
    "research/TENSORFLOW_2016": {
      "id": "research/TENSORFLOW_2016",
      "category": "research",
      "title": "TensorFlow: A System for Large-Scale Machine Learning (2016)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Described a flexible and scalable framework for expressing and executing machine learning algorithms across diverse hardware.",
      "terms": [
        "tensorflow",
        "machine learning",
        "distributed",
        "gpu",
        "tpu",
        "dataflow graph"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Built by Google Brain to replace DistBelief and provide a single platform from research to production.",
          "Open-sourced to accelerate the AI community."
        ],
        "concepts": [
          "Dataflow Graph: Representing computations as a directed graph of tensors.",
          "Hardware Agnostic: Running the same code on CPUs, GPUs, and TPUs.",
          "Distributed Training: Scaling models across clusters of machines."
        ],
        "impact": [
          "Became one of the most widely used libraries for machine learning and deep learning.",
          "Enabled the rapid productionization of complex AI models."
        ],
        "relevance": [
          "Foundational architecture for modern AI frameworks and pipelines."
        ]
      }
    },
    "research/SPARK_2012": {
      "id": "research/SPARK_2012",
      "category": "research",
      "title": "Apache Spark: Resilient Distributed Datasets (2012)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced a fault-tolerant abstraction for in-memory cluster computing, enabling significantly faster data processing than MapReduce.",
      "terms": [
        "apache spark",
        "rdd",
        "in-memory",
        "big data",
        "data processing",
        "iterative"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Developed at UC Berkeley to solve the inefficiencies of MapReduce for iterative and interactive workloads.",
          "Aimed at reducing the heavy disk I/O overhead of earlier distributed systems."
        ],
        "concepts": [
          "Resilient Distributed Datasets (RDDs): Immutable, partitioned collections of records that can be computed in parallel.",
          "Lineage: Tracking the history of transformations to reconstruct lost data without expensive replication.",
          "Lazy Evaluation: Delaying computation until an action is requested to optimize execution."
        ],
        "impact": [
          "Replaced MapReduce as the industry standard for large-scale data processing.",
          "Enabled faster machine learning and real-time analytics."
        ],
        "relevance": [
          "The core architecture for modern big data engineering; teaches the value of in-memory computing."
        ]
      }
    },
    "research/KAFKA_2011": {
      "id": "research/KAFKA_2011",
      "category": "research",
      "title": "Kafka: a Distributed Messaging System for Log Processing (2011)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced a high-throughput, distributed, persistent messaging system designed for real-time event streaming.",
      "terms": [
        "apache kafka",
        "event streaming",
        "messaging",
        "distributed log",
        "throughput",
        "pub-sub"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Built at LinkedIn to handle their massive internal log and activity data streams.",
          "Bridged the gap between traditional messaging and offline log processing."
        ],
        "concepts": [
          "Distributed Log: An append-only sequence of records partitioned across nodes.",
          "Publish-Subscribe: Decoupling producers and consumers through topics.",
          "Zero-Copy: Optimizing data transfer by avoiding expensive copying between kernel and application."
        ],
        "impact": [
          "Defined the 'Event Streaming Platform' category.",
          "Became the central nervous system for thousands of modern companies."
        ],
        "relevance": [
          "Key technology for building event-driven architectures and real-time pipelines."
        ]
      }
    },
    "research/ZOOKEEPER_2010": {
      "id": "research/ZOOKEEPER_2010",
      "category": "research",
      "title": "ZooKeeper: Wait-free coordination for Internet-scale systems (2010)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Provided a centralized service for maintaining configuration, naming, and providing distributed synchronization.",
      "terms": [
        "zookeeper",
        "coordination",
        "consensus",
        "configuration",
        "locking",
        "distributed systems"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Created at Yahoo to solve the recurring coordination problems in their growing cluster applications.",
          "Aimed at providing a high-performance, fault-tolerant 'kernel' for building distributed services."
        ],
        "concepts": [
          "Zab Protocol: A custom consensus protocol designed for primary-backup replication.",
          "ZNodes: A hierarchical namespace similar to a filesystem for storing metadata.",
          "Wait-free: Allowing clients to make progress even if other clients are slow or failed."
        ],
        "impact": [
          "Became a critical dependency for the entire Hadoop and Big Data ecosystem.",
          "Popularized the 'Service Discovery' and 'Distributed Locking' patterns."
        ],
        "relevance": [
          "Foundational system for understanding distributed coordination and metadata management."
        ]
      }
    },
    "research/END_TO_END_1984": {
      "id": "research/END_TO_END_1984",
      "category": "research",
      "title": "End-to-End Arguments in System Design (1984)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Argued that functions placed at low levels of a system may be redundant or of little value compared to higher levels.",
      "terms": [
        "end-to-end",
        "system design",
        "networking",
        "reliability",
        "architecture",
        "correctness"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Foundational principle for the design of the Internet and its protocols (TCP/IP).",
          "Addressed where to place reliability and security checks in a networked system."
        ],
        "concepts": [
          "The Argument: Functions like error checking can only be completely and correctly implemented with the help of the application at the endpoints.",
          "Lower Level Efficiency: Lower levels can provide partial optimizations, but never a complete solution."
        ],
        "impact": [
          "The guiding philosophy for the 'dumb network, smart endpoints' architecture of the modern Internet.",
          "Prevented networks from becoming overly complex and fragile."
        ],
        "relevance": [
          "Essential for making architectural decisions about where to place logic and verification."
        ]
      }
    },
    "research/UNIX_1974": {
      "id": "research/UNIX_1974",
      "category": "research",
      "title": "The UNIX Time-Sharing System (1974)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Ritchie and Thompson described the design of the UNIX operating system, emphasizing simplicity and composability.",
      "terms": [
        "unix",
        "operating system",
        "simplicity",
        "composability",
        "shell",
        "files"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Published by the creators of UNIX at Bell Labs, describing the system that would define modern computing.",
          "Introduced at a time when OSs were massive, complex, and hardware-specific."
        ],
        "concepts": [
          "Everything is a File: A unified interface for disk files, devices, and inter-process communication.",
          "Composability: Building complex systems from small, simple tools linked by pipes.",
          "Hierarchical Filesystem: A clean, recursive structure for organizing data."
        ],
        "impact": [
          "Became the most influential OS design in history, leading to Linux, macOS, and Android.",
          "Established the 'UNIX Philosophy' of software development."
        ],
        "relevance": [
          "The ultimate masterclass in simplicity, elegance, and modular system design."
        ]
      }
    },
    "research/PERCEPTRONS_1958": {
      "id": "research/PERCEPTRONS_1958",
      "category": "research",
      "title": "The Perceptron: A Probabilistic Model (1958)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Frank Rosenblatt introduced the Perceptron, the simplest form of a neural network used for binary classification.",
      "terms": [
        "perceptron",
        "neural networks",
        "binary classification",
        "linear classifier",
        "ai history",
        "supervised learning"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Early attempt to model biological learning and brain function.",
          "Aimed at creating a machine that could learn from experience without explicit programming."
        ],
        "concepts": [
          "Weighted Sum: Input values multiplied by weights and summed.",
          "Threshold Activation: Outputting 1 if the sum exceeds a threshold, otherwise 0.",
          "Learning Rule: Adjusting weights based on classification errors."
        ],
        "impact": [
          "The foundational building block of modern artificial neural networks.",
          "Ignited both optimism and later criticism (Minsky/Papert) that led to the first AI winter."
        ],
        "relevance": [
          "Essential for understanding the basic mechanics of how machines learn linear decision boundaries."
        ]
      }
    },
    "research/LSTM_1997": {
      "id": "research/LSTM_1997",
      "category": "research",
      "title": "Long Short-Term Memory (1997)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Hochreiter and Schmidhuber introduced LSTM networks, solving the vanishing gradient problem in recurrent neural networks.",
      "terms": [
        "lstm",
        "rnn",
        "vanishing gradient",
        "sequence modeling",
        "deep learning",
        "time series"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Addressed the failure of standard RNNs to learn long-term dependencies in data sequences.",
          "Introduced at a time when deep learning was still recovering from its second winter."
        ],
        "concepts": [
          "Memory Cell: Maintaining state over long periods.",
          "Gating Mechanisms: Input, Output, and Forget gates that control information flow.",
          "Constant Error Carousel: Preventing gradients from vanishing or exploding."
        ],
        "impact": [
          "Enabled major breakthroughs in speech recognition, translation, and handwriting recognition.",
          "The dominant architecture for sequential data until the rise of Transformers."
        ],
        "relevance": [
          "Crucial for processing any data with temporal dependencies or long-range context."
        ]
      }
    },
    "research/SVM_1995": {
      "id": "research/SVM_1995",
      "category": "research",
      "title": "Support-Vector Networks (1995)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Cortes and Vapnik introduced Support Vector Machines (SVM), a powerful method for pattern recognition and classification.",
      "terms": [
        "svm",
        "support vector machine",
        "kernel trick",
        "classification",
        "maximum margin",
        "statistical learning"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Grounded in statistical learning theory (VC dimension).",
          "Aimed at finding the optimal hyperplane that separates classes with the largest possible margin."
        ],
        "concepts": [
          "Maximum Margin: Maximizing the distance between the decision boundary and the nearest data points.",
          "Kernel Trick: Mapping data into high-dimensional spaces to solve non-linear problems.",
          "Support Vectors: The critical data points that define the boundary."
        ],
        "impact": [
          "Became the most popular machine learning algorithm before the deep learning era.",
          "Highly effective for high-dimensional data with limited samples."
        ],
        "relevance": [
          "A robust alternative to neural networks for many classification and regression tasks."
        ]
      }
    },
    "research/WORD2VEC_2013": {
      "id": "research/WORD2VEC_2013",
      "category": "research",
      "title": "Efficient Estimation of Word Representations in Vector Space (2013)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Mikolov et al. introduced Word2Vec, a method for learning high-quality vector representations of words from large datasets.",
      "terms": [
        "word2vec",
        "embeddings",
        "nlp",
        "vector space",
        "skip-gram",
        "continuous bag of words"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Addressed the high computational cost of earlier neural language models.",
          "Showed that simple architectures could learn semantic relationships (e.g., King - Man + Woman = Queen)."
        ],
        "concepts": [
          "CBOW: Predicting a word based on its context.",
          "Skip-gram: Predicting context words based on a single word.",
          "Negative Sampling: Optimizing training by only updating a small subset of weights."
        ],
        "impact": [
          "Popularized the use of word embeddings in NLP.",
          "Enabled transfer learning in text processing by providing pre-trained vectors."
        ],
        "relevance": [
          "Foundation for how modern LLMs represent and process text as high-dimensional vectors."
        ]
      }
    },
    "research/GAN_2014": {
      "id": "research/GAN_2014",
      "category": "research",
      "title": "Generative Adversarial Nets (2014)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Ian Goodfellow et al. introduced GANs, a framework for training generative models using a game-theoretic approach.",
      "terms": [
        "gan",
        "generative ai",
        "adversarial",
        "generator",
        "discriminator",
        "synthetic data"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Addressed the difficulty of training deep generative models.",
          "Framed the problem as a competition between two networks."
        ],
        "concepts": [
          "Generator: Tries to create data that looks real.",
          "Discriminator: Tries to distinguish between real data and generated data.",
          "Adversarial Training: The two networks improve each other through competition."
        ],
        "impact": [
          "Triggered a massive surge in generative AI research.",
          "Enabled the creation of highly realistic images, videos, and audio (and deepfakes)."
        ],
        "relevance": [
          "Key architecture for creating synthetic data and artistic generation."
        ]
      }
    },
    "research/BERT_2018": {
      "id": "research/BERT_2018",
      "category": "research",
      "title": "BERT: Pre-training for Language Understanding (2018)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced a bidirectional approach to Transformer pre-training, significantly improving performance on NLP tasks.",
      "terms": [
        "bert",
        "transformer",
        "nlp",
        "pre-training",
        "bidirectional",
        "transfer learning"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Addressed the limitation of earlier models (like GPT) which were only unidirectional (left-to-right).",
          "Designed to pre-train deep representations that could be fine-tuned for many tasks."
        ],
        "concepts": [
          "Masked Language Model (MLM): Predicting hidden words in a sentence using both left and right context.",
          "Next Sentence Prediction (NSP): Learning relationships between sentences.",
          "Fine-tuning: Adding a task-specific layer on top of the pre-trained model."
        ],
        "impact": [
          "Became the new state-of-the-art for almost all NLP benchmarks.",
          "Powering Google Search and many other text-understanding applications."
        ],
        "relevance": [
          "Standard reference for encoder-only transformer architectures."
        ]
      }
    },
    "research/VIT_2021": {
      "id": "research/VIT_2021",
      "category": "research",
      "title": "Vision Transformer (ViT): Image Recognition at Scale (2021)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Showed that the Transformer architecture could be applied directly to images, outperforming CNNs on large datasets.",
      "terms": [
        "vit",
        "vision transformer",
        "computer vision",
        "transformer",
        "scaling",
        "image patches"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Challenged the dominance of Convolutional Neural Networks in computer vision.",
          "Aimed to unify computer vision and NLP under a single architecture."
        ],
        "concepts": [
          "Image Patches: Breaking images into small squares and treating them like words in a sentence.",
          "Linear Projection: Flattening patches into vectors.",
          "Standard Transformer Encoder: Using self-attention to learn relationships between patches."
        ],
        "impact": [
          "Proved that pure Transformers scale better than CNNs for vision tasks.",
          "Led to the development of many hybrid and specialized vision architectures."
        ],
        "relevance": [
          "Crucial for understanding the convergence of vision and language models."
        ]
      }
    },
    "research/ALPHAFOLD_2021": {
      "id": "research/ALPHAFOLD_2021",
      "category": "research",
      "title": "Highly accurate protein structure prediction with AlphaFold (2021)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "DeepMind's AlphaFold 2 solved the 50-year-old challenge of protein folding using deep learning.",
      "terms": [
        "alphafold",
        "biology",
        "protein folding",
        "deep learning",
        "science",
        "3d structure"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Addressed the 'protein folding problem': predicting a protein's 3D shape from its amino acid sequence.",
          "A fundamental problem in biology with huge implications for drug discovery."
        ],
        "concepts": [
          "Evoformer: A specialized block for processing evolutionary and spatial information.",
          "Invariant Point Attention: Predicting the geometry of the protein backbone.",
          "End-to-End Prediction: Learning directly from experimental data."
        ],
        "impact": [
          "Provided highly accurate predictions for almost all known proteins.",
          "Accelerated research in drug development, synthetic biology, and disease understanding."
        ],
        "relevance": [
          "A premier example of AI solving hard physical science problems."
        ]
      }
    },
    "research/LORA_2021": {
      "id": "research/LORA_2021",
      "category": "research",
      "title": "LoRA: Low-Rank Adaptation of Large Language Models (2021)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced an efficient method for fine-tuning LLMs by injecting trainable low-rank matrices into the model.",
      "terms": [
        "lora",
        "fine-tuning",
        "efficiency",
        "llm",
        "peft",
        "adaptation"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Addressed the extreme cost of fine-tuning models with billions of parameters.",
          "Aimed at making model customization accessible on consumer hardware."
        ],
        "concepts": [
          "Low-Rank Decomposition: Representing weight changes as the product of two much smaller matrices.",
          "Frozen Base Model: Keeping original weights unchanged to save memory.",
          "Additivity: Learning an incremental 'patch' rather than retraining the whole model."
        ],
        "impact": [
          "Enabled the explosion of custom 'community models' and fine-tunes.",
          "Became the standard for efficient Parameter-Efficient Fine-Tuning (PEFT)."
        ],
        "relevance": [
          "Essential for anyone customizing agents or local LLMs."
        ]
      }
    },
    "research/COT_2022": {
      "id": "research/COT_2022",
      "category": "research",
      "title": "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models (2022)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Showed that prompting LLMs to show their work significantly improves performance on complex reasoning tasks.",
      "terms": [
        "chain of thought",
        "reasoning",
        "prompting",
        "llm",
        "emergent abilities",
        "few-shot"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Explored how LLMs handle multi-step arithmetic, symbolic, and commonsense reasoning.",
          "Found that standard prompting often fails on complex logic."
        ],
        "concepts": [
          "Intermediate Steps: Asking the model to generate a 'rationale' before the final answer.",
          "System 1 vs System 2: Moving from intuitive reaction to deliberate reasoning.",
          "Elicitation: Showing that reasoning is an emergent ability triggered by specific input patterns."
        ],
        "impact": [
          "Transformed prompt engineering and agent design.",
          "Led to techniques like Self-Consistency and Tree of Thoughts."
        ],
        "relevance": [
          "The core principle behind modern 'reasoning' agents."
        ]
      }
    },
    "research/RLHF_2022": {
      "id": "research/RLHF_2022",
      "category": "research",
      "title": "Training language models to follow instructions with human feedback (2022)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced RLHF (Reinforcement Learning from Human Feedback), the technique used to align GPT-3 into InstructGPT and ChatGPT.",
      "terms": [
        "rlhf",
        "alignment",
        "human feedback",
        "ppo",
        "instructions",
        "safety"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Addressed the 'alignment problem': models generating toxic, false, or unhelpful content despite high performance.",
          "Aimed to make models follow human intent more accurately."
        ],
        "concepts": [
          "Reward Model: Training a separate network to predict human preferences.",
          "PPO (Proximal Policy Optimization): Using reinforcement learning to tune the LLM towards higher rewards.",
          "Alignment: Bridging the gap between 'predict next token' and 'solve the user's task'."
        ],
        "impact": [
          "Enabled the public release of helpful and safe AI assistants (ChatGPT, Claude).",
          "Became the standard method for aligning large foundation models."
        ],
        "relevance": [
          "Critical for understanding why modern agents are so much more usable than raw base models."
        ]
      }
    },
    "research/DIFFUSION_2020": {
      "id": "research/DIFFUSION_2020",
      "category": "research",
      "title": "Denoising Diffusion Probabilistic Models (2020)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced the modern diffusion-based approach to image generation, the core of Stable Diffusion and Midjourney.",
      "terms": [
        "diffusion",
        "generative ai",
        "denoising",
        "stable diffusion",
        "latent space",
        "image synthesis"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "A new class of generative models that outperformed GANs in stability and sample quality.",
          "Based on the physical concept of diffusion (adding noise and then reversing it)."
        ],
        "concepts": [
          "Forward Process: Gradually adding Gaussian noise to an image until it's just white noise.",
          "Reverse Process: Training a model (U-Net) to remove the noise step-by-step.",
          "Denoising Score Matching: Predicting the noise added at each step."
        ],
        "impact": [
          "Replaced GANs as the state-of-the-art for high-resolution image generation.",
          "Led to the 'generative art' explosion of 2021-2022."
        ],
        "relevance": [
          "Fundamental for understanding modern image and video synthesis systems."
        ]
      }
    },
    "research/BATCH_NORM_2015": {
      "id": "research/BATCH_NORM_2015",
      "category": "research",
      "title": "Batch Normalization: Accelerating Deep Network Training (2015)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced Batch Normalization, allowing for significantly faster training and more stable deep networks.",
      "terms": [
        "batch normalization",
        "optimization",
        "deep learning",
        "regularization",
        "training",
        "stability"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Addressed the problem of 'internal covariate shift': the distribution of each layer's inputs changing as parameters change.",
          "Aimed at enabling higher learning rates and reducing sensitivity to initialization."
        ],
        "concepts": [
          "Normalization: Scaling layer inputs to have zero mean and unit variance.",
          "Learnable Parameters: Adding scale (gamma) and shift (beta) parameters that the network can learn.",
          "Mini-batch Statistics: Computing mean and variance over the current training batch."
        ],
        "impact": [
          "Became a standard component in almost every deep neural network (ResNet, etc.).",
          "Reduced the need for careful weight initialization and dropout."
        ],
        "relevance": [
          "Foundational trick for making deep models converge reliably."
        ]
      }
    },
    "research/ADAM_2014": {
      "id": "research/ADAM_2014",
      "category": "research",
      "title": "Adam: A Method for Stochastic Optimization (2014)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced the Adam optimizer, combining the benefits of AdaGrad and RMSProp for efficient deep learning training.",
      "terms": [
        "adam",
        "optimizer",
        "gradient descent",
        "stochastic",
        "deep learning",
        "training"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Addressed the limitations of standard SGD (Stochastic Gradient Descent) on sparse gradients and noisy data.",
          "Aimed for an optimizer with low memory requirements and intuitive hyperparameters."
        ],
        "concepts": [
          "Adaptive Learning Rates: Computing individual rates for different parameters.",
          "Momentum: Using the moving average of gradients.",
          "Bias Correction: Adjusting estimates for the initial steps of training."
        ],
        "impact": [
          "Became the default optimizer for most deep learning practitioners.",
          "Enabled faster training of complex architectures across many domains."
        ],
        "relevance": [
          "The most commonly used optimization algorithm in modern AI training."
        ]
      }
    },
    "research/DROPOUT_2014": {
      "id": "research/DROPOUT_2014",
      "category": "research",
      "title": "Dropout: A Simple Way to Prevent Neural Networks from Overfitting (2014)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced Dropout, a highly effective regularization technique for deep neural networks.",
      "terms": [
        "dropout",
        "regularization",
        "overfitting",
        "deep learning",
        "generalization",
        "ensembling"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Addressed 'overfitting': models performing well on training data but poorly on unseen data.",
          "Inspired by how sexual reproduction prevents co-adaptation of genes."
        ],
        "concepts": [
          "Random Deactivation: Randomly dropping out neurons (setting to zero) during each training step.",
          "Ensemble Effect: Forcing the network to learn redundant representations.",
          "Inference Scaling: Using all neurons but scaling their outputs by the dropout probability."
        ],
        "impact": [
          "Significantly improved the generalization of deep networks.",
          "Became a staple in almost all vision and language models before Batch Norm."
        ],
        "relevance": [
          "Core concept in robust model design and regularization."
        ]
      }
    },
    "research/YOLO_2016": {
      "id": "research/YOLO_2016",
      "category": "research",
      "title": "You Only Look Once: Unified, Real-Time Object Detection (2016)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced YOLO, the first architecture to perform object detection as a single regression problem, enabling real-time speeds.",
      "terms": [
        "yolo",
        "object detection",
        "computer vision",
        "real-time",
        "deep learning",
        "bounding boxes"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Prior detection systems (like R-CNN) were multi-stage and very slow.",
          "Aimed at enabling computer vision for robots, self-driving cars, and real-time video."
        ],
        "concepts": [
          "Single Pass: Predicting all bounding boxes and class probabilities at once.",
          "Grid Cells: Dividing the image into a grid, where each cell is responsible for detections.",
          "Global Context: Seeing the whole image during training and testing."
        ],
        "impact": [
          "Revolutionized real-time computer vision.",
          "Led to a long series of YOLO versions (v2-v11) used across industry."
        ],
        "relevance": [
          "Key reference for high-efficiency, real-world vision applications."
        ]
      }
    },
    "research/DQN_2013": {
      "id": "research/DQN_2013",
      "category": "research",
      "title": "Playing Atari with Deep Reinforcement Learning (2013)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "DeepMind showed that a single deep learning model could learn to play multiple Atari games from raw pixels alone.",
      "terms": [
        "dqn",
        "reinforcement learning",
        "q-learning",
        "atari",
        "pixels",
        "experience replay"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "The first successful combination of deep learning and reinforcement learning (Deep RL).",
          "Aimed at creating 'general' AI that could solve diverse tasks without task-specific engineering."
        ],
        "concepts": [
          "Deep Q-Network: Using a CNN to estimate the value of different actions.",
          "Experience Replay: Storing past transitions and sampling them randomly to break correlations.",
          "Target Network: Using a separate, stable network to compute learning targets."
        ],
        "impact": [
          "Brought RL into the deep learning era.",
          "Led directly to AlphaGo and many other achievements in robotics and strategy."
        ],
        "relevance": [
          "Foundation for autonomous agents that learn through trial and error."
        ]
      }
    },
    "research/GNN_2008": {
      "id": "research/GNN_2008",
      "category": "research",
      "title": "The Graph Neural Network Model (2008)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced Graph Neural Networks (GNNs), extending deep learning to non-Euclidean data structured as graphs.",
      "terms": [
        "gnn",
        "graph neural networks",
        "topology",
        "relational data",
        "non-euclidean",
        "representation learning"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Standard CNNs and RNNs assume grid-like (images) or sequential (text) data.",
          "Many real-world problems (social networks, molecules, power grids) are best modeled as graphs."
        ],
        "concepts": [
          "Message Passing: Nodes update their state by aggregating information from neighbors.",
          "Neighborhood Aggregation: Combining feature vectors from adjacent nodes.",
          "Graph Symmetries: Ensuring the model is invariant to node permutations."
        ],
        "impact": [
          "Revolutionized drug discovery, recommendation engines, and fraud detection.",
          "Became the standard for processing relational and topological data."
        ],
        "relevance": [
          "Essential for building AI that understands complex systems and relationships."
        ]
      }
    },
    "research/CLIP_2021": {
      "id": "research/CLIP_2021",
      "category": "research",
      "title": "Learning Transferable Visual Models from Natural Language Supervision (2021)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "OpenAI's CLIP unified vision and language by learning to connect images with their natural language descriptions.",
      "terms": [
        "clip",
        "multimodal",
        "vision-language",
        "contrastive learning",
        "zero-shot",
        "openai"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Aimed at creating vision models that don't need fixed labels (like 'dog' vs 'cat') and can understand any concept.",
          "Used a massive dataset of 400 million image-text pairs from the internet."
        ],
        "concepts": [
          "Contrastive Pre-training: Predicting which text goes with which image in a batch.",
          "Dual Encoder: One Transformer for text, one for images.",
          "Zero-Shot Transfer: Using the text encoder as a 'classifier' for any new concept."
        ],
        "impact": [
          "The 'bridge' that enabled Stable Diffusion and DALL-E.",
          "Revolutionized how we think about multimodal AI."
        ],
        "relevance": [
          "Key technology for agents that need to see and talk about the world simultaneously."
        ]
      }
    },
    "research/LLAMA_2023": {
      "id": "research/LLAMA_2023",
      "category": "research",
      "title": "LLaMA: Open and Efficient Foundation Language Models (2023)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Meta's LLaMA showed that smaller, well-trained models can outperform much larger ones, igniting the open-source LLM movement.",
      "terms": [
        "llama",
        "open-source",
        "llm",
        "efficiency",
        "scaling laws",
        "meta"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Aimed at providing high-performance models that can run on affordable hardware.",
          "Challenged the 'bigger is always better' paradigm of GPT-3/4."
        ],
        "concepts": [
          "Chinchilla Scaling: Training models on much more data than previously thought optimal.",
          "Transformer Improvements: Using Pre-normalization, SwiGLU activation, and Rotary Embeddings.",
          "Efficiency: Optimized training on thousands of GPUs."
        ],
        "impact": [
          "Triggered the 'LLaMA moment': a massive wave of open-source AI innovation.",
          "Enabled the creation of Alpaca, Vicuna, and thousands of other local models."
        ],
        "relevance": [
          "The most important reference for the current state of open AI weights and local deployment."
        ]
      }
    },
    "research/VON_NEUMANN_1945": {
      "id": "research/VON_NEUMANN_1945",
      "category": "research",
      "title": "First Draft of a Report on the EDVAC (1945)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "John von Neumann described the foundational architecture of the modern computer, featuring a stored-program design.",
      "terms": [
        "von neumann",
        "architecture",
        "stored-program",
        "cpu",
        "memory",
        "foundations"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Written during the design of the EDVAC, one of the first electronic computers.",
          "Moved away from computers that were hard-wired for specific tasks."
        ],
        "concepts": [
          "Von Neumann Architecture: CPU, Control Unit, Registers, and Memory.",
          "Stored-Program: Both data and instructions are stored in the same memory space.",
          "The Bottleneck: The limited throughput between CPU and memory."
        ],
        "impact": [
          "The template for virtually every computer built in the last 80 years.",
          "Defined the core components and fetch-decode-execute cycle."
        ],
        "relevance": [
          "The absolute starting point for understanding how hardware functions."
        ]
      }
    },
    "research/BTREE_1972": {
      "id": "research/BTREE_1972",
      "category": "research",
      "title": "Organization and Maintenance of Large Ordered Indices (1972)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Bayer and McCreight introduced the B-Tree, the fundamental data structure for disk-based storage and databases.",
      "terms": [
        "b-tree",
        "data structures",
        "indexing",
        "database",
        "disk storage",
        "search"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Addressed the need for an efficient way to index massive amounts of data stored on slow spinning disks.",
          "Aimed at minimizing the number of disk reads (I/O) required to find an item."
        ],
        "concepts": [
          "Multi-way Search Tree: Nodes can have more than two children.",
          "Self-Balancing: The tree stays perfectly balanced, ensuring O(log N) performance.",
          "Page-aligned: Nodes are sized to match hardware disk pages."
        ],
        "impact": [
          "The basis for indices in almost every relational database (Postgres, MySQL, SQLite).",
          "Enabled efficient search and range queries on massive datasets."
        ],
        "relevance": [
          "Essential knowledge for database optimization and storage engine design."
        ]
      }
    },
    "research/RAID_1988": {
      "id": "research/RAID_1988",
      "category": "research",
      "title": "A Case for Redundant Arrays of Inexpensive Disks (RAID) (1988)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Patterson et al. introduced RAID, a method for combining multiple cheap disks to improve performance and reliability.",
      "terms": [
        "raid",
        "storage",
        "redundancy",
        "reliability",
        "performance",
        "availability"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Challenged the use of single, expensive, large disks (SLED).",
          "Proposed using many small, cheap disks in parallel."
        ],
        "concepts": [
          "Striping: Spreading data across disks for speed (RAID 0).",
          "Mirroring: Copying data for redundancy (RAID 1).",
          "Parity: Using math to reconstruct data if a disk fails (RAID 5)."
        ],
        "impact": [
          "The standard for server storage and enterprise data protection.",
          "Enabled high-availability storage systems that can survive hardware failure."
        ],
        "relevance": [
          "Core concept for understanding infrastructure reliability and storage throughput."
        ]
      }
    },
    "research/VIRTUAL_MEMORY_1962": {
      "id": "research/VIRTUAL_MEMORY_1962",
      "category": "research",
      "title": "One-Level Storage System (1962)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "The Atlas computer team introduced Virtual Memory, allowing programs to use more memory than physically available.",
      "terms": [
        "virtual memory",
        "paging",
        "mmu",
        "os",
        "memory management",
        "abstraction"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Early computers required programmers to manually manage data movement between RAM and drum storage (overlays).",
          "The Atlas team at Manchester University aimed to automate this."
        ],
        "concepts": [
          "Paging: Dividing memory into fixed-size blocks.",
          "Address Translation: Mapping virtual addresses used by programs to physical hardware addresses.",
          "Demand Paging: Loading data into RAM only when it's accessed."
        ],
        "impact": [
          "Revolutionized operating system design and programmer productivity.",
          "The basis for process isolation and secure memory protection in modern OSs."
        ],
        "relevance": [
          "Fundamental for understanding how operating systems handle memory and isolation."
        ]
      }
    },
    "research/LFS_1992": {
      "id": "research/LFS_1992",
      "category": "research",
      "title": "The Design and Implementation of a Log-Structured File System (1992)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced the Log-Structured File System (LFS), optimized for high-speed writes by treating the entire disk as a log.",
      "terms": [
        "lfs",
        "file system",
        "log-structured",
        "storage",
        "performance",
        "write optimization"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Recognized that CPU and RAM speeds were increasing much faster than disk seek times.",
          "Aimed at turning small, random writes into large, sequential writes."
        ],
        "concepts": [
          "Append-only: All new data and metadata are written to the end of the log.",
          "Segment Cleaning: A 'garbage collector' that reclaims space from deleted files.",
          "Fast Recovery: Using checkpoints to recover quickly after a crash."
        ],
        "impact": [
          "Inspired modern file systems like ZFS and many NoSQL database storage engines.",
          "Particularly relevant for SSDs, which prefer sequential-like write patterns."
        ],
        "relevance": [
          "Crucial for understanding high-performance storage and write-heavy workloads."
        ]
      }
    },
    "research/LSM_TREE_1996": {
      "id": "research/LSM_TREE_1996",
      "category": "research",
      "title": "The Log-Structured Merge-Tree (LSM-Tree) (1996)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "O'Neil et al. introduced the LSM-Tree, the data structure behind high-throughput NoSQL databases like Cassandra and RocksDB.",
      "terms": [
        "lsm-tree",
        "nosql",
        "storage engine",
        "write throughput",
        "compaction",
        "database"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Designed to provide much higher write throughput than B-Trees by avoiding random disk seeks.",
          "Optimized for systems that receive a massive stream of incoming data."
        ],
        "concepts": [
          "Memtable: In-memory buffer for incoming writes.",
          "SSTables: Sorted, immutable files on disk.",
          "Compaction: Background process that merges and deduplicates SSTables."
        ],
        "impact": [
          "The foundation for modern distributed databases (Bigtable, Cassandra, LevelDB).",
          "Enabled the 'Big Data' era by providing ultra-fast write performance."
        ],
        "relevance": [
          "Key knowledge for choosing and tuning modern database storage engines."
        ]
      }
    },
    "research/HYPERLOGLOG_2007": {
      "id": "research/HYPERLOGLOG_2007",
      "category": "research",
      "title": "HyperLogLog: Cardinality Estimation Algorithm (2007)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced a probabilistic algorithm for estimating the number of unique elements in a massive dataset with very little memory.",
      "terms": [
        "hyperloglog",
        "hll",
        "probabilistic algorithm",
        "cardinality",
        "big data",
        "approximation"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Counting unique items (e.g., daily active users) exactly requires O(N) memory, which is impossible at scale.",
          "Aimed at providing a near-exact count with constant memory."
        ],
        "concepts": [
          "Hashing: Mapping elements to random bit strings.",
          "Maximum Zeros: Estimating count based on the longest run of leading zeros seen in the hashes.",
          "Harmonic Mean: Combining multiple estimates to improve accuracy."
        ],
        "impact": [
          "Used by Redis, BigQuery, and Google for real-time analytics on billions of items.",
          "Standard tool for high-scale data engineering."
        ],
        "relevance": [
          "Teaches the power of approximation in solving 'impossible' scaling problems."
        ]
      }
    },
    "research/WAIT_FREE_1991": {
      "id": "research/WAIT_FREE_1991",
      "category": "research",
      "title": "Wait-Free Synchronization (1991)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Maurice Herlihy introduced the concept of wait-free synchronization, enabling concurrent data structures that never block.",
      "terms": [
        "wait-free",
        "lock-free",
        "concurrency",
        "synchronization",
        "non-blocking",
        "parallelism"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Locks (Mutexes) can lead to deadlocks, priority inversion, and performance bottlenecks in multi-core systems.",
          "Aimed at proving that any object can be implemented without locks."
        ],
        "concepts": [
          "Wait-Freedom: Every thread makes progress in a finite number of steps regardless of others.",
          "Lock-Freedom: At least one thread is guaranteed to make progress.",
          "CAS (Compare-and-Swap): The foundational atomic hardware primitive for non-blocking sync."
        ],
        "impact": [
          "Led to the development of ultra-high-performance concurrent queues and maps.",
          "Standard practice for high-frequency trading and low-level kernel programming."
        ],
        "relevance": [
          "Critical for building highly parallel systems that don't scale linearly with lock contention."
        ]
      }
    },
    "research/MESI_1984": {
      "id": "research/MESI_1984",
      "category": "research",
      "title": "MESI Protocol: Cache Coherence for Multiprocessors (1984)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced the MESI protocol, the foundation of cache coherence in modern multi-core CPUs.",
      "terms": [
        "mesi",
        "cache coherence",
        "cpu",
        "multi-core",
        "memory",
        "hardware"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "In multi-core systems, multiple CPUs have their own local caches. What happens if they all try to edit the same memory address?",
          "Aimed to prevent inconsistent data across cores."
        ],
        "concepts": [
          "States: Modified, Exclusive, Shared, Invalid.",
          "Snooping: Cores monitoring the memory bus to see what others are doing.",
          "Invalidation: Telling other cores to discard their cached copy when you write to a value."
        ],
        "impact": [
          "The reason multi-core programming works 'automatically' for most developers.",
          "Defined how hardware handles the 'distributed system' inside a single chip."
        ],
        "relevance": [
          "Fundamental for understanding true hardware-level concurrency and memory visibility."
        ]
      }
    },
    "research/EBPF_1993": {
      "id": "research/EBPF_1993",
      "category": "research",
      "title": "The BSD Packet Filter: A New Architecture for User-level Packet Capture (1993)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced BPF, which evolved into eBPF: a way to run safe, sandboxed programs inside the operating system kernel.",
      "terms": [
        "ebpf",
        "bpf",
        "kernel",
        "linux",
        "networking",
        "observability",
        "security"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Traditional packet filtering required copying every packet to user-space, which was too slow.",
          "Aimed to provide a programmable, high-performance filter inside the kernel."
        ],
        "concepts": [
          "Virtual Machine: A simple, registers-based VM inside the kernel.",
          "JIT Compilation: Compiling BPF code into native machine code at runtime.",
          "Safety Verification: Ensuring the code can't crash the kernel or loop infinitely."
        ],
        "impact": [
          "Transformed Linux into a fully programmable kernel.",
          "Enabled a new generation of tools for networking (Cilium), observability (Pixie), and security (Falco)."
        ],
        "relevance": [
          "The modern 'superpower' for system engineering and deep observability."
        ]
      }
    },
    "research/L4_1995": {
      "id": "research/L4_1995",
      "category": "research",
      "title": "On Micro-Kernel Construction (1995)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Jochen Liedtke introduced L4, proving that microkernels could be as fast as traditional monolithic kernels.",
      "terms": [
        "microkernel",
        "l4",
        "os",
        "kernel",
        "ipc",
        "isolation",
        "security"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Early microkernels (like Mach) were slow because of high IPC (Inter-Process Communication) overhead.",
          "Aimed to move as much as possible out of the kernel into user-space safely."
        ],
        "concepts": [
          "Minimalism: Only Address Space, Thread Management, and IPC stay in the kernel.",
          "Fast IPC: Highly optimized message passing between processes.",
          "Mechanism vs Policy: The kernel provides the tools; user-space defines how to use them."
        ],
        "impact": [
          "Used in highly secure systems and embedded devices (e.g., Apple's Secure Enclave).",
          "Influenced modern 'modular' kernel designs."
        ],
        "relevance": [
          "Teaches the ultimate trade-off between isolation/security and performance."
        ]
      }
    },
    "research/BORG_2015": {
      "id": "research/BORG_2015",
      "category": "research",
      "title": "Large-scale cluster management at Google with Borg (2015)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Google finally revealed Borg, the internal system that manages their entire global fleet and inspired Kubernetes.",
      "terms": [
        "borg",
        "kubernetes",
        "cluster management",
        "orchestration",
        "containers",
        "google"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "How does Google run millions of containers across thousands of clusters?",
          "Aimed at maximizing resource utilization and simplifying application deployment."
        ],
        "concepts": [
          "Jobs and Tasks: The basic units of work (similar to K8s Deployments and Pods).",
          "Allocations: Reserved resources for specific tasks.",
          "Resource Reclamation: Over-subscribing resources to avoid wasting idle CPU/RAM."
        ],
        "impact": [
          "The direct ancestor of Kubernetes.",
          "Proved that 'the data center is the computer' at massive scale."
        ],
        "relevance": [
          "Essential for understanding the philosophy and design of modern cloud orchestration."
        ]
      }
    },
    "research/DREMEL_2010": {
      "id": "research/DREMEL_2010",
      "category": "research",
      "title": "Dremel: Interactive Analysis of Web-Scale Datasets (2010)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced the columnar storage format and execution engine that powers Google BigQuery and Apache Parquet.",
      "terms": [
        "dremel",
        "bigquery",
        "columnar storage",
        "analytics",
        "big data",
        "parquet"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Traditional row-based databases are slow for scanning billions of records for a single column (e.g., 'sum all sales').",
          "Aimed at interactive-speed queries on petabytes of data."
        ],
        "concepts": [
          "Columnar Storage: Storing all values for a column together on disk.",
          "Nested Data: A method for storing complex JSON-like structures in columns efficiently.",
          "Multi-level Execution Trees: Distributing query execution across thousands of nodes."
        ],
        "impact": [
          "Enabled the modern cloud data warehouse industry.",
          "Inspired Apache Parquet and Apache Drill."
        ],
        "relevance": [
          "Foundational knowledge for data engineering and analytical query optimization."
        ]
      }
    },
    "research/MILLWHEEL_2013": {
      "id": "research/MILLWHEEL_2013",
      "category": "research",
      "title": "MillWheel: Fault-Tolerant Stream Processing at Internet Scale (2013)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Described Google's framework for low-latency, stateful stream processing, leading to Google Cloud Dataflow.",
      "terms": [
        "millwheel",
        "stream processing",
        "dataflow",
        "low latency",
        "stateful",
        "exactly-once"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "How do you process data in real-time while ensuring you never lose a single event, even if servers crash?",
          "Aimed at exactly-once processing with high availability."
        ],
        "concepts": [
          "Persistent State: Automatic checkpointing of application state to stable storage.",
          "Watermarks: Tracking progress through event-time to handle late-arriving data.",
          "Exactly-once: Ensuring every record affects the output exactly once."
        ],
        "impact": [
          "Defined the 'Dataflow Model' for unified batch and stream processing.",
          "Led to Apache Beam and Google Cloud Dataflow."
        ],
        "relevance": [
          "The gold standard for reliable, real-time data pipelines."
        ]
      }
    },
    "research/ZFS_2003": {
      "id": "research/ZFS_2003",
      "category": "research",
      "title": "ZFS: The Last Word in File Systems (2003)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Sun Microsystems introduced ZFS, combining file system and volume management with absolute data integrity.",
      "terms": [
        "zfs",
        "file system",
        "data integrity",
        "checksums",
        "copy-on-write",
        "snapshots"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Traditional file systems were vulnerable to 'bit rot' and silent data corruption on disk.",
          "Aimed at ensuring that what you read is EXACTLY what you wrote."
        ],
        "concepts": [
          "Merkle Trees: Hierarchical checksums for every piece of data and metadata.",
          "Copy-on-Write: Never overwriting data; writing changes to new blocks instead.",
          "Pooled Storage: Removing the rigid boundary between file system and physical disk."
        ],
        "impact": [
          "Became the preferred choice for enterprise storage and high-reliability servers.",
          "Introduced advanced features like instant snapshots and compression as defaults."
        ],
        "relevance": [
          "The definitive reference for data durability and 'self-healing' storage."
        ]
      }
    },
    "research/CONTAINERS_2007": {
      "id": "research/CONTAINERS_2007",
      "category": "research",
      "title": "Operating System-level Virtualization (2007)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Early research and implementation of Linux Namespaces and Cgroups, the technologies that enable Docker.",
      "terms": [
        "containers",
        "docker",
        "namespaces",
        "cgroups",
        "virtualization",
        "isolation"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Traditional Virtual Machines (VMs) are heavy and slow because they run a full guest OS.",
          "Aimed at providing isolation with near-zero performance overhead."
        ],
        "concepts": [
          "Namespaces: Isolating what a process can SEE (Network, PID, Mount).",
          "Cgroups: Controlling how much a process can USE (CPU, RAM, I/O).",
          "Shared Kernel: All containers use the host OS kernel, making them ultra-lightweight."
        ],
        "impact": [
          "Enabled the modern 'Cloud Native' and microservices revolution.",
          "The technical foundation for Docker, Kubernetes, and Serverless."
        ],
        "relevance": [
          "Fundamental for understanding how modern applications are packaged and isolated."
        ]
      }
    },
    "research/BLOOM_FILTER_1970": {
      "id": "research/BLOOM_FILTER_1970",
      "category": "research",
      "title": "Space/Time Trade-offs in Hash Coding with Allowable Errors (1970)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Burton Bloom introduced the Bloom Filter, a space-efficient probabilistic data structure for set membership testing.",
      "terms": [
        "bloom filter",
        "data structures",
        "probabilistic",
        "hashing",
        "memory",
        "efficiency"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Checking if an item exists in a set usually requires storing the whole set.",
          "Aimed at a method that uses much less space, at the cost of a small chance of false positives."
        ],
        "concepts": [
          "Bit Array: A simple array of 0s and 1s.",
          "Multiple Hash Functions: Setting multiple bits for each inserted item.",
          "No False Negatives: If the filter says 'No', it's definitely not there. If it says 'Yes', it might be there."
        ],
        "impact": [
          "Widely used in databases (Bigtable, Cassandra) to avoid unnecessary disk lookups.",
          "Essential for web caches, spell checkers, and network routers."
        ],
        "relevance": [
          "Classic example of trading exactness for extreme efficiency."
        ]
      }
    },
    "research/REDBLACK_TREE_1978": {
      "id": "research/REDBLACK_TREE_1978",
      "category": "research",
      "title": "A Dichromatic Framework for Balanced Trees (1978)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Guibas and Sedgewick formalized Red-Black Trees, the most common self-balancing binary search tree.",
      "terms": [
        "red-black tree",
        "data structures",
        "balanced tree",
        "search",
        "binary search tree",
        "algorithms"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Standard binary search trees can become unbalanced (O(N) performance).",
          "Aimed for a tree that stays balanced (O(log N)) with minimal rotation overhead."
        ],
        "concepts": [
          "Coloring: Each node is either Red or Black.",
          "Balance Rules: No two red nodes can be adjacent; every path from root to leaf must have the same number of black nodes.",
          "Rotations: Simple operations to restore balance after insertion or deletion."
        ],
        "impact": [
          "The default balanced tree in most standard libraries (e.g., C++ std::map, Java TreeMap).",
          "Provides highly predictable performance for in-memory data."
        ],
        "relevance": [
          "Core data structure knowledge for every software engineer."
        ]
      }
    },
    "research/SPECTRE_MELTDOWN_2018": {
      "id": "research/SPECTRE_MELTDOWN_2018",
      "category": "research",
      "title": "Spectre Attacks: Exploiting Speculative Execution (2018)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Revealed a massive hardware vulnerability where CPUs leak sensitive data during performance-boosting speculative execution.",
      "terms": [
        "spectre",
        "meltdown",
        "cpu",
        "speculative execution",
        "side-channel",
        "security",
        "hardware"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Modern CPUs use 'branch prediction' to guess future instructions and execute them early to save time.",
          "Found that this leaves a 'side-channel' that can be read by malicious code."
        ],
        "concepts": [
          "Speculative Execution: Executing code before we're sure it should run.",
          "Cache Timing: Measuring how long a memory access takes to see if data was speculatively loaded.",
          "Transient Instructions: Instructions that run but are later 'undone' - except for their effect on the cache."
        ],
        "impact": [
          "Forced the redesign of OS kernels and browser security models.",
          "Showed that performance and security are often in direct conflict at the hardware level."
        ],
        "relevance": [
          "Critical warning for anyone building multi-tenant or security-sensitive systems."
        ]
      }
    },
    "research/RDMA_2003": {
      "id": "research/RDMA_2003",
      "category": "research",
      "title": "Remote Direct Memory Access over Ethernet (2003)",
      "authority": "doctrine",
      "binding": "advisory",
      "summary": "Introduced RDMA, allowing one computer to access the memory of another without involving either computer's OS kernel.",
      "terms": [
        "rdma",
        "networking",
        "low latency",
        "zero-copy",
        "infiniband",
        "high performance"
      ],
      "links": {
        "references": [
          "methodology/RESEARCH"
        ],
        "referenced_by": [
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "context": [
          "Traditional TCP/IP networking is too slow for supercomputers and high-speed database clusters because of kernel overhead.",
          "Aimed at 'Zero-Copy' data transfer."
        ],
        "concepts": [
          "Kernel Bypass: Hardware-to-hardware communication skipping the OS.",
          "Direct Memory Access: One machine's NIC writing directly into another machine's RAM.",
          "Low Latency: Microsecond-scale communication for distributed systems."
        ],
        "impact": [
          "The foundation of high-performance computing (HPC) and modern high-speed data centers.",
          "Enables ultra-fast distributed databases like RAMCloud and Microsoft's Azure storage."
        ],
        "relevance": [
          "The 'elite' tier of networking for building ultra-low-latency distributed systems."
        ]
      }
    },
    "core/RESEARCH": {
      "id": "core/RESEARCH",
      "category": "core",
      "title": "Research Discovery Surface",
      "authority": "namespace-router",
      "binding": "binding",
      "summary": "Route literature review and academic inquiry into seminal computer science papers.",
      "terms": [
        "research",
        "papers",
        "seminal",
        "theory",
        "proof",
        "foundations",
        "distributed",
        "ai",
        "hardware",
        "systems"
      ],
      "links": {
        "references": [
          "research/ADAM_2014",
          "research/ALEXNET_2012",
          "research/ALPHAFOLD_2021",
          "research/ALPHAGO_2016",
          "research/BACKPROP_1986",
          "research/BATCH_NORM_2015",
          "research/BERT_2018",
          "research/BIGTABLE_2006",
          "research/BITCOIN_2008",
          "research/BLOOM_FILTER_1970",
          "research/BORG_2015",
          "research/BROOKS_1986",
          "research/BTREE_1972",
          "research/CHORD_2001",
          "research/CLIP_2021",
          "research/CODD_1970",
          "research/CONTAINERS_2007",
          "research/COOK_1971",
          "research/COT_2022",
          "research/DIFFIE_HELLMAN_1976",
          "research/DIFFUSION_2020",
          "research/DIJKSTRA_1959",
          "research/DQN_2013",
          "research/DREMEL_2010",
          "research/DROPOUT_2014",
          "research/DYNAMO_2007",
          "research/EBPF_1993",
          "research/END_TO_END_1984",
          "research/FLP_1985",
          "research/GAN_2014",
          "research/GFS_2003",
          "research/GNN_2008",
          "research/GPT3_2020",
          "research/GRAY_1981",
          "research/HOARE_1969",
          "research/HYPERLOGLOG_2007",
          "research/KAFKA_2011",
          "research/L4_1995",
          "research/LAMPORT_1978",
          "research/LAMPSON_1983",
          "research/LECUN_1998",
          "research/LFS_1992",
          "research/LISKOV_1974",
          "research/LLAMA_2023",
          "research/LORA_2021",
          "research/LSM_TREE_1996",
          "research/LSTM_1997",
          "research/MAPREDUCE_2004",
          "research/MCCULLOCH_PITTS_1943",
          "research/MESI_1984",
          "research/MILLWHEEL_2013",
          "research/MINSKY_1961",
          "research/PAXOS_1998",
          "research/PERCEPTRONS_1958",
          "research/RAFT_2014",
          "research/RAID_1988",
          "research/RDMA_2003",
          "research/REDBLACK_TREE_1978",
          "research/RESNET_2015",
          "research/RLHF_2022",
          "research/RSA_1978",
          "research/SALTZER_SCHROEDER_1975",
          "research/SHANNON_1948",
          "research/SPANNER_2012",
          "research/SPARK_2012",
          "research/SPECTRE_MELTDOWN_2018",
          "research/SVM_1995",
          "research/TENSORFLOW_2016",
          "research/THOMPSON_1984",
          "research/TRANSFORMER_2017",
          "research/TURING_1936",
          "research/UNIX_1974",
          "research/VIRTUAL_MEMORY_1962",
          "research/VIT_2021",
          "research/VON_NEUMANN_1945",
          "research/WAIT_FREE_1991",
          "research/WORD2VEC_2013",
          "research/YOLO_2016",
          "research/ZFS_2003",
          "research/ZOOKEEPER_2010"
        ],
        "referenced_by": [
          "core/DECAPOD",
          "methodology/RESEARCH"
        ]
      },
      "sections": {
        "match": [
          "Use when the human asks about the theoretical basis, historical context, or seminal research of a computing topic.",
          "Use for deep dives into distributed systems, AI breakthroughs, hardware fundamentals, or data structures."
        ],
        "decide": [
          "Identify the domain: Foundations, Distributed Systems, AI/ML, or Hardware/Systems Architecture.",
          "Select specific papers that provide the necessary proof or architectural precedent for the current task."
        ],
        "route": [
          "turing, computability, shannon, theory -> Foundations papers.",
          "paxos, raft, spanner, gfs, mapreduce -> Distributed Systems library.",
          "attention, transformer, bert, llama, rlhf -> AI/ML library.",
          "von neumann, virtual memory, mesi, ebpf -> Hardware/Systems library."
        ],
        "apply": [
          "Carry forward cited constraints from seminal papers into implementation design.",
          "Use research to resolve fundamental architectural trade-offs (e.g., CAP theorem vs External Consistency)."
        ]
      }
    }
  },
  "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/SECURITY",
      "docs/SECURITY_THREAT_MODEL",
      "specs/SECURITY"
    ],
    "kubernetes": [
      "core/ARCHITECTURE",
      "architecture/KUBERNETES",
      "research/BORG_2015"
    ],
    "cloud": [
      "core/ARCHITECTURE",
      "architecture/CLOUD"
    ],
    "scale": [
      "core/ARCHITECTURE"
    ],
    "performance": [
      "core/ARCHITECTURE",
      "data/DATABASE",
      "architecture/ENTERPRISE",
      "architecture/FRONTEND",
      "architecture/PERFORMANCE",
      "architecture/SYSTEMS_DESIGN",
      "architecture/WEB",
      "research/RAID_1988",
      "research/LFS_1992"
    ],
    "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/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",
      "research/VON_NEUMANN_1945",
      "research/VIRTUAL_MEMORY_1962",
      "research/MESI_1984",
      "research/BLOOM_FILTER_1970"
    ],
    "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",
      "research/SVM_1995"
    ],
    "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",
      "research/LAMPSON_1983"
    ],
    "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",
      "research/BROOKS_1986"
    ],
    "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",
      "research/REDBLACK_TREE_1978"
    ],
    "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",
      "research/EBPF_1993"
    ],
    "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",
      "research/GRAY_1981"
    ],
    "network": [
      "architecture/CLOUD",
      "architecture/NETWORKING",
      "research/CHORD_2001"
    ],
    "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",
      "research/GNN_2008"
    ],
    "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",
      "research/ZOOKEEPER_2010"
    ],
    "liveness": [
      "architecture/CONCURRENCY",
      "interfaces/CONTROL_PLANE",
      "interfaces/TODO_SCHEMA",
      "plugins/HEALTH",
      "plugins/HEARTBEAT",
      "research/FLP_1985"
    ],
    "deterministic": [
      "architecture/CONCURRENCY",
      "interfaces/LCM"
    ],
    "async": [
      "architecture/CONCURRENCY"
    ],
    "parallelism": [
      "architecture/CONCURRENCY",
      "research/WAIT_FREE_1991"
    ],
    "queues": [
      "architecture/CONCURRENCY",
      "architecture/EVENT_DRIVEN",
      "architecture/MESSAGING"
    ],
    "threads": [
      "architecture/CONCURRENCY"
    ],
    "concurrency": [
      "architecture/CONCURRENCY",
      "research/LAMPORT_1978",
      "research/WAIT_FREE_1991"
    ],
    "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",
      "research/GRAY_1981",
      "research/L4_1995",
      "research/CONTAINERS_2007"
    ],
    "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",
      "research/BORG_2015",
      "research/CONTAINERS_2007"
    ],
    "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",
      "research/DIJKSTRA_1959",
      "research/BACKPROP_1986",
      "research/BATCH_NORM_2015"
    ],
    "modeling": [
      "data/PIPELINES",
      "architecture/SECURITY",
      "specs/SECURITY"
    ],
    "privacy": [
      "data/PIPELINES",
      "research/DIFFIE_HELLMAN_1976"
    ],
    "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",
      "research/CODD_1970",
      "research/BTREE_1972",
      "research/LSM_TREE_1996"
    ],
    "consistency": [
      "data/DATABASE",
      "architecture/DISTRIBUTED_SYSTEMS",
      "architecture/EVENT_DRIVEN",
      "interfaces/GLOSSARY",
      "research/GRAY_1981"
    ],
    "transactions": [
      "data/DATABASE",
      "research/GRAY_1981"
    ],
    "indexing": [
      "data/DATABASE",
      "interfaces/KNOWLEDGE_STORE",
      "interfaces/MEMORY_SCHEMA",
      "methodology/KNOWLEDGE",
      "plugins/KNOWLEDGE",
      "research/BTREE_1972"
    ],
    "backups": [
      "data/DATABASE"
    ],
    "replication": [
      "data/DATABASE",
      "research/PAXOS_1998"
    ],
    "safety": [
      "data/DATABASE",
      "docs/MIGRATIONS",
      "specs/GIT",
      "research/RLHF_2022"
    ],
    "migrations": [
      "data/DATABASE",
      "docs/MIGRATIONS"
    ],
    "retries": [
      "architecture/DISTRIBUTED_SYSTEMS",
      "architecture/MESSAGING"
    ],
    "consensus": [
      "architecture/DISTRIBUTED_SYSTEMS",
      "research/FLP_1985",
      "research/PAXOS_1998",
      "research/RAFT_2014",
      "research/BITCOIN_2008",
      "research/ZOOKEEPER_2010"
    ],
    "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",
      "research/MAPREDUCE_2004",
      "research/TENSORFLOW_2016"
    ],
    "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",
      "research/RSA_1978"
    ],
    "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",
      "research/SALTZER_SCHROEDER_1975"
    ],
    "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",
      "research/BROOKS_1986"
    ],
    "cryptographic": [
      "architecture/ENCRYPTION"
    ],
    "custody": [
      "architecture/ENCRYPTION",
      "architecture/SECRETS"
    ],
    "that": [
      "architecture/ENTERPRISE",
      "architecture/SYSTEMS_DESIGN"
    ],
    "enterprise": [
      "architecture/ENTERPRISE"
    ],
    "correctness": [
      "architecture/ENTERPRISE",
      "architecture/SYSTEMS_DESIGN",
      "research/HOARE_1969",
      "research/END_TO_END_1984"
    ],
    "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",
      "research/THOMPSON_1984"
    ],
    "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",
      "research/END_TO_END_1984",
      "research/RAID_1988"
    ],
    "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",
      "research/GFS_2003"
    ],
    "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",
      "research/RAID_1988",
      "research/LFS_1992"
    ],
    "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",
      "research/KAFKA_2011"
    ],
    "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",
      "research/END_TO_END_1984",
      "research/EBPF_1993",
      "research/RDMA_2003"
    ],
    "routing": [
      "architecture/NETWORKING",
      "architecture/WEB",
      "interfaces/MEMORY_INDEX",
      "research/DIJKSTRA_1959"
    ],
    "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",
      "research/KAFKA_2011"
    ],
    "visible": [
      "architecture/PERFORMANCE",
      "specs/engineering/FRONTEND_BACKEND_E2E"
    ],
    "latency": [
      "architecture/PERFORMANCE"
    ],
    "profiling": [
      "architecture/PERFORMANCE"
    ],
    "bottlenecks": [
      "architecture/PERFORMANCE"
    ],
    "scaling": [
      "architecture/SCALING",
      "research/VIT_2021"
    ],
    "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",
      "research/LISKOV_1974"
    ],
    "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",
      "research/EBPF_1993",
      "research/L4_1995"
    ],
    "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",
      "research/SHANNON_1948"
    ],
    "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",
      "research/TURING_1936",
      "research/VON_NEUMANN_1945"
    ],
    "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",
      "research/LAMPORT_1978",
      "research/WAIT_FREE_1991"
    ],
    "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",
      "research/MINSKY_1961"
    ],
    "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",
      "research/CHORD_2001"
    ],
    "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",
      "research/LISKOV_1974",
      "research/VIRTUAL_MEMORY_1962"
    ],
    "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",
      "research/BORG_2015"
    ],
    "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",
      "research/BATCH_NORM_2015"
    ],
    "runs": [
      "specs/evaluations/VARIANCE_EVALS"
    ],
    "comparative": [
      "specs/evaluations/VARIANCE_EVALS"
    ],
    "sre": [
      "methodology/PLATFORM"
    ],
    "sli": [
      "methodology/PLATFORM"
    ],
    "slo": [
      "methodology/PLATFORM"
    ],
    "error budget": [
      "methodology/PLATFORM"
    ],
    "cap": [
      "architecture/DISTRIBUTED_SYSTEMS"
    ],
    "pacelc": [
      "architecture/DISTRIBUTED_SYSTEMS"
    ],
    "raft": [
      "architecture/DISTRIBUTED_SYSTEMS",
      "research/RAFT_2014"
    ],
    "paxos": [
      "architecture/DISTRIBUTED_SYSTEMS",
      "research/PAXOS_1998"
    ],
    "crdt": [
      "architecture/DISTRIBUTED_SYSTEMS"
    ],
    "okr": [
      "methodology/PRODUCT"
    ],
    "rice": [
      "methodology/PRODUCT"
    ],
    "feature flag": [
      "methodology/PRODUCT"
    ],
    "togaf": [
      "architecture/ENTERPRISE"
    ],
    "ddd": [
      "architecture/ENTERPRISE"
    ],
    "bounded context": [
      "architecture/ENTERPRISE"
    ],
    "data engineering": [
      "data/DATA_ENGINEERING"
    ],
    "qa": [
      "methodology/QA",
      "methodology/TESTING"
    ],
    "quality assurance": [
      "methodology/QA",
      "methodology/TESTING"
    ],
    "chaos": [
      "methodology/OPERATIONS"
    ],
    "seminal papers": [
      "methodology/RESEARCH"
    ],
    "turing": [
      "research/TURING_1936"
    ],
    "1936": [
      "research/TURING_1936"
    ],
    "turing machine": [
      "research/TURING_1936"
    ],
    "computability": [
      "research/TURING_1936"
    ],
    "algorithm": [
      "research/TURING_1936"
    ],
    "halting problem": [
      "research/TURING_1936"
    ],
    "decidability": [
      "research/TURING_1936"
    ],
    "shannon": [
      "research/SHANNON_1948"
    ],
    "1948": [
      "research/SHANNON_1948"
    ],
    "information theory": [
      "research/SHANNON_1948"
    ],
    "entropy": [
      "research/SHANNON_1948"
    ],
    "bit": [
      "research/SHANNON_1948"
    ],
    "bandwidth": [
      "research/SHANNON_1948"
    ],
    "signal-to-noise": [
      "research/SHANNON_1948"
    ],
    "dijkstra": [
      "research/DIJKSTRA_1959"
    ],
    "1959": [
      "research/DIJKSTRA_1959"
    ],
    "dijkstra algorithm": [
      "research/DIJKSTRA_1959"
    ],
    "shortest path": [
      "research/DIJKSTRA_1959"
    ],
    "graph theory": [
      "research/DIJKSTRA_1959"
    ],
    "minimum spanning tree": [
      "research/DIJKSTRA_1959"
    ],
    "hoare": [
      "research/HOARE_1969"
    ],
    "1969": [
      "research/HOARE_1969"
    ],
    "hoare logic": [
      "research/HOARE_1969"
    ],
    "formal verification": [
      "research/HOARE_1969"
    ],
    "precondition": [
      "research/HOARE_1969"
    ],
    "postcondition": [
      "research/HOARE_1969"
    ],
    "invariant": [
      "research/HOARE_1969"
    ],
    "codd": [
      "research/CODD_1970"
    ],
    "1970": [
      "research/CODD_1970",
      "research/BLOOM_FILTER_1970"
    ],
    "relational model": [
      "research/CODD_1970"
    ],
    "sql": [
      "research/CODD_1970",
      "research/SPANNER_2012"
    ],
    "normalization": [
      "research/CODD_1970"
    ],
    "data independence": [
      "research/CODD_1970"
    ],
    "algebra": [
      "research/CODD_1970"
    ],
    "cook": [
      "research/COOK_1971"
    ],
    "1971": [
      "research/COOK_1971"
    ],
    "np-complete": [
      "research/COOK_1971"
    ],
    "complexity classes": [
      "research/COOK_1971"
    ],
    "sat": [
      "research/COOK_1971"
    ],
    "p vs np": [
      "research/COOK_1971"
    ],
    "reductions": [
      "research/COOK_1971"
    ],
    "computational complexity": [
      "research/COOK_1971"
    ],
    "diffie": [
      "research/DIFFIE_HELLMAN_1976"
    ],
    "hellman": [
      "research/DIFFIE_HELLMAN_1976"
    ],
    "1976": [
      "research/DIFFIE_HELLMAN_1976"
    ],
    "public-key": [
      "research/DIFFIE_HELLMAN_1976"
    ],
    "cryptography": [
      "research/DIFFIE_HELLMAN_1976"
    ],
    "key exchange": [
      "research/DIFFIE_HELLMAN_1976"
    ],
    "asymmetric": [
      "research/DIFFIE_HELLMAN_1976",
      "research/RSA_1978"
    ],
    "rsa": [
      "research/RSA_1978"
    ],
    "1978": [
      "research/RSA_1978",
      "research/LAMPORT_1978",
      "research/REDBLACK_TREE_1978"
    ],
    "digital signatures": [
      "research/RSA_1978"
    ],
    "prime numbers": [
      "research/RSA_1978"
    ],
    "lamport": [
      "research/LAMPORT_1978"
    ],
    "logical clocks": [
      "research/LAMPORT_1978"
    ],
    "distributed systems": [
      "research/LAMPORT_1978",
      "research/FLP_1985",
      "research/PAXOS_1998",
      "research/RAFT_2014",
      "research/ZOOKEEPER_2010"
    ],
    "event ordering": [
      "research/LAMPORT_1978"
    ],
    "causality": [
      "research/LAMPORT_1978"
    ],
    "saltzer": [
      "research/SALTZER_SCHROEDER_1975"
    ],
    "schroeder": [
      "research/SALTZER_SCHROEDER_1975"
    ],
    "1975": [
      "research/SALTZER_SCHROEDER_1975"
    ],
    "least privilege": [
      "research/SALTZER_SCHROEDER_1975"
    ],
    "access control": [
      "research/SALTZER_SCHROEDER_1975"
    ],
    "defense in depth": [
      "research/SALTZER_SCHROEDER_1975"
    ],
    "open design": [
      "research/SALTZER_SCHROEDER_1975"
    ],
    "gray": [
      "research/GRAY_1981"
    ],
    "1981": [
      "research/GRAY_1981"
    ],
    "acid": [
      "research/GRAY_1981"
    ],
    "atomicity": [
      "research/GRAY_1981"
    ],
    "durability": [
      "research/GRAY_1981"
    ],
    "liskov": [
      "research/LISKOV_1974"
    ],
    "1974": [
      "research/LISKOV_1974",
      "research/UNIX_1974"
    ],
    "abstract data types": [
      "research/LISKOV_1974"
    ],
    "encapsulation": [
      "research/LISKOV_1974"
    ],
    "modular": [
      "research/LISKOV_1974"
    ],
    "liskov substitution": [
      "research/LISKOV_1974"
    ],
    "brooks": [
      "research/BROOKS_1986"
    ],
    "1986": [
      "research/BROOKS_1986",
      "research/BACKPROP_1986"
    ],
    "software engineering": [
      "research/BROOKS_1986"
    ],
    "productivity": [
      "research/BROOKS_1986"
    ],
    "mythical man-month": [
      "research/BROOKS_1986"
    ],
    "silver bullet": [
      "research/BROOKS_1986"
    ],
    "lampson": [
      "research/LAMPSON_1983"
    ],
    "1983": [
      "research/LAMPSON_1983"
    ],
    "system design": [
      "research/LAMPSON_1983",
      "research/END_TO_END_1984"
    ],
    "heuristics": [
      "research/LAMPSON_1983",
      "research/MINSKY_1961"
    ],
    "simplicity": [
      "research/LAMPSON_1983",
      "research/UNIX_1974"
    ],
    "robustness": [
      "research/LAMPSON_1983"
    ],
    "hints": [
      "research/LAMPSON_1983"
    ],
    "flp": [
      "research/FLP_1985"
    ],
    "1985": [
      "research/FLP_1985"
    ],
    "impossibility": [
      "research/FLP_1985"
    ],
    "asynchronous": [
      "research/FLP_1985"
    ],
    "fault tolerance": [
      "research/FLP_1985",
      "research/PAXOS_1998",
      "research/GFS_2003"
    ],
    "1998": [
      "research/PAXOS_1998",
      "research/LECUN_1998"
    ],
    "quorum": [
      "research/PAXOS_1998"
    ],
    "thompson": [
      "research/THOMPSON_1984"
    ],
    "1984": [
      "research/THOMPSON_1984",
      "research/END_TO_END_1984",
      "research/MESI_1984"
    ],
    "compiler": [
      "research/THOMPSON_1984"
    ],
    "backdoor": [
      "research/THOMPSON_1984"
    ],
    "trojan horse": [
      "research/THOMPSON_1984"
    ],
    "binary": [
      "research/THOMPSON_1984"
    ],
    "source code": [
      "research/THOMPSON_1984"
    ],
    "chord": [
      "research/CHORD_2001"
    ],
    "2001": [
      "research/CHORD_2001"
    ],
    "dht": [
      "research/CHORD_2001"
    ],
    "peer-to-peer": [
      "research/CHORD_2001"
    ],
    "consistent hashing": [
      "research/CHORD_2001",
      "research/DYNAMO_2007"
    ],
    "scalability": [
      "research/CHORD_2001",
      "research/GFS_2003",
      "research/MAPREDUCE_2004",
      "research/BIGTABLE_2006"
    ],
    "gfs": [
      "research/GFS_2003"
    ],
    "2003": [
      "research/GFS_2003",
      "research/ZFS_2003",
      "research/RDMA_2003"
    ],
    "distributed file system": [
      "research/GFS_2003"
    ],
    "google": [
      "research/GFS_2003",
      "research/MAPREDUCE_2004",
      "research/BIGTABLE_2006",
      "research/SPANNER_2012",
      "research/BORG_2015"
    ],
    "mapreduce": [
      "research/MAPREDUCE_2004"
    ],
    "2004": [
      "research/MAPREDUCE_2004"
    ],
    "data processing": [
      "research/MAPREDUCE_2004",
      "research/SPARK_2012"
    ],
    "parallel": [
      "research/MAPREDUCE_2004"
    ],
    "bigtable": [
      "research/BIGTABLE_2006"
    ],
    "2006": [
      "research/BIGTABLE_2006"
    ],
    "nosql": [
      "research/BIGTABLE_2006",
      "research/DYNAMO_2007",
      "research/LSM_TREE_1996"
    ],
    "distributed storage": [
      "research/BIGTABLE_2006"
    ],
    "structured data": [
      "research/BIGTABLE_2006"
    ],
    "dynamo": [
      "research/DYNAMO_2007"
    ],
    "2007": [
      "research/DYNAMO_2007",
      "research/HYPERLOGLOG_2007",
      "research/CONTAINERS_2007"
    ],
    "availability": [
      "research/DYNAMO_2007",
      "research/RAID_1988"
    ],
    "eventual consistency": [
      "research/DYNAMO_2007"
    ],
    "amazon": [
      "research/DYNAMO_2007"
    ],
    "spanner": [
      "research/SPANNER_2012"
    ],
    "2012": [
      "research/SPANNER_2012",
      "research/ALEXNET_2012",
      "research/SPARK_2012"
    ],
    "distributed database": [
      "research/SPANNER_2012"
    ],
    "external consistency": [
      "research/SPANNER_2012"
    ],
    "truetime": [
      "research/SPANNER_2012"
    ],
    "2014": [
      "research/RAFT_2014",
      "research/GAN_2014",
      "research/ADAM_2014",
      "research/DROPOUT_2014"
    ],
    "log replication": [
      "research/RAFT_2014"
    ],
    "leader election": [
      "research/RAFT_2014"
    ],
    "understandable": [
      "research/RAFT_2014"
    ],
    "transformer": [
      "research/TRANSFORMER_2017",
      "research/BERT_2018",
      "research/VIT_2021"
    ],
    "2017": [
      "research/TRANSFORMER_2017"
    ],
    "attention": [
      "research/TRANSFORMER_2017"
    ],
    "nlp": [
      "research/TRANSFORMER_2017",
      "research/GPT3_2020",
      "research/WORD2VEC_2013",
      "research/BERT_2018"
    ],
    "llm": [
      "research/TRANSFORMER_2017",
      "research/GPT3_2020",
      "research/LORA_2021",
      "research/COT_2022",
      "research/LLAMA_2023"
    ],
    "neural networks": [
      "research/TRANSFORMER_2017",
      "research/MCCULLOCH_PITTS_1943",
      "research/BACKPROP_1986",
      "research/PERCEPTRONS_1958"
    ],
    "machine learning": [
      "research/TRANSFORMER_2017",
      "research/TENSORFLOW_2016"
    ],
    "bitcoin": [
      "research/BITCOIN_2008"
    ],
    "2008": [
      "research/BITCOIN_2008",
      "research/GNN_2008"
    ],
    "blockchain": [
      "research/BITCOIN_2008"
    ],
    "proof-of-work": [
      "research/BITCOIN_2008"
    ],
    "decentralized": [
      "research/BITCOIN_2008"
    ],
    "cryptocurrency": [
      "research/BITCOIN_2008"
    ],
    "mcculloch": [
      "research/MCCULLOCH_PITTS_1943"
    ],
    "pitts": [
      "research/MCCULLOCH_PITTS_1943"
    ],
    "1943": [
      "research/MCCULLOCH_PITTS_1943"
    ],
    "ai": [
      "research/MCCULLOCH_PITTS_1943",
      "research/MINSKY_1961"
    ],
    "neuron": [
      "research/MCCULLOCH_PITTS_1943"
    ],
    "mathematical model": [
      "research/MCCULLOCH_PITTS_1943"
    ],
    "logic": [
      "research/MCCULLOCH_PITTS_1943"
    ],
    "cybernetics": [
      "research/MCCULLOCH_PITTS_1943"
    ],
    "minsky": [
      "research/MINSKY_1961"
    ],
    "1961": [
      "research/MINSKY_1961"
    ],
    "search": [
      "research/MINSKY_1961",
      "research/BTREE_1972",
      "research/REDBLACK_TREE_1978"
    ],
    "pattern recognition": [
      "research/MINSKY_1961"
    ],
    "problem solving": [
      "research/MINSKY_1961"
    ],
    "backprop": [
      "research/BACKPROP_1986"
    ],
    "backpropagation": [
      "research/BACKPROP_1986"
    ],
    "gradient descent": [
      "research/BACKPROP_1986",
      "research/ADAM_2014"
    ],
    "deep learning": [
      "research/BACKPROP_1986",
      "research/LECUN_1998",
      "research/ALEXNET_2012",
      "research/ALPHAGO_2016",
      "research/LSTM_1997",
      "research/ALPHAFOLD_2021",
      "research/BATCH_NORM_2015",
      "research/ADAM_2014",
      "research/DROPOUT_2014",
      "research/YOLO_2016"
    ],
    "weights": [
      "research/BACKPROP_1986"
    ],
    "lecun": [
      "research/LECUN_1998"
    ],
    "cnn": [
      "research/LECUN_1998",
      "research/ALEXNET_2012"
    ],
    "computer vision": [
      "research/LECUN_1998",
      "research/ALEXNET_2012",
      "research/RESNET_2015",
      "research/VIT_2021",
      "research/YOLO_2016"
    ],
    "lenet": [
      "research/LECUN_1998"
    ],
    "image recognition": [
      "research/LECUN_1998"
    ],
    "convolutions": [
      "research/LECUN_1998"
    ],
    "alexnet": [
      "research/ALEXNET_2012"
    ],
    "gpu": [
      "research/ALEXNET_2012",
      "research/TENSORFLOW_2016"
    ],
    "imagenet": [
      "research/ALEXNET_2012"
    ],
    "alphago": [
      "research/ALPHAGO_2016"
    ],
    "2016": [
      "research/ALPHAGO_2016",
      "research/TENSORFLOW_2016",
      "research/YOLO_2016"
    ],
    "reinforcement learning": [
      "research/ALPHAGO_2016",
      "research/DQN_2013"
    ],
    "mcts": [
      "research/ALPHAGO_2016"
    ],
    "go": [
      "research/ALPHAGO_2016"
    ],
    "game theory": [
      "research/ALPHAGO_2016"
    ],
    "resnet": [
      "research/RESNET_2015"
    ],
    "2015": [
      "research/RESNET_2015",
      "research/BATCH_NORM_2015",
      "research/BORG_2015"
    ],
    "residual learning": [
      "research/RESNET_2015"
    ],
    "deep networks": [
      "research/RESNET_2015"
    ],
    "gradients": [
      "research/RESNET_2015"
    ],
    "skip connections": [
      "research/RESNET_2015"
    ],
    "gpt3": [
      "research/GPT3_2020"
    ],
    "2020": [
      "research/GPT3_2020",
      "research/DIFFUSION_2020"
    ],
    "gpt-3": [
      "research/GPT3_2020"
    ],
    "few-shot learning": [
      "research/GPT3_2020"
    ],
    "emergence": [
      "research/GPT3_2020"
    ],
    "zero-shot": [
      "research/GPT3_2020",
      "research/CLIP_2021"
    ],
    "tensorflow": [
      "research/TENSORFLOW_2016"
    ],
    "tpu": [
      "research/TENSORFLOW_2016"
    ],
    "dataflow graph": [
      "research/TENSORFLOW_2016"
    ],
    "spark": [
      "research/SPARK_2012"
    ],
    "apache spark": [
      "research/SPARK_2012"
    ],
    "rdd": [
      "research/SPARK_2012"
    ],
    "in-memory": [
      "research/SPARK_2012"
    ],
    "big data": [
      "research/SPARK_2012",
      "research/HYPERLOGLOG_2007",
      "research/DREMEL_2010"
    ],
    "iterative": [
      "research/SPARK_2012"
    ],
    "kafka": [
      "research/KAFKA_2011"
    ],
    "2011": [
      "research/KAFKA_2011"
    ],
    "apache kafka": [
      "research/KAFKA_2011"
    ],
    "event streaming": [
      "research/KAFKA_2011"
    ],
    "distributed log": [
      "research/KAFKA_2011"
    ],
    "pub-sub": [
      "research/KAFKA_2011"
    ],
    "zookeeper": [
      "research/ZOOKEEPER_2010"
    ],
    "2010": [
      "research/ZOOKEEPER_2010",
      "research/DREMEL_2010"
    ],
    "configuration": [
      "research/ZOOKEEPER_2010"
    ],
    "locking": [
      "research/ZOOKEEPER_2010"
    ],
    "end": [
      "research/END_TO_END_1984"
    ],
    "to": [
      "research/END_TO_END_1984"
    ],
    "end-to-end": [
      "research/END_TO_END_1984"
    ],
    "unix": [
      "research/UNIX_1974"
    ],
    "operating system": [
      "research/UNIX_1974"
    ],
    "composability": [
      "research/UNIX_1974"
    ],
    "shell": [
      "research/UNIX_1974"
    ],
    "files": [
      "research/UNIX_1974"
    ],
    "perceptrons": [
      "research/PERCEPTRONS_1958"
    ],
    "1958": [
      "research/PERCEPTRONS_1958"
    ],
    "perceptron": [
      "research/PERCEPTRONS_1958"
    ],
    "binary classification": [
      "research/PERCEPTRONS_1958"
    ],
    "linear classifier": [
      "research/PERCEPTRONS_1958"
    ],
    "ai history": [
      "research/PERCEPTRONS_1958"
    ],
    "supervised learning": [
      "research/PERCEPTRONS_1958"
    ],
    "lstm": [
      "research/LSTM_1997"
    ],
    "1997": [
      "research/LSTM_1997"
    ],
    "rnn": [
      "research/LSTM_1997"
    ],
    "vanishing gradient": [
      "research/LSTM_1997"
    ],
    "sequence modeling": [
      "research/LSTM_1997"
    ],
    "time series": [
      "research/LSTM_1997"
    ],
    "svm": [
      "research/SVM_1995"
    ],
    "1995": [
      "research/SVM_1995",
      "research/L4_1995"
    ],
    "support vector machine": [
      "research/SVM_1995"
    ],
    "kernel trick": [
      "research/SVM_1995"
    ],
    "maximum margin": [
      "research/SVM_1995"
    ],
    "statistical learning": [
      "research/SVM_1995"
    ],
    "word2vec": [
      "research/WORD2VEC_2013"
    ],
    "2013": [
      "research/WORD2VEC_2013",
      "research/DQN_2013",
      "research/MILLWHEEL_2013"
    ],
    "embeddings": [
      "research/WORD2VEC_2013"
    ],
    "vector space": [
      "research/WORD2VEC_2013"
    ],
    "skip-gram": [
      "research/WORD2VEC_2013"
    ],
    "continuous bag of words": [
      "research/WORD2VEC_2013"
    ],
    "gan": [
      "research/GAN_2014"
    ],
    "generative ai": [
      "research/GAN_2014",
      "research/DIFFUSION_2020"
    ],
    "adversarial": [
      "research/GAN_2014"
    ],
    "generator": [
      "research/GAN_2014"
    ],
    "discriminator": [
      "research/GAN_2014"
    ],
    "synthetic data": [
      "research/GAN_2014"
    ],
    "bert": [
      "research/BERT_2018"
    ],
    "2018": [
      "research/BERT_2018",
      "research/SPECTRE_MELTDOWN_2018"
    ],
    "pre-training": [
      "research/BERT_2018"
    ],
    "bidirectional": [
      "research/BERT_2018"
    ],
    "transfer learning": [
      "research/BERT_2018"
    ],
    "vit": [
      "research/VIT_2021"
    ],
    "2021": [
      "research/VIT_2021",
      "research/ALPHAFOLD_2021",
      "research/LORA_2021",
      "research/CLIP_2021"
    ],
    "vision transformer": [
      "research/VIT_2021"
    ],
    "image patches": [
      "research/VIT_2021"
    ],
    "alphafold": [
      "research/ALPHAFOLD_2021"
    ],
    "biology": [
      "research/ALPHAFOLD_2021"
    ],
    "protein folding": [
      "research/ALPHAFOLD_2021"
    ],
    "science": [
      "research/ALPHAFOLD_2021"
    ],
    "3d structure": [
      "research/ALPHAFOLD_2021"
    ],
    "lora": [
      "research/LORA_2021"
    ],
    "fine-tuning": [
      "research/LORA_2021"
    ],
    "efficiency": [
      "research/LORA_2021",
      "research/LLAMA_2023",
      "research/BLOOM_FILTER_1970"
    ],
    "peft": [
      "research/LORA_2021"
    ],
    "adaptation": [
      "research/LORA_2021"
    ],
    "cot": [
      "research/COT_2022"
    ],
    "2022": [
      "research/COT_2022",
      "research/RLHF_2022"
    ],
    "chain of thought": [
      "research/COT_2022"
    ],
    "reasoning": [
      "research/COT_2022"
    ],
    "prompting": [
      "research/COT_2022"
    ],
    "emergent abilities": [
      "research/COT_2022"
    ],
    "few-shot": [
      "research/COT_2022"
    ],
    "rlhf": [
      "research/RLHF_2022"
    ],
    "alignment": [
      "research/RLHF_2022"
    ],
    "human feedback": [
      "research/RLHF_2022"
    ],
    "ppo": [
      "research/RLHF_2022"
    ],
    "instructions": [
      "research/RLHF_2022"
    ],
    "diffusion": [
      "research/DIFFUSION_2020"
    ],
    "denoising": [
      "research/DIFFUSION_2020"
    ],
    "stable diffusion": [
      "research/DIFFUSION_2020"
    ],
    "latent space": [
      "research/DIFFUSION_2020"
    ],
    "image synthesis": [
      "research/DIFFUSION_2020"
    ],
    "batch": [
      "research/BATCH_NORM_2015"
    ],
    "norm": [
      "research/BATCH_NORM_2015"
    ],
    "batch normalization": [
      "research/BATCH_NORM_2015"
    ],
    "regularization": [
      "research/BATCH_NORM_2015",
      "research/DROPOUT_2014"
    ],
    "training": [
      "research/BATCH_NORM_2015",
      "research/ADAM_2014"
    ],
    "adam": [
      "research/ADAM_2014"
    ],
    "optimizer": [
      "research/ADAM_2014"
    ],
    "stochastic": [
      "research/ADAM_2014"
    ],
    "dropout": [
      "research/DROPOUT_2014"
    ],
    "overfitting": [
      "research/DROPOUT_2014"
    ],
    "generalization": [
      "research/DROPOUT_2014"
    ],
    "ensembling": [
      "research/DROPOUT_2014"
    ],
    "yolo": [
      "research/YOLO_2016"
    ],
    "object detection": [
      "research/YOLO_2016"
    ],
    "real-time": [
      "research/YOLO_2016"
    ],
    "bounding boxes": [
      "research/YOLO_2016"
    ],
    "dqn": [
      "research/DQN_2013"
    ],
    "q-learning": [
      "research/DQN_2013"
    ],
    "atari": [
      "research/DQN_2013"
    ],
    "pixels": [
      "research/DQN_2013"
    ],
    "experience replay": [
      "research/DQN_2013"
    ],
    "gnn": [
      "research/GNN_2008"
    ],
    "graph neural networks": [
      "research/GNN_2008"
    ],
    "relational data": [
      "research/GNN_2008"
    ],
    "non-euclidean": [
      "research/GNN_2008"
    ],
    "representation learning": [
      "research/GNN_2008"
    ],
    "clip": [
      "research/CLIP_2021"
    ],
    "multimodal": [
      "research/CLIP_2021"
    ],
    "vision-language": [
      "research/CLIP_2021"
    ],
    "contrastive learning": [
      "research/CLIP_2021"
    ],
    "openai": [
      "research/CLIP_2021"
    ],
    "llama": [
      "research/LLAMA_2023"
    ],
    "2023": [
      "research/LLAMA_2023"
    ],
    "open-source": [
      "research/LLAMA_2023"
    ],
    "scaling laws": [
      "research/LLAMA_2023"
    ],
    "meta": [
      "research/LLAMA_2023"
    ],
    "von": [
      "research/VON_NEUMANN_1945"
    ],
    "neumann": [
      "research/VON_NEUMANN_1945"
    ],
    "1945": [
      "research/VON_NEUMANN_1945"
    ],
    "von neumann": [
      "research/VON_NEUMANN_1945"
    ],
    "stored-program": [
      "research/VON_NEUMANN_1945"
    ],
    "cpu": [
      "research/VON_NEUMANN_1945",
      "research/MESI_1984",
      "research/SPECTRE_MELTDOWN_2018"
    ],
    "btree": [
      "research/BTREE_1972"
    ],
    "1972": [
      "research/BTREE_1972"
    ],
    "b-tree": [
      "research/BTREE_1972"
    ],
    "data structures": [
      "research/BTREE_1972",
      "research/BLOOM_FILTER_1970",
      "research/REDBLACK_TREE_1978"
    ],
    "disk storage": [
      "research/BTREE_1972"
    ],
    "raid": [
      "research/RAID_1988"
    ],
    "1988": [
      "research/RAID_1988"
    ],
    "redundancy": [
      "research/RAID_1988"
    ],
    "virtual": [
      "research/VIRTUAL_MEMORY_1962"
    ],
    "1962": [
      "research/VIRTUAL_MEMORY_1962"
    ],
    "virtual memory": [
      "research/VIRTUAL_MEMORY_1962"
    ],
    "paging": [
      "research/VIRTUAL_MEMORY_1962"
    ],
    "mmu": [
      "research/VIRTUAL_MEMORY_1962"
    ],
    "os": [
      "research/VIRTUAL_MEMORY_1962",
      "research/L4_1995"
    ],
    "memory management": [
      "research/VIRTUAL_MEMORY_1962"
    ],
    "lfs": [
      "research/LFS_1992"
    ],
    "1992": [
      "research/LFS_1992"
    ],
    "file system": [
      "research/LFS_1992",
      "research/ZFS_2003"
    ],
    "log-structured": [
      "research/LFS_1992"
    ],
    "write optimization": [
      "research/LFS_1992"
    ],
    "lsm": [
      "research/LSM_TREE_1996"
    ],
    "tree": [
      "research/LSM_TREE_1996",
      "research/REDBLACK_TREE_1978"
    ],
    "1996": [
      "research/LSM_TREE_1996"
    ],
    "lsm-tree": [
      "research/LSM_TREE_1996"
    ],
    "storage engine": [
      "research/LSM_TREE_1996"
    ],
    "write throughput": [
      "research/LSM_TREE_1996"
    ],
    "compaction": [
      "research/LSM_TREE_1996"
    ],
    "hyperloglog": [
      "research/HYPERLOGLOG_2007"
    ],
    "hll": [
      "research/HYPERLOGLOG_2007"
    ],
    "probabilistic algorithm": [
      "research/HYPERLOGLOG_2007"
    ],
    "cardinality": [
      "research/HYPERLOGLOG_2007"
    ],
    "approximation": [
      "research/HYPERLOGLOG_2007"
    ],
    "wait": [
      "research/WAIT_FREE_1991"
    ],
    "free": [
      "research/WAIT_FREE_1991"
    ],
    "1991": [
      "research/WAIT_FREE_1991"
    ],
    "wait-free": [
      "research/WAIT_FREE_1991"
    ],
    "lock-free": [
      "research/WAIT_FREE_1991"
    ],
    "non-blocking": [
      "research/WAIT_FREE_1991"
    ],
    "mesi": [
      "research/MESI_1984"
    ],
    "cache coherence": [
      "research/MESI_1984"
    ],
    "multi-core": [
      "research/MESI_1984"
    ],
    "hardware": [
      "research/MESI_1984",
      "research/SPECTRE_MELTDOWN_2018"
    ],
    "ebpf": [
      "research/EBPF_1993"
    ],
    "1993": [
      "research/EBPF_1993"
    ],
    "bpf": [
      "research/EBPF_1993"
    ],
    "linux": [
      "research/EBPF_1993"
    ],
    "l4": [
      "research/L4_1995"
    ],
    "microkernel": [
      "research/L4_1995"
    ],
    "ipc": [
      "research/L4_1995"
    ],
    "borg": [
      "research/BORG_2015"
    ],
    "cluster management": [
      "research/BORG_2015"
    ],
    "dremel": [
      "research/DREMEL_2010"
    ],
    "bigquery": [
      "research/DREMEL_2010"
    ],
    "columnar storage": [
      "research/DREMEL_2010"
    ],
    "analytics": [
      "research/DREMEL_2010"
    ],
    "parquet": [
      "research/DREMEL_2010"
    ],
    "millwheel": [
      "research/MILLWHEEL_2013"
    ],
    "stream processing": [
      "research/MILLWHEEL_2013"
    ],
    "dataflow": [
      "research/MILLWHEEL_2013"
    ],
    "low latency": [
      "research/MILLWHEEL_2013",
      "research/RDMA_2003"
    ],
    "stateful": [
      "research/MILLWHEEL_2013"
    ],
    "exactly-once": [
      "research/MILLWHEEL_2013"
    ],
    "zfs": [
      "research/ZFS_2003"
    ],
    "data integrity": [
      "research/ZFS_2003"
    ],
    "checksums": [
      "research/ZFS_2003"
    ],
    "copy-on-write": [
      "research/ZFS_2003"
    ],
    "snapshots": [
      "research/ZFS_2003"
    ],
    "docker": [
      "research/CONTAINERS_2007"
    ],
    "namespaces": [
      "research/CONTAINERS_2007"
    ],
    "cgroups": [
      "research/CONTAINERS_2007"
    ],
    "virtualization": [
      "research/CONTAINERS_2007"
    ],
    "bloom": [
      "research/BLOOM_FILTER_1970"
    ],
    "filter": [
      "research/BLOOM_FILTER_1970"
    ],
    "bloom filter": [
      "research/BLOOM_FILTER_1970"
    ],
    "probabilistic": [
      "research/BLOOM_FILTER_1970"
    ],
    "hashing": [
      "research/BLOOM_FILTER_1970"
    ],
    "redblack": [
      "research/REDBLACK_TREE_1978"
    ],
    "red-black tree": [
      "research/REDBLACK_TREE_1978"
    ],
    "balanced tree": [
      "research/REDBLACK_TREE_1978"
    ],
    "binary search tree": [
      "research/REDBLACK_TREE_1978"
    ],
    "spectre": [
      "research/SPECTRE_MELTDOWN_2018"
    ],
    "meltdown": [
      "research/SPECTRE_MELTDOWN_2018"
    ],
    "speculative execution": [
      "research/SPECTRE_MELTDOWN_2018"
    ],
    "side-channel": [
      "research/SPECTRE_MELTDOWN_2018"
    ],
    "rdma": [
      "research/RDMA_2003"
    ],
    "zero-copy": [
      "research/RDMA_2003"
    ],
    "infiniband": [
      "research/RDMA_2003"
    ],
    "high performance": [
      "research/RDMA_2003"
    ]
  }
}