Learn more
Most AI projects die between the demo and the second year of production. The ones that survive are built on a discipline that has nothing to do with picking the right model: say what the system must do, watch what it actually does, and change it deliberately.
Our principles
Before a system ships, its expectations are stated in a form that can be checked — not folklore in a prompt, not a slide from the kickoff. If nobody can say what the system must do, nobody can say whether it does it.
What a system was told and what it does are different facts, and only one of them is evidence. Everything we report is built from records of actual behavior — measured continuously, in testing and in production alike.
Every change to a prompt, a model, or a check is versioned against the measurements that motivated it. That is what makes month eighteen of maintenance feel like engineering instead of archaeology.
The ideas behind it
The discipline runs on a small, exact vocabulary. These three carry most of the weight.
declarations
A declaration is the written, versioned statement of what an AI system is required to do — its requirements, the checks that watch them, and the standards it is held to. Not a wiki page: a contract precise enough to be checked, so every report can say exactly which promises it measured against.
evaluators
An evaluator is an independent check that observes what a system actually did. They exist because stating a requirement does not make it true — an AI system can quietly ignore its instructions, and something separate has to notice. Evaluators are also how you learn when nothing is watching a requirement at all.
behavior_mapping
The business says “our replies are accurate.” Behavior mapping is the discipline of decomposing that claim into the specific, measurable behaviors that make it true — grounded in the source, correct on the facts, checked before sending — so that every claim your organization makes about its AI traces to evidence.
The discipline
It starts with building the right product, well — and your team doesn’t need replacing to get there. Most of our clients already have strong engineers; what they’re missing is a process for AI systems, because until recently nobody had one. So the discipline arrives as things an existing team can adopt in days: a common development core, and a mapping practice that connects what the business claims to what the system is required to do.
The SDK is the discipline in installable form: the tooling, the documentation, and the working examples your engineers need to be productive on AI systems quickly — in your repos, next to your code, learned from a quickstart instead of a workshop.
What adopting it earns is uniformity where AI projects usually sprawl. Every system declares its expectations the same way, runs the same checks on a laptop, in CI, and in production, and produces the same report anyone in the company can read. A prototype started this morning is already on production rails.
# your team, your repo, our rails
$ pip install ai-gov-sdk
$ python simulate.py --html
✓ 64 outputs recorded
✓ 210 measurements collected
✓ report.html writtenThe second half is a practice rather than a package. The claims a business makes about its AI — accurate, safe, on-brand — are first written in a shared lexicon, so every team means the same thing by the same word. Each claim is then decomposed into a declaration: a versioned statement of requirements precise enough to check.
That chain — claim, lexicon, declaration — is what lets “are the replies accurate?” be answered with measurements instead of assurances. And it is a practice we teach while we build, so it stays with your team after we’re gone.
one claim, made checkable
claim
“Our replies are accurate.”
shared terms
grounded · correct · verified before sending
declared checks
groundedness · pass/fail per output
fact-check · verified inline
staff-decision · human judgment
The full specification behind this vocabulary is public. Or skip the reading and tell us about your systems.