In an insurer's model registry, who should hold promotion authority for a claim-severity model, and what makes that approval a real control?

## Why this is an authority question, not a tooling question A registry stage transition is a row change. What makes it a **control** is entirely about who may make it, what evidence it requires, and whether the act is recorded and reversible. Any registry can express the transition; very few organisations get the surrounding four properties right, and that is the part an interviewer is probing. For a claim-severity model the stakes are concrete: the model's output feeds reserve amounts, so a systematic over- or under-prediction is a financial statement problem, not only a quality problem. That is why the approver should be the person who owns the consequence rather than the person who wants the model live. ## Separation of duties, stated precisely - The **author** of the run proposes a version for promotion and supplies the evidence. - The **approver** is accountable for the model's behaviour in production and is not the author. - The **platform** enforces that the transition cannot be made by anyone else, and cannot be made at all when required evidence does not resolve. The third point is what stops separation of duties from being a convention. If a determined engineer can set the production stage directly, the rule is a norm; if the transition validates that a run record, an evaluation on the required set, an input contract and an approval identity all resolve, the rule is a mechanism. ## What the approver is actually reading A number cannot be approved or refused. The promotion document - commonly a **model card** attached to the version - states what the version is claimed to be safe for: - intended use, and explicitly **out-of-scope** use (which lines of business, which claim types); - the evaluation set identifier, the metric definition and the value, broken out by the populations that matter rather than as one aggregate; - known limitations and the conditions under which the model is expected to degrade; - the input contract: which feature-definition version and input schema it requires; - the monitoring plan and the rollback plan, including who executes each. The card is what makes refusal possible, because it converts *this model is better* into a set of claims that can be individually checked. ## The two failure modes, and they are symmetrical | failure | how it looks | what it costs | |---|---|---| | theatre | approval always granted, usually same-day, never with a question | the delay of a real control with none of the protection | | bottleneck | approval takes weeks, committee-scheduled, requires a re-presentation | an emergency path is invented, then used routinely | Both end in the same place: promotions that nobody meaningfully reviewed. The measurable tell for the first is a refusal rate of exactly zero over many quarters; for the second it is the share of promotions that went through the exception route. ## The judgment call: how much to automate The defensible position is to make the **cost of the signature proportional to what is new**: 1. A like-for-like quarterly refresh - same inputs, same objective, same population, same decision threshold - clears on the recorded gates and is promoted automatically, with the same rollback guarantee as any other version. 2. A **material change** - a new input, a new population or line of business, a changed objective, a moved decision threshold - requires the accountable owner's signature against the model card. 3. Anything touching the input contract requires it too, because that is what makes a rollback stop being a pointer flip. This is defensible precisely because rollback is cheap. Reversibility is what converts an approval from a gate that must be right into a decision that can be corrected, and a team that has never rehearsed a rollback has no basis for automating anything. ## What good looks like when audited - Every production version carries an approval naming a person, a time and the artifact digest approved. - The approver is demonstrably not the author of the run. - At least some approvals were refused or returned for more evidence, and the reasons are recorded. - The exception path exists, is rare, and every use has a written justification and a follow-up. - The currently promoted version is not assumed to be the newest one, because rollbacks are recorded as events too. None of that requires a particular registry. It requires deciding, in advance, who is accountable and what they are entitled to refuse.