The fields verifyRecord takes from the stored record itself and hands back to
the extractor, so they reproduce whatever they say: the discovery metadata a
source supplied (a feed row, an aggregator row) is not archived, only the
documents are. What verify does check against archived bytes is everything the
extractor derives from them — full_text, qa, markers, the documents'
sha256 and the extraction stamp — plus the record's validators.
answered_by and dates are here even where the extractor first read them from
the paper (a ministry found in the text, Bayern's head): the stored value is
passed in and wins over the text, so an edit to it reproduces too. reference
and legislative_period are not: they make up the record id, so an edit to one
alone fails.
An edited title, asker, party, date, ministry or document URL used to pass as
"reproduced byte-identically" with nothing saying these were never compared.
The fields
verifyRecordtakes from the stored record itself and hands back to the extractor, so they reproduce whatever they say: the discovery metadata a source supplied (a feed row, an aggregator row) is not archived, only the documents are. What verify does check against archived bytes is everything the extractor derives from them —full_text,qa,markers, the documents'sha256and theextractionstamp — plus the record's validators.answered_byanddatesare here even where the extractor first read them from the paper (a ministry found in the text, Bayern's head): the stored value is passed in and wins over the text, so an edit to it reproduces too.referenceandlegislative_periodare not: they make up the record id, so an edit to one alone fails.An edited title, asker, party, date, ministry or document URL used to pass as "reproduced byte-identically" with nothing saying these were never compared.