Actuarial Validation & Filing Automation

WORM Storage Patterns for Regulatory Retention

WORM storage — write-once-read-many — keeps filing evidence in a medium that accepts an object once and then refuses to overwrite or delete it until a retention date has passed, so that an actuarial memorandum, a sealed reserve run, or an audit-chain anchor cannot be quietly removed inside the years-long window an examiner may reach across. This page implements the object-lock and legal-hold patterns that enforce that guarantee, and it sits within the Actuarial Audit Trail Architecture discipline as the durability counterpart to the integrity mechanism described in Hash-Chaining Audit Logs for Actuarial Filings.

The Problem

A hash chain proves that filing evidence was not altered, but it says nothing about whether the evidence still exists. An operator with delete rights, a mis-scoped lifecycle rule, or a ransomware process can erase the very records a regulator expects to inspect, and no amount of cryptographic linkage recovers bytes that are gone. Retention regimes assume the opposite: that once a reserve filing or supporting workpaper is committed, it remains retrievable for a fixed number of years regardless of who later wishes it were not. WORM storage is how that assumption is made physically true rather than merely policy. The pattern is to seal each piece of evidence into an object carrying an explicit retain-until date under a lock mode that even a root administrator cannot shorten, and to layer an indefinite legal hold on top for records under active examination. The distinction from the chaining approach matters: chaining answers “was this changed”, WORM answers “can this be destroyed”, and a defensible retention posture needs both.

A Minimal Working Example

The following seals an evidence object into an object-lock store, records its retain-until date, and refuses any deletion attempted before that date arrives. It models the S3 Object Lock compliance-mode contract but keeps the store abstract so the logic is testable without a cloud account:

from __future__ import annotations

from dataclasses import dataclass
from datetime import datetime, timedelta, timezone


class RetentionError(Exception):
    """Raised when a WORM policy forbids a mutation."""


@dataclass(frozen=True)
class SealedEvidence:
    object_key: str
    body: bytes
    retain_until_utc: datetime      # compliance-mode retention boundary
    legal_hold: bool                # indefinite, independent of the date
    sealed_at_utc: datetime


class WormStore:
    """A compliance-mode object store: no early delete, no shortening."""

    def __init__(self) -> None:
        self._objects: dict[str, SealedEvidence] = {}

    def put_sealed(self, object_key: str, body: bytes,
                   retention_years: int, legal_hold: bool = False) -> SealedEvidence:
        if object_key in self._objects:
            raise RetentionError(f"{object_key!r} already sealed; WORM is write-once")
        now = datetime.now(timezone.utc)
        obj = SealedEvidence(
            object_key=object_key,
            body=body,
            retain_until_utc=now + timedelta(days=365 * retention_years),
            legal_hold=legal_hold,
            sealed_at_utc=now,
        )
        self._objects[object_key] = obj
        return obj

    def set_legal_hold(self, object_key: str, active: bool) -> None:
        obj = self._objects[object_key]
        # A hold may be toggled; the retention date may never be shortened.
        self._objects[object_key] = SealedEvidence(
            obj.object_key, obj.body, obj.retain_until_utc, active, obj.sealed_at_utc)

    def delete(self, object_key: str) -> None:
        obj = self._objects[object_key]
        now = datetime.now(timezone.utc)
        if obj.legal_hold:
            raise RetentionError(f"{object_key!r} under legal hold; deletion refused")
        if now < obj.retain_until_utc:
            remaining = (obj.retain_until_utc - now).days
            raise RetentionError(
                f"{object_key!r} retained {remaining} more days; deletion refused")
        del self._objects[object_key]


if __name__ == "__main__":
    store = WormStore()
    store.put_sealed("filings/2025Q2/vm31_memorandum.pdf",
                     body=b"...sealed actuarial memorandum...",
                     retention_years=7)
    try:
        store.delete("filings/2025Q2/vm31_memorandum.pdf")
    except RetentionError as exc:
        print("blocked ->", exc)     # retained ~2555 more days; deletion refused
WORM retention flow: seal evidence, lock with a retention date, refuse early deletion, then tier to cold A sealed evidence object is placed under object-lock compliance mode carrying a retain-until date. A deletion attempted before the date is refused; once the retention window elapses and no legal hold is set, a lifecycle rule tiers the object to cold storage. A legal hold sits beneath and can override the retention window, extending it indefinitely. Seal evidence body + retain-until write-once Object Lock compliance mode date cannot shorten Retention window early delete refused Tier to cold lifecycle rule after retention Legal hold overrides the date
Evidence is sealed once, locked with a retain-until date that cannot be shortened, and only tiered to cold storage after the window elapses — unless a legal hold extends it.

How It Works, Block by Block

put_sealed enforces the write-once half of WORM. A second write to an existing key raises rather than overwriting, mirroring how a compliance-mode object refuses to accept a new version that would supersede the sealed one. The retain-until date is computed from the ingest moment plus the mandated retention span, so the boundary is fixed at the instant of sealing and travels with the object rather than living in an external policy table that could be edited independently.

Compliance mode is the property that makes the lock meaningful. In S3 Object Lock terms there are two modes: governance mode, which privileged users can bypass, and compliance mode, which no one — not the account root, not the storage vendor — can shorten or override until the date passes. The WormStore models compliance mode: set_legal_hold may toggle a hold, but there is deliberately no method to move retain_until_utc earlier. That asymmetry is the whole point; a retention control an administrator can quietly relax is not a control a regulator will credit.

delete checks the legal hold before the date. A legal hold outranks the retention clock: an object under hold cannot be deleted even after its retain-until date has passed, because active litigation or examination can require evidence to persist beyond its ordinary schedule. Only when no hold is set and the retention window has fully elapsed does the delete succeed. This is the same precedence a filing team relies on when Assembling Examiner-Ready Filing Packages, where a package under review must be pinned in place until the reviewer releases it.

The legal hold is independent of the retention span. Because the hold is a boolean toggled separately from the date, it can be applied to an object already years into its retention life and lifted once the matter closes, without disturbing the underlying schedule. When the hold clears, the ordinary retain-until date resumes governing the object, so an evidence item does not accidentally become deletable the moment a hold is released if its original window has not yet expired.

Edge Cases and Production Hardening

Clock and retention drift can expire an object early. The retain-until date is only as trustworthy as the clock that set it and the clock that checks it. If the sealing host’s clock ran fast, the stored boundary is earlier than intended; if a deletion worker’s clock runs fast, it may judge a still-protected object as expired. Compute retention against an authoritative time source and never against a client-supplied timestamp:

def retain_until(sealed_at_utc: datetime, retention_years: int) -> datetime:
    if sealed_at_utc.tzinfo is None:
        raise RetentionError("sealed_at must be timezone-aware UTC")
    # Add whole years defensively rather than 365-day blocks across leap years.
    return sealed_at_utc.replace(year=sealed_at_utc.year + retention_years)

Server-side object-lock enforcement removes the client clock from the trust path entirely; the store itself, not the application, decides whether the window has elapsed.

Retention versus legal hold precedence must fail safe. The dangerous ordering is checking the date first and short-circuiting a delete before the hold is ever evaluated. If the code returns “expired, delete allowed” without consulting the hold, an object under active examination is destroyed. Evaluate the hold as an unconditional veto — as the example does, hold before date — so that no code path can reach a deletion while a hold is set, regardless of how far past the retention date the object is.

Lifecycle-to-cold-storage must preserve the lock, not drop it. Tiering a sealed object to a colder, cheaper storage class after its active period is sound cost management, but a lifecycle rule that transitions an object must carry the object-lock retention with it; a rule that instead expires or replaces the object silently defeats the whole guarantee. Scope lifecycle transitions to change only the storage class, keep expiration actions off any prefix holding locked evidence, and verify after migration that the retain-until date and any hold survived the move — ideally by re-reading the object’s lock status and reconciling it against the Actuarial Audit Trail Architecture record that first sealed it.

Compliance Note

Record-retention duties are what give WORM storage its regulatory teeth. NAIC model laws and the annual-statement framework oblige insurers to retain the workpapers and actuarial support behind a filing for multiple years and to produce them on examination, and OSFI’s E-23 guideline on model risk management expects that model documentation, validation evidence, and the records underpinning a model’s use are maintained and available for supervisory review across the model’s lifecycle. A compliance-mode object with a retain-until date and an override-only legal hold operationalizes those duties: the evidence cannot be destroyed on schedule-shortening whim, and it can be pinned indefinitely when an examination demands. This is a different guarantee from the one Hash-Chaining Audit Logs for Actuarial Filings provides — chaining defends against silent alteration, WORM defends against destruction — and a retention posture within the wider Regulatory Architecture & Compliance Mapping discipline needs both working together: hash the evidence to prove it is unchanged, then seal it in WORM so it survives to be checked.

Frequently Asked Questions

How does WORM storage differ from a hash-chained audit log?

They answer different questions. A hash chain proves that a record was not altered by binding each entry to its predecessor’s digest, but it does nothing to stop the record being deleted. WORM storage proves a record cannot be destroyed before its retention date by refusing early deletion at the storage layer. A defensible archive uses both: chaining for integrity, WORM for durability.

What is the difference between governance mode and compliance mode object lock?

Governance mode lets sufficiently privileged users bypass or shorten the retention setting, which is useful for correcting mistakes but weak as a regulatory control. Compliance mode allows no one, including the account root and the storage provider, to shorten or remove the retention before the date passes. Filing evidence that a regulator may inspect should be sealed in compliance mode.

Yes. A legal hold is an independent, indefinite overlay that can be applied and later lifted as an examination or litigation opens and closes. Removing the hold does not delete the object; the original retain-until date resumes governing it, so the evidence remains protected until its ordinary retention window has also elapsed.

How do you keep a retention date from expiring evidence early?

Compute the retain-until date against an authoritative time source at the moment of sealing, never against a client-supplied timestamp, and let the storage layer itself enforce the window rather than trusting an application clock. Server-side object-lock enforcement takes the deletion worker’s local clock out of the trust path entirely.

Up a level: Actuarial Audit Trail Architecture · Regulatory Architecture & Compliance Mapping

Regulatory references: NAIC Model Audit Rule and record-retention framework; OSFI Guideline E-23 (Model Risk Management).