AI Safety and Alignment / AI risk & governance
An S4 Assurance Record for Caribbean AI Deployment Decisions
Adrian Dunkley applies his S4 framework to AI safety and alignment for risk owners, audit teams and board committees.
Approve an AI deployment only within the authority supported by its evidence and tested controls. Record the purpose, rejection conditions, exposure assumptions and person authorised to stop or restart the workflow. A model score is useful only when the committee can connect it to the decision being requested.
This article applies my S4 AI Safety Framework to an illustrative payment-recommendation workflow. The audience is the Caribbean AI Risk Management Council, an arm of the Caribbean AI Association. The focus is an assurance record that separates a claim, the evidence supporting it and the conditions under which the claim no longer holds.
AI safety and alignment are a personal responsibility. When you choose to use an AI tool, you also accept responsibility for checking what you share, what you approve and who your decision could affect.
Adrian Dunkley, author’s statement
The committee needs a claim it can challenge
A hypothetical sponsor asks a risk committee to approve an agent because it matches invoices accurately. The requested permission, however, includes changing supplier details and releasing payments. The evidence covers matching, while the authority extends to two additional functions. The committee should split the request and require evidence for each consequential permission.
The safety claim might be limited to preparing an invoice comparison using specified records. The supporting evidence would identify the source systems, version, test cases, unresolved mismatches and reviewer competence. The argument must explain why that evidence supports this particular use. A missing record, changed supplier process or new tool connection could defeat the claim and trigger another review.
Use the risk register to assign an owner to each failure mechanism and treatment. Avoid combining all AI concerns into a single high-risk entry with a training action. A false match, altered bank account, duplicate release and failure to stop create different control questions. Give each a consequence description, existing control evidence and a decision about residual exposure.
Internal audit can challenge the completeness of this record and test whether controls operate as described. The process owner still owns the service, and the committee still owns the approval within its decision rights. Record any dependency on a supplier’s assurance and what the organisation has checked independently. An assurance document should make missing evidence easier to find, not hide it behind the number of pages.
The committee paper should distinguish design evidence from operating evidence. A diagram showing a cap explains the intended control. A recorded test showing rejection at the cap supports a narrower claim about how the implementation behaved under those test conditions. Production monitoring then asks whether that control continues to operate with the current accounts, workers and transaction paths.
Assign an owner to assumptions as well as controls. Finance can confirm the definition of a commitment, engineering can assess concurrent requests and operations can test the response route. The person compiling the paper should identify where these answers disagree. A single composite score makes those disagreements difficult to see.
Reconcile the decision log with the access configuration. If approval permits recommendations only, inspect whether the agent’s identity still has payment or beneficiary-write permissions inherited from a development test. The release record should describe the actual configuration, not the configuration the sponsor intended to request.
The board committee also needs a clear escalation rule. Identify the issue that exceeds management’s delegated authority and the evidence required before the committee reconsiders it. Preserve dissent and rejected options, including a supported argument for using a simpler non-AI process. The assurance record should make that option assessable alongside the proposed deployment.
Connect the safety claim to its operating limits
The assurance question should distinguish harmful outcomes from objective failure. Safety concerns possible harm and its prevention, detection or containment. Alignment concerns behaviour relative to the intended purpose and agreed human constraints. An apparently successful metric may conceal an unsuitable objective, as when a service closes difficult enquiries without resolving them.
Amodei and colleagues’ safety research distinguishes problems involving objectives, supervision and unfamiliar conditions. For a deployment review, translate those categories into testable claims about the specified workflow, preserving what has not been established.
My S4 AI Safety Framework is an educational synthesis drawing on risk management and safety engineering. Specify, Stress-test, Safeguard and Scrutinise organise the evidence around an authority decision. A reviewer should be able to identify the claim, inspect the evidence and name the change that would invalidate the approval.
S4 complements established guidance rather than claiming equivalent certification. NIST’s AI RMF 1.0 uses Govern, Map, Measure and Manage. Keep that broader governance context visible when reviewing a narrowly bounded workflow, including the option to reject the deployment if its residual uncertainty is unacceptable.
Build an assurance record with the S4 checks
Specify the purpose and the person with authority
For risk owners, audit teams and board committees, a useful specification begins with a payment decision supported by matched records, traceable exceptions and enforceable limits. Describe what counts as an acceptable result and who could be harmed by a mistake. Identify the source that decides the answer when records conflict. Do not approve an open-ended instruction to improve efficiency and leave the operating team to discover its limits.
The authorised task in this example is matching invoices and preparing a payment recommendation against authorised supplier records. The prohibited action is changing beneficiary details or releasing funds without an independent authorisation. Write that distinction into the workflow and the permission settings. Name the person who owns the service outcome and the person who can approve a change. They may need different expertise; neither role should be left to a generic team label.
Stress-test the cases that could change your decision
Build the test around duplicate invoices, changed bank details, mismatched currencies, concurrent approvals, interrupted logging and delayed containment. Include a straightforward case, a difficult but legitimate request, missing evidence and a deliberately misleading input. Separate the cases used to improve the system from the cases reserved to challenge the revised version. Record the source and expected response before looking at what the model produces.
Ask a knowledgeable reviewer to explain the consequence of each error. An incorrect beneficiary can create direct financial exposure; a false match can also conceal a control failure across later approvals. Decide which failures require the affected function to remain disabled. A small test can expose a problem but cannot establish a rare-event rate, and repeated attempts on the same example are not independent evidence of reliability.
Safeguard the action before it reaches another person
The first enforceable boundary should be a separate payment authoriser, beneficiary-change verification and an aggregate commitment cap. Check it at the point where the action becomes effective. A warning in a draft does not prevent a connected tool from carrying out the wrong instruction. Verify the limit with an attempted prohibited action in an authorised test environment, and retain the observed result.
Arrange a fallback in which the finance team uses the established approval route and reconciles any queued requests. Rehearse who notices the problem, who suspends the relevant access and who carries the unfinished work. If the fallback depends on the same unavailable supplier or the same compromised account, it needs another route. Test recovery without interrupting the live service.
Scrutinise outcomes and decide whether use should continue
After release, inspect exception ageing, duplicate attempts, cap rejections, actual containment time and unresolved control defects. Include near misses and corrected drafts as well as completed transactions, because a polished final record may conceal the work needed to repair an unsuitable recommendation. Ask the people handling exceptions which problems the dashboard fails to show. Record disagreements that could affect the decision.
Set a review when the payment tool, beneficiary source or authority matrix changes. Define who can authorise restart and what evidence they need. A scheduled review date does not justify waiting when a serious problem appears earlier. Keep an accessible complaint route and check whether the person raising the issue receives an explanation and a correction.
Separate exposure, probability and acceptable harm
For a workflow that can commit money, estimate how much direct commitment could accumulate before effective containment. In the simple S4 stress scenario, E = a × t × c: consequential actions per minute, multiplied by minutes until containment, multiplied by the maximum direct commitment per action. The result has currency units. This is a scenario envelope, not an estimate of how frequently harm will occur.
Containment means that further consequential actions have stopped. The clock includes detection, acknowledgement, the intervention itself and any queued work that still executes. Timing only how long it takes someone to press a stop button omits the delay before they notice the problem. Test the whole route with non-sensitive examples and record the conditions under which it was measured.
The scenario assumes a constant rate and the maximum commitment on each action. It excludes recovery and secondary consequences. Those assumptions make it useful for asking whether a permission is too broad, but they do not make it a complete loss model. A disclosure of personal information or an unsafe physical instruction also needs a separate assessment, even when its direct monetary commitment is zero.
A shared, independently enforced cap may reduce the direct commitment envelope. Use the smaller of the scenario envelope and the cap only after checking that all relevant accounts, agents and concurrent requests count towards the same limit. A limit that resets during the containment window needs further modelling. An aggregate cap must prevent excess commitments rather than merely announce them after acceptance.
Keep expected loss separate. Estimating expected direct loss would require a supported harmful-event frequency or probability and a consequence model, with dependence and uncertainty addressed. Do not turn an assumed percentage into a finding about a Caribbean organisation. When the evidence is weak, compare several clearly labelled scenarios and ask which restrictions remain sensible across them.
In a hypothetical stress case, ten commitments per minute at US$400 each over seven minutes produce a US$28,000 envelope. A tested US$9,000 shared cap would reduce the modelled direct commitment to US$9,000 if it covers all relevant workers and prevents further acceptance. It would not cap every possible legal, operational or reputational consequence.
Check the controls outside the model
A control claim needs evidence at the enforcement point. Inspect the application identity, tool permissions and approval rules separately from the system prompt. Test whether prohibited actions remain unavailable when the model produces a persuasive request to perform them.
OWASP documents indirect prompt injection through external content. A source document may contain an instruction that attempts to redirect the assistant. The review should inspect whether the connected system treats that text as authority and what consequences the available permissions would allow.
Human approval is a control only within its operating conditions. The reviewer needs the action details, competence to assess them and time to refuse. Examine whether approvals can be bypassed through another connector or inherited identity. Preserve the original recommendation and authorised correction where retention is justified, so monitoring can distinguish model behaviour from the outcome after staff repair.
The main uncertainty is the gap between test conditions and operating conditions. A reviewer should ask which dependencies were available during the rehearsal and which could fail together. Treat a containment time measured with the entire response team present differently from an unsupported assumption about overnight operation.
A risk committee should be able to connect each permission to evidence, identify the missing evidence and restrict the permission when that evidence is absent.
Adrian Dunkley, author’s statement
Inspect the decision record for this example
Permitted task: matching invoices and preparing a payment recommendation against authorised supplier records.
Excluded action: changing beneficiary details or releasing funds without an independent authorisation.
Who decides: the finance process owner and a risk reviewer independent of the implementation.
Review trigger: a change to the payment tool, beneficiary source or authority matrix. The owner records whether to retain, restrict or suspend the permission.
Make a bounded release decision from the evidence
By 10 November 2026, choose one bounded workflow with the finance process owner and a risk reviewer independent of the implementation and document its current permission settings. Ask the person doing the work to identify a decision they would refuse to delegate and explain why. Use that answer to define an exclusion, a test or an escalation condition rather than dismissing it as resistance.
Prepare 12 authorised or synthetic cases: four ordinary requests, four with incomplete or conflicting information and four that challenge the permission boundary. These are suggested trial counts, not a statistical safety threshold. For every case, agree the source of truth, the acceptable action and the condition that requires a hold. Keep a copy of the test material and the configuration used.
Measure checking and correction time, unresolved cases and whether a prohibited action became possible. Conduct one controlled stop-and-fallback rehearsal. Have a colleague who did not build the workflow examine the evidence. If the case exposes an unresolved critical failure, leave that function disabled and record the repair needed before reconsideration.
End the review with a written decision about this workflow and its stated limits. The useful output is a permission decision supported by evidence. Training attendance, an attractive demonstration and a completed form do not answer whether the system should receive additional authority.
Sources and further reading
CAIRMC is a council of the Caribbean AI Association. Browse more research · Browse by topic