Cookpit v3.2 — Publishable Generation Bundle

This directory holds the publishable artefacts for v3.2 Cookpit cooking files. A user (or an online tool acting on their behalf) gives these to an LLM of their choice along with a source recipe, and gets back a JSON-LD cooking file that the v3.2 validator can accept or reject.

The bundle is intentionally portable: any LLM may attempt the task. The validator is the gate — it tempers the model's enthusiasm by judging the output against the v3.2 JSON Schema, the rules in rules.md and the criteria in validation.md. Models that follow instructions well and support structured-output JSON will pass more often, but conformance is decided by the validator, not by the model's reputation.

The persona — rebel chef detective

The AI Chef writing the file is a rebel chef detective. They read the source recipe as a body of evidence — every ingredient line, every method sentence, every stated duration, every "add", "pour", "fold", "season" is a clue — and they deduce the optimal schedule the recipe implies. They do not transcribe the source method line by line. They write the deduced schedule in the rebel-chef voice defined in lexicon.md §0.

The detective stance has two consequences for every v3.2 file:

• Prep that the source mentions without a time gets placed by working backwards from the moment the prep is needed (Add the chopped onion → onion in pan at moment T → chop deadline T → place prep at T − chop duration). The new sourceImpliedDeadline timingBasis.basis records the deduction.
• Prep that satisfies its deadline trivially (chopping ahead, grating cheese ahead, beating eggs ahead) is promoted to cookpit.prerequisites. Prep is kept live only when quality, freshness, kitchen-flow or temperature reasons force it inside the cook window.

Files

File	Role
prompt.md	The optimised AI Chef system prompt.
rules.md	The concise governing rules, numbered for cross-reference.
lexicon.md	The chef language and terminology guide — persona, vocabulary, heat language, sensory cues, forbidden terms, allowed informalisms.
validation.md	The validation criteria, mapped 1:1 to the rules.
canonical-id-derivation.md	The canonical generation profile cookpit-ai-canonical-v3.2: per-entity-type rules for deterministic id derivation, with self-test vectors. Referenced by rules.md G3 and the validator's V-IDS-DETERMINISTIC check.
canonical-fingerprint-normalisation.md	The canonical normalisation cookpit-active-number-sequence-v3.2.0: tokenisation rules that turn a source recipe's text into the strict quantitative fingerprint sequence. Referenced by rules.md K3-K5 and the validator's V-FINGERPRINT-B check.
source-content-handling.md	Categorisation rules for the five kinds of non-method source content (sponsored / chrome / culinary explanation / structurally-actionable / source typo). Referenced by prompt.md and the corpus's prereq-note conventions.
canonical-units.md	The unit vocabulary used in cookpit.ingredients[].unit and adjacent fields. Seven classes (metric mass / volume, UK measure, imperial mass / volume, count and structural, semantic).
canonical-patterns.md	Six concurrency patterns + lane-model dual reading + leadTime scale + process-label phase qualifiers + detective-inserted check tasks + filename slug separator. Walk-confirmed patterns that the chef-detective and downstream consumers can rely on as canonical references.
glossary.md	The definitive field-by-field reference for the v3.2 schema. Treats v3.2 as a clean-slate format: every value defined by schema/cookpit-cooking-file-v3.2.json is documented (name, JSON type, purpose, constraints, references) in 15 sections. Indexes the v3.2 world rather than re-explaining it; cross-references the canonical documents above.
README.md	This file.

How they relate

• prompt.md is given to the LLM as the system message.
• rules.md is given to the LLM alongside the source recipe so it can self-check before emitting.
• lexicon.md is given to the LLM alongside the rules. It defines the voice — a rebel chef, easy-going and concise — that every active cooking instruction must adopt. The lexicon governs tasks[].action, tasks[].completion.cue, processes[].label, processes[].completion.cue and prerequisite items that carry a cooking action. It does not apply to declarative naming of ingredients, equipment, utensils or sundries.
• validation.md is the validator's specification. It is not given to the LLM; it is the operator-side / Chef-app-side acceptance test that the generated file must pass to be considered conformant v3.2.

The v3.2 JSON Schema (schema/cookpit-cooking-file-v3.2.json) sits beside this bundle as the executable structural contract.

The executable validator (scripts/validate_cookpit_v3.2.py) is the runnable embodiment of validation.md and the two canonical profiles above. Run it against any v3.2 candidate file to get a per-criterion pass/fail/warn/info report.

The three central principles of v3.2

1. Optimal. Every task time is the optimal moment an expert chef would commit to the action so the dish reaches its outcome — deduced from the source's evidence, not transcribed from its narrative order.
2. Closed. The plan is bounded by the resources declared in the file. Equipment is declared at heat-level abstraction: hob is a hob, regardless of whether the heat comes from gas, induction, electric, charcoal, wood-fire or a volcano.
3. Static. The plan does not adapt at runtime; the Chef app manages time and progress against the fixed plan. No padding, no filler, no stretched timings.

These principles are enumerated in prompt.md (for the AI), restated in section A of rules.md (for both the AI and the validator), and enforced through the criteria in validation.md (for the validator).

The four lifecycle stages

Every v3.2 cooking file passes through four stages, each with a single responsible actor and a single integrity question (rules.md A0):

#	Stage	Actor	Output	Filename flag	Integrity question
1	Generation	AI Chef	unauthenticated file with cookpit.attestation.status: "unauthenticated" and cookpit.quantitativeFingerprint (source)	U	"Has the AI faithfully captured the source's numbers?"
2	Validation	Canonical validator	pass / fail verdict	(input remains U)	"Does the file conform to v3.2 and faithfully reflect its source?"
3	Attestation	Canonical validator	authenticated file with fileFingerprint, signature, keyId, etc.	A	"Has the validator approved this exact file body?"
4	Consumption	Chef app / library / audit tool	trusted run, or rejection	A (verified)	"Has anything changed since the validator stamped it?"

The validator is the only actor that touches both the source-faithfulness check (stage 2) and the file-content certification (stage 3). It is the handoff between the two integrity questions, and the single trust authority that can issue an A file. AI Chefs never produce A files; consumers never accept files on filename flag alone.

Two distinct fingerprints support these stages:

• Source fingerprint at cookpit.quantitativeFingerprint (rules.md K, canonical-fingerprint-normalisation.md) — AI populates, validator confirms at stage 2.
• File fingerprint at cookpit.attestation.fileFingerprint (rules.md R, A0.6) — validator computes at stage 3, consumer verifies at stage 4.

The two fingerprints answer different questions and are not redundant. The filename's A/U flag is decorative; the cryptographic binding inside the attestation block is the load-bearing trust signal (rules.md A0.7, R10).