Verifiable Trust

Never entrust AI with more time, data or money than you're willing to lose, unless you can independently verify its work and bound the consequences of failure.

Short form: Trust AI only as far as you can verify its work or afford its failure.

This applies equally to outputs and actions. Verifiable code does not make unbounded execution safe; read-only work can still waste time, disclose data or produce false conclusions.

Rules

1. Design for independent verification. Prefer objectively testable outputs: compilers, meaningful tests, static analysis, observed behaviour, bounded comparisons and authoritative sources. Plan verification before relying on results.
2. AI confidence is not verification. Self-assessment, second-model agreement, or generated tests mirroring generated assumptions cannot independently establish correctness against the requirement.
3. Bound exposure. Limit time, retries, tokens/API spend, data access, permissions, change scope and potential production impact. Use the least privilege and cost needed.
4. Prefer reversible actions. Branches, disposable sandboxes, staged rollout, backups and tested recovery where consequence justifies them. Durable data deletion remains high risk even if the code is unit-tested.
5. Make rigour proportional to loss. A small doc edit needs little ceremony; authentication, credentials, destructive migrations, production infra and financial operations need stronger checks, constrained authority and possibly explicit approval.
6. Report evidence and limitations. Separate observed verification from assumptions, and disclose untested failure modes and residual risk.

Decision loop