The artifact behind the claim. The operator thesis.
Two institutions of the same size decide in the same quarter to put AI to work.
The first sends every proposal to committee. Each one is assessed on its merits, from nothing, by people who have not seen one quite like it before. The eleventh proposal waits behind the tenth. Six months in, four use cases are live, the queue is longer than when it started, and a good share of the staff who were waiting have quietly started pasting work into consumer tools on their own accounts, where no committee will ever see it.
The second institution spends its first six weeks doing something that looks slower. It agrees, in advance, what kinds of action an AI system may take on its own, which it may take with someone notified, and which need a named person to say yes before they happen. It agrees what must be recorded and who can stop a system that misbehaves. Then it starts approving. A new use case is not assessed from nothing. It is placed in a tier, and the tier already has an answer.
By the end of the quarter the second institution has more running, and more control over what is running. That is not a paradox. It is how brakes work.
The mechanism
A committee that reviews every case from first principles is doing expensive work that only has to be done once. The question “what may a system in this category be trusted to do” is the same question every time. Answer it once, write it down, enforce it in software, and each subsequent decision shrinks to “which category is this.”
That is the whole argument. Safety, done properly, is not a gate a use case passes through. It is a throughput system. The boundary is agreed before the work arrives, so the work does not wait for the boundary.
The Canadian supervisor has already described it
This is not a theory about what regulators might accept. OSFI’s Guideline E-23, which takes effect on 1 May 2027, brings models “including AI/ML methods” into a single framework, and it builds that framework on exactly this mechanism.
Each model receives a risk rating. The guideline then says what that rating should drive: the “level of authority required to approve the model”, the “frequency, intensity, and scope of model review”, the “frequency, intensity, and scope of model monitoring”, and the “limits or constraints on model usage.”
Read that list again. It is a tiering system. Rate the thing, and you already know who signs, how closely it is watched and what it is not allowed to do. E-23 also asks that policies be “sufficiently flexible to accommodate evolving technologies,” which is the supervisor saying plainly that it expects institutions to adopt, not to wait.
An institution that treats E-23 as a documentation exercise will build an inventory and a filing cabinet. One that reads it properly will build rails, and will find it can move faster in 2027 than it can today.
The six rails
Here is what those rails look like once a system is in production rather than in a policy document. None of them is exotic. Each one makes the next use case faster to approve, not slower.
One. An inventory that is reconciled, not asserted. A register of what AI-enabled work is actually running, checked against what is actually running, on a stated schedule. E-23 asks for one that is “accurate, evergreen, and subject to robust controls.” Why it speeds things up: you cannot tier what you cannot see, and a reconciled inventory is also the list of patterns you have already approved. The fortieth request looks like the twelfth, and you can say yes in a day.
Two. Authority scoped to the action, not the identity. A credential tells you what a system can reach. It does not tell you what the system may do once it is there. The rail is a mandate: this agent may read these records, draft these letters, and may not send, pay or delete. Why it speeds things up: narrow mandates are easy to approve. The committee that would never sign off “give the agent access to the customer system” will sign off “let it read three fields and draft a reply for a person to send” the same afternoon.
Three. Tiers set by consequence, decided before the action. Every action a system can take is classed in advance: it may act, it may act and someone is told, or a named person must approve before it happens. The approval happens before the consequential action, never as a review of it afterwards. Detection after the fact is a finding. It is not a control. Why it speeds things up: this is the rail that removes the committee from the critical path. Most actions most systems take are low consequence and never need to be escalated. The approvals that remain are the ones that deserve a person.
Four. A record of every consequential action. Who or what made the request, under which policy, to which system, with what result, and when. Not a log that might be reconstructed later, but a record made at the moment of the action. Why it speeds things up: an institution that can produce a sample for a named month can answer its auditor in an hour instead of a quarter, and an auditor who gets that answer stops asking for everything to be slowed down. The record should also say what it does not cover. Not assessed, inconclusive and not supported are three different answers, and a record that collapses them into a pass is worse than no record at all.
Five. Evidence that someone outside the system can verify. A record produced by the same system whose behavior it describes is useful, but it is not yet evidence. It becomes evidence when a reviewer who does not have to trust the system can check it has not been altered and can see it matches what happened downstream. Why it speeds things up: this is the rail that lets second and third line, and the institution’s external assurer, stop re-performing the work. It works best when the evidence arrives in the vocabulary they already use: completeness, accuracy, authorization, occurrence, and the three that AI adds, explainability, human oversight and whether the outcome was achieved. Evidence an assurer has to translate is evidence that waits.
Six. A way to stop that fails safe. Every system in production needs a person who can halt it, a known state it falls back to, and a decision made in advance about what happens when data goes bad or a connection is lost. Failing closed must not mean failing unsafe. Why it speeds things up: a risk committee will approve almost anything it knows it can switch off. It will approve almost nothing it cannot.
The standards bodies have arrived at the same place from the security side. The OWASP Top 10 for Agentic Applications and the FINOS AI Governance Framework both now describe controls that live in the runtime, not in the binder.
We run our own company this way
I should say where this comes from, because it is not a theory for us either.
iTmethods operates with small teams directing AI agents, and the actions those agents take sit in one of three tiers: autonomous, notify, or approve. The tiers were agreed before the work, not argued case by case. When a new workflow arrives, the conversation is about which tier it belongs in, and that conversation is usually short.
We did not adopt this because we are cautious. We adopted it because it is the only way a small team moves quickly without losing track of what its own systems have done.
What the rails do not do
Four honest limits.
Rails do not make a use case worth doing. They make it safe and fast to try. Whether it was worth it is a separate question.
Rails do not let a check say more than it tested. A check that confirms an action was authorised supports exactly that. It says nothing about whether the work was accurate, complete or achieved what it was for.
Rails do not prove that the AI caused the improvement. They can establish that a process ran as intended and whether the intended outcome occurred. Attributing a gain in satisfaction or efficiency to one agent, while five other initiatives were also running, is a harder problem, and anyone who tells you their dashboard solves it is claiming more than it can show.
And rails do not replace judgment. They decide in advance which decisions need a person. They do not make those decisions easier.
The question nobody has answered yet
In the last week, two separate voices in this field, an analyst channel and an independent governance researcher, each published four questions an institution should be able to answer about its AI systems. They were close to identical: which systems are acting, with what authority, under what control, and can you reconstruct what happened. Those are rails one to four.
Neither asked the question behind rail five: who produced the evidence, and do they also own the work it describes. That is the one the market has not closed. It matters more as systems act more, because the more consequential the action, the less an institution can accept a record it has no way to check.
We have not closed it either, but we are working on it with customers, on real workloads rather than on slides. Reign Assurance is being delivered through a co-design partner process, for workloads that are in production or planned for it, as the evidence layer for rail five. It sits apart from the systems it examines, so the check is not inside the thing it is grading. It starts from the business workflow and its risks, not from whatever telemetry happens to be available. Each check states in advance the result it expects, and the record keeps not assessed, inconclusive and not supported apart, with the exceptions sent to a person for judgment.
Two boundaries are part of the design, not caveats added to it. The process is controlled: scope is agreed partner by partner, and Reign Assurance is not yet generally available. And it does not give an opinion. It hands the institution and its assurer the evidence they need to form their own. Rail five applies to us on the same terms as anyone else: where we also operate the work being examined, our evidence has to be checkable by someone who has no reason to trust us, or it is not evidence.
That is the division of labor rails make possible. The institution’s own risk, compliance and audit functions keep the judgment. Assurance providers bring the methodology and, where one is required, the opinion. The rails produce the evidence both of them use. None of the three replaces the others, and a design that tries to collapse them into one tool will be rejected by all three.
On live television last week, Palantir’s chief executive put the first principle plainly: “You’re liable for your own actions.” Liability needs evidence, and evidence needs rails. The institutions that build them will not be the careful ones that fell behind. They will be the ones that could say yes.
About Reign from iTmethods
iTmethods builds and operates Reign for regulated institutions: operated engineering platforms, governed software delivery with the customer’s team, AI traffic governance for calls sent through the gateway, and an assurance capability delivered through a co-design partner process. A reader is entitled to know where the writer’s interest lies, so here is what each part does, and its status, stated plainly.
Reign Ops. Available. Operates and manages the engineering tool estate, commercial and open source, inside the institution’s own trust boundary. Reign Ops holds a SOC 2 Type II, which does not extend to the other three products.
Reign Factory. Available, Beta Release, not generally available. Governed software delivery, from requirements through agent implementation and testing, with a named person approving before any change is merged. Our engineers work alongside the institution’s own. It is rail three, applied to how software gets built.
Reign Gateway. Available Today. For AI calls sent through it, Gateway applies identity, access, policy and spend controls, and creates a record of the request, the policy decision and the outcome. For that traffic, it is rails two and four.
Reign Assurance. Delivered through a co-design partner process, for workloads in production or planned for production. Not yet generally available, and not an audit opinion. The evidence layer for rail five, built apart from the systems it examines. We are taking on a small number of further design partners; if your institution is working on rail five, I would like to hear how.
Where we operate work that is under examination, our assessment is evidence for the reviewer, not an opinion on it. Reign prepares. People decide.
Reign, by iTmethods. Governed AI. Outcomes assured.
BIO
Paul Goldman is the Founder and CEO of iTmethods, the company behind Reign. His team runs the platform, does the work, and proves it. He writes The Trust Layer at itmethods.com.
SOURCING AND DISCLOSURE
This essay is not legal or regulatory advice. Supervisory expectations differ by jurisdiction and by institution, and any reader acting on it should take their own counsel. References to OSFI Guideline E-23 are to the published text; quoted phrases are the guideline’s own words.
iTmethods builds and operates Reign for regulated enterprises: operated engineering platforms, governed software delivery and AI traffic governance, with an assurance capability delivered through a co-design partner process. It competes in the market this essay describes. iTmethods is a member of the Linux Foundation, FINOS and the Agentic AI Foundation. Membership of a foundation is not a claim to have authored its standards.
The two institutions in the opening are illustrative, not clients. The analyst channel and the researcher referred to are characterized rather than quoted. The quotation attributed to Palantir’s chief executive is from a televised interview and is used for the principle it states, not as an endorsement.
SOURCES
OSFI, Guideline E-23 Model Risk Management (2027), effective 1 May 2027. Sections A.4, C.1, C.3, D.1: https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/guideline-e-23-model-risk-management-2027
- OWASP GenAI Security Project, Top 10 for Agentic Applications, 9 December 2025: https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/
- FINOS, AI Governance Framework v2.0, 12 November 2025: https://www.finos.org/blog/finos-ai-governance-framework-v2.0-addressing-agentic-ai-risks-in-a-rapidly-evolving-landscape
- SiliconANGLE / theCUBE Research, AI governance moves from observability to provable control, 19 September 2026: https://siliconangle.com/2026/09/19/ai-governance-provable-control-agentic-ai-thecube-appdevangle/
- Patrick Upmann, The AI Governance Gap Brief, Issue 35, 22 September 2026: https://www.linkedin.com/newsletters/the-ai-governance-gap-brief-7075439091571388416/
- CNBC, Palantir’s Karp on AI liability, 17 September 2026: https://www.cnbc.com/2026/09/17/ai-safety-palantir-karp.html
RELATED READING
OSFI E-23 Model Risk Management: What Changes for AI: itmethods.com/reign/osfi-e23
- The Answer Is an Estimate. Somebody Has to Check It. (9 September): itmethods.com/insights/answer-is-an-estimate
- The Filing Is Not the Work (2 September): itmethods.com/insights/the-filing-is-not-the-work
The artifact behind the claim. The operator thesis.