How should a human-readable page, structured data, canonical JSON, downloadable file and API carry the same truth?

Direct answer

Link every publication family to one canonical record set. The human page may offer an intelligible account; structured data, discovery fields; canonical JSON, the complete machine record; a PDF or DOCX, a fixed reading edition; and an API, programmatic access. These surfaces need not match word for word. They do require field-level parity for record identity, question, normative status, principal ruling, version, date, sources, licence and limitations. A parity statement explains any difference as a permitted summary, access restriction, lag or error.

In plain language

Think of a restaurant's wall menu, online menu and till price list. Their designs may differ, but the same dish must have the same name, price and allergen information. An old price on one surface is not a design difference; it is a conflict about reality.

Why this matters

If people, AI systems and downloaded files receive different information, it becomes unclear which version is authoritative. Outdated JSON or an incomplete API record can keep an inaccurate representation alive even after the human page is corrected.

Do not confuse

A presentation difference shows the same truth in a form suited to a different reader.
A permitted summary is shorter but preserves the principal meaning and limit.
Semantic drift strengthens, weakens or changes a ruling during summarisation or transformation.
Data lag means that a surface has not yet reached the new version and requires an explicit status.
A factual conflict occurs when two surfaces give incompatible values for the same field.

What should you do?

Designate one canonical data source containing record identifiers and parity-critical fields.
Record how each surface presents each canonical field in a field-mapping table.
Validate JSON and API output against a versioned schema; do not silently invent unknown or missing fields.
Where possible, generate HTML, JSON, download files and API output from the same locked source.
Link surface version, generation time, file hash and canonical record in a parity statement.
Run automated parity tests for identity, ruling, normative force, source, limit, date and licence.
Stop publication on a critical conflict; if a surface lags, mark it explicitly as outdated or pending.

How do you audit it?

Are all surfaces linked to the same record identifier and version family?
Do the human narrative and machine field carry the same principal ruling?
Does one surface make a requirement mandatory while another presents it as advice?
Were sources, dates, licence or limitations lost?
Were JSON and API output validated against the applicable schema?
Is the version and file-integrity relationship between the download and live page recorded?
Was a lagging surface presented as current?

Limit

Parity does not mean that every surface must be byte-for-byte identical. Accessibility, privacy, security, file format or user needs may require different presentation of some details. If an omitted field affects material meaning, however, the difference and reason must be visible.