Union Specification Sheet¶
Specification artifact — instantiates Inclusive Membership Union Design
A single declared document that fixes the union's universe, its contributing sources, and the downstream-use label — the contract every other mechanism is built against.
Every other mechanism in this archetype does something to the union; the Union Specification Sheet declares what the union is. It is the up-front design document that fixes three decisions before any data moves: the universe of admissible elements (what kind of thing this union is even about), the sources that are permitted to contribute, and the downstream-use label that tells consumers what the union does and does not warrant. Its defining move is that it is a contract, not a computation — it states intent and constraints, and the ingestion, resolution, dedup, and review mechanisms are all built to honor it. It performs no matching, no collapsing, no counting. Its whole value is that everything downstream has one authoritative place to check what this union was designed to be.
Example¶
A data team is asked to build a "Customer 360" union combining records from the billing system, the support ticketing tool, and the marketing platform. Before writing any pipeline, they draft the specification sheet. Universe: individual paying account-holders — explicitly not prospects, not organizations, not deleted accounts. Sources: billing (system of record), support (contributes only account-holders who filed a ticket), marketing (contributes only opted-in contacts matched to an account). Downstream-use label: "This union is an inclusive membership set for outreach and analytics; presence does NOT imply an active subscription, consent to be contacted, or a validated identity — join to the billing status table before acting on any member."
That one sheet settles a dozen arguments that would otherwise surface months later: whether prospects count (no), whether a support-only contact is a member (only if matched to an account), and how a downstream team may use the result (analytics, not a consent list). Every subsequent mechanism — ingestion, resolution, dedup — is built to satisfy this contract rather than to someone's unspoken assumption.
How it works¶
- Declare the universe. State precisely what kind of element is admissible — the type, the boundary cases explicitly in or out — so "member" has a fixed meaning before any source is read.
- Register the intended sources. List the sources the union is designed to draw on, each with its role (system of record, supplementary, opt-in-only), as the reference roster ingestion is built against.
- Write the use label. State plainly what any-source membership does and does not warrant, and what extra evidence a consumer must join before treating a member as validated, consented, or active.
- Version the contract. Treat the sheet as a versioned artifact, so a change to scope, sources, or use is a deliberate, dated amendment rather than silent drift.
Tuning parameters¶
- Universe tightness — how narrowly the admissible element is defined and how explicitly boundary cases are ruled in or out. Tight, explicit scoping prevents downstream disputes but takes hard decisions up front; loose scoping is quick but defers the argument to production.
- Source-role granularity — whether sources are just listed or each annotated with a role and contribution rule. Rich roles guide ingestion precisely but make the sheet heavier to write and maintain.
- Label strength — how strongly the use caveat constrains consumers, from a gentle note to an enforced "must join X before use." Strong labels prevent misuse but can be ignored if not tied to access; weak ones inform without protecting.
- Amendment discipline — how formally changes to the sheet are governed. Strict versioning keeps the contract trustworthy; informal edits are fast but let the spec and the real union quietly diverge.
When it helps, and when it misleads¶
Its strength is that it converts unspoken assumptions into an explicit, checkable contract — the single place to answer "what is this union, and what may I do with it?" — which is what keeps a reusable union from being quietly repurposed into something it was never validated for. In current data practice this artifact is essentially a data contract: a declared, versioned agreement about a dataset's scope, semantics, and permitted use.[n1]
Its failure mode is the spec that exists but is not honored: a sheet declaring a universe of "paying account-holders" is worthless if the pipeline quietly admits prospects and no one checks. The classic misuse is the opposite of writing no spec — writing one and then treating the union as self-evidently valid because it is documented, mistaking a scope label for a validation guarantee. A subtler trap is spec drift, where sources or scope change in production but the sheet is never amended, so the contract now lies. The guarding discipline is to tie the mechanisms to the sheet (ingestion registers exactly its sources, checks enforce its universe), keep the use label attached wherever the union is consumed, and amend the sheet as a deliberate versioned act rather than letting reality drift away from it.
How it implements the components¶
union_universe_scope— its core declaration: the admissible element type and boundary, fixed before any data is read.downstream_union_scope_label— the written use caveat stating what any-source membership does and does not warrant.source_collection_registry— the intended-source roster with roles, as the reference contract ingestion and vetting are built to satisfy.
This sheet declares intent; it does not execute the intake or handle a failed fetch (null_and_empty_source_policy) — running the roster and managing source presence is Source Collection Ingestion Workflow. It also does not vet type compatibility (type_compatibility_gate); that enforcement against the declared universe is Type Compatibility Checklist.
Related¶
- Instantiates: Inclusive Membership Union Design — declares the universe, sources, and use scope the whole union is built against.
- Sibling mechanisms: Canonical Identity Resolution Pass · Deduplicating Union Pass · Inclusive-OR Membership Test · Overlap and Coverage Dashboard · Provenance Tagging Protocol · Source Collection Ingestion Workflow · Type Compatibility Checklist · Union Delta Review
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Union Specification Sheet is defined in the frozen evidence as: A single declared document that fixes the union's universe, its contributing sources, and the downstream-use label — the contract every other mechanism is built against. Its operative deployed or enacted form is therefore Representation, Specification & Plan.
Nearest alternative: Rule, Policy & Commitment — Rule, Policy & Commitment can support this mechanism, but the evidence centers the concrete operation described above rather than the alternative family's defining operation.
Review outcome: Adjudicated after independent review; medium confidence.
Origin Attribution¶
Primary origin: Mathematics
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: Encyclopaedia of Mathematics, Set-theoretic operations documents that set theory defines union, subset, complement, and the universe relative to which complement is evaluated. This is direct, mechanism-specific evidence for mathematics as the best-evidenced historical home of the operation—A single declared document that fixes the union's universe, its contributing sources, and the downstream-use label — the contract every other mechanism is built against.—rather than evidence merely that the operation is useful there. The retained alternates record genuine adjacent lineages; later portability is represented separately by domain_reach=universal.
Related originating lineages:
- Computer Science & Software Engineering — Computer science and software-engineering practice supplies a parallel or contributing lineage for the mechanism's defining operation: a single declared document that fixes the union's universe, its contributing sources, and the downstream-use label — the contract every other mechanism is built against.
- Library & Information Science — Library and information-science stewardship supplies a parallel or contributing lineage for the mechanism's defining operation: a single declared document that fixes the union's universe, its contributing sources, and the downstream-use label — the contract every other mechanism is built against.
- Organizational & Management Science — Organizational Management supplies a historically relevant adjacent lineage or formative practice for the operation—A single declared document that fixes the union's universe, its contributing sources, and the downstream-use label — the contract every other mechanism is built against.—but the adjudicated evidence more directly locates the defining lineage in mathematics.
- Systems Thinking & Cybernetics — Systems science's feedback, boundaries, control, and regulation tradition contributes a separate formative lineage to the mechanism's union specification sheet logic.
Review resolution: The blind reviewers disagree on primary lineage (organizational_management versus mathematics). The defining operation is: A single declared document that fixes the union's universe, its contributing sources, and the downstream-use label — the contract every other mechanism is built against. The researched Encyclopaedia of Mathematics, Set-theoretic operations establishes that set theory defines union, subset, complement, and the universe relative to which complement is evaluated. That source therefore supports mathematics as the historical origin. organizational management remains in the uncapped alternates where it contributes a formative practice, but application or governance is not itself proof of origin. origin_mode=convergent records lineage construction; domain_reach=universal separately records later applicability.
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:
Notes¶
[n1] A data contract is a declared, versioned agreement specifying a dataset's schema, semantics, scope, and permitted use, so producers and consumers share one authoritative definition. The specification sheet is a data contract for a union — its universe, sources, and use label written down before the union is built. ↩