Holdt skjemaet ærlig gjennom 1 022 migreringer med en CI‑port som bygger databasen begge veier — en ny installasjon, og en installasjon pluss alle migreringer — og feiler når de to ikke stemmer overens.

Situasjon. Et skjema beskrives to ganger i de fleste prosjekter: én gang av det første oppsettet som bygger det fra bunnen av, og én gang av de akkumulerte migreringene som fikk det til å vokse. Begge skal gi samme database. Ingenting kontrollerer at de gjør det, så de glir fra hverandre — og avviket er usynlig til et nytt miljø oppfører seg annerledes enn produksjon, som regel i det verst tenkelige øyeblikket.

Oppgave. De to beskrivelsene måtte kunne bevises å være identiske, automatisk, i stedet for at man med jevne mellomrom bare trodde at de var det.

Handling. Databasen er versjonert som 1 022 migreringer, nummerert fra 036 til 1102, og disiplinen rundt rekkefølgen er uglamorøs og ikke til forhandling. Det som får det til å holde, er en CI‑jobb som bygger databasen to ganger ved hver endring: én gang fra det ferske startskjemaet, én gang fra startskjemaet pluss alle migreringene spilt av i rekkefølge — og deretter sammenligner de to. Ikke bare strukturen, som er den enkle halvdelen, men også startdataene, fordi en migrering som etterfyller en oppslagstabell feil, er nøyaktig like skadelig som en som glemmer en kolonne, og bare én av dem vises i en skjemadiff. Ethvert avvik får byggingen til å feile, med forskjellen skrevet ut.

Resultat. Et nytt miljø og et langlivet miljø er den samme databasen, og det blir kontrollert i stedet for antatt. Kostnaden havner hos den som skriver en migrering: den må virke når den spilles av på nytt, og den må virke fra kald start, noe som krever mer omtanke enn en rask ALTER vanligvis får. Det er nettopp poenget — alternativet er å oppdage det under en gjenoppretting, når svaret betyr noe og det ikke er tid til å finne det ut.