Overlap Exception Register¶
Register ledger — instantiates Overlap Exclusion Design
A durable ledger that names, labels, and dates every sanctioned or known overlap, so an accepted exception stays explicit and reviewable instead of quietly hardening into ordinary membership.
Not every overlap can — or should — be eliminated; some are legitimate special cases that must be allowed on the record. Overlap Exception Register is the durable ledger where each such case is written down: which element is shared, between which collections, under what label, on whose authority, and until when. Its defining purpose is memory and accountability, not action. It does not detect overlaps, move elements, or fix anything; it ensures that every sanctioned or tolerated overlap remains an explicit, attributed, reviewable entry rather than an unexamined fact of the system. Its whole value is that a documented exception cannot silently decay into an ordinary, forgotten membership.
Example¶
A health insurer normally keeps its coverage pools disjoint — a claim is paid from exactly one pool so reserves and reporting stay clean. But some claims legitimately straddle two pools: a work-related injury that also involves a chronic pre-existing condition genuinely belongs, in part, to both. Rather than let adjusters quietly split such claims off the books, the insurer keeps an Overlap Exception Register. Each cross-pool claim is entered with a label ("coordination-of-benefits exception"), the two pools it spans, the rule that permits it, the approver, and a review date.
Months later, an actuary reconciling reserves does not have to guess why two pools share members: the register lists every sanctioned overlap, labeled and dated, and states what the disjointness guarantee still supports elsewhere. The exceptions are visible, bounded, and up for review — not a hidden erosion of the invariant.[1]
How it works¶
- Record on entry — when an overlap is sanctioned or discovered-and-tolerated, log the shared element, the collections, the permitting rule, the approver, and a review-by date.
- Label by type — apply a controlled vocabulary of exception categories so entries can be counted, filtered, and reasoned about, not just read.
- Keep the history — the register is append-mostly: superseded entries are retained so the trail of what was allowed, when, and by whom is reconstructable.
- Publish the standing set — expose the current live exceptions so downstream consumers know exactly where the clean guarantee has holes.
Tuning parameters¶
- Label taxonomy granularity — how many distinct exception categories exist. Fine labels support precise analysis but burden the person filing an entry; coarse labels are easy but blur why an overlap was allowed.
- Review cadence — how often standing exceptions must be re-justified or they expire. Short cadences prevent quiet permanence but add churn.
- Approval bar — who may sanction an exception and at what level; a higher bar keeps the register small but slows legitimate special cases.
- Retention depth — how much superseded history is kept; deeper history aids audit but grows the ledger.
When it helps, and when it misleads¶
Its strength is converting the ungoverned exception — the one everybody "just knows about" — into an owned, expiring, countable record, which is what keeps a disjointness guarantee honest about its own holes. It is the antidote to boundary cases that get handled informally and then treated as normal. Its weakness is that a register only records; it neither limits how many exceptions accumulate nor fixes any of them, so a neglected register can become a long list of permanent overlaps wearing the costume of "temporary." The classic misuse is logging exceptions and never reviewing them, so the ledger legitimizes drift instead of bounding it. The guarding discipline is a real expiry-and-review cycle, so entries must be re-earned rather than merely remembered.
How it implements the components¶
exception_labeling_rule— it applies a controlled vocabulary that names and categorizes each sanctioned overlap, so exceptions are typed rather than ad hoc.membership_change_log— it is the durable, attributed history of which overlaps were allowed, when, and by whom.downstream_use_boundary— by publishing the standing exception set it tells consumers exactly where the disjointness guarantee holds and where it is knowingly relaxed.
It does not apply a boundary policy to pull contested elements out, drive them along a remediation path, or reassign them under an authority — boundary_case_policy, overlap_remediation_path, and assignment_authority belong to Quarantine and Reassignment Queue, which acts on overlaps while this register only records the ones that are allowed to stand.
Related¶
- Instantiates: Overlap Exclusion Design — governs the sanctioned exceptions to the no-overlap invariant so they stay explicit.
- Consumes: Quarantine and Reassignment Queue — its adjudications of contested cases feed the sanctioned exceptions this register records.
- Compare: Exception Register — this register logs sanctioned set-overlaps against a disjointness invariant, whereas that general exception register logs waivers of a guardrail or threshold together with their compensating controls.
- Sibling mechanisms: Holdout Leakage Test · Mutual-Exclusion Constraint · Namespace Collision Scan · Overlap Matrix · Pairwise Intersection Audit · Quarantine and Reassignment Queue · Segregation-of-Duties Check · Single-Assignment Workflow · State Exclusivity Table
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Overlap Exception Register operates as a persistent ledger, log, register, or case record that preserves history and traceability because it a durable ledger that names, labels, and dates every sanctioned or known overlap, so an accepted exception stays explicit and reviewable instead of quietly hardening into ordinary membership.
Independent corroboration: The frozen evidence defines Overlap Exception Register as 'A durable ledger that names, labels, and dates every sanctioned or known overlap, so an accepted exception stays explicit and reviewable instead of quietly hardening into ordinary membership', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Law & Governance
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: A dated register of sanctioned exceptions follows legal and compliance practice for making departures explicit and reviewable.
Related originating lineages:
- Organizational & Management Science — Overlap Exception Register is most directly rooted in organizational and management science's practice of coordinating people, authority, strategy, knowledge, and work. The lineage fits its defining practice: A durable ledger that names, labels, and dates every sanctioned or known overlap, so an accepted exception stays explicit and reviewable instead of quietly hardening into ordinary membership.
Review resolution: Authoritative-source research resolves the primary-origin disagreement in favor of law governance. Document Drafting Handbook — Office of the Federal Register documents the formative practice or theory represented here. The retained alternate domains identify material co-development or translation, while current applicability is recorded separately as domain_reach=multi_domain; origin_mode=convergent describes the historical relationship among lineages.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
References¶
[1] U.S. General Services Administration. Section 508 Exceptions Request and Approval Process (2025). Requires documented, time-bounded exceptions with regular reassessment. registry ↩