Sigil: Constitution Governance

• a governance rule should apply across future artifacts,
• a constitution is becoming a catch-all file,
• a task needs only the constitutions that match its artifact type or structure,
• selected constitutions need composition before a task runs,
• a new constitution rule requires a validation adapter,
• a validator should be updated in response to a constitution rule,
• constitution context load is weakening rule effect.

• a local task note is enough,
• there is no reuse or validation expectation,
• a deterministic validator already covers the rule and no governance decision remains,
• Context Builder selection alone is enough and no composition, conflict, or validator impact exists.

• target task, artifact type, constitution path, or rule proposal,
• existing constitution files,
• validator scripts or checks,
• known artifact failures,
• desired canonicality level,
• context budget or task scope,
• evidence from prior runs or reviews.

1. arcana/constitution-governance/development/ for sigil development artifacts,
2. <target>/development/constitution-pack.md for task-specific composition packs,
3. framework/<NAME>-CONSTITUTION.md for framework-level constitutions,
4. tools/ updates only when the user approves or the rule is already accepted.

1. task-specific constitution pack,
2. artifact-type constitution,
3. domain or capability constitution,
4. framework constitution,
5. repository-wide default.

When two rules conflict:

• preserve both rules,
• classify the conflict as blocker, deferrable, or local override,
• use Decision Gate for blocker conflicts,
• do not silently let the larger constitution override the narrower one.

Context packs should include only the rules needed for the task, plus enough source links to audit them.

• deterministic: script, lint, test, schema, or static check can enforce it,
• review: human or model review required,
• hybrid: deterministic precheck plus review,
• none-yet: constitution records intent, but promotion is blocked until a validation route exists.

Validator changes must cite the constitution rule they enforce.

• keep constitutions modular and scoped,
• avoid loading a large constitution when selected rules suffice,
• separate Context Builder selection from constitution composition,
• define rule authority, selectors, examples, and validation mode,
• identify validator updates needed by new rules,
• preserve conflicts instead of smoothing them over,
• route blocker precedence or canonicality decisions through Decision Gate,
• keep generated task packs separate from canonical constitutions,
• return a pass, flag, or block result with paths and validators.

• adding every new rule to one giant constitution,
• treating context selection as enforcement,
• treating validators as authority without a constitution rule,
• promoting rules without examples and non-examples,
• loading all constitutions into every task,
• hiding conflicts by choosing the newest rule,
• adding a validator check that is broader than its constitution scope,
• making a constitution canonical because it is convenient rather than evidenced.

• mode,
• constitutions inspected,
• rules selected,
• rules added,
• composition pack path,
• validator changes proposed or applied,
• conflicts found,
• decision gates required,
• pass/flag/block result,
• context budget status.

## Constitution Governance Result

- Mode: <create | add-rule | select | compose | validate | split | promote>
- Target: <target>
- Status: pass | flag | block
- Constitutions inspected: <paths>
- Rules selected or changed: <summary>
- Composition pack: <path or none>
- Validator impact: <required | applied | none | blocked>
- Conflicts: <none or list>
- Decisions needed: <none or list>
- Validation: <checks and result>
- Next route: context-builder | decision-gate | task-session | sigil-development | deferred