Who signs off when the model proposes

Rules detect, a model proposes with a stated confidence, a named person approves, and every event lands in a hash-chained ledger. Each part has one job, and the ledger's protection has an edge worth knowing.

Willy Tai · Smart Cities · AI · ESG · October 2026

At 09:02 a chilled-water rule fires on chiller CH-2. Forty seconds later a diagnostic model proposes a cause, fouled condenser tubes, with a confidence of 0.71. At 09:31 the duty engineer approves an inspection and a work order goes out. Eleven days later the cleaning has found little, and someone asks three fair questions: who decided, on what evidence, and can anyone show that the record of the decision has not been tidied up since?

In the estates I have worked on, the first question is usually answerable and the second can be rebuilt from emails and chat messages with some effort. The third rarely is. The pattern I build into the governed-AI demos on this site is meant to make all three answerable from records the system writes as it runs. Rules detect. A model proposes and states how confident it is. A named person approves anything consequential. Every event is written to an append-only ledger in which each entry carries the hash of the one before it. The explainer below follows one proposal through that pattern and then tampers with the ledger on purpose.

Four jobs, kept apart

Rules detect. A threshold on chilled-water supply temperature is ordinary engineering: someone set it at commissioning, anyone can read it, and it either fired or it did not. The MAS guidelines on AI risk management, issued on 7 October 2026, define AI in a way that leaves out tools running only on fixed logic [1], which matches the split. My Alarm Referee demo shows how far deterministic passes go before any model is needed: a synthetic week of 1,157 building alarms comes down to 29 that deserve a person, and every suppression points to the rule that made it.

The model proposes. It adds what a single threshold cannot, a likely cause read across several signals, and it hands that over as a proposal with its confidence and the trend it relied on. Raising the work order stays with a person.

A named person decides. MAS expects human oversight in proportion to the risk of the use case, with clear escalation roles, people who have the authority to intervene, outputs escalated for review when set conditions are met, and logged oversight decisions that are reviewed, near misses included [1]. IMDA's framework for agentic AI, updated to version 1.5 in May 2026, lists four triggers for a human approval checkpoint: high-stakes actions, irreversible actions, outlier behaviour and thresholds the user has set [2].

The ledger records, and it records all three of the others, including the proposals nobody acted on.

Keeping the four apart is what lets a reviewer test each one alone. A reviewer can re-run the rule, compare the proposal with what was later found and trace the approval to a person and a reason. With the four blended into one "AI decision", none of these tests is possible.

What the confidence number is for

In this pattern the confidence routes work and never authorises it. The reason is calibration: a model's confidence is only as good as the match between what it states and how often it is right. Guo and colleagues showed in 2017 that modern neural networks are often poorly calibrated, so a stated 0.9 need not mean right nine times in ten [7]. A threshold therefore has to be tested on labelled cases before anyone relies on it, and the test has to be fixed before the results are seen.

That is the job of my Go-Live Gate demo. Five acceptance criteria are hashed before any result appears, the confidence threshold is chosen against a visible trade-off between accuracy and coverage, a named reviewer signs the operating point, and a week-six drift re-run suspends the approval when two criteria fail. In the fictional chiller scenario, 0.71 sits under a 0.75 line agreed at go-live, so the proposal reaches the engineer with its evidence attached. Above the line it would still reach a person, because inspecting a chiller means taking plant out of service.

IMDA recommends that approval requests carry useful context such as the associated risk or a confidence score [2], and a 2012 systematic review of automation bias found that attaching updated confidence levels to a system's output was among the measures that reduced it [6]. If the threshold decides which proposals a person sees, the threshold itself needs a named sign-off.

What a signature has to carry

A name on an approval is a starting point. Parasuraman and Manzey's review found that automation bias affects experts as well as novices and is not prevented by training or instructions alone [5]. So the approval screen shows the exact action and the evidence behind it, rejecting or asking for more takes no more effort than approving, and the approver writes a reason in their own words.

Then someone has to look at the approvals as a population. IMDA suggests tracking the human override rate, since a very low rate may mean the checkpoint has become a rubber stamp, and watching reviewer response times for the same reason [2]. The EU AI Act asks that people overseeing a high-risk system stay aware of the pull to over-rely on its output and remain able to disregard, override or reverse it [3]. For high-risk uses listed in its Annex III, the 2026 Digital Omnibus means those duties will apply from 2 December 2027 [4], and MAS expects financial institutions to have its life-cycle controls, human oversight among them, in place by 7 October 2028 [1].

Why each entry carries the last one's hash

Haber and Stornetta proposed in 1991 that each time-stamp certificate include a hash of the previous certificate's linking information, so a record could not be back-dated without breaking the chain [8]. A ledger built this way computes a SHA-256 digest [9] over each entry together with the previous entry's digest. Change one character in entry two and its digest changes completely. Entry three still holds the old value, so a check that walks the chain fails at that exact link, and every entry after it has to be treated as suspect until someone reviews it.

Regulators are converging on the duty to keep such records, though none of them prescribes a hash chain. Once its high-risk obligations apply, the EU AI Act requires high-risk systems to log events automatically and providers and deployers to keep those logs for at least six months [3]. MAS asks for clear records of monitoring, issues and remediation, controlled and logged access to AI systems and their configuration, and for generative or agentic systems it suggests logging prompts, responses and model versions [1].

The chain has limits, and they belong in the design review. Someone with write access to the whole ledger can rewrite an entry and recompute every hash after it, leaving a chain that checks out. A chain held by one party is tamper-evident only to someone who kept an earlier copy of its latest hash. Crosby and Wallach made this point in 2009 and argued for outside auditors holding earlier commitments [10]; Certificate Transparency applies the same idea to public logs at internet scale [11]. The remedy is to copy the latest hash to a store the ledger's owner cannot edit, or have a third party time-stamp it [12]. The demos on this site do neither: their ledgers live in the page, which is enough to show a chain breaking and not enough for production. Two further limits remain. The chain shows a record has not changed since it was written, which says nothing about whether it was true when written. And it cannot say who made an edit. Access logs answer that.

This is objectives three and four of the control framework I use for agentic AI, bounded autonomy and auditability, worked through one decision.

Five questions for any approval screen

1. If the approver clicked reject, where would that decision and its reason be recorded, and who reads it?
2. Was the confidence threshold fixed and tested before the results were known, and who signed it?
3. What share of proposals did people override last quarter, and has anyone looked at the ones they approved in under ten seconds?
4. Where does a copy of the ledger's latest hash live that the ledger's owner cannot change?
5. Could a reviewer rebuild one decision, from the rule that fired to the work order, using only records the system wrote itself?

Sources

1. Monetary Authority of Singapore, Guidelines on Artificial Intelligence Risk Management, paras 1.3, 1.8, 5.9 and 5.23(d). www.mas.gov.sg (7 Oct 2026; effective 7 Oct 2027, life-cycle controls by 7 Oct 2028)
2. Infocomm Media Development Authority, Model AI Governance Framework for Agentic AI, version 1.5, section 2.2.2. www.imda.gov.sg (20 May 2026, updated 5 Jun 2026)
3. Regulation (EU) 2024/1689 (AI Act), Articles 12(1), 14(4)(b) and (d), 19(1) and 26(6). eur-lex.europa.eu (13 Jun 2024)
4. Regulation (EU) 2026/1744 (Digital Omnibus on AI), amended Article 113 of the AI Act. eur-lex.europa.eu (8 Jul 2026; in force 27 Jul 2026)
5. Parasuraman, R. and Manzey, D.H., Complacency and bias in human use of automation: an attentional integration, Human Factors 52(3), 381 to 410. doi.org/10.1177/0018720810376055 (2010)
6. Goddard, K., Roudsari, A. and Wyatt, J.C., Automation bias: a systematic review of frequency, effect mediators, and mitigators, JAMIA 19(1), 121 to 127. doi.org/10.1136/amiajnl-2011-000089 (2012)
7. Guo, C., Pleiss, G., Sun, Y. and Weinberger, K.Q., On calibration of modern neural networks, Proceedings of ICML 2017, PMLR 70, 1321 to 1330. proceedings.mlr.press (2017)
8. Haber, S. and Stornetta, W.S., How to time-stamp a digital document, Journal of Cryptology 3(2), 99 to 111, section 5.1. doi.org/10.1007/BF00196791 (1991)
9. NIST, FIPS PUB 180-4, Secure Hash Standard. csrc.nist.gov (Aug 2015)
10. Crosby, S.A. and Wallach, D.S., Efficient data structures for tamper-evident logging, 18th USENIX Security Symposium. www.usenix.org (Aug 2009)
11. Laurie, B., Messeri, E. and Stradling, R., RFC 9162, Certificate Transparency Version 2.0, section 1. www.rfc-editor.org (Dec 2021)
12. Adams, C. and others, RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol. www.rfc-editor.org (Aug 2001)