Lesson 175: WORM-Style Archived Submission Packet Retention and 90-Minute Cold-Storage Retrieval Drill (2026)

Why this matters now

Lessons 170-174 built the live-loop: FAQ-bound readback, tuple-drift publish-pipeline blocks, mock-audit tabletops, deficiency trend boards, and signer fatigue heat-maps. That stack assumes the current quarter's packets are reachable through normal dashboard queries against live tables. This lesson installs the post-submission archive lane for packets that have already shipped — the WORM (write-once-read-many) retention policy, the cold-storage pointer schema, and the 90-minute retrieval drill that proves the archive is real, not just configured.

The 2026 trigger is concrete: off-cycle January 2027 partner auditor questions against Q3 2026 packets are already appearing in partner templates being circulated in December 2026 planning decks. The pattern is consistent — a partner reviewer in their January year-opening rhythm pulls a packet that shipped to them five months earlier and asks "show me the dictionary row that backed metric M in the readback we received on date D." Five months earlier, the dictionary was at semver v2.3.1; today the live dictionary is at v2.5.0 with three column renames and two deprecated rows. The team that can produce the v2.3.1 snapshot bound to the original publish_tuple_hash answers in minutes. The team that cannot will rebuild the snapshot by piecing together git history, dashboard exports, and Slack screenshots — a process that consistently misses the 48-hour reply SLA and surfaces as a yellow on the year-opening risk letter.

Three concurrent 2026 shifts make this lesson essential rather than optional:

• Partner reviewers shifted off-cycle question cadence from rare to routine in Q4 2026 — what used to be one or two retroactive lookups per cert window has become a standing part of the quarterly readback cycle, often involving packets from one or two quarters back.
• Cold-storage pricing dropped enough in 2026 that retaining the full packet artifact (not just the dashboard row pointers) became affordable for small indie teams — meaning partner reviewers now expect retention of the rendered packet PDF + the underlying snapshot rows + the parser contract version + the footer semver for at least 12 months, where 2024-2025 templates accepted "we retain row-level data only."
• Footer schema semver discipline from Lesson 165 created the artifact-reproducibility primitive that makes retrieval drills mechanically possible — without footer_schema_semver pinned per packet, retrieval would be best-effort reconstruction; with it, retrieval is deterministic regeneration from cold storage.

A team that ships this lesson before December 2026 answers off-cycle auditor questions on the 48-hour SLA with a single SQL query plus a cold-storage fetch. A team that does not ships a launch-week scramble into January.

Lesson objectives

By the end of this lesson you will have:

• A packet_archive_pointer table capturing one immutable row per shipped packet with cold-storage URI, content-addressed hash, retention class, and binding back to the live publish_tuple_hash from Lesson 171.
• A WORM enforcement layer — application-level + database-level constraints + storage-bucket-level object-lock — that makes archived rows actually write-once-read-many rather than nominally so.
• A retention class taxonomy (hot / warm / cold / vault) with explicit transition rules driven by packet age and recurrence-trend evidence from Lesson 173.
• A cold-storage retrieval procedure with named entry points, named role responsible at each step, and named expected wall-clock times so a drill can be measured against a known target.
• A 90-minute retrieval drill rehearsal with hashed fixture parity against Lesson 165 footer semver, mirroring Lesson 169's dry-run discipline applied to archive retrieval instead of freeze-lift.
• A partner reply packet template for off-cycle auditor questions that drops cleanly into the Lesson 170 FAQ-bound readback structure and produces a SHA-256-verified retrieval audit trail.

Prerequisites from earlier lessons

This lesson assumes:

• Lesson 165 footer metadata schema versioning exists with footer_schema_semver pinned per packet and a registry mapping each semver to its parser contract.
• Lesson 167 synthetic replay diff gate + epsilon_policy_version exists so retrieved packets can be re-rendered with the original epsilon policy, not the current one.
• Lesson 170 FAQ-bound readback packet exists with the structured Markdown export pattern this lesson's retrieval reply extends.
• Lesson 171 tuple-drift publish-pipeline block + publish_tuple_hash exists so the archive can bind back to the exact upstream snapshot.
• Lesson 172 mock-audit rubric + mock_audit_log exists so rehearsal cadence has historical precedent in the team's calendar.
• Lesson 173 deficiency trend board exists so retention-class promotion (warm → cold → vault) can be informed by recurrence trends rather than age alone.
• Lesson 174 signer fatigue heat-map exists so the on-call retrieval owner is not always the same overloaded primary signer.

If any of these is missing, build it first. Archive retention without footer semver is best-effort reconstruction; retrieval drills without trend-board cross-reference produce arbitrary retention class decisions; retrieval owner routing without fatigue heat-map duplicates the burden on signers already at red.

The packet_archive_pointer table

The archive is not a copy of the live data. It is a pointer table that records exactly where the immutable packet artifact lives in cold storage plus the metadata needed to retrieve and verify it:

CREATE TABLE packet_archive_pointer (
  archive_id              TEXT PRIMARY KEY,
  cert_window_id          TEXT NOT NULL,
  publish_tuple_hash      CHAR(64) NOT NULL,                 -- from Lesson 171
  source_tuple_hash       CHAR(64) NOT NULL,                 -- from Lesson 171
  footer_schema_semver    TEXT NOT NULL,                     -- from Lesson 165
  epsilon_policy_version  TEXT NOT NULL,                     -- from Lesson 167
  dictionary_semver       TEXT NOT NULL,                     -- from Lesson 164
  cold_storage_uri        TEXT NOT NULL,                     -- e.g. 's3://gov-archive/2026/q3/...'
  artifact_sha256         CHAR(64) NOT NULL,                 -- content hash of the archived blob
  artifact_size_bytes     BIGINT NOT NULL,
  retention_class         TEXT NOT NULL
                          CHECK (retention_class IN ('hot', 'warm', 'cold', 'vault')),
  retention_class_set_dt  TIMESTAMPTZ NOT NULL,
  retention_class_reason  TEXT NOT NULL,                     -- references Lesson 173 trend-board row
  archived_at_dt_utc      TIMESTAMPTZ NOT NULL,
  archived_by             TEXT NOT NULL,                     -- signer who acked the archive event
  scheduled_purge_dt_utc  TIMESTAMPTZ,                       -- nullable; vault rows have no purge date
  UNIQUE (publish_tuple_hash)
);

The UNIQUE (publish_tuple_hash) constraint is the anti-duplicate-archive invariant: every shipped packet produces exactly one archive row, and re-shipping the same packet does not produce a second archive row (only an updated retention_class transition).

The eight version-pinning columns (publish_tuple_hash, source_tuple_hash, footer_schema_semver, epsilon_policy_version, dictionary_semver plus the three hash + size columns) together form the retrieval contract: given any archive_id, the team can deterministically re-render the packet because every input the rendering pipeline depends on is pinned in the row.

WORM enforcement in three layers

Nominal WORM (a retention_class = 'vault' value in a row) is not WORM. Real WORM requires three layers:

Layer 1 — Database-level invariants. Add a forbid-mutate trigger on the archive table that rejects UPDATE on any column except retention_class + retention_class_set_dt + retention_class_reason + scheduled_purge_dt_utc:

CREATE OR REPLACE FUNCTION packet_archive_pointer_worm_check()
RETURNS TRIGGER AS $$
BEGIN
  IF NEW.archive_id            <> OLD.archive_id
  OR NEW.cert_window_id        <> OLD.cert_window_id
  OR NEW.publish_tuple_hash    <> OLD.publish_tuple_hash
  OR NEW.source_tuple_hash     <> OLD.source_tuple_hash
  OR NEW.footer_schema_semver  <> OLD.footer_schema_semver
  OR NEW.epsilon_policy_version<> OLD.epsilon_policy_version
  OR NEW.dictionary_semver     <> OLD.dictionary_semver
  OR NEW.cold_storage_uri      <> OLD.cold_storage_uri
  OR NEW.artifact_sha256       <> OLD.artifact_sha256
  OR NEW.artifact_size_bytes   <> OLD.artifact_size_bytes
  OR NEW.archived_at_dt_utc    <> OLD.archived_at_dt_utc
  OR NEW.archived_by           <> OLD.archived_by THEN
    RAISE EXCEPTION 'WORM violation: immutable column changed on packet_archive_pointer.archive_id=%', OLD.archive_id;
  END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER packet_archive_pointer_worm_trigger
  BEFORE UPDATE ON packet_archive_pointer
  FOR EACH ROW EXECUTE FUNCTION packet_archive_pointer_worm_check();

DELETE is similarly restricted via a row-level security policy or a separate trigger; only a service role with delete_archive privilege (granted to no human under normal operation) can delete, and only after a 30-day audit hold.

Layer 2 — Application-level archive event. The archive write is append-only through a single application endpoint that emits a packet_archive_event row before inserting into packet_archive_pointer. The event row captures the requester, the upstream publish_tuple_hash provenance, and the signer ack:

CREATE TABLE packet_archive_event (
  event_id              TEXT PRIMARY KEY,
  archive_id            TEXT NOT NULL,
  event_type            TEXT NOT NULL
                        CHECK (event_type IN (
                          'archive_created',
                          'retention_class_changed',
                          'retrieval_verified',
                          'retrieval_failed',
                          'purge_scheduled',
                          'purge_executed'
                        )),
  signer_ack            TEXT NOT NULL,        -- from Lesson 174 backup-owner-aware ack table
  event_dt_utc          TIMESTAMPTZ NOT NULL,
  event_metadata_json   JSONB
);

The application refuses to insert into packet_archive_pointer without a matching archive_created event row from the same transaction.

Layer 3 — Storage-bucket-level object-lock. The cold-storage bucket itself has object-lock retention mode enabled (S3 Object Lock in Governance or Compliance mode, GCS Bucket Lock, Azure Immutable Blob Storage). Without this, the database invariants are circumventable by anyone with bucket credentials. The retention period at the bucket level should match the highest tier of the retention class taxonomy (vault = 7 years for partner-audit purposes; cold = 24 months; warm = 12 months; hot = 90 days). The bucket-level lock makes the artifact bytes themselves immutable for the retention window even if the database row is somehow tampered with.

The three layers together produce defensible WORM: the row is immutable, the event log is append-only with signer evidence, and the bytes themselves are locked at the storage layer.

The retention class taxonomy

Four classes with explicit transition rules:

The transition rules are deterministic, not curated:

CREATE OR REPLACE FUNCTION packet_archive_recommended_class(
  p_archived_at TIMESTAMPTZ,
  p_publish_tuple_hash CHAR(64)
) RETURNS TEXT AS $$
DECLARE
  age_days NUMERIC;
  has_trend_touch BOOLEAN;
  has_reviewer_touch BOOLEAN;
BEGIN
  age_days := EXTRACT(EPOCH FROM (NOW() - p_archived_at)) / 86400;
  SELECT EXISTS (
    SELECT 1 FROM deficiency_trend_board
    WHERE classification IN ('structural-red', 'hot')
      AND last_event_dt > p_archived_at - INTERVAL '30 days'
      AND last_event_dt < p_archived_at + INTERVAL '90 days'
  ) INTO has_trend_touch;
  SELECT EXISTS (
    SELECT 1 FROM packet_archive_event
    WHERE event_type = 'retrieval_verified'
      AND event_dt_utc > NOW() - INTERVAL '180 days'
  ) INTO has_reviewer_touch;
  IF has_trend_touch OR has_reviewer_touch OR age_days >= 730 THEN
    RETURN 'vault';
  ELSIF age_days >= 365 THEN
    RETURN 'cold';
  ELSIF age_days >= 90 THEN
    RETURN 'warm';
  ELSE
    RETURN 'hot';
  END IF;
END;
$$ LANGUAGE plpgsql;

A nightly job runs this function across every packet_archive_pointer row and proposes transitions. Transitions are not automatic — they are written to a proposed_retention_class_change queue that a signer reviews weekly during the operating review. This single human-in-the-loop step prevents an over-eager classifier from sending a still-relevant packet to deep archive where retrieval costs 24 hours instead of 90 minutes.

The cold-storage retrieval procedure

Five steps with named entry points, named owners, and named expected wall-clock times:

Step 1 — Resolve archive_id from question (5 minutes). Auditor question lands ("show me the dictionary row backing metric M in the readback you sent us on date D"). On-call governance owner (per Lesson 174 backup-owner table for this owner-route) runs SELECT archive_id FROM packet_archive_pointer WHERE cert_window_id = ? plus filter clauses on dictionary_semver matching the packet date. Output: one archive_id.

Step 2 — Pull from cold storage (20-90 minutes by class). Owner runs the storage-specific retrieval command (S3 restore-object, GCS rehydrate, Azure rehydrate) against cold_storage_uri. For warm retrieval is instant; for cold it is 60 minutes; for vault it is 24 hours. Owner logs the retrieval request start time + ETA in a Slack thread or partner-comms channel so the auditor sees acknowledgment before the artifact is in hand.

Step 3 — Verify content hash (5 minutes). Owner downloads artifact, computes SHA-256, compares against artifact_sha256 in the row. On mismatch the retrieval logs a retrieval_failed event and escalates to the WORM forensic procedure (covered below in the troubleshooting section). On match the retrieval logs a retrieval_verified event and proceeds.

Step 4 — Render the answer (15-30 minutes). Owner reads the archived packet (which is the rendered Markdown + the underlying snapshot rows + the parser contract version + the footer semver) and extracts the specific row the auditor asked about. Owner cross-references against the dictionary_semver pinned in the archive row, not against the current live dictionary — the auditor is asking about the state of the world on the packet's date, not today's state.

Step 5 — Reply with reproducible answer (15 minutes). Owner drafts a reply using the Lesson 170 FAQ-bound readback structure plus an extension block that pins the archive_id, the SHA-256, and the retrieval timestamp. Owner gets a backup-owner-aware signer ack per Lesson 174 backup-owner-policy, and sends.

Total wall-clock budget: hot 60 minutes, warm 90 minutes, cold 130 minutes, vault 24h45m. The 90-minute retrieval drill rehearses the warm path because warm is the most common retrieval class for off-cycle auditor questions touching the prior 6-9 months.

The 90-minute retrieval drill

The drill mirrors Lesson 169's freeze-lift dry-run discipline applied to archive retrieval. Run it monthly on a standing calendar block:

Drill setup (5 minutes). Drill operator picks a packet_archive_pointer row at random from the warm retention class (no hand-picking — randomisation forces the procedure to handle whatever the dice produce). Drill operator records a synthetic auditor question against the chosen packet that exercises a non-trivial cross-reference (e.g. "show me the dictionary row for metric M at the time this packet shipped, plus the epsilon policy version, plus whether the reconciliation job for that week was green").

Drill execution (60 minutes). On-call governance owner runs steps 1-5 above against the synthetic question with a stopwatch. No shortcuts allowed; the owner must actually pull from cold storage, actually verify the SHA-256, actually cross-reference the pinned dictionary_semver against the registry, and actually render the reply in the Lesson 170 FAQ-bound packet structure.

Drill scoring (15 minutes). Operator scores against three deterministic rules:

1. Wall-clock time under 90 minutes for the warm path: yes / no.
2. SHA-256 verification step actually executed and event row written: yes / no.
3. Reply pins archive_id + dictionary_semver + footer_schema_semver + epsilon_policy_version: yes / no.

Three yes = drill pass. Any no = drill fail with named failure mode written to a retrieval_drill_failure_log table for next month's review.

Drill cadence (10 minutes review at end). Operator + on-call owner sit briefly with the trend-board (Lesson 173) and check whether any structural-red or hot row touches the chosen packet; if so, the packet's retention class should have been vault not warm, and the transition queue from the retention taxonomy section is reviewed for misclassifications.

Pin the drill on the calendar monthly, on the same week as the Lesson 174 monthly fatigue review so on-call signer rotation is fresh and the drill load is distributed.

The partner reply packet template

When a real off-cycle auditor question arrives, the reply uses the Lesson 170 FAQ-bound structure plus an archive-retrieval extension block:

## Reply to Off-Cycle Auditor Question (Retrieved from Archive)

**Question received (UTC):** [timestamp]
**Reply target SLA:** 48 hours
**Reply produced (UTC):** [timestamp]
**On-call governance owner (per Lesson 174):** [signer]
**Backup-owner promote in effect at retrieval time:** [yes/no, with promote_event_id if yes]

### Archive retrieval audit

| Field | Value |
|---|---|
| archive_id | [TEXT] |
| cert_window_id | [TEXT] |
| publish_tuple_hash | [CHAR(64)] |
| source_tuple_hash | [CHAR(64)] |
| footer_schema_semver | [TEXT] |
| epsilon_policy_version | [TEXT] |
| dictionary_semver | [TEXT] |
| artifact_sha256 (expected) | [CHAR(64)] |
| artifact_sha256 (verified) | [CHAR(64)] |
| retention_class at retrieval | [hot|warm|cold|vault] |
| retrieval_drill_last_pass_dt | [timestamp] |

### Answer (rendered from archived packet, not from live dictionary)

[Direct answer to the auditor's question, sourced from the archived packet and explicitly referencing the pinned `dictionary_semver` from the archive row, not the current live dictionary.]

### Cross-reference

This answer reflects governance state as of **[archived_at_dt_utc]**. The live dictionary has since advanced to **[current dictionary_semver]**. If the auditor's question depends on the current state, see the live readback packet for [current cert window]. If the question is specifically about the state at the time the original packet shipped, this archived answer is authoritative.

The structure is deliberately verbose. Partner reviewers in 2026 explicitly look for the artifact_sha256 (expected) vs (verified) row as evidence the team actually performed the verification step rather than transcribing from a live dashboard.

Common mistakes to avoid

• Treating retention_class = 'vault' as the WORM implementation. The column value is metadata; the three-layer enforcement (database trigger + append-only event log + bucket-level object-lock) is the WORM. A vault row without bucket-level object-lock is not WORM.
• Letting retention transitions be fully automatic. Automatic age-only transitions send still-relevant packets to deep archive prematurely. The weekly human-review step on the proposed-transition queue is what keeps retrieval SLAs honest.
• Running the drill only when an auditor question is overdue. The first time the procedure runs is the slowest. Monthly cadence keeps the wall-clock time honest and surfaces tooling decay (expired bucket credentials, rotated IAM roles, deprecated retrieval commands) before a real auditor question.
• Verifying SHA-256 only sometimes. The verification step is the difference between "we have an archive" and "we have a verified archive." Skipping it on time pressure is the failure mode that produces a tampered-byte forensic event two years later when no one can reconstruct what happened.
• Pinning the answer against the current dictionary_semver instead of the archived one. The auditor is asking about the state of the world on the packet's date. Answering with today's dictionary is a category error.
• Skipping the backup-owner-aware ack on the reply. Per Lesson 174, the on-call owner may be the primary or the backup depending on the heat-map. The reply must carry whichever signer is currently in effect, not the canonical primary.
• Letting the cold-storage URI drift. Bucket migrations, region moves, and lifecycle-policy changes all silently update the URI. The archive row must be updated through the WORM-allowed retention-class-change path (which now also allows cold_storage_uri mutation under a tightly-scoped URI_RELOCATION event type) rather than direct edit.
• Treating drill failures as drill problems instead of system problems. A drill failure means the retrieval procedure has decayed since last month; that is a real failure that would have surfaced on a real auditor question. Log it in retrieval_drill_failure_log and address before next month's drill.

Verification checklist

• [ ] packet_archive_pointer table exists with eight version-pinning columns, UNIQUE (publish_tuple_hash) constraint, and retention_class CHECK.
• [ ] WORM enforcement is layered: database trigger forbidding column mutation, append-only packet_archive_event log with signer ack, bucket-level object-lock matching the vault retention period.
• [ ] packet_archive_recommended_class function exists with deterministic transition rules cross-referencing Lesson 173 trend-board state.
• [ ] Weekly review of proposed_retention_class_change queue is on the calendar with a named owner.
• [ ] Cold-storage retrieval procedure is documented in the team runbook with named owners, named entry points, and named wall-clock budgets for each retention class.
• [ ] Monthly retrieval drill is on the calendar, same week as the Lesson 174 monthly fatigue review, with a retrieval_drill_failure_log table for tracking failures.
• [ ] The partner reply template is pinned in docs/partner-reply-templates/archive-retrieval.md and matches the Lesson 170 FAQ-bound structure.
• [ ] At least one drill has been executed end-to-end with a SHA-256 mismatch deliberately injected to verify the failure-path logs correctly.

If any item is missing, fix it before December 2026. The off-cycle January 2027 auditor questions will not wait for the archive to come online.

What you have just earned

After this lesson, the team's relationship to its shipped packets changes. Packets older than 90 days are not "things we sent and forgot"; they are assets with content-addressed hashes, retention classes, retrieval SLAs, and rehearsed retrieval paths. When the January 2027 partner reviewer pulls a Q3 2026 packet and asks the inevitable "show me the dictionary row that backed metric M," the team has a 90-minute path from question to verified reply rather than a 48-hour scramble.

More importantly, the team has the language to discuss archive retention with partner reviewers in late 2026: retention class, SHA-256 verification, retrieval drill cadence, bucket-level object-lock, transition queue review. This is what mature governance looks like — and the team that runs it routinely is the team that turns off-cycle questions from a crisis into a known-bounded operational task.

Next lesson teaser

The next lesson (Lesson 176: Partner Reply Packet Versioning Against Archived Tuple Hashes (2026)) covers versioning partner reply PDFs and annexes against archived publish_tuple_hash rows. This Lesson 175 archive retrieval procedure gives the team a verified packet artifact to reply from; Lesson 176 versions the reply PDFs and annexes themselves so silent rewrites on comment rounds (the 2026 PDF toolchain default-to-optimistic-merge failure mode) cannot drift the reply away from the archive's pinned publish_tuple_hash. Without 176, retrieval is honest but replies can still silently change in the partner's review tool; with 176, both sides of the conversation are tuple-bound.

After Lesson 176, the queue extends through Lessons 177-181 (dictionary minor-increment migration without breaking the Lesson 164 bind contract, carved-back deficiency quorum + evidence rebind workflow, multi-region reviewer feedback ingestion across US/EU/Asia handoff weeks, AI-assisted governance packet red-team prompts with human sign-off gate, and Q1 2027 cert-intake rehearsal calendar export from the Lesson 172 rubric JSON).

Continuity

• Paired Unity guide chapter (next Guide-Create pass will author): Unity 6.6 LTS OpenXR governance WORM-style archived submission packet retention and cold-storage retrieval drill preflight - editor-side Governance/Packet Archive Pointer ScriptableObject group mirroring the SQL table with eight version-pinning fields, BI-side bind contract on the packet_archive_pointer table with database trigger invariant enforcement and bucket-level object-lock parity check, and the retrieval drill rehearsal block pinned in Governance/Retrieval Drill Log as a fail-closed monthly cadence gate.
• Help article: OpenXR Governance Partner SLA Snapshot vs Leadership Dashboard Rollup Mismatch (Quest) Fix - the rollup mismatch failure mode upstream of the readback packets this lesson archives.
• Lesson 174 - Signer Route Fatigue Heat-Map, Backup Owner Promotion, and Escalation (2026) - the on-call routing for the retrieval owner role; backup-owner promotes in effect at retrieval time must be reflected on the reply packet's signer ack line.
• Lesson 173 - Mock Audit Deficiency Recurrence Trend Board and Sprint Hardening Budget (2026) - the trend-board cross-reference that informs vault promotion (any structural-red or hot touch on a packet's window forces vault classification regardless of age).
• Lesson 172 - Q3 2026 Submission Intake Mock Audit Tabletop Scoring Rubric (2026) - the rehearsal cadence pattern this lesson's monthly retrieval drill mirrors.
• Lesson 171 - Tuple Drift Automatic Block on Dashboard Publish Pipeline (2026) - the source of publish_tuple_hash + source_tuple_hash that bind every archive row to its upstream snapshot.
• Lesson 170 - Executive Readback Redlines Versus Partner Annex FAQ Discipline (2026) - the FAQ-bound readback structure the partner reply template extends.
• Lesson 169 - Freeze Lift Rehearsal Dry Run (2026) - the rehearsal discipline this lesson's retrieval drill applies to archive retrieval instead of freeze-lift.
• Lesson 167 - Synthetic Replay Diff Gate + Epsilon Policy (2026) - the epsilon_policy_version pin that lets retrieved packets be re-rendered with the original epsilon, not the current one.
• Lesson 165 - Footer Metadata Schema Versioning (2026) - the footer_schema_semver pin that makes deterministic regeneration mechanically possible.
• Lesson 164 - Leadership Partner SLA Dashboard Sync (2026) - the dictionary_semver pin that lets archive answers be sourced against the dictionary in effect at packet-ship time, not today's dictionary.

A WORM-enforced archive plus a monthly retrieval drill is the team's promise to its future self that the work it ships today will still be answerable in January 2027. Run the monthly drill, the weekly transition-queue review, and the storage-bucket object-lock verification quarterly, and off-cycle auditor questions become a 90-minute operational task instead of a launch-week crisis.