How do you decide what moving from stage-gated verification to continuous verification actually changes?

## What the shift actually is Stage-gated verification treats a check as an **event**: at a defined boundary, a body of checking is executed, and its result informs a decision. Continuous verification treats a check as a **standing property**: an assertion that should hold at all times, evaluated on every change and, where the property is about live behaviour, evaluated continuously against the running system. The difference is when the evidence is produced and how fresh it is when someone relies on it. That is a smaller change than the vocabulary suggests, and treating it as a wholesale replacement is the usual mistake. The useful framing for a lead is a triage of the existing checking, not a migration project. ## The triage Five properties decide whether a check can stand continuously. 1. **Speed relative to the change rate.** A check that takes longer than the interval between changes cannot be continuous in any useful sense; it will always be reporting on a system that no longer exists. 2. **Determinism.** A check that fails occasionally on unchanged code destroys the signal faster the more often it runs. Continuity multiplies nondeterminism rather than tolerating it. 3. **Self-diagnosis.** A standing assertion that fails must say what broke without a human reconstructing the state. At boundary cadence someone investigates each failure; at continuous cadence nobody can. 4. **Resource independence.** Anything needing a scarce shared environment, a licence-limited generator, or coordination with another team cannot run on every change, whatever its value. 5. **Oracle type.** If the thing that decides whether behaviour is wrong is a person's judgement — usability, fitness for a real job, whether a workflow makes sense — no amount of automation makes it continuous. That work belongs to a session with a human in it. A check failing any of these is not a failure of the team; it is a check that belongs at a boundary, and saying so explicitly is more valuable than forcing it. ## A worked triage A smart-meter reading feed ships on a 3-week release train and carries three bodies of checking. The functional checks over the ingest and entitlement rules pass all five tests: seconds to run, deterministic, and they name the failing rule. They become standing assertions evaluated on every change, and the train stops being the moment anyone learns the rules are broken. The volume work does not. Reproducing 218,400 meters reporting into one bunched window needs a dedicated environment and takes 47 minutes. A reduced form of it can stand continuously — a smaller shaped burst that catches order-of-magnitude regressions — while the full-scale run stays a boundary activity. Splitting a check into a continuous cheap form and a boundary-time full form is usually a better answer than choosing one. The entitlement review does not become continuous at all. The escalation that mattered on this feed was a rule that granted a technician access to any household's history: it was implemented exactly as specified and passed every check written against that specification. No standing assertion would have caught it, because the assertion would have been derived from the same specification. What did catch it was a human comparing the rule to how the job is actually done. Continuous verification does not eliminate that; it frees the schedule so it can happen more often. ## What does not change Three things survive the shift, and a principal answer names them. The **artefact-to-level pairing** is untouched: a check still verifies against some stated intent, and moving it to run continuously does not change which intent it verifies against. A continuous check derived from a wrong specification is a wrong check evaluated more often. **Validation** still needs real users and real context. Continuous verification produces fresher conformance evidence, not evidence of fitness. **Judgement about sufficiency** remains a human decision. Continuity tells you the standing assertions hold right now; it does not tell you they are the right assertions or that they cover what this change touched. ## The organisational cost The expensive failure is ownership. A standing assertion that fires with no owner becomes an alert people mute, and a muted assertion is worse than an absent one because it appears on a report as covered. So each standing check needs a named owner, a defined response, and a rule for what happens when it stays red — most usefully, an agreement that a persistently failing standing check either gets fixed or gets removed, never left red indefinitely. There is also a subtler one: continuous verification makes evidence cheap, and cheap evidence gets over-trusted. A dashboard that is green all the time is easy to read as "the system is fine" rather than "the properties someone thought to assert still hold". ## Framing the answer Say that the shift changes freshness and cadence, not the definition of evidence. Give the triage properties. Give an honest example of something that cannot move and say why. Name what stays the same, and name the ownership cost. Avoid claiming that continuity removes the need for a release-time judgement — it changes what that judgement is made from.