Type Compatibility Checklist¶
Validation checklist — instantiates Inclusive Membership Union Design
A pre-union gate that checks each candidate source's elements are the same kind of thing, in the same universe, before it is allowed to contribute members.
Union is only meaningful when the things being combined are the same kind of thing. Type Compatibility Checklist is the gate that verifies this before any source contributes a single member. For each candidate source it runs a fixed set of checks: are these elements the same entity type as the union's universe? Do the identifying fields mean the same thing, or do they merely share a name? Are units, encodings, and granularity aligned? A source that fails is quarantined — held out of the union with a stated reason — rather than silently blended in. Its defining move is that it judges a source's fitness to join the universe, element-type by element-type, as an up-front admissions test. It does not register sources, resolve individual identities, or count overlap; it decides, yes or no, whether a source's contents belong in this union at all.
Example¶
An e-commerce company builds a unified catalog by unioning product feeds from a dozen suppliers. One supplier's feed uses the field id for the manufacturer's part number; another uses id for that supplier's own internal SKU; a third's id is actually a bundle identifier that names a set of products, not one product. Concatenated blindly, these three id fields would collide into one column and fuse unrelated things. The type compatibility checklist catches it at the door: it confirms each feed's element is a single sellable product (not a bundle, not a category), that price is in the same currency and tax basis, that weight is in consistent units, and that the identifier field means the same thing across feeds. The bundle feed fails the "one element = one product" check and is quarantined with the note "elements are product sets, not products — needs unbundling before union."
The outcome is a union whose members are genuinely comparable products, not a mash-up of parts, bundles, and SKUs that happen to share a field name.
How it works¶
- Fix the checklist to the universe. The union's declared universe defines the required element type and field semantics; the checklist tests each source against that fixed reference, not against the other sources ad hoc.
- Check meaning, not just shape. Beyond matching field names and datatypes, verify that same-named fields carry the same meaning, units, encoding, and granularity — the homonym traps that pass a schema check but corrupt a union.
- Decide per source: admit or quarantine. A source that passes joins the union; one that fails is held out with an explicit failure reason, so the gap is visible and fixable rather than silent.
- Run before membership, not after. The gate sits ahead of the union build, so incompatible elements never enter and never have to be found and removed later.
Tuning parameters¶
- Check depth — name-and-datatype only, versus full semantic checks on units, encoding, and granularity. Deeper checks catch homonym and unit bugs but take real analyst effort per source.
- Failure disposition — hard-reject a failing source, or admit it into a quarantine lane for remediation. Hard rejection keeps the union clean but loses coverage; quarantine preserves the option to fix and re-admit.
- Universe strictness — how narrowly the admissible element type is drawn. A tight universe blocks borderline sources cleanly; a loose one admits more but lets marginally-compatible elements dilute the union.
- Re-check trigger — whether a passed source is re-vetted when its schema or the universe definition changes. Frequent re-checks catch drift; infrequent ones save effort but let a once-valid source rot into incompatibility.
When it helps, and when it misleads¶
Its strength is preventing the quietest and most corrosive union bug: elements that are combined only because they share a label, not a meaning. Catching that at the door is far cheaper than discovering, downstream, that a "products" table is one-third bundles. The underlying hazard has a name — semantic heterogeneity, the data-integration problem where identically-named fields carry different meanings across sources.[n1]
Its failure mode is a checklist that verifies structure while missing meaning: two feeds both have a price column of type decimal and pass — but one is pre-tax USD and the other tax-inclusive EUR, and the union now sums incomparable numbers. The classic misuse is trusting a schema match as a compatibility proof, when schema alignment is necessary but nowhere near sufficient. A second trap is vetting a source once and never re-checking, so a supplier's silent schema change slips incompatible elements into a long-standing union. The guarding discipline is to check meaning and units, not just names and types; to quarantine with a stated reason rather than reject-and-forget; and to re-run the checklist whenever a source or the universe definition changes.
How it implements the components¶
type_compatibility_gate— its core: the per-source admissions test that admits type-compatible sources and quarantines the rest before they can contribute members.union_universe_scope— used as the fixed reference the checklist tests against, confirming each source's elements fall within the union's declared admissible universe.
This checklist vets a whole source's fitness before membership; it does not register sources or handle a failed fetch (source_collection_registry, null_and_empty_source_policy) — that intake governance is Source Collection Ingestion Workflow. Deciding whether two individual records are the same entity (canonical_member_identity_key) is Canonical Identity Resolution Pass, which applies its own type gate at the record level rather than the source level.
Related¶
- Instantiates: Inclusive Membership Union Design — enforces the type-compatibility gate that keeps the union's elements genuinely comparable.
- Consumes: Source Collection Ingestion Workflow supplies the registered candidate sources this checklist vets.
- Sibling mechanisms: Canonical Identity Resolution Pass · Deduplicating Union Pass · Inclusive-OR Membership Test · Overlap and Coverage Dashboard · Provenance Tagging Protocol · Source Collection Ingestion Workflow · Union Delta Review · Union Specification Sheet
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Type Compatibility Checklist operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it a pre-union gate that checks each candidate source's elements are the same kind of thing, in the same universe, before it is allowed to contribute members.
Independent corroboration: The frozen evidence defines Type Compatibility Checklist as 'A pre-union gate that checks each candidate source's elements are the same kind of thing, in the same universe, before it is allowed to contribute members', so its operative form is Assessment, Review & Assurance.
Nearest alternative: Decision, Gate & Allocation — Type Compatibility Checklist includes features of a case-specific gate, selection, routing, prioritization, or resource disposition, but its defining operation is a bounded evaluation of existing evidence or work that produces a finding or disposition.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: Checking that values and operations inhabit compatible types before composition is programming-language type discipline. Cardelli and Wegner analyze types as constraints on values, abstraction, and polymorphic operations; organizational checklists merely operationalize that semantic compatibility test.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: a pre-union gate that checks each candidate source's elements are the same kind of thing, in the same universe, before it is allowed to contribute members.
- Library & Information Science — Library and information-science stewardship supplies a parallel or contributing lineage for the mechanism's defining operation: a pre-union gate that checks each candidate source's elements are the same kind of thing, in the same universe, before it is allowed to contribute members.
- Mathematics — Mathematical modeling, proof, and abstract-structure practice supplies a parallel or contributing lineage for the mechanism's defining operation: a pre-union gate that checks each candidate source's elements are the same kind of thing, in the same universe, before it is allowed to contribute members.
- Organizational & Management Science — organizational_management contributes organizational design, management, and operational governance to this mechanism's defining operation—A pre-union gate that checks each candidate source's elements are the same kind of thing, in the same universe, before it is allowed to contribute members—without displacing the selected primary historical lineage.
- Philosophy — philosophy contributes philosophical logic, epistemology, and normative reasoning to this mechanism's defining operation—A pre-union gate that checks each candidate source's elements are the same kind of thing, in the same universe, before it is allowed to contribute members—without displacing the selected primary historical lineage.
- Systems Thinking & Cybernetics — Feedback, system boundaries, stocks, flows, and regulation supplies a distinct formative lineage for the mechanism's type compatibility checklist logic.
Review resolution: The blind reviewers disagree on primary lineage (organizational_management versus computer_science). Authoritative or primary research supports computer_science as the best historical origin: Checking that values and operations inhabit compatible types before composition is programming-language type discipline. Cardelli and Wegner analyze types as constraints on values, abstraction, and polymorphic operations; organizational checklists merely operationalize that semantic compatibility test. The cited Cardelli and Wegner, On Understanding Types, Data Abstraction, and Polymorphism directly supports the mechanism's defining operation. All independently supported contributing domains are retained without an arbitrary cap. origin_mode=single_lineage records lineage, while domain_reach=universal records later applicability separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] Semantic heterogeneity is the data-integration problem in which fields that look alike — same name, same datatype — carry different real-world meanings across sources (one price pre-tax, another tax-inclusive; one id a part number, another a bundle). A schema match does not detect it, which is why the checklist tests meaning and units, not just structure. ↩