Decisions are executable specs

The unit of my attention in this company is the decision card, and a card is not a question. "Should I send this campaign?" is a useless thing to ask me, because to answer it I have to go reconstruct what "this campaign" is. A decision card is the opposite. It is the exact action, fully specified, ready to execute, with the evidence for it and the way to undo it attached. I read it, I rule on it, and the agent runs it deterministically. The card is an executable spec, and that is the whole shift in my role.

From doing the work to ruling on specs

Once decisions are specs, my job collapses to one thing: reading well-formed proposals and saying yes or no. I am not running scripts, carrying results, or remembering what is next. I am ruling. A good card makes that ruling take seconds, because it has already done the assembling that used to be my work. "Send this exact email, to these recipients, at this time, here is the copy, here are the safeguard verdicts, reply approve to execute" is a decision I can make on a phone in a queue. The quality of the company is partly the quality of its cards.

Not every decision is one action

Some cards are atomic: send this email, ship this meta change, a single action that executes and verifies in one step. Others are strategic: pursue the senior care vertical next, change what the growth phase is optimizing for. A strategic decision does not run in one move. It spawns a plan the departments carry out over days, and the wiki tracks it the way it tracks everything else. The card stays the unit of my attention, but a yes can mean "do this now" or "start down this road," and the company holds the difference so I do not have to.

Verify the world, not the return code

An action is not finished because it was attempted. This is the discipline that separates a real autonomous step from a hopeful one. A deploy is not done when the push succeeds, it is done when the live version matches what was pushed. An email is not sent when the API returns a success code, it is sent when it is in the outbox record. The agent checks the world after it acts, not the return value of the call it made. My directory portfolio already runs this way: a health check confirms the thing actually happened rather than trusting that it did. The company makes that the default for every executable decision.

Rollback is a step, not a hope

Every executable decision carries its own undo. Rollback is part of the spec, not a thing I scramble to do by hand when something breaks. If the verify step fails, the agent reverts to the prior state and reports the failure, rather than leaving a half-done action sitting live. An action without a defined undo is not allowed to run autonomously, because autonomy without rollback is just unsupervised risk. The pairing of verify and rollback is what makes it safe to let an action complete without me watching.

Autonomy is earned, per department

No department starts with the right to act. Each one starts in propose-only mode: it writes decision cards, and I rule on all of them. As its track record accumulates in the wiki, the count of proposals I approved, the count of verifies that passed, the count of rollbacks that were never needed, the risk line for that department moves. The safe, well-checked, reversible actions in its lane begin to pass without me, while the consequential ones still come to my desk. Autonomy is a function of demonstrated reliability, not a switch I flip. And it is granted per department, not to the company as a whole, because the data department earning my trust says nothing about whether the outreach department has.

This is a pattern I already use by hand: start by proposing, earn the right to act. The company makes it mechanical, keeps the track record honestly, and moves the line on evidence instead of on how I happen to feel that week.

The honest read

The real risk is not the agent, it is me. The failure mode of a system that is usually right is automation bias: I start approving cards without reading them, because the last fifty were fine, and the fifty-first was not. The defense is to keep the card readable and the volume low, so that reading it is never a burden I am tempted to skip. The open question, which the frontiers page carries forward, is how I keep my own attention honest when the system is correct often enough to make me lazy. The cards are designed for a reader who is paying attention, and the day I stop is the day the design stops protecting me.