Unity Test Specification Sheet¶
Specification template — instantiates Part-Whole Unity Criterion Design
A reusable design form that declares, for one kind of whole, what is being tested for and what a positive verdict licenses.
Before anyone argues whether a particular collection of parts is one whole, someone has to say what kind of whole is even on the table and what would change if the answer is yes. The Unity Test Specification Sheet is that up-front artifact: a blank-then-filled template that fixes, for a single kind of whole, the frame and the stakes of the test. It declares the kind under consideration — object, system, organization, event, dataset, legal unit — noting that the same parts can be one whole under one kind and many under another, and it schedules the consequences a positive verdict will license: count once, one identifier, one owner, merge the records, persist as a single entity across change. It deliberately does not pick the relation that binds the parts or set how much of it is enough; those are delegated. Its job is to make sure every later step inherits the same declared target and the same understanding of what is riding on the verdict.
Example¶
A national statistics agency maintains a business register and must keep two kinds of whole from collapsing into each other: the establishment (a single physical site of production) and the enterprise (the smallest legally autonomous decision-making unit). Analysts kept counting a large food conglomerate one way in employment tables and another way in ownership tables. So the register team writes a spec sheet for the kind "enterprise": kind declared as the unit of legal and financial control; consequences of a positive verdict declared as counted once in enterprise counts, assigned one legal-control identifier, reported through one set of consolidated accounts, and presumed to persist across address and branding changes. None of this classifies any particular firm yet. But when the conglomerate's twelve sites come up for assessment, the relation checklist and threshold test that actually render the verdict now run against a single fixed frame — everyone already agrees what "one enterprise" would mean and what it would trigger downstream.
How it works¶
The sheet has two authored sections and a set of delegated slots:
- Kind declaration. Name the whole-kind precisely and record the contrast kinds it must not be confused with. This is where the archetype's "one under one kind, many under another" ambiguity is closed by fiat.
- Consequence schedule. Enumerate, before any evidence, exactly what a positive verdict licenses and what a negative verdict forbids — the counting, identity, ownership, and persistence changes that follow. This is the "why the test exists" made concrete.
- Delegated slots. Named placeholders that point to the relation selection and threshold tools rather than filling them, so the sheet stays a frame and not a verdict.
One sheet is authored per kind and reused across every candidate of that kind.
Tuning parameters¶
- Kind granularity — one sheet per narrowly-defined kind versus one broad sheet covering a family; finer sheets reduce cross-kind leakage but multiply maintenance.
- Consequence scope — how many downstream actions the verdict is allowed to govern; a wide scope makes the test high-stakes and slows adoption, a narrow one risks the verdict being ignored where it should bind.
- Persistence horizon — how long a positive verdict is presumed to hold before it must be re-earned; longer horizons buy stability at the cost of stale wholes.
- Rigidity — whether the template is mandatory boilerplate or advisory scaffolding for each new test.
When it helps, and when it misleads¶
Its strength is that it settles the stakes before the evidence, so debates about a specific collection stay about the facts of that collection rather than sliding into a fresh argument about what "one whole" should mean or trigger. It is the cure for the same system being counted once here and many times there.
Its characteristic failure is reification[n1]: a tidy sheet with a confident consequence schedule can conjure a "whole" that the parts do not actually cohere into, and a rich pre-declared list of licenses tempts teams to grant them before the binding relation has been shown to hold at all. The guarding discipline is to keep the consequence schedule strictly contingent — nothing is licensed until the delegated relation and threshold are actually met — and to revisit the sheet whenever the kind's downstream use changes, since the stakes it encodes are only as current as those uses.
How it implements the components¶
The sheet fills the framing side of the archetype — the two components that bracket the whole test:
wholehood_scope_and_kind— the kind declaration is its core output: it names the kind of whole under test and the contrast kinds it must be held apart from.identity_and_persistence_consequence— the consequence schedule states exactly what a positive verdict licenses about identity, count, ownership, and persistence.
It does NOT implement unity_relation_specification (that is the Unity Relation Selection Checklist) or unity_threshold_condition (the Wholehood Threshold Test); and unlike its nearest twin the Unity Verdict Decision Log, which owns unity_verdict_record, this sheet defines the rule ex ante and generically rather than recording specific verdicts after the fact.
Related¶
- Instantiates: Part-Whole Unity Criterion Design — the sheet supplies the declared frame and stakes the rest of the design hangs on.
- Sibling mechanisms: Part Inventory and Granularity Review · Unity Relation Selection Checklist · Wholehood Threshold Test · Borderline Whole Review Protocol · Unity Verdict Decision Log · Part-Whole Dependency Map · Unity Reassessment Trigger
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Unity Test Specification Sheet is defined in the frozen evidence as: A reusable design form that declares, for one kind of whole, what is being tested for and what a positive verdict licenses. Its operative deployed or enacted form is therefore Representation, Specification & Plan.
Nearest alternative: Interface, Display & Cue — Interface, Display & Cue 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: Philosophy
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: Stanford Encyclopedia of Philosophy, Parts and Wholes documents that mereology makes the relations that bind parts into wholes, and competing principles of composition, an explicit philosophical problem. This is direct, mechanism-specific evidence for philosophy as the best-evidenced historical home of the operation—A reusable design form that declares, for one kind of whole, what is being tested for and what a positive verdict licenses.—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:
- Mathematics — Mathematical modeling, proof, and abstract-structure practice supplies a parallel or contributing lineage for the mechanism's defining operation: a reusable design form that declares, for one kind of whole, what is being tested for and what a positive verdict licenses.
- Organizational & Management Science — Organizational Management supplies a historically relevant adjacent lineage or formative practice for the operation—A reusable design form that declares, for one kind of whole, what is being tested for and what a positive verdict licenses.—but the adjudicated evidence more directly locates the defining lineage in philosophy.
- Systems Thinking & Cybernetics — Systems science's feedback, boundaries, control, and regulation tradition contributes a separate formative lineage to the mechanism's unity test specification sheet logic.
Review resolution: The blind reviewers disagree on primary lineage (organizational_management versus philosophy). The defining operation is: A reusable design form that declares, for one kind of whole, what is being tested for and what a positive verdict licenses. The researched Stanford Encyclopedia of Philosophy, Parts and Wholes establishes that mereology makes the relations that bind parts into wholes, and competing principles of composition, an explicit philosophical problem. That source therefore supports philosophy 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] Reification — treating an abstraction as if it were a concrete thing, a version of Whitehead's "fallacy of misplaced concreteness." A specification that names a whole and lists its consequences can make that whole feel real before any binding relation has been shown to hold. ↩