Toolkit — Replace vs Stack Policy¶

This policy prevents framework stacking: the slow accumulation of overlapping systems that produce conflicting artifacts, unclear precedence, and compliance theater.

It is intentionally strict. If you can’t enforce it, don’t pretend you have governance—admit you are experimenting.

Purpose¶

Ensure that every recurring decision domain has:

one clear owner (authority boundary),
one source-of-truth artifact, and
one system that is primary (others must be subordinate or removed).

Definitions¶

System: a decision machine that produces inspectable artifacts under enforceable constraints.

Stacking: adding a new system without removing or subordinating existing systems that optimize the same decision or control the same object.

Replace: retire a system and move its decision ownership to a new system.

Subordinate: keep a system but explicitly declare it secondary via precedence rules.

Non-Negotiable Rules¶

Rule 1 — No new system without an observable failure¶

A proposal must include an Observable Failure Statement.

If the proposal begins with “we need alignment/clarity/visibility,” it is rejected until rewritten as an observable failure.

Rule 2 — No new system without a named decision type¶

A proposal must specify exactly one primary decision type:

priority / scope / ownership / sequencing / investment / diagnosis / repair

If it claims to optimize multiple, it must be decomposed into smaller systems or rejected.

Rule 3 — No new system without a source-of-truth artifact¶

A proposal must name the artifact that becomes authoritative for the decision domain and where it lives.

If it doesn’t change what artifact wins, it isn’t a system—it’s a meeting.

Rule 4 — Add implies remove or subordinate¶

Every new system must identify at least one existing system that will be:

removed, or
subordinated (with explicit precedence rules)

If “none,” then the proposal must prove it owns a currently unowned decision domain (a true gap).

Rule 5 — Precedence must be explicit¶

If two systems touch the same domain, the policy requires a precedence rule:

“When X conflicts with Y, Y wins, because Y owns the decision.”

Ambiguity is treated as collision and must be resolved before rollout.

Rule 6 — Enforcement and defaults are mandatory¶

Every system must include at least one enforceable constraint and an explicit default when violated.

If enforcement relies on reminders or goodwill, the system cannot be mandated.

Rule 7 — Systems must be reviewable and killable¶

Every new system must include:

a review date, and
kill criteria (evidence that triggers modify/subordinate/remove)

If the system cannot be retired, it is an institution and requires a different governance process.

Required Proposal Packet (Minimum)¶

A proposal is considered valid only if it includes:

Observable Failure Statement
Dominant frame (strategy/discovery/delivery/cooperation/evolution)
Primary decision type
Object(s) of control (1–2 max)
Artifact(s) produced (source of truth identified)
Constraint + default
Misuse model (at least 3) + mitigations
Adoption path (who first; minimal viable use; time to first value)
Replacement/subordination plan (what changes in the landscape)
Review date + kill criteria

Replace vs Subordinate Decision Guide¶

Prefer Replace when:¶

the old system optimizes the same decision and causes collision
the old system is ritual/theater (no enforceable constraints)
the new system provides a stronger artifact + enforcement model

Replacement requirement:

migrate or archive the old system’s artifacts
explicitly communicate end date and what changes

Prefer Subordinate when:¶

the old system is still useful locally but conflicts at a higher level
you need it as an input artifact, not a decision artifact
the new system owns the decision but consumes outputs from the old

Subordination requirement:

write precedence rules in the documentation and artifacts
clarify what the subordinate system is not allowed to decide

Precedence Rules Template¶

Use this exact format:

Decision domain: ______
Primary system: ______
Source-of-truth artifact: ______
Subordinate systems: ______
Precedence rule: “When artifacts conflict, ______ wins.”
Default when conflict is unresolved by deadline: ______
Decider for precedence disputes: ______

Governance Workflow (Lightweight)¶

Step 1 — Decompose the proposed system¶

Use the Decomposition Table to confirm decision type, object of control, unit of analysis, and enforcement.

Step 2 — Map the collision risk¶

Update the System Landscape Matrix:

show where it overlaps
show what it replaces/subordinates

Step 3 — Require a minimal viable run¶

Before any mandate:

run one cycle in a small scope
produce real artifacts
demonstrate enforcement once (constraint + default triggered or proven)

Step 4 — Decide rollout level¶

Only after evidence:

keep local
expand to adjacent teams
mandate (rare; requires strong enforcement and clear authority)

Step 5 — Review and kill if needed¶

At the review date, choose:

keep / modify / subordinate / remove

“No decision” is treated as “remove” by default.

Default Rules (When People Avoid Decisions)¶

These defaults prevent indefinite limbo:

If precedence disputes are unresolved by the deadline, the primary system’s artifact wins.
If a new system cannot name what it replaces/subordinates, it is not introduced.
If a system cannot show decision improvement by the review date, it is removed or reduced.

Common Policy Failure Modes (and Fixes)¶

Failure mode: “We’ll keep both”¶

Result: collisions, translation work, slow drift into theater.

Fix:

enforce Rule 4 (add implies remove/subordinate) with no exceptions.

Failure mode: “We’ll pilot forever”¶

Result: no commitment, no selection pressure, sprawl.

Fix:

require kill criteria and a hard review date.

Failure mode: “This is just guidance”¶

Result: no enforcement, no decision improvement.

Fix:

refuse mandate; redesign constraint/default or abandon.

Policy Summary (One Screen)¶

No failure → no system
No decision type → no system
No source artifact → no system
Add implies remove/subordinate
Precedence rules are mandatory
Constraints + defaults are mandatory
Review + kill criteria are mandatory