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.[1]
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.
References¶
[1] Pnueli, A., Siegel, M., & Singerman, E. “Translation validation”. In Tools and Algorithms for the Construction and Analysis of Systems (TACAS '98), Lecture Notes in Computer Science 1384, 151–166 (1998). Introduces translation validation as checking each individual compiler run rather than proving the compiler correct for all runs. registry ↩ Show verification details
Supported in partVerified against the publisher's abstract
States translation validation as verifying each individual compiler run rather than proving the compiler correct for all runs; it does not itself assert the 'archetype' framing.
“We present the notion of translation validation as a new approach to the verification of translators (compilers, code generators). Rather than proving in advance that the compiler always produces a target code which correctly implements the source code (compiler verification), each individual translation (i.e. a run of the compiler) is followed by a validation phase which verifies that the target code produced on …”