The trigger register template and the Thornbury example.
Chapter 10 of OSFI E-23 for AI Systems sets out every field of this template in its text. The file is a convenience; the method is in the book. Every field is below, before anything is asked of you.
Every field, before the form.
Where a field cites E-23, the guideline states it. Where it says the discipline’s, the handbook’s method chose it, inside what E-23 permits. Open any part to see its fields.
Part A. The register
A trigger is a threshold, an owner and a consequence, all three fixed before the system is deployed. Remove any one and what remains is a metric (Chapter 10). Alert on the conditions the approval was conditioned on; list every condition the approval assumed. Write each consequence as a review, a rollback or a loop-back.
| # | Approval condition the row watches | Trigger | Threshold | Owner (one name) | Consequence: a review, a rollback or a loop-back |
|---|---|---|---|---|---|
| T1 | |||||
| T2 | |||||
| T3 | |||||
| T4 | |||||
| T5 | External finding: admits any outside finding as a signal | ||||
| T6 | Reconstruction gap: fires when a decision cannot be reconstructed |
Add rows as needed. The two rows T5 and T6 are required by Chapter 10's exercise.
Rows Chapter 13 adds, for a system behind a hosted model. Each is, on the book's reading, the guideline's external dependency watched call by call.
| # | Trigger | Threshold | Owner (one name) | Consequence: a review, a rollback or a loop-back |
|---|---|---|---|---|
| T7 | The serving model differs from the pinned one, or the response names none, the absence itself the signal | |||
| T8 | A pinned snapshot nears its published deprecation date | |||
| T9 | A scheduled replay of the fixed evaluation set scores outside its baseline band, compared by score | |||
| T10 | A gap opens in the retrieval ledger | |||
| T11 | The completeness reconciliation of the evidence store against the gateway's request log finds a gap |
Rules for the register (Chapter 10, unless marked).
| # | Rule | Basis |
|---|---|---|
| R1 | Test every row: what fires it, whose name stands beside it, and what happens next | The discipline's |
| R2 | Which incidents reopen validation is defined in advance in the register, and "MUST NOT be decided case by case after an incident by the people whose work would be reopened" | The discipline's (the deposited specification) |
| R3 | What does not touch the approval does not belong on the register. Latency and uptime are the platform's health, not the model's fitness | The discipline's |
| R4 | The evidence store's outage belongs on the platform's availability alerting with its contingency plan, not on this register (Chapter 13) | The discipline's; E-23: contingency plans for model unavailability |
| R5 | Owners: each trigger is owned by whoever watches its signal in the first line, who raises it and may not settle it; the gate decisions sit with the head of the governance office, who holds G5; the validation function receives every loop-back and orders no rollback of a system it reviews (Chapters 5, 10) | The discipline's |
| R6 | The office arms its highest-rated systems' registers first, because the inherent risk rating drives the frequency, intensity and scope of monitoring | E-23; the order is the discipline's |
| R7 | A threshold figure is a choice, and it is the institution's; the register requires someone to make it and sign it | The discipline's |
Part B. The signal register
The signal register is the trigger register's downstream: every trigger that fires, and every outside finding, enters it as a signal, confirmed or not. The discipline's instrument for the moment something has gone wrong is the AI Incident Response Protocol (AIRP)™, which runs in six stages: signal, classify, contain, escalate, reconstruct and close. It keeps one record per admitted signal, every non-incident included, because "A register of confirmed incidents is shorter, cleaner and easier to present. It is also a numerator with no denominator." (Chapter 10)
| # | Signal: the trigger row that fired, or the outside finding | Date | Admitted (yes / no) | Confirmed as an incident (yes / no) | If closed without becoming an incident: the reason | If closed: the name of the person who closed it |
|---|---|---|---|---|---|---|
| G1 | ||||||
| G2 |
The test (Chapter 10). Open the signal register for last month and look past the confirmed incidents for the signals closed without becoming one: each breach, alert or outside finding that someone set aside, with the reason and the name of the person who closed it. A register holding only incidents, or nothing, cannot show how many signals the institution saw.
Part C. The retirement record, written in advance
Write the retirement record in advance, blank except for the fields, so that the day the system leaves, it leaves by a decision (Chapter 10). Retirement is one of G5's three exits: a recorded decision by the accountable person at G3 or a successor, with every gate's evidence records retained as long as the institution's obligations require.
| # | Field | Basis | Entry |
|---|---|---|---|
| X1 | Who decided | The discipline's (Chapter 10) | |
| X2 | On what evidence | The discipline's | |
| X3 | On what date | The discipline's | |
| X4 | What replaces the system, or that nothing does | The discipline's | |
| X5 | What is retained, and for how long | The discipline's; E-23: "Retaining the retired model and documentation for a set period as a benchmark or fallback" | |
| X6 | What downstream depends on the retired output | The discipline's; E-23: "Monitoring downstream effects to ensure no residual impacts" | |
| X7 | For a vendor model, what the contract's exit terms actually delivered when exercised | The discipline's; E-23: "Determining what additional actions are needed for decommissions of any third-party models" | |
| X8 | Relevant stakeholders alerted of the planned decommission | E-23: "Alerting all relevant stakeholders of the planned decommission" |
Decommissioned models stay on the inventory "for a period the institution considers reasonable". A system switched off without this record has not been decommissioned. It has been abandoned (Chapter 10).
The claim, the test, the artifact (Chapter 10)
The claim. Three things fixed before deployment make a trigger: a threshold, an owner and a consequence. Take any one away and a metric remains.
The test. Test one row of your register for all three, then check the signal register for signals closed without becoming incidents.
The artifact. A trigger register with every trigger armed and owned.
Worked example: Thornbury, Sextant
Thornbury is fictional. The institutions, systems, people and incidents in the book are fictional composites constructed to teach; they are not drawn from any real institution, incident or client engagement. Every value below is a fact the book states about Thornbury. The register itself is the discipline's construction, not a fact about the case; the case supplies the failure it would have caught (Chapter 10).
What Thornbury had
From March 2024 a monthly report, a stability index on six inputs and the straight-through rate, each against a threshold, was the whole of Thornbury's G5: nothing armed, no one named. The report went to a shared mailbox that no one owned. Four months running, December 2025 to March 2026, each report computed its numbers, showed the breach and wrote the word "monitor" beside it (Chapter 10). Sextant's score was validated between January and March 2024 on 2022 applicants (Chapter 3).
The register Sextant should have carried into G5 in March 2024
Built from the conditions Sextant's own validation recorded: the 2022 population the score was validated on and the disclosure patterns that population produced. Owners stand where Chapter 5 put them: the signals with the first line, the Chief Underwriter as model owner and Aisha Farouk as developer; the gate decisions with the head of the governance office, who holds G5; and Tomasz Wierzbicki's validation function as the recipient of every loop-back, ordering no rollback of a system it reviews (Chapter 10).
| Trigger | Threshold | Owner | Consequence |
|---|---|---|---|
| Input stability breach | Stability index over threshold on any input for two consecutive months | Aisha Farouk, developer | Targeted review of the breached inputs against the validation population, opened within the month |
| Outcome drift | Straight-through rate within any one sales channel more than five points from that channel's baseline, read beside the input series | Chief Underwriter, model owner | Side-by-side outcome review; loop-back to G2 if the gap persists a second month |
| New data source | Any new sales channel or applicant population entering the model | Chief Underwriter, model owner | Loop-back to G2 before straight-through issue is enabled for the new population |
| Altered data definition | Any change to a laboratory partner's reference ranges or to an input's definition | Aisha Farouk, developer | Recalibration review of the affected inputs; the head of the governance office suspends straight-through for those inputs pending review |
| Ground-truth sample | A random sample of accelerated issues sent each month to full underwriting; the share that would have been rated or declined, past a signed tolerance above the validation sample's 3 percent | Chief Underwriter, model owner | Loop-back to G2; straight-through issue suspended for any channel past the tolerance |
| External dependency | Any version change in the hosted model behind the assistant | The assistant's platform owner, first line | Sampled reconstruction of rationales on the new version before it serves underwriters |
| Reconstruction gap | Any assistant output whose retrieved passages cannot be produced on request | Head of the governance office | Rollback of the assistant to G4 until passage logging is live |
| External finding | Any reinsurer or audit variance from the validation sample | Head of the governance office | Signal admitted to the register; classification within the week |
| Scheduled review | At the interval the risk rating sets | Tomasz Wierzbicki, validator | Review on the risk-based schedule, with the rating re-assessed |
The approval condition each row watches, in the template's first column, is the conditions above: the 2022 validation population and its disclosure patterns. Chapter 10 also names the reasons for three rows: a changed reference range is an altered data definition, a new channel is a new data source, and a version change is an external dependency. The signed tolerance in the ground-truth row and the five-point figure in the outcome-drift row are choices that are the institution's; the five-point figure is the one Chapter 10 uses, and the tolerance is [not stated in the book].
The winter of 2025, read against the register
| What happened (Chapter 10) | Row that fires | What follows on the register |
|---|---|---|
| September 2025: the direct channel opened | New data source | G2 reopens before the younger applicants reach straight-through issue |
| The laboratory changed two reference ranges | Altered data definition | The two inputs are suspended pending recalibration |
| December 2025: the stability index breached | Input stability breach, on the second month, in January | Aisha Farouk owns a review that is open before the reinsurer's audit is scheduled |
| October 2025 to March 2026: the straight-through rate rose from 61 to 74 percent | Outcome drift, stratified by channel, because a pooled rate moves with the channel mix whether or not the score changed | The walk-through states only that the row is stratified by channel; the row's own consequence is a side-by-side outcome review, and loop-back to G2 if the gap persists a second month |
| The reinsurer found 11 percent against 3 | Ground-truth sample, run monthly by Thornbury itself | The quarter the reinsurer audited in April is read while it runs, and the loop-back is a decision on the register rather than a suspension forced by an outside party in May |
The signal register Thornbury never kept
| Signal | Date | Admitted | Confirmed as an incident | Reason it was closed | Closed by |
|---|---|---|---|---|---|
| Stability index breach, marked "monitor" | December 2025 | No | No | The word "monitor", where a reason belonged | No one |
| Stability index breach, marked "monitor" | January 2026 | No | No | The word "monitor", where a reason belonged | No one |
| Stability index breach, marked "monitor" | February 2026 | No | No | The word "monitor", where a reason belonged | No one |
| Stability index breach, marked "monitor" | March 2026 | No | No | The word "monitor", where a reason belonged | No one |
| The reinsurer's sample audit, an outside finding | 22 April 2026 | Admitted, it classifies as a breach of the conditions the approval assumed | [not stated in the book] | Not closed: contained, reconstructed and closed through the stages below | [not stated in the book] |
Thornbury's four "monitor" breaches are four signals never admitted, each set aside by a word where a reason belonged, and by no one (Chapter 10).
Thornbury, run through AIRP's six stages
| Stage | Thornbury (Chapter 10) |
|---|---|
| Signal | From outside: the reinsurer's sample audit of 22 April 2026 |
| Classify | A breach of the conditions the approval assumed |
| Contain | 6 May 2026: straight-through issue suspended for the direct channel, a rollback of that path to G4, which the protocol records as a gate decision with a named person and a stated reason |
| Escalate | [not stated in the book] |
| Reconstruct | Divides in two: the score reproducible from its logged feature vectors, the assistant's rationales not, so the report is partial and names the missing artifact |
| Close | Reopens G2 for the score against the direct channel's population, and derives one test, the register's ground-truth sample |
Graham Pelletier, Thornbury's Director of Internal Audit, opened an audit on 20 May 2026 of why four breaches produced no action, and the register Thornbury never kept is the answer (Chapter 10).
The retirement record
Thornbury's retirement record is [not stated in the book].
nabeelkhan.com/e-23/trigger-register. Questions: nabeelkhan.com/contact.
The Excel file has started
Excel file again Now the Word file
Next in the book: The gap plan template (Chapter 11). Or take the E-23 check to see which template matters most for you.
Where this sits.
The Office of the Superintendent of Financial Institutions (OSFI) does not endorse, approve or recommend this book, its author or any framework in it. Conformance with any framework named here is self-declared, by the institution, on its own record. Coldbrook, Thornbury and Pellbrook are fictional institutions, invented for the book.
Who receives your monitoring breach report, by name?
Ask your AI assistant instead.
This page is a snapshot, accurate at the release it cites. The same corpus is callable, publicly and without a key, so an assistant can query it live and return an answer carrying the source it came from. For this page that is get_framework, which returns the Defensible AI Framework Registry entry for any framework these templates are built on (the Five-Gate Deployment Model, the AVRF, PEVG, PARA), with its version and the concept DOI of its deposited specification. It does not yet hold the E-23 handbook or the guideline itself; for those, this page and the book are the source.
claude mcp add --transport http concylium https://mcp.nabeelkhan.com/api/mcpClaude Desktop, ChatGPT, Cursor, VS Code and Gemini CLI take the endpoint on its own: https://mcp.nabeelkhan.com/api/mcp. No key, no account, nothing to sign. Setup for every client.
“Using Concylium, get the Five-Gate Deployment Model and the AVRF from the framework registry, with their versions and DOIs, and tell me which gate a vendor model decision belongs to.”
A framework quoted from memory drifts. One returned from its registry, with the DOI of the deposited specification, does not.