Federate pillar ownership; resolve three boundary cases

[ehharvey]

Makes inventory each pillar's own job, and records the rule that stops a process landing in two pillars.

Inventory federates

The 2026-08 audit was necessarily centralised — nobody could inventory their own pillar before anyone knew what existed. Ongoing inventory is per-pillar: nobody re-audits 68 processes, but each pillar can handle its own 5–16.

Tracked as Theme: Season re-audit with eight children, one per pillar.

The arbitration rule

Recorded in the Process Index itself:

One row, one section. A process belongs to exactly one pillar — the one whose volunteer is holding the document at the moment they need it. This page is the register that decides; Project 47 follows it.

The risk was never the field — Pillar is single-select. It was two pillars each filing their own item for the same process and reaching different conclusions. A single register upstream prevents that, and #26/#27 make it a policy with a checker.

Three boundary cases

Process	Was	Now	Why
Writing hacknight recaps	Hacknights	Marketing	The Season 8 role that writes them is "Marketing, Outreach and Documentation"; they feed the blog and the recap control
Event roles on the night	Hacknights	Hacknights	Events owns what a role does on the night; Roles owns who signs up across a season
New member onboarding	Roles	Split	Greeting script → Events (the Emcee holds it); attendee-to-volunteer path → Roles

Counts

68 processes, 18 gaps. Verified programmatically against the table rows; all five prose references updated to match.

🤖 Generated with Claude Code