A prompt is a suggestion. A policy is a suggestion someone can waive. An agent's account of what it did is a suggestion about what happened. Security by design means the controls live in the structure, where they are neither. When review is the bottleneck, governance has to live in the review step, and it has to be deterministic and tool-agnostic rather than delegated to another agent. This page is the doctrine behind the governance framework we teach: three layers, two disciplines, and one case.
No component both acts and verifies what it did, and the separation is enforced by the structure, not by a policy someone can waive under deadline. This is what makes reward hacking impossible rather than discouraged: an agent that cannot grade its own work has nothing to game. Unilateral failure becomes impossible by construction.
The system verifies itself, and it is required to disclose its residual blind spots. The doctrine is never "we check everything." It is: we check what we can, and we tell you precisely what we cannot. A verification that does not state its limits is a claim, not a verification.
When the separated roles interact, the result is written to a space that neither controls alone. Authority cannot rewrite history because history is not in authority's hands.
Our name for the way verification is arranged so that agreement between examiners is evidence rather than echo, and a shared error cannot hide. An outside CTO reviewed the method and accepted it as rigorous. How it is arranged is taught in the workshop, not published here.
The seven elements that implement these layers are named on the Training page. What they are is public. How they are built is the workshop.
What counts as passing is decided and recorded before anyone sees the data, by someone who will not run the test. It is how a testing lab keeps itself honest, and it is how the framework keeps an agent from grading on a curve it drew afterwards.
Verification checks what is actually there, not the account an agent gives of its own work. An agent describing what it did is not evidence that it did it. The record has to be able to contradict the narrator.
Info Science AI leads verification for a financial engineering firm's production system, with six figures of live capital riding on the output. Our precision audit caught a drift of up to 1.66 × 10−4 in a derived constant before it reached production. We did not patch the constant. We changed the system so that every constant derives at runtime from a single primitive, and every one now matches its canonical value to full floating-point precision. That class of drift cannot recur. Finding one error is luck. Closing a class is design.
The firm's own CTO, a PhD in mathematics, then independently inspected and ran all four verification modules in their environment. Every assertion passed. His written review called the precision audit alone enough to justify the engagement, and described the stereo verification method as producing genuinely independent evidence. That is the kind of proof this practice values: not our description of what we did, but an outside party re-executing it and getting the same answer.
The same package included a test that failed its literal question and succeeded on its structural one: a negative result that turned out to confirm something from the other side. A method that could only report successes would have thrown it away.
For twenty years Daniel Wilson ran a department that operated as a third-party testing lab for other companies, vendors, and manufacturers. Independent verification as a business, for two decades. The subject changed from digital media to AI systems. The discipline did not.
He also served as Data and AI Sovereignty Advisor to Malaysia's National AI Office, on the AI & Data Sovereignty working group whose guidance helped steer the country's domestic and international AI policy positions.
We teach the structure and hand over the templates. Then we tell you exactly what it catches in your environment, and what it cannot. Few will tell you the second part.
The three layers are built from seven working elements. Those, the workshop outline, and the offerings are on the Training page.
