---
id: RISK-METHOD-PRODUCTION
type: method
title: "The production transition: what expires, and who says when"
status: proposed
owner: the-custodian
drafted_by: risk-nexus
drafted: "2026-08-21"
workplan: RISK-WP-0005-T03
review_interval: 6m
---

# The production transition

Five findings owe a re-score here. One acceptance **expires** here. Several
dormant legal policies activate here. And until 2026-08-21 nobody had defined
the event, named who declares it, or told the repos that carry the obligations.

An acceptance that expires on an undefined event expires on nobody's calendar.

**Status: `proposed`.** The definition is the custodian's; the plumbing is
this repo's.

## Proposed definition

> **The production transition is the first moment any system in the estate
> holds, processes or decides about the data of a real external person or
> tenant.**

Deliberately not: a launch announcement, a version number, a deployment to a
cluster named production, or a declaration made in advance. All four can be
true while nothing real is at stake, and all four can be false on the day
something is.

Two consequences worth stating, because they are what make the definition
usable:

- **It can happen by accident.** A single real signup, a migrated contact list,
  one counterparty's document sent through a pipeline for testing. Which is
  why it is defined by what is held rather than by what was announced.
- **It is not reversible.** Deleting the data afterwards does not un-transition
  the estate; it changes the exposure and not the fact that the estate is now
  the kind of thing that holds real data.

## Who declares it

The operator, through `the-custodian`. Not this register: `INTENT.md` keeps
"deciding what canon says" and estate-level facts with the custodian, and a
risk register that unilaterally declares the estate to be in production has
appointed itself.

What this register does is **notice and ask**. Any finding, verification or
policy check that turns up real external data in a system triggers one question
to the custodian: *has the transition happened?* The answer is theirs; the
record is ours.

## What fires on the day

| Obligation | Carried by | Count today |
| --- | --- | --- |
| Re-score every finding with `production_rescore: true` | this register | 5 |
| `RISK-F-0007`'s acceptance expires — the unverified tenant boundary stops being carried | this register, escalating | 1 |
| `RISK-POL-0001`, `0003`, `0004`, `0005`, `0008` activate; `0002` fully | owning repos | 6 policies |
| `RISK-F-0008`'s acceptance ends — the retention basis stops being an internal determination | this register | 1 |

`make check` lists the first two under "owed at the production transition"
today, so the size of the obligation is visible before the day rather than
discovered on it.

## How the register hears about it

Three routes, in order of reliability:

1. **The custodian says so**, in a message. Preferred, and the only one that is
   also a decision.
2. **A finding or verification turns up real external data**, and this register
   asks. This is the route that works when nobody remembered to declare.
3. **A legal policy activates on its own condition** — the accessibility or
   data-subject-rights entries in `docs/regulatory/policies/` fire on facts
   about the world, not on a declaration, and a repo consulting one is evidence
   the transition may have happened.

Route 2 exists because route 1 is exactly the kind of announcement that gets
skipped in a busy week, and the estate has already demonstrated (`RISK-POL-0012`)
that an obligation can be live for nineteen months without anyone noticing.

## What this document does not do

It does not schedule the transition, gate it, or require anything before it. In
build mode a finding is information — that is unchanged. This says only what
becomes true on a day that will arrive whether or not it is planned.