Structure-Preservation Checklist¶
Verification checklist — instantiates Composable Relation Modeling
Checks, feature by feature, that a proposed mapping preserves identities, composition, and associativity before you rely on it.
A Structure-Preservation Checklist is a short, human-run review applied to one specific proposed mapping — a refactor, a rewrite, a translation from an old model to a new one — asking, item by item, whether it preserves the structural features that make the model trustworthy. Does it send identity arrows to identity arrows? Does the image of a composite equal the composite of the images? Does regrouping survive the mapping? Its defining character is that it is a confirmatory, in-place gate on a single map, worked as a checklist by a reviewer, not an executable battery of cases and not a cross-domain search. It presumes the two models already exist and the mapping between them is already proposed; its job is to certify — before anyone cuts over — that nothing structural silently breaks in the crossing. A single "no" on any item stops the cutover and localizes the defect to one preservation property.
Example¶
A compiler team has written a new optimization pass — a mapping from unoptimized intermediate code to a faster equivalent. The whole value of the pass depends on it being semantics-preserving: the optimized program must do exactly what the original did. Rather than trust it because the benchmarks got faster, a reviewer runs a Structure-Preservation Checklist over the pass, treating it as a map from the "before" model to the "after" model.
Identity preservation: does a no-op fragment (an empty basic block, a +0) map to a no-op, or does the pass "optimize" it into something with a side effect? Checking this catches that a dead-store elimination rule was removing a store that another thread observed. Composition preservation: if you optimize A then B separately, is that the same as optimizing the sequence A;B? The reviewer finds it is not — the pass reorders across the A;B boundary in a way that changes results when the fragments are composed. Associativity preservation: does regrouping a chain of fragments before optimizing agree with regrouping after? Each item is checked and signed off or flagged. The checklist's verdict — composition is not preserved across sequence boundaries — blocks the cutover and points the fix at one property, rather than leaving a subtle miscompilation to surface in production months later.
How it works¶
- Fix the one mapping under review. The checklist is always about a single proposed map between two already-existing models; it does not search for a map or invent one.
- Walk the preservation items in order. For each structural feature, ask the preservation question: identities → identities, composites → composites of images, regroupings preserved. Each item gets an explicit pass/flag with the reasoning.
- Localize any failure to a property. A flagged item names which structural law the map breaks, so the fix is scoped ("preserve composition across boundaries") rather than "the map is wrong somewhere."
- Gate the cutover on a clean sheet. The map is adopted only when every item passes; a single flag holds the change.
The checklist certifies preservation qualitatively, by review; it does not run a case suite and it does not carry the mapping across into a different domain.
Tuning parameters¶
- Item completeness — how many structural features the checklist covers (just identity and composition, or also associativity, ordering, and declared invariants). More items catch subtler breakage but lengthen the review.
- Evidence bar per item — how much justification each pass requires: a reviewer's argument, a spot-checked example, or a referenced proof. A high bar makes the sign-off trustworthy but slow.
- Reviewer independence — whether the map's author or an independent reviewer runs the checklist. Independence catches author blind spots; self-review is faster but weaker.
- Blocking strictness — whether any flagged item hard-blocks the cutover or merely warns. Hard-blocking is safest for irreversible changes; warnings suit low-stakes maps.
When it helps, and when it misleads¶
Its strength is that it turns "the refactor should be equivalent" into a signed, itemized certification before commitment, catching structure-breaking maps at review time rather than after cutover — exactly when different implementation paths are wrongly "treated as equivalent without proving they preserve the same result." It is the archetype's gate on a single proposed transformation.[n1]
Its failure mode is checklist theater: items checked off from optimism rather than evidence, so the sheet is clean but the map still breaks a property no one actually tested. The classic misuse is a self-reviewing author signing every item green under deadline pressure, converting a real gate into a ritual. A subtler trap is an incomplete item list that omits the one property this particular map violates. The guarding discipline is an independent reviewer, a real evidence bar per item (an argument or worked instance, kept informal — this is a review, not a test battery), and hard-blocking on any flag for irreversible cutovers.
How it implements the components¶
composition_rule— the checklist item verifying the map preserves composition: the image of a composite equals the composite of the images.identity_arrow_baseline— the item verifying identity arrows map to identity arrows, so "no change" stays "no change" across the mapping.associativity_invariant— the item verifying that regrouping a chain survives the mapping, so summarized paths remain faithful after the crossing.
It does not define or carry the cross-domain mapping itself (structure_preserving_transfer_rule — that is Functorial Transfer Probe, its nearest twin; the probe searches across domains, this checklist confirms one in-domain map), and it does not run an executable battery of cases (diagram_validation_case_set — that is Identity and Associativity Test Suite); this is a qualitative review, not a test run.
Related¶
- Instantiates: Composable Relation Modeling — the checklist is the archetype's single-map preservation gate.
- Consumes: Object–Arrow Diagram supplies the before-and-after models the mapping runs between.
- Sibling mechanisms: Functorial Transfer Probe · Identity and Associativity Test Suite · Composition Table · Object–Arrow Diagram · Commutative Path-Equivalence Diagram · Source/Target Type Check · Interface-Contract Category Map · Categorical Refactoring Workflow
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Structure-Preservation Checklist operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it checks, feature by feature, that a proposed mapping preserves identities, composition, and associativity before you rely on it.
Independent corroboration: The frozen evidence defines Structure-Preservation Checklist as 'Checks, feature by feature, that a proposed mapping preserves identities, composition, and associativity before you rely on it', so its operative form is Assessment, Review & Assurance.
Nearest alternative: Analysis, Modeling & Optimization — Structure-Preservation Checklist includes features of an analytical, modeling, inference, comparison, or optimization procedure that derives insight or a solution, 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: Mathematics
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Checking identities, composition, and associativity verifies a homomorphism-like mapping.
Related originating lineages:
- Computer Science & Software Engineering — Typed transforms implement checks.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
[n1] Translation validation is a compiler-verification technique that checks, for a given input, that a transformed program preserves the semantics of the original — certifying the specific transformation rather than the whole optimizer. This checklist is the relational, whole-map analogue: it certifies that one proposed mapping preserves the structural laws. ↩