---
slug: zombie_validity
name: Zombie Validity
one_liner: "An entity formally declared no-longer-valid that nonetheless continues to be relied upon in practice — the reliance-persists-past-invalidation pole of the axis whose opposite is a validity-ending event's clean stop of reliance."
type: prime
schema_version: 2
status: density_v2_draft
categories: [systemic, social, epistemic]
origin_domain: governance_and_administration
alternate_origin_domains: [software_and_systems, law_and_regulation, information_and_records]
aliases: [zombie_reliance, invalidated_but_live, stale_authority, dead_but_load_bearing]
related: []
solution_archetypes: []
review_flags:
- "OPERATOR-DERIVED (op-01 dualization, sub-flavor 1c) — the dual of `validity_ending_event` along the does-reliance-actually-stop axis: a validity-ending event assumes the declared-invalid entity stops being acted upon; its 1c dual is the case where formal invalidation fires but downstream reliance persists (a 'zombie'). Discovered in the op-01 full sweep 2026-07-03. Verified absent via search_prime + slug check; no existing zombie/stale-reliance prime, but NOVEL COINAGE — needs literature check (see Notes). STATUS: HOLD — pending owner curation."
- "Created 2026-07-03; STUB ONLY (frontmatter + Core Idea + Notes). Did NOT go through Phase-A triage. SI/SF/similarity grades are PROPOSER ESTIMATES pending triangulation. Body sections (Structural Signature onward) NOT yet written."
- "Phase-C action: literature-check the coinage (does an established name exist for 'formally-invalid-but-still-relied-upon' — e.g. zombie systems, stale references, deprecated-but-in-use, dangling references?) and re-similarity check vs `validity_ending_event`, `technical_debt`, `stale_state`/`cache_invalidation`, `legacy` and `path_dependence`. If kept, draw the sibling edge to `validity_ending_event` and the parent edge to the mismatch/decoupling genus at incorporation. one_liner must be synced to a v1 draft per CLAUDE.md before merge."
substrate_independence:
  composite_substrate_independence: 3
  domain_breadth: 4
  structural_abstraction: 4
  transfer_evidence: 2
  reasoning: 'The structure — a formal state has flipped to invalidated while the operative behavior that depends on it has not — is a medium-neutral decoupling of *declared status* from *actual reliance*, so structural abstraction is a 4. It plausibly recurs broadly: expired certificates still trusted, deprecated APIs still called, revoked laws still enforced by habit, retracted papers still cited, cancelled policies still shaping behavior — domain breadth 4. But it is a NOVEL COINAGE, so the transfer evidence is soft: the instances are real but the cross-domain identification has not been done or vetted, and some cases may be better filed under technical_debt / stale_state / path_dependence, so transfer_evidence is a candid 2 and composite 3. Honest read: a promising decoupling structure whose independence from neighboring primes is unproven.'
similarity_to_nearest_existing_prime:
  slug: validity_ending_event
  similarity: 0.55
structural_framed:
  label: mixed-framed
  aggregate: 0.52
  criteria: {vocab_travels: 0.3, evaluative_weight: 0.6, institutional_origin: 0.6, human_practice_bound: 0.5, import_vs_recognize: 0.4}
  rationale: 'The bare relation — declared-status decoupled from actual-reliance — is structural, but the prime as posed leans framed: "validity", "authority", "in-force", "revoked" are institution-originated notions (regulators, maintainers, courts issue invalidations), and the pattern carries evaluative weight (a zombie is treated as a *failure mode*, a thing that ought to have stopped and did not). Much of its bite depends on human/institutional practices of declaring and honoring validity. It reads mixed-framed: a real decoupling structure but heavily clothed in governance/normative vocabulary, and Kurt should judge whether the structural core survives de-framing.'
phase_b_passes_completed: []
---
# Zombie Validity

## Core Idea

Zombie validity is the structure in which *an entity has been formally declared no longer valid, yet continues to be relied upon in practice*. It is the dual of `validity_ending_event` along a single axis — *whether the declared invalidation actually stops the reliance it was meant to stop*. A validity-ending event is the discrete, dateable moment at which some in-force entity (a certificate, a rule, a record, a version) is officially moved to the *invalidated* state; the pattern as normally told assumes the invalidation *takes* — the thing is henceforth retained for the record but no longer acted upon. Zombie validity occupies the opposite pole: the expiry machinery fires correctly — there is an authority, a triggering condition, a notice, an effective date — and yet the operative behavior downstream *does not update*. The entity is dead by declaration and alive by use: formally invalid, functionally load-bearing.

The load-bearing invariant is a *decoupling between declared status and actual reliance*. Two clocks that a validity-ending event implicitly assumes stay coupled come apart: the **status clock** (what the record/system officially says the entity is) has advanced to *invalid*, while the **reliance clock** (what actors, processes, or systems actually do) still treats it as *in-force*. The gap between them is the zombie. This requires three things to coexist: a *completed invalidation* (the status genuinely flipped — this is not a case of forgetting to expire something), a *persisting dependency* (something downstream still reads, trusts, cites, enforces, or calls the invalidated entity), and *no propagation of the status change to that dependency* (the invalidation was never plumbed through to where reliance actually happens, whether from oversight, cost, habit, cached state, or deliberate foot-dragging). The characteristic payoff of tolerating a zombie is *continuity*: things keep working without the disruption of chasing down every dependency at the moment of invalidation. The characteristic cost is *silent illegitimacy and latent failure*: decisions and outputs are being generated from an authority the system itself has already disowned, so the reliance is unbacked, auditably wrong, and liable to break — or to be exploited — exactly when the discrepancy is finally noticed or enforced.

Read as one pattern, the same object recurs wherever *invalidation is declared centrally but reliance is distributed*. In **software and systems**, an expired or revoked TLS certificate still trusted by clients that skipped the revocation check, a deprecated API still being called by live services, a cache still serving state whose source-of-truth has changed, a dangling reference to freed memory — each is a status-flipped, still-relied-upon entity (the literal "zombie" of "zombie process"). In **law and regulation**, a repealed statute still enforced by habit or a revoked license still honored by a counterparty who never got the notice. In **information and records**, a retracted paper that continues to be cited as valid, or a superseded standard still followed in the field. Across all of them the recognizable move is the decoupling: the declaration of invalidity did its job on the status clock and failed to reach the reliance clock, leaving a thing that is, in the system's own terms, both dead and depended upon.

## Notes

**Provenance.** Produced by op-01 dualization, sub-flavor 1c, as the dual of `validity_ending_event` along the *does-reliance-actually-stop* axis. The input prime models a clean invalidation (entity moves to *invalidated*, retained but not acted upon); the 1c dual is the case where the invalidation fires but downstream reliance persists — a formally-invalidated entity still load-bearing in practice ("zombie systems"). Single-route proposal in the sweep; no independent convergence.

**For owner evaluation (keep/cut).** The case FOR: this names a genuine and important *structural decoupling* — declared status vs. actual reliance coming apart — that is not the same object as `validity_ending_event` (that prime is about the clean stop; this is about the stop failing to propagate), and it has a real, recurring, cross-domain footprint (revocation-checking failures, deprecation debt, retracted-but-cited papers, repealed-but-enforced rules). If genuine, it plausibly completes a pair with `validity_ending_event` and fills a real systems/governance failure-mode gap. The RISKS behind the HOLD: (1) **NOVEL COINAGE — needs literature check.** "Zombie validity" appears to be a coinage; before adopting it, confirm whether an established term already covers "formally-invalid-but-still-relied-upon" (candidates to check: *zombie process/object* in systems, *stale reference*, *dangling reference*, *deprecated-but-in-use*, *stale cache*, *decertification lag*). If a standard name exists, prefer it; if genuinely no name exists, that is a point in favor of coining one — but it must be a deliberate choice, not an accident. (2) **Screen-overlap risk with neighbors** — the pattern may fragment into, or be dominated by, existing primes: `technical_debt` (deferred cost of not updating), `stale_state`/`cache_invalidation` (systems form), `path_dependence`/`legacy` (why the old thing persists), or a general *map–territory / declared-vs-actual mismatch* prime. The distinctive residue — *invalidation completed AND reliance persisting AND status-change unpropagated* — needs to be shown to survive after those neighbors take their share. (3) **Framed-not-structural risk** — as posed it leans on institutional validity vocabulary (authority, in-force, revoked, notice); Kurt should judge whether a de-framed core (status/reliance decoupling) is what we want, with governance as one instance, rather than a governance prime with a structural veneer. (4) **Failure-mode vs. structure** — decide whether this is a *pattern* (a recognizable structure) or merely a *named bug* (the failure to do propagation), since the encyclopedia holds structures, not every way a structure can go wrong.

**At incorporation.** Do the coinage literature-check first; adopt an existing term if one is canonical. Re-run similarity against `validity_ending_event` (sibling/dual), `technical_debt`, `stale_state`/`cache_invalidation`, `path_dependence`, `legacy`, and any declared-vs-actual mismatch prime to confirm non-collapse. If it survives, draw the sibling edge to `validity_ending_event` along the reliance-propagation axis and a parent edge to the status/reliance-decoupling (or mismatch) genus. Then write the body sections (Structural Signature onward) and sync the final one_liner to a v1 draft per CLAUDE.md before merge.
