Stale Edge Expiration¶
Protocol — instantiates Graph Pruning
Gives every temporary connection an expiration date so it lapses automatically unless someone actively renews it with fresh justification.
Stale Edge Expiration attaches an expiration date to every temporary connection so that it lapses by default unless someone actively renews it with fresh justification. Its defining idea is inverting the default: continued connectivity must be re-earned on a clock, rather than persisting as the residue of a past decision. There is no review meeting and no human weighing each tie — the mechanism is a policy plus a timer, with a grace window that warns before the lapse and monitoring on renewal rates. This is what makes it a protocol rather than a judgment: the removal is automatic, and the only way an edge survives is that someone chose, on the record, to keep it.
Example¶
A company's data warehouse hands analysts access to sensitive datasets for specific projects. Historically those grants never expired, so thousands of stale entitlements accumulated — access to data for projects that ended years ago. Stale Edge Expiration attaches a 90-day expiration policy to every project grant. At day 76 the holder gets an automated renewal prompt asking them to re-justify the access; this grace window is when a still-needed grant is saved. If no renewal with justification arrives, the grant auto-revokes at day 90.
The platform monitors renewal-versus-lapse rates and any access-denied errors that spike after expirations, using them to tune the window length. The effect is that standing dataset access stays proportional to active need without anyone convening a review: an analyst who still needs the data renews in one step, and an analyst who has moved on simply lets it lapse. The graph cannot silently regrow, because every edge that persists past 90 days is one someone deliberately renewed.
How it works¶
- Attach an expiration policy per edge type. Each temporary connection carries a time-to-live appropriate to its kind — a permission, a subscription, a temporary agreement.
- Warn in a grace window. Before the lapse, an automated prompt asks the holder to renew with justification; this staged window is the one chance to save a still-needed edge.
- Lapse by default. With no renewal, the edge is automatically removed or restricted — the default action is removal, not retention.
- Monitor renewal behavior. Track renewal-versus-lapse rates and post-expiration errors to tune windows and catch edges that lapsed but shouldn't have.
Tuning parameters¶
- Time-to-live per edge type — how long each kind of connection lives before expiring. Too short churns and annoys; too long defeats the purpose.
- Grace-window length and reminders — how much warning precedes the lapse. Longer, better-reminded windows reduce accidental expiry of critical edges.
- Renewal friction — one-click renewal vs a required fresh justification. Low friction avoids fatigue but invites reflexive renewal; high friction forces real re-justification but risks losing edges to inertia.
- Lapse action — full auto-removal vs auto-restriction. Restriction is gentler and more reversible than deletion.
When it helps, and when it misleads¶
Its strength is preventing regrowth at the source: by making continued connectivity a deliberate, renewable claim rather than a permanent residue, it stops the graph from silently re-accreting the sprawl a one-time cleanup removed. It works like a lease — a time-bounded grant[1] that dies unless renewed — applied to any edge that should not outlive its justification.
Its failure modes sit at both ends of the friction dial. Renewal fatigue turns re-justification into reflexive clicking, so accretion returns under a veneer of process; and a critical long-lived edge can lapse because its owner missed the prompt, causing an expiry-driven outage of something that should never have expired on a generic timer. A uniform time-to-live across edge types that need genuinely different lifetimes guarantees one of these failures. The guarding discipline is to right-size the time-to-live per edge type and to exempt designated must-persist edges from the generic clock — so the timer prunes the transient without threatening the permanent.
How it implements the components¶
edge_expiration_policy— the per-edge-type time-to-live that makes lapse the default; this mechanism's signature.staged_removal_window— the pre-lapse grace period with renewal prompts, the one chance to save a still-needed edge before it goes.pruning_rule— the automatic removal-or-restriction that fires when no renewal arrives.monitoring_signal— the renewal-versus-lapse tracking and post-expiration error watch that tunes the policy.
It does not implement exception_edge, edge_criteria, or accountable_pruning_owner — case-by-case retention of weak-but-valuable ties, merit-based value criteria, and a human owner who judges each connection belong to Relationship Cleanup Review; this protocol expires edges on a clock rather than judging them on the merits.
Related¶
- Instantiates: Graph Pruning — expiration is lifecycle governance that prevents graph regrowth by default.
- Sibling mechanisms: Relationship Cleanup Review · Access Revocation Pass · Least-Privilege Review · Channel Consolidation · Unsubscribe / Filtering · Dependency Pruning Workflow · Integration Decommissioning Runbook · Link Decommissioning Plan · Graph Sparsification Pass
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Stale Edge Expiration operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it gives every temporary connection an expiration date so it lapses automatically unless someone actively renews it with fresh justification.
Independent corroboration: The frozen evidence defines Stale Edge Expiration as 'Gives every temporary connection an expiration date so it lapses automatically unless someone actively renews it with fresh justification', so its operative form is Control, Automation & Runtime.
Nearest alternative: Rule, Policy & Commitment — Stale Edge Expiration includes features of a standing rule, threshold, contractual commitment, or policy constraint governing future conduct, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: Time-limited graph links are lease and TTL design.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: gives every temporary connection an expiration date so it lapses automatically unless someone actively renews it with fresh justification.
- Law & Governance — Fresh justification legitimizes continued connection.
- Organizational & Management Science — Relationships require active renewal.
Review resolution: The blind reviewers agree that computer_science is the primary origin and differ only on alternate origin disagreement, origin mode disagreement, domain reach disagreement, encyclopedia synthesis disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain convergent because the combined evidence shows independent disciplinary development. The broader reach of universal records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Gray, Cary G.; Cheriton, David R.. "Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency". Proceedings of the Twelfth ACM Symposium on Operating Systems Principles 202–210 (1989). Defines a lease as a grant of specified rights for a limited term that must be extended after expiry. registry ↩