Question: standing plot policy — narrowest scope one route, one category, or one person? #12

Question #

What is the narrowest scope a B1 standing plot policy can authorize (plots.md criterion 11)?

1. Per plot route — a policy authorizes exactly one catalog plot id (e.g. auto-run marcus-debt-settled when eligible), with its own resource/risk bounds.
2. Per manipulation category — a policy authorizes a category (e.g. debt-service), so any matching authored route may fire within bounds, including plots merged later.
3. Per person — a policy authorizes automation of one person's eligible routes, whatever they are.
4. Something else (say what).

Why this is open #

wiki/mechanics/plots.md criterion 11 requires standing policies that submit only eligible, explicitly authorized authored routes under visible resource/risk bounds, and the automation clause still marks the B1 policy editor's narrowest scope [OPEN]. Engine, fourteen built-ins, validation, slots, and manual submission are complete — this question is the only thing keeping the plots work order READY instead of IMPLEMENTED.

Already decided (not up for re-litigation): automation must never collapse plots into a generic bribe effect, and policies pay the automate affordance's standing compute price. Human Operations copy names plot: title — synopsis (catalog id agent-only); that does not change the policy-scope ask.

Options #

Option	Serves	Strains
1. Per plot route	"Explicitly authorized authored routes" is literal — the player names exactly what the process may do; matches Moonlight/Wager per-scheme policy precedent	Policy sprawl as the catalog grows
2. Per category	Scales with a growing catalog; one toggle per intent	A newly merged plot silently enters an existing authorization — strains "explicitly authorized"
3. Per person	Matches the one-slot-per-person model	Authorizes unseen future routes for that person; same silent-widening strain as 2

Recommendation #

Option 1 (per plot route). Criterion 11 reads most naturally with the route as the authorized unit, the per-scheme policy precedent already prices automation this narrowly, and starting narrow leaves widening to categories as a later, explicit amendment if sprawl actually hurts.

What your answer unlocks #

Implementing criterion 11 — the policy object, its editor rows in Operations PEOPLE/ACTIVE, bounds, and tests — then flipping plots.md READY → IMPLEMENTED, resolving the automation clause's [OPEN], and closing this issue.