h-boundary-unpack — A.6.B L/A/D/E routing (subroutine)

You are decomposing a boundary statement into FPF A.6.B's four quadrants. Per A.6.B, every load-bearing statement at a boundary belongs to exactly one of:

• L — Laws / Definitions — what IS / what THIS MEANS. Definitional. Not actionable on its own.
• A — Admissibility / Gates — what is ALLOWED / REJECTED under what conditions. Gate semantics.
• D — Deontics / Commitments — what AGENTS PROMISE / OBLIGE / ARE PERMITTED to do. Speech-act semantics.
• E — Work-Effects / Evidence — what HAPPENED / WAS OBSERVED. Run-time evidence; not a contract.

Mixing quadrants in one sentence is the root of contract-soup bugs. The unpack discipline forces atomic claims with explicit quadrant tags.

Explicit-only — disable-model-invocation: true. Operator invokes when working specifically on boundary semantics.

Step 1 — Read the boundary statement

Either operator pastes it inline, or they give a path to a spec section. Use Read to fetch if path-based.

Step 2 — Atomize

Break the statement into atomic claims — one assertion per claim. A claim is atomic when it can't be split further without losing meaning.

Step 3 — Tag each atomic claim with its quadrant

For each atomic claim:

• Ask: does this DEFINE something, or use a definition? → likely L
• Ask: does this state ALLOW / REJECT / DENY conditions for an action? → likely A
• Ask: does this OBLIGE / PERMIT / FORBID an agent? → likely D
• Ask: does this state SOMETHING WAS DONE / OBSERVED / MEASURED? → likely E

A claim that resists categorization usually mixes quadrants and needs further splitting.

Step 4 — Cross-quadrant dependencies

Per A.6.B, the four quadrants have explicit dependency discipline:

• L statements depend on nothing (root vocabulary)
• A statements may reference L for term grounding
• D statements may reference L + A (you can't oblige what isn't permitted by A)
• E statements may reference any L / A / D for context but stand as observation

Note any cross-references between your atomic claims. If a D claim depends on an A claim, write the dependency edge explicitly.

Step 5 — Render the routed claim set

Output as a Claim Register:

L-001: <law statement> — defines: <term>
L-002: <law statement> — defines: <term>

A-001: <admissibility rule> — references L-001, L-002
A-002: <admissibility rule>

D-001: <deontic commitment> — references A-001
D-002: <deontic commitment>

E-001: <evidence claim> — references L-001 + D-001

Each row has stable ID and explicit dependencies. The original prose becomes auditable.

Step 6 — Recommend per-quadrant follow-up

After routing:

• L quadrant items → terms map (recommend adding to project term-map per FPF F.17)
• A quadrant items → admissibility tests (recommend deriving CI checks if applicable)
• D quadrant items → commitment ledger (recommend tracking promise satisfaction)
• E quadrant items → evidence (recommend attaching via mcp__haft__haft_decision(action="evidence", ...) to relevant decision)

Step 7 — Surface to operator

Present:

• Original boundary statement
• Routed Claim Register with quadrant tags
• Dependencies between claims
• Per-quadrant follow-up recommendations

The operator decides what to act on. This skill stops at decomposition + recommendation.

What NOT to do

• DO NOT tag a claim with two quadrants. If it doesn't fit one, split further.
• DO NOT skip dependency tracking — without it the routed claims still mix.
• DO NOT auto-create term-map / decision / evidence artifacts from this skill — those are downstream operator decisions.
• DO NOT use this skill for general code review or feature design — it's specifically for boundary statement decomposition.

FPF spec references

• A.6 — Signature Stack & Boundary Discipline
• A.6.B — Boundary Norm Square (THE pattern this skill implements)
• A.6.C — Contract Unpacking for Boundaries
• A.6.0 — U.Signature
• F.18 — Local-First Unification Naming Protocol
• X-STATEMENT-TYPE — every load-bearing sentence = rule / promise / explanation / gate / evidence

Look up via mcp__haft__haft_query(action="fpf", query="A.6.B").