Resolution Link Checker¶
Monitor — instantiates Persistent Identifier Stewardship
Continuously tests that tokens still resolve to meaningful current targets, flagging resolver rot before references silently decay.
Resolution Link Checker is the standing monitor that keeps a persistent-identifier system honest by testing its own promises: it periodically resolves the tokens under stewardship and checks that each still lands somewhere meaningful and current. Its defining trait is that it detects and reports, it does not repair — it surfaces dangling mappings, broken redirects, soft failures, and hijacked or wrong targets, then raises them so a steward or another mechanism can act. Persistence is a claim that decays silently: a token that quietly stopped resolving looks fine until someone follows it. This mechanism is the archetype's smoke detector — the thing that makes decay visible before a reference is lost for good.
Example¶
A law journal's citations lean heavily on persistent identifiers and archived URLs, and over years those targets rot: a hosting institution shuts down, a publisher's redirect breaks, an identifier that once resolved to an article now lands on a parked domain. The problem — link rot, and its quieter cousin reference rot, where the link resolves but the content has changed — is well documented in legal scholarship, and services like Harvard's Perma.cc exist to counter it.[1]
A resolution link checker crawls the journal's identifier set on a schedule and resolves each one, classifying the result: healthy, dangling (no target), soft-404 (resolves to a generic "not found" page returning a success code), redirect-loop, or content-changed. It does not fix anything; it produces a report — "these forty identifiers no longer resolve, these twelve resolve to something suspicious" — that routes broken cases to the redirect-and-tombstone policy or a steward for repair. The rot was always happening; the checker is what made it a work item instead of a silent loss.
How it works¶
The checker is a scheduled audit loop over the identifier population:
- Enumerate and resolve. Walk the set of tokens under stewardship and resolve each one, following redirects to their end.
- Apply health checks. Test more than the status code — detect soft-404s, redirect loops, hijacked or changed targets, and stale content, and verify that redirect and tombstone entries still land where they should.
- Classify and score. Bucket each token by failure mode and severity, distinguishing transient blips from real decay.
- Report and route. Emit alerts and a rot report for stewards, re-checking flapping cases before escalating. It surfaces the defect; it does not author the fix.
Tuning parameters¶
- Cadence — continuous versus periodic sweeps. Frequent checks catch rot early but load targets and risk being impolite to hosts.
- Depth — status-only, content-fingerprint, or semantic match against expected metadata. Deeper checks catch content rot but cost more and raise false positives.
- Soft-404 sensitivity — how aggressively to flag success-coded "not found" pages. Higher sensitivity catches silent failures but misfires on legitimate generic pages.
- Coverage — exhaustive versus sampled checking of very large identifier sets. Sampling scales; full coverage misses nothing.
- Alert threshold — how much rot, or how severe, before escalating. Tight thresholds catch problems early but risk alert fatigue.
When it helps, and when it misleads¶
Its strength is that it closes the archetype's "detect and repair" invariant: without a monitor, a persistence commitment is unfalsifiable, and rot accumulates invisibly until a citation is followed and found dead. The checker converts silent, gradual decay into an explicit, prioritized queue while repair is still cheap.
Its failure mode is false confidence. A target that returns a healthy status code can still be a hijacked page, a paywall stub, or the wrong content entirely — status looks fine, meaning is gone — so a status-only checker certifies rot as health. The opposite failure is alert fatigue, where too many low-value flags train stewards to ignore the report. The classic misuse is treating a 200 OK as proof of correct resolution. The discipline is to check content, not just reachability — compare against the entity's expected metadata as an informal sanity test — and to tune thresholds so that what surfaces is worth a steward's attention.
How it implements the components¶
Resolution Link Checker realizes the monitoring slice of the archetype — the parts that make decay visible:
resolution_integrity_monitor— it is this monitor: the scheduled, population-wide resolution-health check that detects broken, stale, ambiguous, or hijacked resolution.alias_redirect_and_tombstone_map— it does not author the map, but it maintains the map's integrity, verifying that every redirect still lands and every tombstone still explains, and flagging entries that have decayed.
It does NOT author redirects or apply the lifecycle_event_update_rule that decides a response to a withdrawal or move — that's Redirect and Tombstone Policy; the checker only detects that a response is needed and raises it, while the policy decides what that response should be.
Related¶
- Instantiates: Persistent Identifier Stewardship — the checker is the monitoring loop that keeps the persistence promise falsifiable.
- Consumes: Persistent Identifier Resolver Service — it resolves through the same service it audits, testing what real callers would receive.
- Sibling mechanisms: Persistent Identifier Resolver Service · Resolver Landing Page · Identifier Version Resolution Rule · Redirect and Tombstone Policy · Custodial Transfer Protocol · Identifier Registry · Identifier Minting Workflow
Editorial Notes¶
Form Classification¶
Form family: Monitoring, Sensing & Alerting
Rationale: Resolution Link Checker operates as ongoing observation, sensing, or alerting that detects and surfaces state without itself executing the response because it continuously tests that tokens still resolve to meaningful current targets, flagging resolver rot before references silently decay.
Independent corroboration: The frozen evidence defines Resolution Link Checker as 'Continuously tests that tokens still resolve to meaningful current targets, flagging resolver rot before references silently decay', so its operative form is Monitoring, Sensing & Alerting.
Nearest alternative: Assessment, Review & Assurance — Resolution Link Checker includes features of a bounded evaluation of existing evidence or work that produces a finding or disposition, but its defining operation is ongoing observation, sensing, or alerting that detects and surfaces state without itself executing the response.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Automated extraction and dereferencing of links and fragments to detect broken targets is a Web-maintenance tool; persistent-reference stewardship supplies the information-science application.
Related originating lineages:
- Library & Information Science — library_information_science contributes classification, provenance, access, and persistent-reference stewardship to the mechanism’s formative or independently convergent form; that contribution does not displace the primary computer_science lineage.
Review resolution: The blind reviewers disagreed on primary lineage; authoritative research supports computer_science over the competing primary. Automated extraction and dereferencing of links and fragments to detect broken targets is a Web-maintenance tool; persistent-reference stewardship supplies the information-science application. The cited W3C Validators and Link Checker provides direct evidence for that defining form. Alternates are retained only where they contributed an independent formative tradition, while domain_reach=multi_domain records later transfer separately from historical origin.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
References¶
[1] Zittrain, J. L., Albert, K., and Lessig, L. "Perma: Scoping and Addressing the Problem of Link and Reference Rot in Legal Citations". Harvard Law Review Forum 127, 176–199 (2014). Documents link and reference rot in legal citations and describes Perma as preserving records against both failure modes. registry ↩