The Guardrail Lifecycle

A detector is not a feature that ships once. It is a control with a lifespan, and the mistake that produces most guardrail incidents is treating the first deployment as the end of the work rather than the middle of it.

This blueprint specifies the path from proposal to retirement, what each gate requires, and which gates are allowed to block. ARCH-005 said who owns the decisions. This one says when they get made.

Eight gates

1. Intake. Someone proposes a control, usually because of an incident, a regulation, a red-team finding, or a new system going live. The intake record captures what harm this addresses, which chokepoint it would sit at, and who is asking. Cheap and fast; the point is that controls have a front door rather than arriving as a ticket in a sprint.

2. Tiering. The system this control protects gets a tier, and the tier sets everything downstream. This gate blocks: an untiered system cannot proceed, and a tier assigned by the delivery team without second-line sight is not a tier.

3. Build. Technique, interface, composition, per ARCH-002. First line owns this outright. The output is a detector that satisfies the interface contract and a test set that is honest about its size.

4. Red team. Someone whose job is to break it, tries. Not the author. Exit criterion: every bypass found is either fixed, routed to a control at a different chokepoint, or accepted in writing by the threshold owner. An open bypass with no disposition holds the gate.

5. Shadow. The detector runs against real production traffic and records what it would have done. It takes no action. Exit criteria: the observed base rate is measured rather than assumed, the projected daily alert volume is inside what the review workflow is staffed for, and added latency at p95 is inside the budget from ARCH-008. Failing any of the three sends the threshold or the pipeline back, not the release forward.

6. Canary. The detector enforces, on a bounded slice: one surface, one user group, or a percentage of traffic. Blast radius is the point. Exit criteria: the support and override volume is understood and attributable, and no unexplained class of false positive remains open.

7. Enforce. Full traffic, enforcing. This gate blocks: it needs the go-live pack.

8. Monitor, then revalidate or retire. The control is live and generating evidence on a cadence. Revalidation is scheduled at go-live, not triggered by memory.

Tiering decides the rest

Every organisation that runs this well has a tier model, and every one that struggles has the same argument repeatedly about how much process a given system deserves. Tier once, at intake, and inherit.

Tier on three properties, scored independently, then take the highest. Authority: can the system only read, or can it write to systems of record and take actions in the world. Data sensitivity: what the worst document it can retrieve would cost if disclosed. Exposure: internal users, or customers and the public. Collapsing these into a single “is it customer-facing” question is what puts a read-only public FAQ bot in the same tier as an agent that can move money, and that mistake discredits the model with the teams you need to apply it.

Every number in that table is illustrative. Neither the NIST Generative AI Profile nor the OWASP list sets review frequencies or shadow durations; those are yours to choose, and no external source will settle them for you. What matters is that they exist before the first system needs them, because a tier model negotiated during a launch is a tier model that reflects the launch date.

Tiering is also the point where this lifecycle meets an organisation’s wider agent governance posture. The Enterprise AI Transformation playbook sets out a maturity ladder for that posture, from ad hoc through to governance embedded in the development lifecycle, which is a useful way to work out which gates you can realistically enforce today rather than which ones you would like to.

Shadow, then canary, then enforce

This is the sequence teams compress, and compressing it is the single most reliable way to lose the mandate for a guardrail programme.

Shadow answers questions your test set cannot. ARCH-003 shows that precision depends on the population. Shadow mode is where you measure that population. You learn the real base rate, the real false positive volume per day, and the real latency at production concurrency. A detector that looked fine at 0.91 precision offline routinely produces a four-figure daily alert volume in shadow, and it is much cheaper to discover that before it is blocking anything.

Shadow requires the full decision path to run and record, taking no action. If shadow mode is implemented as “log the score”, it will not surface the policy and action bugs, which are the ones that break users.

Canary bounds the blast radius of being wrong. Enforcement changes user experience. Pick a slice where the population resembles production, where you have a feedback channel, and where you can revert in minutes. Two weeks of canary tells you what the support ticket volume looks like.

Enforcement is a decision, not a deployment step. It needs the go-live pack, and the person who signs it is the threshold owner from ARCH-005, not the engineer merging the change.

Shadow mode is not a testing phase. It is the only place you get to measure the population your detector will actually meet, and it costs nothing but patience.

The go-live pack

The artefact that the enforce gate requires. Keeping it to one page is deliberate: a pack that takes a week to assemble will be assembled once and never updated.

GO-LIVE PACK  ·  <control id>  ·  <system>  ·  <tier>

1  What this control detects, and the harm it prevents
2  Chokepoint, technique, composition rule
3  Offline results: precision and recall, with intervals, and
   the size of the flagged set they rest on
4  Shadow results: duration, request volume, observed base rate,
   daily alert volume, p95 added latency
5  Red-team summary: attempts, bypasses found, fixed vs accepted
6  Threshold: the cost ratio, the approver, the traffic assumption
7  Action on fire, and action on detector failure
8  Review workflow: who sees what, at what volume, and the
   staffing that assumes
9  Rollback: the exact change that reverts to shadow, and who
   can make it without an approval
10 Revalidation date, and what would trigger it early

Item 9 is the one that gets waved through and matters most under pressure. If reverting to shadow requires a code deploy and a change advisory board, the actual rollback procedure during an incident will be someone disabling the control entirely.

The regression gate that blocks a release

Guardrails need the same CI discipline as any other production dependency, and this is where policy-as-code stops being a slogan. Two gates belong in the pipeline.

# .github/workflows/guardrail-gates.yml
name: guardrail-gates
on: [pull_request]

jobs:
  policy-validation:
    # Gate 1: policy is data, so it compiles or it does not ship.
    steps:
      - run: guardrail policy validate policies/
        # schema check, conflict detection, precedence ties are
        # errors here rather than resolution rules at runtime
      - run: guardrail policy test policies/ --cases tests/policy-cases.yaml
        # synthetic verdicts with expected actions. catches the
        # edit that quietly widens a default from redact to allow

  detector-regression:
    # Gate 2: no silent accuracy loss.
    steps:
      - run: >
          guardrail eval run
            --detector pii_in_response
            --set eval/pii-v7.jsonl
            --baseline baselines/pii_in_response.json
            --floor baselines/pii_in_response.floor.json
            --fail-on recall_drop=0.02,precision_drop=0.03,
                      alert_volume_increase=0.15,latency_p95_increase=15ms
      - run: guardrail eval report --format markdown >> $GITHUB_STEP_SUMMARY

Three design notes.

The gate fails on a drop against the last accepted baseline, because absolute targets get lowered until they pass. But a per-change tolerance alone permits cumulative decay: twenty changes each losing 1.9 percent of recall all pass, and the detector has quietly lost a third of its recall. So the gate also carries a floor, set at go-live and changeable only with the same approval as the original threshold. Baseline catches the bad change; floor catches the slow slide.

It fails on precision and projected alert volume, not just recall. A change that improves recall while doubling false positives has not improved the control, it has moved the cost onto the review queue, and per ARCH-003 that is the failure mode that ends guardrail programmes socially.

And it fails on latency, because a detector that became 40ms slower has spent someone else’s budget whether or not anyone noticed.

Worked example: a prompt injection detector

An enterprise RAG assistant over internal documents, Tier 2. Injection arrives inside retrieved content, which is the case ARCH-001 says the prompt layer cannot attribute. This walkthrough is a constructed example, not a report of a specific deployment; the figures show the shape of what each gate produces.

The two things this example is meant to show. Shadow changed the threshold, which means shipping straight from offline results would have produced 340 alerts a day into a queue staffed for a fraction of that. And red team found nine bypasses, three of which were correctly not fixed in this detector, because the right control for them lived at a different chokepoint. A programme that treats every red-team finding as a defect in the detector under test will build one enormous detector that does everything badly.

Where this blueprint stops working

The lifecycle assumes a stable definition of the thing you detect. Prompt injection in 2026 is not what it was in 2024, and a detector that passes revalidation against a 2024 test set is measuring the wrong thing accurately. Test set refresh has to be its own scheduled work, owned by whoever owns the threat model, or revalidation becomes a ritual that always passes.

Shadow mode has a real cost. Running every detector against full production traffic while taking no action doubles the detection compute for the shadow period, and for an LLM judge that is not a rounding error. Tier 3 systems will not justify it. Say that explicitly rather than letting teams quietly skip the gate.

Retirement almost never happens. Controls accumulate, each one adding latency and false positives, and no team is rewarded for removing one. Without a forcing function the pipeline only grows.

Resist the obvious proxy. “It has not fired a true positive in a year” is not evidence a control is unnecessary: the attack may be rare rather than absent, the control may be deterring the attempt, or it may be failing to detect what is happening. A defensible retirement case needs three things instead. The harm it addresses is now prevented deterministically somewhere else, usually by an authorization control that made the classification question moot. Its true positives over the period are attributable to that other control on replay. And the threat model that motivated it has been reviewed and still says the same thing. Absent those, the honest answer is that the control stays and its cost is the price of the risk.