Enterprise AI operating principles

These are written for the person accountable for how AI behaves in production, not for a deployment checklist. Each principle links to the concept or paper that argues it in full, so this page can stay a reference you return to rather than a case you read once.

1. Measure outcomes, not activity

Judge every AI decision by the real result it was meant to produce, pulled from the system where that result actually lands, not by the trace, the eval score, or the fact that it ran. Activity is what the machine did; the outcome is whether the work was right, and only the second is worth trusting. When a metric is available in two forms, the self-reported one and the reconciled one, the reconciled one wins every time. This is the foundation the rest of the principles stand on, and it is treated in full in Outcome Intelligence.

2. Define what "done right" means before you automate

Before an agent is allowed to act autonomously, write down what a good outcome looks like as concrete conditions: the real question answered, the policy followed, nothing done twice, resolved in time. Vague success cannot be verified, and an outcome you cannot verify you cannot trust. Writing the standard down as an outcome contract is usually the most clarifying hour a team spends, because it forces agreement on what success means before anything is measured against it. If you cannot state the conditions, you are not ready to automate the decision.

3. Keep a record a human can read

For every decision, keep a record that a non-engineer, an auditor, a compliance officer, a reviewer, can read and understand: what the agent faced, what it decided, and how it turned out. Raw traces do not count, because the people who have to answer for a decision cannot read them. The test is simple: if a decision were questioned six months from now, could someone outside the engineering team reconstruct why it was made and whether it worked. That is Runtime Evidence, and it has to be captured when the decision is made, not reconstructed under pressure later.

4. Start in shadow, earn autonomy

Do not grant an agent authority on the promise that it works. Run it alongside the current process first, decide as if it were live, and compare its decisions to the real outcomes without letting it act. Autonomy is earned by a track record measured against reality, not by a passing demo or a green evaluation suite. The amount of autonomy a system holds should track the amount of trust it has actually demonstrated on real outcomes, and that trust is built one reconciled decision at a time. A system that has not been checked against reality has not earned the right to act unattended.

5. Fix causes, not symptoms

When a decision goes wrong, resist the reflex to patch the surface. A prompt edit that silences one bad case often moves the failure somewhere less visible. Ask instead why the decision was wrong, and answer the honest version of the question: was the agent actually at fault, or was the agent right and the world moved against it. That distinction, decision attribution, is what keeps a trust program credible, because a program that blames the agent for every bad outcome is as useless as one that excuses it for every one. Fix the cause the attribution points to, then confirm the fix against the outcome.

6. Treat trust as maintained, not granted

A system that was trustworthy at launch will not stay trustworthy on its own. The model gets updated, the data shifts, the world moves, and a decision rule that was right last quarter quietly stops being right. Treat trust as a property you keep re-earning, through continuous verification that keeps comparing decisions to real outcomes over time. Every change you make to improve a result is a hypothesis until the outcome, measured before and after, confirms it. Bank no result you have not re-checked.

7. Degrade honestly, say unknown

An autonomous system should be able to say it does not know. The most dangerous failure is the confident, well-formed wrong answer, because it is indistinguishable in the moment from a right one and passes every check built to watch the machine. Design the system, and the way you report on it, to surface uncertainty rather than paper over it: an honest "unresolved" or "not verified" is worth far more than a fabricated success. What you cannot yet measure, mark as unmeasured; do not let a blind spot read as a pass. The failure modes worth being honest about are treated in Honest limits and Silent Failure.