We publish the framing. We retain the machinery.
Notes that make one argument at a time, and three working artifacts, open and free to use. If they are useful, take them into your own programme — you do not need to engage us to benefit from them. That is the point of publishing them.
Notes
Short, sourced essays — one argument each, one per practice area to start
Regulatory Crosswalk
E-23 mapped to NIST AI RMF, ISO/IEC 42001, SR 26-2 and the EU AI Act
Reference Architecture
Governed private LLM with evidence emission points on the request path
Inventory Schema
The Appendix 1 minimum standard, as a working schema
Featured guide · Identity Orchestration & Agent Access
Identity Orchestration, Plainly Explained
What it is, why it matters now, six places it pays off, how it works for people and AI agents, and how to start without a big-bang programme.
Read the guide · 20 minNotes
One argument at a time.
Short, sourced essays on what the frameworks leave out — one for each practice area to start.
AI Audit & Compliance
Governance is not the fifth layer
NVIDIA and Red Hat describe the AI factory as a five-layer cake, with governance at the top. In a regulated or sovereign environment, that is precisely where AI programmes go to die.
Read · 9 minIdentity Orchestration & Agent Access
When the compromised thing was trusted, the logs look clean
Six national cyber agencies, Canada’s among them, advise keeping AI agents to low-risk work. Banking roadmaps point the other way. Nobody has had that argument out loud yet.
Read · 4 minAI Security
Nobody asks for the drill record
An empty AI incident log looks the same whether the month was quiet or nobody wanted to write the failure up. The evidence that tells them apart is somewhere else.
Read · 4 minAsset 01 — Regulatory Crosswalk
Twelve E-23 principles, mapped to the frameworks you already report against.
Guideline E-23 takes effect 1 May 2027 — roughly 7 months away. Most institutions already hold NIST AI RMF or ISO/IEC 42001 artifacts. The question is what carries over and what does not.
Enterprise-wide model risk management
Model risk is well understood and managed across the enterprise.
Risk-based approach
Model risk is managed using a risk-based approach.
Model lifecycle management
Model governance covers the entire model lifecycle.
Provenance
The three outcomes, twelve principles and principle statements above are taken from OSFI Guideline E-23 – Model Risk Management (2027), published 11 September 2025, effective 1 May 2027.
SR 26-2 references are to the US interagency Supervisory Guidance on Model Risk Management issued 17 April 2026, which supersedes SR 11-7 (2011) and SR 21-8. Section numerals are that document’s own.
The cross-framework mappings are Aegis interpretation, not regulator-issued equivalences. No standards body publishes an official concordance between E-23, NIST AI RMF, ISO/IEC 42001, SR 26-2 and the EU AI Act. We publish ours so it can be challenged; your second line should satisfy itself independently before relying on it.
What SR 26-2 does not cover
“Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance. Nonetheless, a banking organization’s risk management and governance practices should guide the determination of appropriate governance and controls for any tools, processes, or systems not covered in this document. However, the principles described in this guidance apply to traditional statistical and quantitative models and non-generative, non-agentic AI models.”
SR 26-2, Supervisory Guidance on Model Risk Management, footnote 3
The agencies have said they intend to issue a request for information covering model risk management generally and banks’ use of AI, including generative and agentic AI. Until that produces guidance, the governance determination for these systems rests with the institution.
The practical consequence: a generative or agentic system sits outside the guidance your model risk function works to, while remaining squarely inside your own governance obligation. Whichever way an institution resolves that, the resolution needs to be a documented determination rather than an omission.
Read the guidance — footnote 3 is on page 3Asset 02 — Reference Architecture
Governed private LLM, with the evidence on the path.
Most reference architectures put governance beside the pipeline as a reporting layer. This one puts evidence emission points E1–E6 directly on the request path, so audit evidence is a by-product of running the system rather than something assembled before an exam.
E2 — Policy & Entitlement
This is where the traceability spine attaches. The control identifier and the model risk tier are bound to the request before anything is retrieved or inferred.
Evidence emitted: Control ID + risk tier stamped on the request
Asset 03 — AI System Inventory Schema
The seventeen fields E-23 requires you to track.
Appendix 1 of the guideline sets a minimum information tracking standard: six fields for every identified model, eleven more for any model carrying non-negligible inherent risk. This is the inventory a supervisor will ask to see.
model_idcorePrimary key across the estatemodel_namecorePlus description of key features and usemodel_risk_ratingcoreFrom the tiering rubric (Principle 2.2)model_ownercoreAccountable unit or individualmodel_developercoreUnit or individualmodel_origincoreInternally developed or vendormodel_versionextendedBound to a deployed artifactdeployment_dateextendedDate moved into productionmodel_reviewerextendedIndependent of the developermodel_approverextendedAuthority that approved usemodel_dependenciesextendedUpstream models, libraries, servicesdata_sourcesextendedWith description — ties to lineageapproved_usesextendedScope boundary for the modelmodel_limitationsextendedIncluding exceptions and conditionslast_review_dateextendedMost recent independent reviewmonitoring_statusextendedWith exceptions as applicablenext_review_dateextendedDrives the review calendarThe field list is authoritative — it is Appendix 1 of Guideline E-23. The snake_case naming and the core/extended split are our schema convention. The machine-readable version, with types, enumerations and validation rules, is released to clients under engagement.
Why we give this away
The crosswalk is not the moat.
A populated inventory, a working capacity model, and a traceability spine that actually binds a control identifier to a compute partition — those take an engagement. The framing does not, so we publish it.
Book a qualification call