Kalsa/workshop/deepening/README.md

Institutional Deepening Contract

This directory owns the critique-and-repair process. It does not own lore. Canonical claims live under Kalsa/; these records explain why and how an owner note changed.

Pass Contract

One pass addresses one bounded institution, region, practice, or cross-cutting system. Copy pass-template.md into a dated pass file before editing canon.

A pass must:

1. Select a target with a named canonical owner or explicitly record that the missing owner is the defect.
2. Inventory seed evidence, adopted claims, provisional design, contradictions, rumors, deprecated material, and unknowns without blending their authority.
3. Model owner, allowed inputs, outputs, dependencies, beneficiaries, costs, failure modes, enforcement limits, and interfaces.
4. Critique generic fantasy defaults, missing material constraints, false consensus, absent subordinate perspectives, and consequences that stop at the page edge.
5. Repair the smallest coherent set of canonical owner notes. Delete or demote duplicate owners before adding compensating prose.
6. Connect the repair to people, places, events, resources, language, magic, and playable pressure.
7. Falsify the result through at least one hostile or marginal perspective and one historical stress case.
8. Verify seed hashes, wikilinks, publication boundaries, the Quartz build, affected rendered pages, and the actual git diff.
9. Record the result in ledger.md, update queue.md, and promote only a durable operating lesson or decision into .epiphany/project-memory.md.

Completion Standard

A pass is complete when the repaired system produces more specific downstream consequences without leaving split authority, erasing the seed witness, or requiring workshop prose to explain the canonical note.

Word count, heading count, and link density are useful pressure gauges. They do not certify depth. The qualitative parity standard lives in benchmark.md.

Required Evidence

• source paths and exact seed witnesses read;
• canonical owner notes changed;
• authority map before and after;
• unresolved questions and explicit non-decisions;
• hostile/marginal and historical stress findings;
• verification commands and results;
• rendered-page inspection when published content changed.

If timing, interaction, or runtime behavior matters to a Ghostlight contract, verify that path in Ghostlight's owning repository rather than inventing a lore proxy here.