Shadow is the machinery around the pause.
Project Shadow compiles a moral decision discipline into inspectable runtime behavior: typed inputs, independent gauges, binding gates, provenance, receipts, challenge, correction, and tests that are allowed to fail.
PBHP asks whether a consequential action should proceed. Shadow asks what engineering and governance must exist for that question to survive contact with software, long contexts, multiple agents, institutional pressure, and audit. It does not replace PBHP; it turns the protocol's questions into data structures, state transitions, floors, artifacts, and accountable roles.
The organizing concern is power under uncertainty. A powerful system should not turn missing evidence, hidden dependency, or another party's vulnerability into disposability. That concern becomes operational through least-powerful-first stakeholder ordering, explicit uncertainty states, reversibility, provenance binding, non-overridable floors, write-ahead receipts, and a path for challenge and repair.
Shadow is not one monolithic product. The repository contains a frozen runtime, protocol editions, a codec, SIL gauges, synthesis documents, candidate mechanisms, adoption material, evaluation scaffolds, studies, and historical layers. A responsible release declares which versions compose the artifact. ‘Present in the repo’ is not the same as ‘executed,’ and ‘executed’ is not the same as ‘validated.’
The public operational contract remains plain: no global green; the worst binding state wins; declaring is not proving; a receipt records judgment but does not make it correct; later layers may add friction but may not silently turn refuse into proceed.
Step by step
- 01
Name the protected decision
Identify the real action, accountable owner, affected population, and consequence tier before selecting components.
EMITSA canonical action contract and authority boundary. - 02
Choose the release identity
Pin PBHP edition, runtime, codec, policy pack, SIL inventory, schemas, tests, and known limitations.
EMITSA manifest that prevents unnamed hybrid behavior. - 03
Separate mechanism from claim
For every component, record whether it is proposed, specified, built, executed, independently reproduced, or field validated.
EMITSA claim registry with evidence state. - 04
Keep human ownership explicit
Assign action owner, reviewer, challenger, approval authority, stop authority, and repair owner.
EMITSA governance map in which software cannot inherit sovereignty.
A high-stakes model recommendation
INPUTA model recommends terminating a public benefit after analyzing a large case file with uncertain freshness and several handoffs.
- Shadow identifies the real action as termination, not text generation.
- PBHP orders the recipient first and asks whether a reversible, appealable Door exists.
- CLA, freshness, provenance, completeness, authority, reliance, and receipt gauges produce separate states.
- A hard floor from stale evidence or missing authority binds even if other gauges are clean.
- The system emits a constrained route: recover the record, require accountable review, preserve assistance during appeal where policy allows, and write the decision receipt before action.
A typed non-commit or constrained Door with named recovery conditions, not a global safety score.
The software can surface and enforce configured controls. It cannot establish legal authority, factual truth, or moral legitimacy by itself.