r365 System Card

Technisches Originaldokument auf Englisch

Version: r365 2.0.0 (2026-09-22) Status: Deployed as a closed beta (hosted on Cloudflare containers with the state mirrored to Cloudflare storage; sign-in through WorkOS). Not launched: public launch waits on the internal launch gate and on the open findings of the 2026-09-22 release-readiness audit.

(a) What r365 is and what it is not

r365 is a meal-planning tool for households with complex dietary requirements. It computes, adapts, and certifies a household’s week of food from audited data whose every version is identified by a fingerprint of its content. Every number is calculated by a deterministic engine and traced back to its data source.

r365 is not intended as a medical device and has not been assessed as one, and it does not provide medical advice. It does not diagnose conditions, recommend treatments, or interpret lab values. When the engine cannot model a medication or condition, it says so explicitly — it never substitutes a guess.

It does, however, adjust a member’s nutrient targets and upper limits when a condition (for example a kidney condition) or a medication (for example an ACE inhibitor) is recorded, using general published recommendations bound in the evidence register. These condition- and medication-driven adjustments are under legal review for their medical-device implications (intended purpose under the Swiss Medical Devices Ordinance and the EU Medical Device Regulation; see an internal legal-safety review of 2026-09-23) and have not yet been reviewed by a physician or dietitian. This posture is “clinical-grade data honesty” in the sense of being provably derived, not in the sense of being a clinical intervention.

The legal opinion on the intended purpose (EU Medical Device Regulation / Swiss Medical Devices Ordinance) is a go/no-go gate before any public listing copy is finalised. Planned wording: “a computationally verified meal-planning engine for households with complex dietary requirements.” Do not read this card as a substitute for that opinion.

(b) The constitution — five rules, enforced by automated checks

The engine’s five founding rules, in plain words:

ADEQUACY OVER PREFERENCE. Taste, sustainability, variety and novelty always rank strictly below nutritional adequacy and hard safety, and a proof that this ordering holds is checked every time the engine starts.

DERIVED, NOT ASSERTED. Nutrition, dietary flags, allergens and safety exclusions are computed from the verified food data every time they are used; they are never stored as a fact of their own.

NO AI MODEL AT SERVING TIME. Planning and adaptation never call a language model. Language models only help author new recipes (checked and scored before admission) and turn free-text wishes into proposed changes a person confirms.

VISIBLE DEGRADATION. When data or a method falls short, the result says so in a written notice — a silent fallback is not allowed.

IF THE ENGINE CAN’T DERIVE IT, WE SAY “WE DON’T KNOW.”

Enforcement: Rule 1 — a proof that the adequacy floor holds runs every time the engine starts, and the optimiser’s priority tiers keep adequacy above preference. Rule 2 — allergen status is recomputed from the ingredients on every use. Rule 3 — an automated structural test inspects every part of the engine and fails if anything outside the authoring code can load the AI provider’s library. Rules 4 and 5 — every shortfall is a typed note, and conditions and medications the engine does not model are listed explicitly so that the certificate must say so.

© How serving works

The serving path — weekly planning, recipe adaptation, recipe verification, and every tool the assistant connector offers — runs a deterministic mathematical optimiser (mixed-integer linear programming with SciPy). No model is invoked, no prompt is sent, and no AI provider key is used at serving time. An automated structural test proves this: the AI provider’s library is absent outside the authoring code, and the assistant server, the web service and the local app cannot load the authoring code at all. See the design decision.

Language models are used in authoring only: recipe synthesis and the conversational intake that turns free-text wishes into proposed changes. Both are gated: synthesised recipes pass through a judge; intake proposals wait for explicit human confirmation. Authoring results enter the fingerprinted data build; they never serve facts directly.

(d) Data provenance

The data was inherited verbatim from Regional 365 on 2026-06-10, with a full internal provenance record. Key counts: 1,312 fully verified ingredients; 1,242 anchor recipes; 382 cited knowledge-base truths (261+ nutritional, 54 culinary, 48 flavor, 14 environmental); D-A-CH and EFSA reference targets.

Swiss federal reference values (BLV, 2022) check (2026-07-03): vitamin D 15 µg, folate 330 µg DFE, fiber 30 g confirmed against the BLV reference values of September 2022. Potassium deferred — absent from the BLV export; the EFSA candidate of 3,500 mg was not applied at that time.

Fresh-eyes allergen adjudication (2026-07-02): 4,300 three-state verdicts across six previously inoperative EU Annex II allergens, under a safety-conservative rubric (an ingredient is marked free of an allergen only when that is obviously the case; everything else stays “unknown”, which is disclosed). All 14 EU Annex II allergens are now operative. The counts below are pinned by an automated test:

Allergen	Contains	Free	Unknown
celery	9	1,287	9
mustard	7	1,294	4
shellfish (crustacean)	8	1,297	0
sesame	8	1,163	134
sulphites	39	881	385
lupin	2	1,089	214
peanuts	13	27	1,265
molluscs	6	2	1,297

Peanuts and molluscs were split from their parent nut and shellfish categories on 2026-07-03; their high unknown counts reflect the state before the split and are work in progress.

(e) Safety model

Propose, then confirm. Safety-touching changes (allergens, conditions, medications) are never applied automatically. The engine validates a proposed change, stores it for a limited time, and waits for an explicit confirmation by a person — the only way such a change is written.

Three-state allergens. Every allergen field is yes, no, or unknown. Unknown is treated as unsafe — an ingredient with unknown status is excluded, never silently passed. The EU 1169/2011 three-state declaration is embedded in every certificate.

Modelled conditions (11) — the engine adjusts targets, tightens upper limits, or excludes ingredients for: iron deficiency, heavy menstrual bleeding, osteoporosis, PCOS, endometriosis, acid-reducing medication (PPI) use, heart condition, kidney condition, diabetes, hemochromatosis, histamine intolerance.

Unmodelled conditions (3) — the engine recognises but does NOT model these; the certificate carries an explicit note that they are managed by a clinician: gestational diabetes, a history of gestational diabetes, a history of preeclampsia.

Modelled medications (12): metformin, statins, oral contraceptives, ACE inhibitors, angiotensin receptor blockers (ARBs), GLP-1 agonists, trimethoprim, loop diuretics, anticonvulsants, methotrexate, potassium-sparing diuretics, MAO inhibitors.

Unmodelled medications (11): allopurinol, apixaban, dabigatran, edoxaban, levothyroxine, lithium, phenprocoumon, rivaroxaban, SGLT2 inhibitors, SSRIs, warfarin.

The modelled/unmodelled split is enforced automatically: every recognised condition and medication must be in exactly one of the two lists, and a newly added one fails the automated checks until it is consciously classified.

(f) Verification

Certificate. Every plan ships a SHA-256-sealed certificate. Seals verify against the stored bytes — a certificate sealed today verifies forever, even after the format gains fields. It records its format version, the computing environment (software versions and platform), the corrections made while planning, and the EU 1169/2011 three-state allergen declaration. See the certificate explainer.

The reproduce check. It re-derives a stored plan independently and checks that the seal is byte-identical. A different computing environment is reported as its own verdict, ENVIRONMENT MISMATCH, rather than a false NOT REPRODUCED.

Proven adequacy floor (2026-07-03). A proof runs every time the engine starts: the worst-case swing at default weights is 0.24×100 + 3 + 0.5×115 + 3 = 87.5, which bounds the induced critical deficit at 4.375%; at the sustainability ceiling (×1.5) the bound is 4.625%. Both are strictly under the 5% tolerance the engine enforces, and an automated test pins them.

Automated checks. Linting, strict type checks and the full test suite must pass before any change ships — this card never claims ahead of them. Three reference households produce byte-identical plans across every code change that does not change the data build.

(g) Limitations

11 unmodelled medications (no target adjustment or food exclusion applied): allopurinol, apixaban, dabigatran, edoxaban, levothyroxine, lithium, phenprocoumon, rivaroxaban, SGLT2 inhibitors, SSRIs, warfarin. The certificate says so explicitly.
3 unmodelled conditions: gestational diabetes, a history of gestational diabetes, a history of preeclampsia. Same explicit note.
Allergen unknowns remain (treated as unsafe, not as free): peanuts 1,265 unknown, molluscs 1,297, sulphites 385, lupin 214, sesame 134.
Potassium adult target resolved — 3,500 mg is applied to adult rows (BLV/EFSA chain confirmed 2026-07-03). Senior, child and pregnancy rows remain D-A-CH lineage (covered under limitation 5).
Non-adult life-stage reference rows (children, adolescents, pregnancy and lactation) are D-A-CH lineage without a completed check against the Swiss BLV 2022 values.
Unmeasured nutrients on some foods — the largest gap is selenium (unmeasured on 393 of 1,305 foods, 30.1%; the Swiss food composition database has no value and filling from the USDA database is pending); smaller gaps exist for other nutrients. The engine counts an absent value as zero before summing, so a certificate total is a lower bound. This is now disclosed, not silent: every nutrient claim reports the share of ingredient mass and the number of ingredients that were actually measured, and each EFSA or clinical upper limit adds an advisory when unmeasured ingredients mean the limit saw only part of the plate (the limit still enforces on the measured data — an upper limit can never trip on a contribution that was counted as zero). The disclosure narrows the trust gap; it does not fill the data — unmeasured stays unmeasured until the values are sourced.
Swiss food composition cross-reference incomplete — 359 ingredients without a match; 165 proposed matches (89 from the Swiss database, 76 from the USDA database) await a founder decision.
Single-account households — no household sharing, invitations, or roles.
Mid-week replanning and meal swaps exist. Each replan or applied swap produces a new sealed revision that never overwrites the earlier ones; a week is capped at 10 revisions. Residual limitation: swap suggestions are drawn from the week’s stored choices — the full set of candidates the optimiser considered is not kept, so the previews show estimated differences only; applying a swap re-solves the whole week and seals the result as a new revision. Shortfalls recorded in the cooking log carry forward to the next week.
Consent text is a placeholder — the current consent wording is marked as pending legal review, and every signup records that it was given under placeholder wording. The placeholder does not itself block signup; it must be replaced with reviewed wording before public launch.
Legal opinion on intended purpose pending — a go/no-go gate; listing copy is not final until the opinion exists.
Data protection impact assessment pending — required before answers about the handling of health data are finalised.
Hosted on a US provider (Cloudflare), identity on a US provider (WorkOS) — the data-protection assessment and consent text must describe these processors; the internal launch gate is not cleared.

(h) Privacy

Identity and accounts — WorkOS handles sign-in and identity information. The engine uses an identifier derived from the identity provider’s account identifier. This is not a promise that the identity provider collects no email address or name.

Separate storage per account — each account’s state (household settings, plans, cooking log, pending proposals) lives in its own dedicated database.

Logs free of health data, by construction — the logging layer keeps a list of forbidden health and identity fields; any attempt to log one of them fails before a log record is created, and a second filter on the log output guards the same rule. Operational logs carry structural facts only: which tool was used, the outcome, the duration, and an account identifier.

Data export — under the Swiss Federal Act on Data Protection, the assistant connector offers a data export that returns the complete account store as structured data. Swiss-only beta — the beta is limited to Switzerland. Local app stays on the machine — the local version of the app only listens on the computer it runs on; unauthenticated health data never leaves that machine.

The consent text is a placeholder (see limitation 10). No beta can open without counsel-reviewed wording under Art. 6(7) of the Federal Act on Data Protection.

(i) Evaluations

Honesty benchmark (planned). A public food-AI benchmark built from deliberately flawed test cases (an unsalted stew, dishes named after meat they do not contain, invented nutrition values) is planned and expected to ship with the public launch.

Until it ships, the primary public verification tool is the reproduce check on any stored plan: re-derive it, check the seal, and read the environment record.