When validation changes the draft you reviewed

A valid draft can still be a different draft#

A validator can accept a record while normalizing its content. Trimming a text value is a small example, but it still means the accepted payload differs from the file someone reviewed.

The handoff runner compares canonical content hashes before and after validation. If they differ, the draft needs to be normalized and reviewed again. Indentation and object-key order do not change the canonical content, so formatting alone does not trigger that result.

Three identities answer three different questions#

The fileSha256 value identifies the original bytes. contentHash identifies the canonical payload. validatorSha256 identifies the validation module used for the check.

A changed file hash with an unchanged content hash points to serialization differences. A changed content hash means the payload changed. The validator hash records which module performed the check, but does not include its dependencies. None of these hashes is an approval receipt or a signature.

Check the bundle, not just individual records#

The runner also requires Draft status, rejects publication dates and checks IDs and slugs for duplicates. Each article must link to a project supplied in the same bundle.

That rule keeps the check self-contained, but means an article about an existing project still needs its project file beside it. The runner does not query the content store to resolve missing links. It returns a local report and leaves saving and publication to the portfolio.