Before downloading, readers see a card; afterward they see the file’s own notice. Reading the resource card, generator and content schema together led me to define a consistency contract for those two descriptions.
Matching wording alone is insufficient
Identical statements can still point to different versions. Notice comparison checks asset, language, version and statement together, rejecting missing fields and naming differences. It verifies that descriptions refer to the same declared object rather than deciding actual permission.
The original site’s usage terms were not copied into a new document. A new modification-and-reuse notice applies to original synthetic shapes only. No third-party resource or lesson photo is included, avoiding an unsupported assumption about original rights. Substantive permission and presentation consistency remain separate questions.
Consider changes that split card and file
A regenerated file might leave an old card version, or a translated card might describe another language. These are reviewable conditions, not invented incident reports. The synthetic counterexample changes only one version to v2 and returns version among the differences.
A date in a notice also needs meaning: asset version and review date are not interchangeable. This contract compares a version string without interpreting its policy. Content operations must define that policy; string equality cannot explain every change-history question.
Read the notice inside an actual PDF
The printing module’s single-page PDF has a new synthetic notice in its footer. The generated file was reopened and text-extracted to check the NOTICE string; its example record retains the same statement and v1. This goes beyond checking only what a download card displays.
The rendered image was also inspected for separation from body text and cutting line. That is a file-content and placement check for this new example, not review of customer rights or a legal opinion. The generating code retains the same notice constant for reproducibility.
Consistency does not create rights
Consistent true does not identify who holds permission; rights certification remains false. Two locations could repeat the same incorrect statement and still match. Presentation checks and original-rights review therefore need separate completion records.
A real file replacement should check card version, file version and the currently served link together. Retaining an old asset also requires clarity about what the current card downloads. Separating machine-detectable mismatch from human permission review makes the tool useful without overstating it.
Explain one resource from card to file
The evidence package’s twelve tests include matching notices, version mismatch and missing fields. The PDF has its separate twelve geometry tests plus extraction and visual review. Those distinct checks are not combined into a claim of completed rights clearance.
For a maker, adding a download button does not complete the resource. Expectations before receiving it should connect to the file’s explanation afterward. The reusable structure traces which notice version belongs to which asset and language; another format can begin with those same four fields.
Translation equivalence needs its own review
Different languages require separate notice pairs. Their wording need not be identical across languages, but a person must review whether the meaning of the usage conditions is preserved. Notice comparison checks two locations for the same asset language and version; it does not assess translation adequacy. A multilingual download workflow should record that review separately rather than treat matching identifiers as proof that both audiences received the same substantive explanation.