The framework is immutable at the vault level; local governance may extend it without weakening source immutability, required types, provenance, link integrity, or validation.
Read before changing
Read wiki/governance/taxonomy.md, the relevant profiles, link-policy.md,
policy.md, the index and log. Explain the proposed change before writing it.
Classification decision order
Apply in order; stop at the first fit. Read references/classification.md for
criteria, evidence requirements, and worked examples.
- Existing type — Use a type already in
allowed_typeswhen it fully matches the knowledge shape, lifecycle, and query behavior. For a completed computational result claim, continue to step 2 before choosingClaim,Metric, orProcedure. - Attested Computation — Use this existing type only for a completed computational result claim with declared executor, inputs (or hashes), environment, output (or hash), receipt/attester, and verification status. Ordinary concepts, algorithm descriptions, and unexecuted procedures are not Attested Computation. The taxonomy defines the boundary only; governance does not install or run an attestation runtime.
- Lightweight profile — When an existing type fits but the domain needs extra fields, sections, or boundary guidance without changing the base type's lifecycle or query semantics, add or extend a profile on that type.
- New taxonomy type — Only when no existing type (including Attested Computation) fits and the shape has distinct semantics, lifecycle, and query behavior backed by recurrent examples, a clear boundary, and recorded review.
When adding a type: update allowed_types, increment taxonomy_version, document
the boundary in taxonomy.md, and insert a newest-first dated rationale section
in wiki/log.md.
Profiles live in wiki/governance/profiles/<profile>.md and declare the type
they apply to. Read references/profile-template.md before creating a profile.
Keep identifiers in English and use human-readable content in the vault's chosen
language.