# Related-work ledger

Status: paper-local author ledger

Verified source date inherited from the binding dossier: 22 July 2026

This ledger states what the manuscript may attribute to prior work and what it
must not imply is new. `references.bib` contains the citation records;
`primary-source-bibliography.md` records provenance and use.

| Key | Established result or system capability used by P3 | P3 boundary / forbidden novelty implication |
|---|---|---|
| `Spivak2012Functorial` | A schema functor induces the canonical \(\Sigma\), \(\Delta\), and \(\Pi\) data-migration functors under the paper's categorical model. | Schemas as categories, functorial migration, or the three operators are not CatDB inventions. |
| `SpivakWisnesky2015Relational` | Relational foundations, expressiveness, and compositional behavior for functorial data migration. | P3 may not describe relational realization or composable categorical migration as unexplored. |
| `WisneskyEtAl2015Practice` | FQL case-study evidence that functorial migration has been executed outside toy definitions. | P3 may not claim to be the first executable bridge from category theory to data integration. |
| `BrownEtAl2019Computational` | CQL applied to materials-data integration with constraints. | CatDB's eventual empirical result must differ from merely executing categorical integration. |
| `CQL2026` | Official CQL documentation for typed schemas, instances, mappings, transforms, constraints, and executable delta/sigma workflows. | A mapping syntax or executable `delta`/`sigma` is not novel. P3's \(\Sigma\) and \(\Pi\) remain unsupported. |
| `CurinoEtAl2008PRISM` | Schema Modification Operators, derived and composed mappings, evolution histories, information-preservation analysis, legacy queries, views, and migration generation. | Typed evolution histories, compatibility views, or generated migrations cannot be claimed alone as P3's novelty. |
| `CurinoEtAl2010PRISMPlus` | Integrity Constraint Modification Operators, impact analysis, and legacy query/update rewriting in a deliberately restricted language. | Constraint-aware evolution and decidable restriction are strong direct prior art. |
| `BernsteinMelnik2007Model` | First-class models and mappings with match, compose, diff, merge, translation, inversion-related operations, and transformation generation. | “Mappings are first class” and “schema changes compose” are not sufficient contributions. |
| `SchultzEtAl2017ModelManagement` | Algebraic/categorical organization of model-management operators. | Categorical vocabulary around diff/merge/compose is not by itself a novelty claim. |
| `FaginEtAl2005DataExchange` | Solutions, universal solutions, the chase, and certain-answer semantics for data exchange. | Future synthesis, target construction, and \(\Sigma\) claims must compare against data exchange. |
| `FaginEtAl2005Composition` | Expressiveness and closure boundaries for mapping composition; second-order dependencies recover closure in the stated language. | “Composable” must always name the admitted mapping language and conditions. |
| `BohannonEtAl2006Lenses` | Well-behaved relational views and update propagation under lens restrictions and laws. | Read invertibility or a view does not establish writable migration; P8 owns writeability. |
| `HerrmannEtAl2017BiDEL` | Co-existing schema versions with generated view/trigger delta code and physical-design independence. | Generated compatibility views and simultaneous versions are not novel. |
| `RaeEtAl2013F1` | Online asynchronous schema change requires intermediate states and bounded version skew; unsafe transitions can corrupt data. | A semantic mapping cannot be presented as an online cutover protocol. |
| `BhattacherjeeEtAl2021BullFrog` | Lazy relational schema evolution, concurrency control, and comparison with eager conversion. | Lazy migration is prior art; CatDB needs correctness and cost evidence against this baseline. |
| `PostgreSQLAlterTable2026` | Backend-specific locks, scans, type conversion, dependency behavior, staged validation, and rewrites. | SQL syntax or a generated plan is not proof of semantic totality, availability, or low cost. |
| `PostgreSQLCreateView2026` | Restricted conditions under which a PostgreSQL view is automatically updateable. | A generated compatibility view is read-only absent a separate writeability result. |
| `Flyway2026Versioned` | Ordered, once-only, checksum-tracked versioned migrations and schema history. | Immutable or checksummed migration history alone is not novel. |
| `Alembic2026Autogenerate` | Candidate migration generation that requires review and does not infer renames, reporting them as add/drop. | Stable semantic IDs are a testable delta, not permission to disparage or misstate ORM tooling. |
| `Confluent2026Evolution` | Versioned message schemas and backward/forward/full/transitive compatibility policies. | Registry compatibility is a narrower baseline, not equivalent to relational migration. |
| `EventSourcingDB2026Versioning` | Immutable event versions and on-read normalization/upcasting in application or projection code. | Upcasting is a lazy analogue, not automatically a typed schema functor. |
| `DeCastroEtAl1997SchemaVersioning` | Relational schema versioning and distinction between evolution and multiple version interfaces. | Schema versioning predates CatDB. |
| `MaddoxEtAl2016Decibel` | Dataset branching, version operations, physical layouts, and versioning benchmarks. | Database branching and version-aware storage are not new. |
| `HuangEtAl2017OrpheusDB` | Bolt-on relational version control with representation and physical-migration tradeoffs. | P3's plausible delta concerns co-versioned semantic obligations, not version control itself. |

## Comparison dimensions required in the manuscript

The prior-art section and later technical sections must compare systems along
the dimensions below, rather than grouping them under a vague “related work”
heading:

1. semantic input: functor, schema operator, dependency, lens, script, or
   version-policy declaration;
2. mapping direction and whether the result is a single instance or a solution
   space;
3. support for loss, partiality, synthesis, identity, and ambiguity;
4. legacy reads versus legacy writes;
5. semantic history versus physical plan history;
6. eager, lazy, virtual, and mixed-version execution;
7. stable declaration identity and rename handling;
8. impact/dependency analysis;
9. backend-specific locks, scans, conversion, and recovery;
10. executable and experimental evidence.

## Citation discipline

All literature capability statements use `SUPPORTED PRIOR LITERATURE`. That
label means only that the cited source supports the statement under its own
assumptions. It is never CatDB implementation evidence.