Overlap Transition Table¶
Registry table — instantiates Local-Chart Atlas Modeling
Enumerates every overlapping chart pair as a row — the shared cases, the invariants that must survive the crossing, and the seams still unresolved.
The Overlap Transition Table is the seam ledger of an atlas: one row per pair of charts that overlap, recording where they overlap, what must be preserved when a case moves between them, and which seam questions are still open. It is a documentation artifact, not a machine — its unit is the chart-pair, and its value is completeness: every place two local views touch has an entry, so no seam is left implicit. Its defining move is to make the overlaps of the atlas enumerable and inspectable — you can read down the table and see, at a glance, which pairs agree cleanly, which need translation, and which are flagged as unresolved holes. It records the seam; it does not perform the crossing and it does not run the test that would close an open row.
Example¶
A company runs a customer relationship system (CRM) and a finance/ERP system, each a locally-valid chart with its own vocabulary — "account" means a sales relationship in one and a general-ledger entity in the other; a "closed" opportunity in the CRM is not a "posted" invoice in the ERP. Rather than pretend one schema covers both, the integration team builds an Overlap Transition Table. Each row names a pair of overlapping objects (CRM Account ↔ ERP Customer, CRM Opportunity ↔ ERP Sales Order), the shared cases where both systems hold the same real-world entity, the invariants that must survive any sync (a customer's legal identity and tax ID; the total contract value must not change), and the unresolved seams flagged in red — for example, that a split-billing customer maps to two ERP records with no agreed rule yet.
When a reconciliation later goes wrong — revenue double-counted for one customer — the team does not spelunk through code; they open the table, find the split-billing row already marked as an unresolved hole, and know exactly which seam to fix. The table did not prevent the crossing from being lossy; it made the loss predicted and locatable instead of a surprise.
How it works¶
- One row per overlapping pair. Every pair of charts whose domains intersect gets an entry; pairs that never overlap are deliberately absent.
- Columns for the seam's anatomy. Overlap criterion (when both charts apply), the fields that must be translated, the invariants that must hold across the crossing, and a status flag.
- Flag unresolved seams as first-class rows. A disagreement with no agreed resolution is recorded as an open hole, not silently dropped — the table's honesty is that it shows what it cannot yet reconcile.
- Point outward, don't execute. The translation column references the protocol that does the conversion and the test that checks it; the table itself only catalogs.
Tuning parameters¶
- Row granularity — object-level pairs versus field-level pairs; finer rows catch subtle mismatches but the table grows and ages faster.
- Invariant strictness — which columns carry hard invariants (identity, conserved totals) versus soft preferences; more hard invariants make violations loud but flag more rows as blocked.
- Open-seam tolerance — how many unresolved holes the atlas will ship with; permissive gets the table published sooner, strict blocks until seams close.
- Refresh trigger — whether rows are revisited on a schedule or only when a chart on either side changes.
When it helps, and when it misleads¶
Its strength is coverage: it forces every seam into the open as a row, so overlaps become a finite list you can audit rather than an unknown number of implicit assumptions scattered through the system. A well-kept table functions as a data crosswalk[n1] — a durable concordance that new integrations and audits both read from.
Its failure mode is drift into decoration: a table that lists pairs but leaves the invariant and status columns vague looks like governance while asserting nothing checkable, and its worst misuse is marking a row "reconciled" on the strength of the table alone — no crossing was ever actually run through it. A table is a claim about seams, not evidence that they hold. The guarding discipline is to require that any row marked resolved cite the mechanism that verified it, and to keep unresolved holes visibly red rather than quietly deleting the rows that are hard to close.
How it implements the components¶
overlap_region— each row is an overlap: it names the pair of charts and the cases where both apply.global_invariant_set— a dedicated column records what must remain stable across each crossing (identity, conserved totals, rights), making the atlas's invariants explicit per seam.hole_or_loop_marker— unresolved-seam rows are the atlas's holes, catalogued as first-class entries rather than dropped.
It does not build the executable conversion — the local_coordinate_vocabulary declarations and transition_map logic are Coordinate Translation Protocol's — and it does not verify a crossing: the seam_consistency_check belongs to Round-Trip Consistency Test. The table catalogs seams; those siblings translate and test them.
Related¶
- Instantiates: Local-Chart Atlas Modeling — the table is the atlas's inventory of every place two charts must agree, translate, or admit conflict.
- Consumes: Coordinate Translation Protocol — the translated-fields column references the protocol that actually performs each conversion.
- Sibling mechanisms: Chart Atlas Map · Coordinate Translation Protocol · Round-Trip Consistency Test · Boundary Case Path Trace · Atlas Stewardship Review · Local Model Ensemble with Gating · Manifold Learning Diagnostic · Neighborhood Preservation Probe · Geodesic or Path-Distance Audit
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Overlap Transition Table operates as a persistent ledger, log, register, or case record that preserves history and traceability because it enumerates every overlapping chart pair as a row — the shared cases, the invariants that must survive the crossing, and the seams still unresolved.
Independent corroboration: The frozen evidence defines Overlap Transition Table as 'Enumerates every overlapping chart pair as a row — the shared cases, the invariants that must survive the crossing, and the seams still unresolved', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Mathematics
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Overlap Transition Table is most directly rooted in mathematics' axiomatic study of abstract structure, relations, and formal operations. The lineage fits its defining practice: Enumerates every overlapping chart pair as a row — the shared cases, the invariants that must survive the crossing, and the seams still unresolved.
Related originating lineages:
- Computer Science & Software Engineering — Schema crosswalks and integration tables materially adapt the same seam-enumeration idea to information systems.
- Physics — Overlap Transition Table also draws materially on physics' modeling of matter, dynamics, waves, and experimentally constrained systems, which shaped this mechanism rather than merely adopting it as an application.
Review resolution: Both independent reviews agree on primary origin mathematics; reconciliation resolves alternate_origin_disagreement, origin_mode_disagreement, encyclopedia_synthesis_disagreement. Formative alternate lineages retained: physics, computer_science. The broader reach of later applications is kept separate as domain_reach=specialized; origin_mode=cross_disciplinary_synthesis records how the formative lineages relate. Confidence is conservatively reconciled to high, and encyclopedia_synthesis=true preserves the reviewers' boundary judgment.
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.
Notes¶
[n1] A crosswalk (or concordance) is a maintained mapping table that states how the categories of one classification correspond to another — familiar in data management and standards work, where crosswalks connect coding schemes without merging them. The Overlap Transition Table generalizes this to any pair of local charts. ↩