Part 7 — Conformance

What it takes to say "this shop serves DBNF labels" — and mean something verifiable by it.

DBNF-1 · Part 7 Normative

7.1Levels

Level	Name	One-line meaning	Typical adopter
L1	Static	Every standard menu drink has a DBNF-formatted label available at or before purchase.	A café that prints labels from its published menu once a season.
L2	Dynamic	Declared values are recomputed for the as-ordered drink — size, sweetness, syrups, milk, toppings.	A boba shop with a POS plugin; the reference implementation.
L3	Connected	L2, plus machine-readable labels and open recipe data.	A regional chain with a deposit-cup fleet.

Levels are strict supersets. A claim of "DBNF conformant" without a level means L1. The level claimed applies per location, not per brand.

7.2L1 checklist — Static

Every standard menu beverage has a label following the Part 1 element stack (§1.2), including the Caffeine row and DBNF mark.
Declared values follow the Part 3 rounding rules; %DV computed from unrounded values.
Labels are available at or before the point of sale — on the cup, at the counter, or via QR at the register. "On our website" alone does not satisfy this.
Serving sizes state both fl oz and mL and match what is actually served at regular ice.
Labels are regenerated whenever a recipe changes, and dated (meta.generatedAt).

7.3L2 checklist — Dynamic

All L1 items.
The calculation engine implements pipeline stages 4–5 (sweetness, pumps, shots) at minimum, and stages 1–3 and 6 wherever the menu offers those modifications.
Engine passes the Part 2 §2.10 and Part 3 §3.7 test vectors.
Invariants (Part 2 §2.7) enforced; estimation fallbacks flagged (sizeMethod, sweetnessMethod).
The label reflects the as-ordered drink before order confirmation on kiosks/apps, and on the cup or receipt for counter orders.
Vendor-measured modifier tables (milks, syrups, toppings) replace reference defaults for everything actually sold.
Warning flags computed per Part 3 §3.6; the 100%-DV added-sugar warning surfaces to the customer.

7.4L3 checklist — Connected

All L2 items.
Every label carries a Part 6 QR resolving to the full label (short link, deep link, or inline state).
DBNF documents validate against the Part 4 JSON Schema and are retrievable by id or canonical hash.
Recipe data (presets, milks, syrups, toppings) is published via the Part 5 API or an equivalent static export, refreshed within 7 days of any recipe change.
If a deposit fleet operates: cup IDs follow §6.3, the state machine per §6.4 is enforced, and the deposit ledger reconciles per §6.5.
Documents are immutable; corrections issue new documents (Part 4 §4.6).

7.5Test suite

The executable test surface today is the reference implementation's console API:

// Engine vectors (Part 2 §2.10) — run on the app page
const t1 = BevFacts.compute({ sugars:33, addedSugars:28, calories:250,
                              caffeine:150, sweetness:100, pumps:3, shots:2 });
console.assert(t1.calories === 320 && t1.sugars === 48 &&
               t1.addedSugars === 43 && t1.caffeine === 300, "T1");

// Rounding vectors (Part 3 §3.7)
console.assert(BevFacts.round.calories(324) === 320, "R-cal");
console.assert(BevFacts.round.gram(0.7) === "less than 1", "R-gram");
console.assert(BevFacts.round.sodium(146) === "150", "R-Na");

A standalone vector file (machine-readable, all Parts) ships with 1.0-final so engines can be tested without a browser. Until then, the tables in Parts 2–3 are the normative vectors.

7.6Self-certification

Run the applicable checklist (§7.2–7.4) and the test vectors (§7.5).
Publish a conformance statement at a stable URL: level claimed, spec version, engine name/version, date, and the checklist with each item affirmed.
Keep one sample DBNF document (or printed label photo) per menu category from the certification date, for audit.
Re-certify on any major-version bump, engine change, or menu-wide recipe revision.

Self-certification is deliberately lightweight — the standard's enforcement mechanism is that labels are checkable: anyone with the published recipe data and this spec can recompute any cup in the room. Sunlight, not audits.

7.7Badge usage

Rule	Detail
Form	`DBNF · L2` (level always stated) adjacent to the menu or door decal; the mark string on labels is Part 1 §1.2 row 17 and carries no level.
Scope	Per location. A brand `MUST NOT` badge locations that don't individually conform.
Revocation	The badge claim `MUST` be withdrawn while conformance is broken (engine bug, stale recipes) — a wrong label with a badge is worse than no label.
No endorsement	The badge asserts process conformance, not nutritional virtue. A 90 g-sugar drink with an honest label is conformant.

7.8Versioning & governance

Semantic versioning over the whole spec: breaking changes to the data model, pipeline order, or rounding bump the major version; new optional fields, modifier types, and endpoints bump the minor. Documents pin their version via the dbnf field; QRs printed under any 1.x MUST resolve under every later 1.y (Part 5 §5.1.1).

The spec is developed in the open at github.com/DomTheDeveloper/BevFacts — changes by pull request, discussion by issue. Research notes live in /docs/ (LABEL-RULES.md, BUSINESS-IDEAS.md, NAMES.md). The standard is open and royalty-free: implementing DBNF requires no license, fee, or permission — that's a design requirement, not a courtesy (Part 7 exists so a two-person boba shop can conform with a $40 thermal printer).