Sigil: Definitions Governance

1. Scientific/formal voice: the normative meaning, formal expression, symbol or notation meanings when relevant, and any testable boundary conditions.
2. Plain-language voice: a non-normative ordinary-language intuition that helps a reader understand the term without changing the formal meaning.
3. Domain-context voice: a non-normative explanation of how the term is used in the consuming project's current workspace, project surface, or active artifact set.

The domain-context voice is local to the consuming project. In the Arcanum repository, it may point to reader-facing context under development/user-guide/ when that surface helps explain how a definition appears in practical use. In other repositories, resolve the current workspace's own context surface instead of importing Arcanum-specific examples as authority.

When used in any repository, resolve the consuming project's root and write to that project's configured definitions surface. Do not place project definitions inside the installed sigil package, copied skill directory, .codex/skills snapshot, .agents/skills symlink target, or arcana/definitions-governance/ unless the repository has explicitly configured that path as its project-level definition authority.

Default project-level convention when no authority source exists:

definitions/
  DEFINITIONS.md
  DEFINITIONS-INDEX.md
  DEFINITION-DRIFT-AUDIT.md

For this Arcanum repository, the canonical project-level source is definitions/DEFINITIONS.md and the lookup layer is definitions/DEFINITIONS-INDEX.md.

• resolve and report the consuming project's canonical definitions path,
• avoid writing project definitions into the sigil package or installed skill copy,
• keep critical terms in the canonical source,
• preserve stable IDs when used,
• require scientific/formal, plain-language, and domain-context voices for every definition,
• colocate plain-language intuition and domain context with formal definitions,
• ensure domain context is anchored to the current project or workspace,
• prevent intuition or domain context from contradicting normative wording,
• keep indexes synchronized,
• identify downstream drift with exact remediation targets,
• validate structure where checks exist.

• using the sigil's own folder as the default project definition authority,
• treating copied skill packages as canonical definition stores,
• letting narrative artifacts become hidden definition authorities,
• adding formulas without symbol meaning and plain-language intent,
• adding definitions without a current project or workspace context voice,
• creating detached intuition that can drift away from the definition,
• using Arcanum's development/user-guide/ as the domain context for a different consuming repository,
• letting plain-language or domain-context wording redefine formal semantics,
• changing stable IDs casually,
• syncing indexes without auditing downstream consumers,
• treating local glossary terms as global canonical definitions without review.

1. Collect each feature SPEC's Concept Registry table (Concept | ID | Type, where Type is a DS-D1 meta-type per definitions/DEFINITIONS.md#ds-d1-meta-type-system).
2. Aggregate into a global registry keyed by ID, carrying the DS-D1 meta-type.
3. Build concept-graph edges from each feature's typed relationships (DS-D2 verbs), validated against the DS-D8 edge signature; reject edges whose endpoint meta-types violate the signature.
4. Detect duplicates (same ID, different type or feature) and drift (a concept whose meta-type changed across features) — flag, never auto-merge.
5. Emit the aggregated registry + edge list + a dup/drift report. Promotion of any new global term still follows the authority rules above.

Wedge method only: reads the public DomainSpec spec interface (M2-CONTRACT) and the canonical DS-D1/D2 definitions; it does not import governance-engine logic.

## Definitions Governance Summary

- Definitions updated: <ids or none>
- Definition voices complete: yes | no | not audited
- Index synced: yes | no | not applicable
- Drift found: yes | no
- Undefined critical terms: <count>
- Conflicting consumers: <count>
- Domain context surface: <project/workspace path or not resolved>
- Concept registry aggregated: <concept count | n/a>
- Registry duplicates/drift: <count | n/a>
- Validation: pass | fail | not run
- Canonical source: <project-relative path>
- Follow-ups: <ordered remediation list>