ugglr · ugglr · Jun 3, 2026 · Jun 2, 2026
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -4,6 +4,13 @@ All notable changes to this project are documented here. Format follows [Keep a
 
 ## [Unreleased]
 
+### Added: one-command verdict and calibrated baselines (production-QA direction)
+
+- **Verdict banner.** `./run` now ends with a clear `SHAKEDOWN VERDICT: PASS/FAIL` banner (green/red on a TTY) summarizing the performance result, so a run finishes with an unambiguous answer instead of a JSON dump. Performance-focused (the batch-variance / thermal / memory / GPU defect class), not cosmetics.
+- **Calibrated baselines.** `make-baseline.sh` turns N known-good reports into `baselines/<preset>.json` (per-metric golden value plus a 3-sigma control limit, or a tolerance band below 8 samples). When `baselines/<preset>.json` exists for the `--target`, `./run` bins each metric against its golden limit and a metric outside its limit escalates the result to FAIL: the verdict becomes a calibrated pass/fail instead of within-unit advisory, recorded in the new optional `baseline_check` field. Absent a baseline, behavior is unchanged. Schema 1.4.
+- **`Verification/Production QA.md`.** An honest engineering gap analysis between Shakedown today and a factory production-QA station (calibrated limits, golden binning, Measurement System Analysis, gated preconditions, defect coverage / escape rate, SPC), and the architecture to close it. The calibrated-baseline mechanism is the first leg.
+- **Store Day Checklist** reframed to a single in-store flow centered on the one command (`./run --store`) and the verdict banner.
+
 ### Added: in-store verification toolkit (wave 8)
 
 - **`--store` thorough profile.** One flag for verifying a new unit (M5 especially): turns on `--noaccel` and `--gpu` and runs a longer warmup with more iterations, so an intermittent batch defect has more chances to surface. Honors any timing env vars the user set.
@@ -12,6 +19,7 @@ All notable changes to this project are documented here. Format follows [Keep a
 - **Phase 12 STREAM triad.** Memory bandwidth now prefers a vendored single-file STREAM triad (`stream-triad.c`: real copy / scale / add / triad), compiled at runtime with clang, no network. Falls back to the pure-Python `memmove` proxy when clang is unavailable. Closes the copy-only-proxy gap; `details.method` records which ran.
 - **Phase 14 `--llama` (opt-in).** Clones and builds llama.cpp at a pinned ref and runs `llama-bench`, a combined CPU+GPU+memory AI load (the workload class the M5 defect was reported on). Off by default; it reaches the network and runs third-party code (disclosed in SECURITY.md) and skips cleanly without git / cmake / network / model.
 - **Schema 1.3.** Phase 12 gains the triad method and `*_triad_gb_per_s` fields; new phase key `14_llama_bench` (a `skipped` placeholder by default), added to the CI submission-audit required-phase list. Backward compatible: both phase-12 methods keep `mean_copy_gb_per_s`, and 14 is skipped unless opted in.
+- **Store Day Checklist** (`Verification/Store Day Checklist.md`). A short, top-to-bottom run-this-then-that guide for verifying a unit at the store and then at the hotel, sitting on top of the Benchmark Reference. Linked first from the README and the Benchmark Reference.
 
 ### Added: roadmap completion (wave 7)
 

diff --git a/README.md b/README.md
@@ -41,7 +41,7 @@ Or without a preset, which auto-detects chassis class from `system_profiler` (fi
 
 The orchestrator runs the automated phases (preflight → inventory → battery → race benchmark → SSD test → memory bandwidth → CPU variance → thermal load) end-to-end, asks for sudo once upfront (Phase 5 and the SSD page-cache drop need it), and writes a SCHEMA-compliant report to `Reports/local/` plus a sanitized PR-able copy to `Reports/submissions/`. Opt-in flags add heavier passes: `--noaccel` (a non-accelerated BLAKE2b variance pass), `--gpu` (a Metal GPU compute pass), and `--llama` (clones and builds llama.cpp for a combined CPU+GPU+memory AI load). `--store` bundles the thorough profile for verifying a new unit. Runtime ~20 min on Intel, ~27 min on Air, ~47 min on MacBook Pro.
 
-> Verifying a new purchase, especially in a store you can't easily return to? The [Benchmark Reference](Verification/Benchmark%20Reference.md) is the install-this / run-this / expected-score guide (sourced per-generation Cinebench + Geekbench baselines, the in-store and hotel protocols, and crowd-sourced live-lookup links). To diff your unit against a known-good sibling, run `Verification/scripts/compare-reports.sh reference.json yours.json`.
+> Verifying a new purchase, especially in a store you can't easily return to? Follow the [Store Day Checklist](Verification/Store%20Day%20Checklist.md), a top-to-bottom run-this-then-that guide for verifying your machine in one sitting at the store. The [Benchmark Reference](Verification/Benchmark%20Reference.md) behind it has the sourced per-generation expected scores and live-lookup links, and `Verification/scripts/compare-reports.sh reference.json yours.json` diffs your unit against a known-good sibling.
 
 `./run --no-sudo` skips the 10-min thermal phase (the only phase that needs sudo) for a half-runtime no-password variance-only pass.
 
@@ -118,6 +118,8 @@ mac-shakedown/
 │   ├── Runbook.md                  # the procedure
 │   ├── Pass-Fail Criteria.md       # thresholds (parameterized by chassis class)
 │   ├── Benchmark Reference.md      # install/run/expected-score + in-store protocol
+│   ├── Store Day Checklist.md      # the one-command in-store flow
+│   ├── Production QA.md            # gap analysis: toward factory-grade QA
 │   ├── per-core-pinning.md         # why macOS has no per-core affinity (methodology note)
 │   └── scripts/
 │       ├── run-shakedown.sh        # the orchestrator (`./run` execs this)
@@ -132,7 +134,9 @@ mac-shakedown/
 │       ├── gpu-variance.sh         # opt-in Metal compute variance, swiftc at runtime → JSON
 │       ├── llama-bench.sh          # opt-in llama.cpp combined load (clone+build) → JSON
 │       ├── compare-reports.sh      # diff two reports (unit vs known-good sibling)
+│       ├── make-baseline.sh        # build baselines/<preset>.json from known-good reports
 │       └── display-test.sh         # fullscreen color cycle (HTML)
+├── baselines/                      # calibrated golden limits per SKU (mostly empty; built from known-good runs)
 ├── targets/                        # preset SKU configs
 │   ├── README.md
 │   ├── mbp-16-m5-max-64.json
@@ -190,10 +194,12 @@ Wave 7 shipped most of the original roadmap: the non-accelerated variance pass (
 
 Wave 8 added the in-store toolkit: the `--store` thorough profile, `compare-reports.sh` (diff your unit against a known-good sibling), a sourced [Benchmark Reference](Verification/Benchmark%20Reference.md), a vendored STREAM triad in Phase 12 (real copy / scale / add / triad), and an opt-in `--llama` phase that builds llama.cpp for a combined CPU+GPU+memory load.
 
+Since then: a one-command verdict banner on `./run`, a single-sitting [Store Day Checklist](Verification/Store%20Day%20Checklist.md), and the first leg of production-grade QA, calibrated golden baselines (`make-baseline.sh` builds `baselines/<preset>.json` from known-good runs; `./run` then bins against it for a calibrated verdict). [`Verification/Production QA.md`](Verification/Production%20QA.md) is the honest gap analysis to a factory-grade screen.
+
 Still open:
 
 - **Hosted aggregator.** Eventually, submission via API to a public site so reports aren't reviewed by hand. Until then, the PR-submission flow above *is* the aggregator. Slower, but no infra, and PR review catches PII before merge.
-- **Calibrated v0.3 thresholds.** The race / SSD / memory-bandwidth / GPU phases are informational in v0.2. Once the submission corpus has per-SKU baselines, they get chassis-family pass/fail bands. The SSD floor is the only band today, and it's a conservative sanity floor (flags below 500 MB/s with the cache dropped), not a calibrated range.
+- **A corpus to calibrate against.** The mechanism now exists: `./run` bins against a golden baseline when `baselines/<preset>.json` is present (`make-baseline.sh` builds one from known-good reports), turning the verdict calibrated. What is still missing is the population of known-good units to characterize, plus a Measurement System Analysis (is our gage error small vs the tolerance?) and gated preconditions. [`Verification/Production QA.md`](Verification/Production%20QA.md) lays out the full path to a production-grade screen.
 - **Per-core pinning.** macOS lacks public CPU affinity APIs, so we can't pin workers to specific cores; a defective single core gets averaged across N P-cores. Reporting `worker_imbalance_pct_per_iter` is the partial mitigation. The investigation is written up in [`Verification/per-core-pinning.md`](Verification/per-core-pinning.md): the short version is that `THREAD_AFFINITY_POLICY` is ignored on Apple Silicon and QoS hints only steer between the P and E clusters, so there's no per-core pinning to be had today.
 
 ## Origin

diff --git a/Reports/SCHEMA.md b/Reports/SCHEMA.md
@@ -9,7 +9,7 @@ Every QA run produces two artifacts in `Reports/`:
 
 | Field | Type | Required | Notes |
 |---|---|---|---|
-| `schema_version` | string | yes | Semver of the schema. Currently `"1.3"`. |
+| `schema_version` | string | yes | Semver of the schema. Currently `"1.4"`. |
 | `shakedown_version` | string | yes | Tool version that produced the report (e.g. `"0.1.0"`). |
 | `timestamp` | string | yes | ISO 8601 UTC. |
 | `illustrative` | bool | no | `true` for hand-crafted samples (under `examples/sample-report-*`). Aggregator must filter these out. |
@@ -19,6 +19,7 @@ Every QA run produces two artifacts in `Reports/`:
 | `phases` | object | yes | One key per phase (see Phase shape). |
 | `result` | string | yes | `"PASS"` / `"FAIL"`. |
 | `result_reason` | string | yes | One-line summary. |
+| `baseline_check` | object\|null | no | The calibrated golden-limit binning (see below). Non-null only when a `baselines/<preset>.json` exists for the target; `null` otherwise. |
 | `submission_safe` | bool | yes | Orchestrator's assertion that no PII is present. |
 | `store_location` | string\|null | no | Opt-in only. |
 | `purchase_date` | string\|null | no | Opt-in only. |
@@ -347,6 +348,25 @@ The hash is genuinely useful for **deduplication**: the aggregator can detect re
 
 A future hosted aggregator should rotate to HMAC-SHA-256 with a per-deployment secret, so the aggregator-side dedup works but external attackers can't recover the serial. Until that lands, the threat model is: aggregator operator can recover serials; everyone else can't.
 
+## Calibrated baseline check (`baseline_check`)
+
+Present (non-null) only when `baselines/<preset>.json` exists for the `--target` SKU. It is the production-QA-style binning of this unit's metrics against golden control limits derived from known-good units (see [Production QA](../Verification/Production%20QA.md) and `Verification/scripts/make-baseline.sh`). When present, a metric outside its limit escalates `result` to `FAIL`, turning the verdict from advisory (within-unit only) into calibrated.
+
+```json
+"baseline_check": {
+  "baseline_preset": "mbp-16-m5-max-64",
+  "n_samples": 12,
+  "verdict": "pass",
+  "checks": [
+    {"metric": "4_cpu_variance.mean_mb_per_s", "value": 23110.5, "golden": 23089.0, "min": 21934.6, "pass": true},
+    {"metric": "12_memory_bandwidth.mean_triad_gb_per_s", "value": 402.1, "golden": 404.0, "min": 383.8, "pass": true},
+    {"metric": "5_thermal_load.cpu_die_temp_c.max", "value": 96.4, "golden": 94.8, "max": 101.2, "pass": true}
+  ]
+}
+```
+
+Each check carries the measured `value`, the `golden` reference, and either a `min` (higher-is-better metrics) or a `max` (lower-is-better), plus `pass`. `verdict` is `fail` if any check fails. `baseline_check` is `null` (and the verdict stays within-unit advisory) when no baseline exists for the SKU, so reports without a baseline omit the binning and remain valid.
+
 ## Versioning policy
 
 - **Patch bumps (1.0.0 → 1.0.1)** add optional fields. Old aggregators read the new reports fine.
@@ -361,3 +381,4 @@ If a test methodology changes (e.g. variance test gains a new metric, or thresho
 - **1.1** → added phases 10_race_bench and 11_ssd_test (informational; pass/fail thresholds pending v0.3 calibration corpus). Backward compatible: reports without these phases still validate as 1.0 shape.
 - **1.2** → added phases 12_memory_bandwidth (informational), 4b_cpu_variance_noaccel (opt-in non-accelerated variance, real pass/warn/fail when run), and 13_gpu_variance (opt-in Metal compute, informational). Added a conservative warn-only floor to 11_ssd_test (`ssd_floor_mb_per_s`) and split the `active-cooled-pro` thermal class into `active-cooled-pro-14` / `active-cooled-pro-16` (the bare class stays valid as the 16"-equivalent, so older reports and presets still compare). Backward compatible: 4b and 13 are `skipped` placeholders unless opted in.
 - **1.3** → Phase 12 now prefers a vendored STREAM triad (`details.method` is `stream-triad` or the `memmove-proxy` fallback; new `*_triad_gb_per_s` / `mean_scale_gb_per_s` / `mean_add_gb_per_s` fields). Added phase 14_llama_bench (opt-in `--llama`: clones/builds llama.cpp and runs llama-bench, a combined CPU+GPU+memory load; informational, `skipped` unless opted in). Backward compatible: both phase-12 methods keep `mean_copy_gb_per_s`, and 14 is a `skipped` placeholder by default.
+- **1.4** → added the optional top-level `baseline_check` object: when `baselines/<preset>.json` exists for the target, the run bins each metric against a golden control limit and a metric outside its limit escalates `result` to FAIL (a calibrated verdict instead of within-unit advisory). Added `make-baseline.sh` (builds a baseline from known-good reports) and the `baselines/` directory. Backward compatible: `baseline_check` is `null` and the verdict stays advisory when no baseline exists, so it is not a required field.
diff --git a/Verification/Benchmark Reference.md b/Verification/Benchmark Reference.md
@@ -7,6 +7,8 @@ tags: [verification, benchmarks, reference]
 
 Shakedown's own thresholds are not yet calibrated against confirmed-good hardware, and its default workload (SHA-256) is hardware-accelerated, so the harness is a structured *consistency* check, not an absolute pass/fail. Published third-party benchmarks fill the other half: an absolute floor your unit should clear when cool, plus a crowd-sourced distribution of real units you can compare against. This is the "install this, run this, your unit should score about X" companion to the [Runbook](Runbook.md), tuned for catching a bad unit (the M5 Max especially) in a store you cannot easily return to.
 
+> In a hurry at the counter? The [Store Day Checklist](Store%20Day%20Checklist.md) is the short, top-to-bottom run-this-then-that version. This page is the detailed reference behind it (expected scores, sources, caveats).
+
 Use it alongside the harness:
 - `./run --store` runs the thorough profile (both CPU workloads, GPU, longer warmup, more iterations) for the structured variance and thermal verdict.
 - `compare-reports.sh REFERENCE.json UNIT.json` diffs your unit against a known-good sibling, which is the most trustworthy signal while the absolute thresholds are uncalibrated.