Certificate explainer — what the seal means and how a plan is verified

Every plan produced by r365 ships a verification certificate: a structured document that traces every number to its data source and every exclusion to its clinical authority, and then seals the whole thing with a SHA-256 integrity hash.

What a certificate contains

• Nutrition coverage — per member and per nutrient, with every value traced to the ingredients that contribute it and to the cited knowledge-base entries behind it.
• Measurement coverage for each nutrient — every claimed total also reports how much of the contributing ingredient mass actually carried a measured value for that nutrient, and how many contributing ingredients were measured. An absent value is unknown, not zero, yet the engine sums it as zero — so a claim below 100% is a disclosed lower bound, never a silent one. For nutrients with an upper limit (from EFSA or a clinical recommendation), the certificate adds an advisory when unmeasured ingredients mean the limit only ever saw part of the plate. The limit is still enforced on the measured data; the advisory discloses that it saw partial data.
• Safety exclusions — every ingredient removed for a member, with the allergen or the medication or condition authority that triggered it.
• EU 1169/2011 three-state allergen declaration — for each of the 14 allergens in Annex II of the regulation: contains, free, or unknown. Unknown is always disclosed, never dropped.
• Degradations — amber notes for anything the engine cannot compute fully.
• Environment — the software versions and platform the plan was computed on, plus the fingerprint of the exact data build used to produce it.
• Integrity seal — a SHA-256 hash over the stored bytes of the certificate. The seal is computed once at creation and verifies forever against those exact bytes, even if the certificate format later gains new fields.

Certificates can be read as a self-contained web page or as structured data.

How a plan is verified

The reproduce check works like this:

1. It loads the stored plan’s inputs: the household configuration, the calendar week and the data build fingerprint.
2. It re-derives the plan from scratch with the same engine.
3. It seals the reproduced certificate from its own bytes.
4. It compares the two seals and every certificate field.

Possible verdicts:

• REPRODUCED — byte-identical seal; the plan is deterministic and unaltered.
• ENVIRONMENT MISMATCH — the software versions or platform differ from the sealing environment. This is reported as its own verdict rather than as a false NOT REPRODUCED. The content may still match; the mismatch is disclosed honestly.
• NOT REPRODUCED — the seals differ and the environment matches; the stored plan diverges from what the current engine would produce.
• SEAL BROKEN — the stored certificate’s integrity seal does not verify against its own bytes; the stored document was modified after sealing.

What ENVIRONMENT MISMATCH means

A certificate sealed on one machine (for example the server, with its particular Python and SciPy versions on Linux) will report ENVIRONMENT MISMATCH when reproduced on a different machine. This is expected and honest. The seal is still intact; the plan is still valid. The mismatch tells you that the determinism guarantee applies within matching environments, not across them — which is the correct, narrower claim.