Skip to content

Long-Term Archive Stewardship

A data architect working at ecosystem scale eventually has to answer questions that span years rather than releases: "Can we restore the exact v1.2.1 vocabulary-mapping state from two years ago?"; "Is the archive retention policy aligned with Solvency II Article 44 record- keeping?"; "What happens to an archived model artifact when legal-hold is placed on its parent case?" The Long-Term Archive Steward (LTAS) persona, introduced in v1.5.0 stage 5, is the authority on all three questions.

This page is the data-architect-facing reference for LTAS. It covers the persona's Zachman cell, the POLARIS archive surface, the tar- manifest discipline that anchors bit-perfect restore, the four retention classes (hot / warm / cold / legal-hold), and the coordination with KGSE on bridge-symbol SemVer review.

The LTAS persona, in one paragraph

LTAS sits in the ENGINEER/WHEN cell of the Zachman matrix — the engineer row (implementation detail), the WHEN column (temporal discipline). The persona coordinates the POLARIS archive (the ice_ext model-storage subsystem) across the ecosystem: tar-manifest integrity on every push, retention-class declaration at push time, legal-hold registry enforcement, ice_ext model-storage integration contracts, and bit- perfect restore verification. LTAS is the liaison between IHL (innovation handoff, which triggers archive snapshots) and the ice_ext model-storage subsystem. Every LTAS deliverable cites the POLARIS archive_id, the manifest SHA-256, and the retention class.

For the full R.I.S.C.E.A.R. specification, see src/fcc/data/personas/long_term_archive_steward.yaml.

POLARIS, in one paragraph

POLARIS is the FCC ecosystem codename for the ice_ext model-storage adapter — the long-term archive of model-evolution artifacts. POLARIS — named for the North Star and its mythological role as constant mariner's guide — is the archive that must not drift. Downstream consumers (FCC, AOME, constellation verticals) import the stable bridge via fcc.archive.polaris_bridge (module-level home) or fcc.api.get_polaris_bridge() (aggregate). The mock fallback (PolarisMockBridge) activates automatically when the live ice_ext adapter is not importable, keeping tests and CI deterministic.

For the full origin reasoning, see the Codename Decoder entry on POLARIS.

The tar-manifest discipline

The core LTAS constraint is: every POLARIS push MUST have a signed tar- manifest with SHA-256 integrity. "Signed" here means detached signature, not inline — the manifest is a separate artifact co-located with the tarball. A typical archive push produces three files:

archive/
├── INV-0042_model_v1.2.1.tar
├── INV-0042_model_v1.2.1.tar.manifest.yaml
└── INV-0042_model_v1.2.1.tar.manifest.sig

The manifest YAML carries:

archive_id: INV-0042_model_v1.2.1
created_at: 2026-04-22T18:40:00Z
created_by: LTAS
retention_class: warm
sha256: 3c2f8a9e6b1d0c4a7f5b8e2d9c6f1a3e7b2d9f0c4e6a8b1d3f5c7a9e2b4d6f8a
size_bytes: 14_382_901
contents:
  - path: model.yaml
    sha256: a1b2c3...
    size_bytes: 12_480
  - path: dimensions.yaml
    sha256: d4e5f6...
    size_bytes: 8_192
  # ... more entries ...

The detached signature covers the manifest YAML. On restore, LTAS re-verifies the manifest signature, then re-computes each file's SHA-256 against the manifest entry, then re-computes the tarball-level SHA-256. Any mismatch is a tier_1 finding and blocks the restore.

The pattern is drawn from OAIS (Open Archival Information System) — ISO 14721 reference architecture — which LTAS's "role skills" spec names explicitly as a background requirement.

The four retention classes

LTAS's archive lifecycle has four retention classes. The class is declared at push time and cannot be changed retroactively without an owner-gated exception.

Hot

  • Use case. Recently created artifacts that are still actively referenced by other subsystems.
  • Storage tier. Primary object store with low-latency read.
  • Retention window. Typically 90 days (configurable per domain).
  • Cost profile. High storage cost, low retrieval cost.
  • Access pattern. Read-heavy, may be re-read dozens of times.

Warm

  • Use case. Artifacts that have aged out of hot but are still relevant to the current release window.
  • Storage tier. Secondary object store with moderate read latency.
  • Retention window. Typically 1 year.
  • Cost profile. Moderate storage cost, moderate retrieval cost.
  • Access pattern. Read-occasional, used for regression testing or cross-release comparisons.

Cold

  • Use case. Long-term retention for audit, compliance, or research.
  • Storage tier. Cold object store (Glacier-class) with multi-hour retrieval.
  • Retention window. 7 years (configurable per regulatory regime).
  • Cost profile. Low storage cost, high retrieval cost.
  • Access pattern. Read-rare, typically triggered by audit or legal request.
  • Use case. Artifacts subject to an active legal or regulatory hold.
  • Storage tier. Any tier; the class overrides normal lifecycle.
  • Retention window. Indefinite until hold is released.
  • Cost profile. Same as underlying tier.
  • Access pattern. Read-controlled; every access is logged against the hold ID.

The critical LTAS constraint: legal-hold archives cannot be deleted or overwritten until the hold is released. A push to an archive_id already under legal-hold is a tier_1 finding. An LTAS attempt to delete a legal-hold archive is a tier_1 governance violation.

The archive lifecycle

Under normal conditions an artifact flows: hot → warm → cold → retired. Legal-hold is orthogonal — it can be placed at any stage and freezes the artifact until released.

push → hot (90d) → warm (1y) → cold (7y) → retire
                     ↕
                legal-hold (indefinite)

The lifecycle transitions are policy-driven, not LTAS-driven. LTAS enforces the policy; it does not author the policy. The policy lives at src/fcc/data/governance/quality_gates.yaml under the retention- schedule section and is jointly owned by GCA and the CISO-level persona.

On each transition, LTAS re-verifies the manifest and re-records the archive_id under the new retention class. The manifest SHA-256 does not change; only the retention class annotation does.

Restore-test readiness

A restore that only works on paper isn't a restore. LTAS runs periodic restore-test drills against sampled archives:

  1. Pick a random archive_id from each retention class.
  2. Request a restore via the POLARIS bridge.
  3. Verify the tarball SHA-256 matches the manifest.
  4. Verify each contained file SHA-256 matches the manifest entry.
  5. Load the restored artifact into FCC and confirm it parses cleanly.

The drill frequency:

Class Drill frequency
Hot Weekly
Warm Monthly
Cold Quarterly
Legal-hold On placement + annually

A failed drill is a tier_1 finding. The failure mode is almost always either (a) a bit-rot issue in cold storage or (b) a manifest-signature drift after a key rotation. Both are recoverable but must be surfaced promptly.

ice_ext model-storage integration

ice_ext is the internal sibling repo that provides the live POLARIS adapter. The v1.4.x → v1.5.0 absorption arc closed all five outstanding STATUS.md §n asks between FCC and ice_ext, the most important of which — §4 — was the public-API elevation of the PolarisBridge symbol.

The ice_ext-side contract is tested by the model-storage contract tests at tests/contracts/test_polaris_bridge_contract.py. The contract covers:

  • push(archive_id, payload, retention_class, manifest) — accepts a well-formed push.
  • pull(archive_id) — returns the exact bytes pushed, verified against the manifest.
  • list(prefix) — enumerates archive IDs matching a prefix.
  • describe(archive_id) — returns the retention-class + SHA-256 + timestamp metadata.

Contract failures are tier_1 findings and block any FCC release that bumps the ice_ext dependency floor.

The PolarisMockBridge fallback

The mock bridge lives at src/fcc/plugins/v1_5_preview/polaris_bridge.py and implements the same protocol as the live bridge, backed by an in-memory dict. Its purpose is test + CI determinism — FCC's CI must run cleanly on a runner that has no access to the private ice_ext adapter.

The mock bridge is chosen automatically when the live adapter is not importable, via the get_polaris_bridge() sentinel factory. Data architects designing new integrations should default to the mock for development and test, then switch to the live adapter only when the deployment topology requires it.

Interaction with KGSE — the SemVer review

Every new archive-facing symbol promoted from preview to stable passes through the KGSE ↔ LTAS review. The protocol:

  1. KGSE drafts the promotion migration guide.
  2. LTAS reviews the archive-manifest implications — does the new symbol change the manifest schema? Does it affect restore semantics?
  3. If LTAS finds a retention-class concern (e.g., the new symbol requires a retention-class migration), the promotion is blocked.
  4. If LTAS approves, KGSE finalises the fcc.api.__all__ update.

The protocol is symmetric. When LTAS proposes a new retention class, KGSE reviews for SemVer compatibility against any downstream consumer that may rely on the four-class enum.

For the KGSE side of this protocol, see the companion Graph Serialization Elevation page.

Interaction with DAR

DAR (Decision Archaeologist) draws archive-manifest provenance from LTAS during pre-v1.0 decision reconstruction. Early FCC history is sparse on ADRs; the LTAS archive provides the manifest-level chronology that DAR can triangulate against event-stream and commit history. The interaction is upstream-to-DAR: LTAS supplies manifest provenance on request.

For the DAR side of this protocol, see Decision Archaeology.

Worked example — restoring a v1.2.1 vocabulary snapshot

Suppose a data architect needs to restore the exact state of the athenium_vocabulary_mappings.yaml file at v1.2.1, two years ago.

Step 1: Locate the archive_id. The archive_id schema is <project>_<artifact>_<version>. Here: athenium_vocab_v1.2.1. List against POLARIS:

from fcc.api import get_polaris_bridge

polaris = get_polaris_bridge()
results = polaris.list(prefix="athenium_vocab_v1.2")
# -> ["athenium_vocab_v1.2.0", "athenium_vocab_v1.2.1"]

Step 2: Describe the archive. 

meta = polaris.describe("athenium_vocab_v1.2.1")
# -> {"retention_class": "cold",
#     "sha256": "3c2f8a9e...",
#     "created_at": "2024-06-01T12:00:00Z"}

Step 3: Pull the payload. 

payload_bytes = polaris.pull("athenium_vocab_v1.2.1")

Step 4: Verify the manifest. Compute SHA-256 of payload_bytes. Compare against meta["sha256"]. If they match, the restore is bit-perfect.

Step 5: Unpack and use. The payload is a tarball. Extract, locate the target file, parse.

Every step is cited in the LTAS role_adoption_checklist. An auditor reviewing a restore operation should be able to replay the five steps from the archive access log.

Common LTAS findings

manifest_mismatch

Computed SHA-256 does not match the manifest entry. Severity tier_1. Remediation: investigate the storage tier for bit-rot; escalate to GCA if the archive is under legal-hold.

missing_manifest

Archive was pushed without a manifest. Severity tier_1. This is rare in practice because the push API requires the manifest; when it occurs it usually indicates an out-of-band push that bypassed the bridge. Remediation: quarantine the archive; re-push with a proper manifest or purge.

retention_class_drift

Archive's current retention class differs from the policy-driven expected class. Severity tier_2. Remediation: verify the lifecycle policy; if the policy changed, update the archive; if the archive drifted, re-apply the policy-driven class.

An attempt to delete or overwrite a legal-hold archive occurred. Severity tier_1 governance violation. Always an incident. Escalate immediately to GCA + owner.

restore_test_failure

A scheduled restore drill failed. Severity tier_1 if the archive is hot or warm; tier_2 for cold; always tier_1 for legal-hold. Remediation: root-cause the failure, fix the storage condition, re- schedule the drill.

Retention class mapping for regulatory regimes

Data architects working on regulated verticals can use this mapping as a starting point. (Every deployment must verify against counsel.)

Regulation Typical cold retention
Solvency II Art. 44 5 years from reporting
IFRS 17 7 years from contract close
BCBS 239 7 years
SR 11-7 (model risk) 7 years from model retirement
HIPAA 6 years from creation or last use
GDPR Art. 30 (records of processing) duration of processing + 6 months
DCAT-US indefinite (public record)

The FCC governance subsystem does not author the policy — it enforces whatever class is declared at push time. Data architects working on a vertical are responsible for choosing the correct class.

LTAS does NOT own

  • LTAS does NOT author the retention policy. GCA + CISO-level persona authors it; LTAS enforces.
  • LTAS does NOT create archive_ids. Owning subsystems do; LTAS accepts what is pushed.
  • LTAS does NOT operate the live adapter. ice_ext does.
  • LTAS does NOT decide on legal-hold placement. Legal + GCA do.

Keeping these lanes clean avoids the most common archive-ownership disputes.

Persona Direction Interaction
KGSE peer POLARIS bridge SemVer review
DAR downstream Supplies archive-manifest provenance for rationale reconstruction
IHL upstream Innovation handoffs trigger archive snapshots
FA downstream Retention-compliance findings in forensic audits
GCA downstream Retention + legal-hold compliance for governance sign-off

Next steps

  • Read the Graph Serialization Elevation page — KGSE is LTAS's closest peer and together they own the POLARIS bridge contract.
  • Read the Decision Archaeology page — DAR draws archive-manifest provenance from LTAS.
  • Consult the Codename Decoder for POLARIS origin reasoning and canonical links.
  • Read ADR-008 — POLARIS absorption for the framework-level archive-adoption rationale.
  • Open the LTAS persona YAML at src/fcc/data/personas/long_term_archive_steward.yaml for the authoritative R.I.S.C.E.A.R. spec.
  • Review docs/personas/evolution/ltas.md for the LTAS evolution guide.
  • Walk docs/tutorials/advanced-capabilities/polaris-archive-integration.md (Pool B) for a hands-on POLARIS bridge integration tutorial.
  • Browse docs/tutorials/sample-prompts/persona-ltas-prompts.md for ready-to-run archive-steward prompts.
  • Consult the Data Governance guide for how retention policy interacts with QG-DGS-001 data-flow audits.