Recovered from historical V9.2.1 evidence in File Library. This is a non-regression contract, not proof that current 11-ZIP input contains these exact bytes.

• 258 canonical Skills
• 15 Skill aliases
• 60 active Agents
• 175 active Rules
• 373 glossary/taxonomy entries

Semantic rigor applies to Skills, Rules, Agents, Validators, Tests, Templates, Routers, Retrievers, Registries, Knowledge Graphs, Scripts, Generators, Runtime Governors, Ledgers, Adapters, Bootstrap, Release Gates, Manifests, Schemas, Config, CI/CD, Migrations, Fixtures, Eval Datasets, Benchmarks, Prompts, System Instructions, Examples, Policies, Crosswalks, Receipts, Reports, Generated/Status Docs, Capability Catalogs, Aliases, Fallback/Dependency Maps, Cleanup/Recovery, Installers, Packaging, Update/Repair/Uninstall, Compatibility Matrices, Run State, State Machines, Concurrency Controls, Tool/Plugin Metadata, Source Provenance and Negative Knowledge stores.

• Operational surface: any artifact capable of changing what the system selects, executes, believes, validates, writes, delivers or declares as PASS.
• Skill: reusable specialized procedure triggered by intent/phase/risk/gap.
• Rule: invariant/policy restricting system behavior; ENFORCED or ADVISORY with explicit reason.
• Agent: independent-context executor/reviewer justified by isolation, specialization, adversarial review or parallelism.
• Validator: executable detector for a well-defined property; competence must match the claim.
• Test: executable experiment with stimulus, oracle and expected outcome; not synonymous with a structural validator.
• Template: future-artifact mold; headings are not implementation.
• Router: chooses capabilities/branches from intent/context.
• Retriever: retrieves minimum relevant knowledge/authority while controlling provenance/context budget.
• Crosswalk: explicit mapping preserving unmapped/conflict states rather than pretending equivalence.
• Disposition: explicit treatment such as INCORPORATED, MERGED, DOMAIN_ONLY, REFERENCE_ONLY, SUPERSEDED, REJECTED_WITH_REASON.
• Operational destination: where knowledge actually acts; closes SOURCE→CONCEPT→COMPONENT→CONSUMER→VALIDATOR→TEST.
• Negative knowledge: durable failures, rejected hypotheses, unsupported routes and reopen conditions.
• Capability Reality Gate: lifecycle separating declared capability from runtime-verified capability.
• Tool Route Receipt: why a provider/tool was selected/rejected/substituted, including state and limitations.
• Generated doc: derived projection; not an independent source of truth.
• Status doc: current-state projection; must not become stale authority.

REQUIRED_KNOWLEDGE ⊆ LOCAL_KNOWLEDGE ∪ REFERENCED_KNOWLEDGE ∪ ROUTABLE_KNOWLEDGE

A smaller component is valid only if all material deeper knowledge remains reachable through validated routing/retrieval. Missing material knowledge becomes REVIEW/UNKNOWN, not model-memory fallback.

SOURCE → CONCEPT/FAILURE/SUCCESS → WHAT IT SHOULD CHANGE → AFFECTED COMPONENT CLASSES → CURRENT IMPLEMENTATION → CONSUMER → ROUTER/TRIGGER → ENFORCEMENT → DETECTOR → TEST → MUTATION → RUNTIME EVIDENCE → STATUS/GAP/FIX

ACTIVE COMPONENT → WHY IT EXISTS → SOURCE KNOWLEDGE → CONTRACT → CONSUMER → TRIGGER → OUTPUT → ENFORCEMENT → DETECTOR → EVIDENCE

DISCOVER → CLASSIFY → ROUTE → RETRIEVE MINIMUM SUFFICIENT KNOWLEDGE → EXECUTE ATOMIC UNIT → OBSERVE → VALIDATE → FALSIFY → RE-ROUTE → CLOSE

A component that exists, is non-empty or is registered is not automatically operational. Operational files require a consumer and contract; derived/reference files require authority/disposition. Runtime behavior requires execution evidence.