Engineering
Build decision systems that can be stopped, explained, and reversed, with the guardrails written as code rather than as policy.
Where to start
Three moves, in order
Each ends somewhere you can act rather than somewhere you can read.
-
Audit a system spec and generate guardrails
Run the System Auditor against a spec to surface failure modes and synthesize TypeScript or Python middleware.
-
Enforce STD-01: temporal rights and recourse
Implement deterministic time-to-halt, reversal SLAs, and the receipt structure a decision has to emit.
-
Model burden and human substitution
Calculate the load the system pushes onto people, and check review capacity against the ceiling it assumes.
Tools and standards
What to run and what to satisfy
The diagnostics that surface risk for this role, and the standards that bear on its work.
Diagnostics
What to attend to
The parts of the method that bear on your work
Not everything here is yours. These are the parts that are.
- Instrument systems to surface burden, latency, and escalation signals.
- Build policy controls that enforce standards in production.
- Coordinate with stewards on maintenance and rollback readiness.
What to open
Where the material actually is
- Standards — Doctrine and rights to codify in system guardrails.
- Mechanisms catalog — Spec sheets for governance, friction, and policy controls.
- Validators — Diagnostics that surface operational risk.
- What we can check — Which governance properties a probe can actually establish.
First moves
- Map existing telemetry to the burden and latency validators.
- Implement a mechanism spec as a feature flag or control rail.
- Partner with stewards to define rollback and escalation ownership.
Adoption checklist
What to have in place
For a team that has decided to adopt. Each line is a thing that either exists or does not; none of them is a posture.
- Set explicit action boundaries for high-risk automations.
- Require approvals before sensitive sends, deploys, or data writes.
- Instrument rollback paths and verify they are runnable under pressure.
- Log all override actions with named owners and timestamps.
Other roles
If that was not you
Seven audiences, one page each. Picking the wrong one costs a click, not a detour.
- Policy and compliance — You write the rules the system has to satisfy, or prove to a regulator that it does.
- Audit and assurance — You verify someone else's claims from the evidence their system emits.
- Operations — You run the appeals, the incident response, or the queues where the system's errors land.
- Design — You shape the interface where a person meets the decision.
- Research — You study these systems and publish about them.
- Executive — You decide whether to deploy, and you carry the liability when it goes wrong.
Or go back to Start, which asks the same question with all seven answers on one screen.