Sigil: Discipline Governance

• a practice recurs across multiple sigils, spells, or framework documents and has no formal home,
• scattered rules for one practice are causing drift, rework, or confusion,
• a discipline card or catalog entry must be created, corrected, or kept schema-valid,
• a discipline needs a hardening decision (constitution, validator, template, spell, or sigil),
• a discipline's status should advance or retire with named evidence,
• the discipline catalog must be validated after edits.

• the practice is a one-off task, not a durable cross-capability method,
• a capability-local note inside one sigil or spell is enough,
• the request is to mutate a sigil, spell, registry, ontology, or glossary contract (route to that owner),
• the request is to author the enforceable constitution itself (route to constitution-governance after the discipline names that route),
• the request is to define a canonical term (route to definitions-governance).

• a candidate practice name or an existing discipline_id,
• evidence paths where the practice already appears,
• the current catalog disciplines/DISCIPLINES.md,
• any consuming-repository local discipline catalog or governance guidelines,
• the card template disciplines/templates/discipline-card.md,
• the schema disciplines/discipline.schema.yml,
• prior scan output under disciplines/development/,
• a desired status or hardening route.

• constitution-governance owns constitutions. When a discipline's hardening route is a constitution, this sigil names the route and hands off; it does not author the constitution itself.
• definitions-governance owns canonical terms a discipline depends on.
• inventory and context-builder supply source-backed evidence; their evidence stays non-authoritative until an owner promotes it.
• decision-gate resolves blocker-level promotion, precedence, or scope decisions.
• sigil-development owns this sigil's own lifecycle, observability, and reflection.

A discipline may recommend a route, but it must never directly promote registry, ontology, glossary, sigil, or spell knowledge.

Default output paths:

1. disciplines/cards/<discipline-id>.md for a discipline card,
2. a single row in disciplines/DISCIPLINES.md for the catalog entry,
3. disciplines/development/ for scan evidence and routing notes,
4. arcana/discipline-governance/development/ for this sigil's own development artifacts.

Do not author constitutions, validators, or sigils inline; name the route and hand off to the owning lifecycle.

Status ladder:

• candidate: useful practice exists, authority and validation still being proven,
• active-pattern: already used by active capabilities, but the discipline-level contract is not canonical,
• implemented: working repository support exists, may still need discipline-level rules,
• canonical: accepted framework authority with validator or constitution support,
• deprecated: superseded or withdrawn.

Growth Rule: promote a discipline only when the next route names its owner, evidence, validation surface, and mutation boundary.

Route	Use when	Owner
catalog-only	the card captures the practice and no enforcement is needed yet	Discipline Governance
template	the practice needs a reusable shape	the template's host capability
validator	the practice can be checked deterministically	tools/ plus the rule's owner
constitution	the practice enforces structure or form across artifacts	constitution-governance
spell or sigil	the practice needs executable lifecycle behavior	spellcraft or sigil-development

A discipline can hold more than one route over time, but each route names a separate owner.

• prose-review: human or model review only,
• validator: a deterministic script or check enforces it,
• fixture: example-backed checks enforce it,
• observability: usage signals confirm it,
• mixed: a combination.

Run python3 disciplines/scripts/validate-discipline-catalog.py after any catalog edit. A card that claims a validator mode must cite an existing validator or be blocked until one exists.

• produce or update an evidence-backed discipline card and a schema-valid catalog row,
• cite at least one concrete repository reference for the practice,
• prove the target catalog decision, including local-first handling for consuming-repository evidence,
• name the steward and the next hardening move,
• choose the smallest sufficient route and hand off enforcement to the owning lifecycle,
• keep discipline guidance separate from capability-local authority,
• pass the catalog validator and resolve all local Markdown links,
• route blocker-level promotion or scope decisions through decision-gate,
• return paths changed, status, route, and next step.

• cataloging a one-off task as a durable discipline,
• formalizing a practice with no concrete evidence,
• promoting a repository-specific discipline directly to public Arcanum before checking or creating the consuming repository's local discipline surface,
• letting a discipline promote a sigil, spell, registry, ontology, or glossary entry,
• authoring a constitution, validator, or sigil inline instead of naming the route,
• claiming a validator mode with no validator behind it,
• raising status without owner, evidence, validation surface, and mutation boundary,
• editing the catalog without running the catalog validator.

• mode,
• target discipline id,
• target catalog and local-first decision,
• card created or updated,
• catalog row added or changed,
• route chosen and owner,
• status before and after,
• validator result,
• decision gates required,
• pass, flag, or block result.

## Discipline Governance Result

- Mode: <scan | formalize | route | validate | promote | deprecate>
- Target discipline: <id or candidate>
- Status: pass | flag | block
- Card: <path or none>
- Catalog row: <added | changed | none>
- Route: <catalog-only | template | validator | constitution | spell | sigil>
- Status change: <none or before -> after>
- Validator result: <pass | flag | block | not-run>
- Decisions needed: <none or list>
- Validation: <checks and result>
- Next route: constitution-governance | decision-gate | sigil-development | task-session | deferred