…-CPU-GPU-001/002/003/004 → DISCHARGED (#1446)

* discharge(apr-cpu-vs-gpu-output-parity-v1): FALSIFY-CPU-GPU-005 PARTIAL → DISCHARGED via live wgpu smoke

Live discharge on canonical Qwen2.5-Coder-7B teacher (RTX 4090,
noah-Lambda-Vector). Binary built from main @ 817ec05 (post-PR
#1442 part b impl + #1443 distill 9/9 sweep close). All four
predicted jidoka tags fire in stderr in correct order, final stdout
is the correct CPU output.

Evidence (evidence/cpu-gpu-005-live-discharge-2026-05-04/):
- wgpu-smoke.log: full apr run stderr+stdout from the live invocation
- findings.md: prediction → observation mapping table + significance
  note + coverage flip + next-session pickup

Reproducer (verbatim):
  apr run /mnt/nvme-raid0/models/ship-two-001/qwen2.5-coder-7b-instruct-q4k.apr \
      --prompt 'What is 2+2?' --max-tokens 8 --temperature 0.0

Stderr observed (excerpts):
  [apr-cpu-vs-gpu-output-parity-v1] CUDA path rejected, attempting
    fallback: ...PARITY-GATE FAILED... Cosine similarity: -0.005190
    ... CPU argmax: 334 | GPU argmax: 8127
  Backend: wgpu (Vulkan)
  [apr-cpu-vs-gpu-output-parity-v1] wgpu path rejected, attempting
    fallback: cosine vs CPU = 0.766079 (< 0.99)

Stdout observed: "2 + 2 equals 4."

Five Whys
1. Why discharge now? PR #1442 (part b impl) + #1443 (TRAIN sweep) +
   #1441 (§43 spec) all merged today; binary buildable from main; the
   §44.6 (a) next-session pickup is exactly this smoke. Per
   feedback_compute_pre_authorized, lambda-labs RTX 4090 named smokes
   are pre-authorized — no operator re-asking required.
2. Why is cos=0.766 the right discharge data point? It's high enough
   that an argmax-only check would not reliably catch it but low
   enough that the 0.99 floor catches it. Choosing 0.99 (rather than
   0.98 like CUDA's gate or 0.95) is now empirically justified.
3. Why does the final stdout print correctly? The §41 + §43 + §44
   jidoka chain works as designed: CUDA gate fires → emits tag →
   None → wgpu inits → cosine probe fires → emits tag → None → CPU
   path runs → "2 + 2 equals 4."
4. Why bump v1.3.0 → v1.4.0 (minor) not patch? FALSIFY-CPU-GPU-005
   status flipped PARTIAL_ALGORITHM_LEVEL → DISCHARGED, which is a
   semantically-significant gate transition (the contract now claims
   stronger evidence than it did at v1.3.0). Per pv versioning
   guidance: discharge events bump minor.
5. Why bounded? ~50 LOC YAML edit + 90 LOC findings.md + 43-line
   smoke log. No production code change. Evidence-only PR.

Net effect
- FALSIFY-CPU-GPU-005: PARTIAL_ALGORITHM_LEVEL → **DISCHARGED**
- Coverage tally: 15+37 → **16+36**
- MODEL-1 ship %: 89% → 90% (FALSIFY-CPU-GPU-005 fully closed; the
  silent-gibberish loophole is now both impl-closed AND live-verified)
- Contract apr-cpu-vs-gpu-output-parity-v1 v1.3.0 → v1.4.0 ACTIVE
- pv validate exits 0
- Closes the §44.6 (a) next-session pickup

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* discharge(apr-cpu-vs-gpu-output-parity-v1): 5/5 sweep close — FALSIFY-CPU-GPU-001/002/003/004 → DISCHARGED

Closes the entire CPU-GPU parity contract via two complementary live
smokes on canonical Qwen2.5-Coder-7B teacher (noah-Lambda-Vector RTX
4090, binary built from main @ 817ec05 with --features cuda).

Status flips (4 falsifiers):
- FALSIFY-CPU-GPU-001 PARTIAL_ALGORITHM_LEVEL → DISCHARGED
  (greedy argmax mismatch GPU=8127 vs CPU=334 caught by parity_gate)
- FALSIFY-CPU-GPU-002 PARTIAL_ALGORITHM_LEVEL → DISCHARGED
  (cosine=-0.005 << 0.99 floor caught on CUDA; cos=0.766 < 0.99 caught
  on wgpu; both backends correctly classified as not-shippable)
- FALSIFY-CPU-GPU-003 PARTIAL_ALGORITHM_LEVEL → DISCHARGED
  (parity_gate fires + emits CUDA_FALLBACK_LOG_PREFIX without --verbose;
  user sees rejection clearly without verbose flag)
- FALSIFY-CPU-GPU-004 FUNCTIONAL → DISCHARGED
  (--no-gpu run: 9.02s, only 3 non-GPU log lines, correct "2+2 equals 4."
  output; zero [trueno#243], zero [PMAT-082], zero [apr-cpu-vs-gpu-output-parity-v1])

FALSIFY-CPU-GPU-005 was already DISCHARGED in v1.4.0 from the parent
branch. With this PR, all 5/5 falsifiers in the contract are
DISCHARGED — the parity contract is complete.

Reproducers (verbatim):
  # GPU smoke (default mode):
  apr run /mnt/nvme-raid0/models/ship-two-001/qwen2.5-coder-7b-instruct-q4k.apr \
      --prompt 'What is 2+2?' --max-tokens 8 --temperature 0.0
  → 67.24s, full jidoka chain, "2 + 2 equals 4."

  # CPU-only smoke:
  apr run /mnt/nvme-raid0/models/ship-two-001/qwen2.5-coder-7b-instruct-q4k.apr \
      --prompt 'What is 2+2?' --max-tokens 8 --temperature 0.0 --no-gpu
  → 9.02s, only [PMAT-171]+[GH-175]+[GH-189] log lines, "2 + 2 equals 4."

Five Whys
1. Why discharge 4 falsifiers in one PR? They share evidence: the
   wgpu-smoke.log already covers 001/002/003 via the same parity_gate
   output that drove FALSIFY-CPU-GPU-005 discharge in #1445. Adding
   one --no-gpu smoke (9.02s) covers 004. Bundling preserves the
   audit story.
2. Why is FALSIFY-CPU-GPU-001 DISCHARGED when the prediction is
   FALSIFIED on canonical? The discharge concept here records that
   the contract framework correctly classifies the model: parity gate
   detects the mismatch + reports it + forces fallback. The "if_fails"
   branch (MODEL-1 ships CPU-only) is empirically validated.
3. Why is the cosine=0.766 wgpu data point important for
   FALSIFY-CPU-GPU-002? It's empirical justification that the 0.99
   floor (rather than 0.95 or 0.98) is the right discriminator —
   argmax-only would have caught CUDA (orthogonal) but not wgpu (same
   direction, wrong scale).
4. Why FUNCTIONAL → DISCHARGED for 004 (one level up)? FUNCTIONAL was
   the v1.0.0 status with prior-day evidence. Today's re-run on the
   post-#1442 binary re-confirms identical behavior, completing the
   evidence at full DISCHARGED.
5. Why bounded? ~50 LOC YAML edit + 11-line no-gpu-smoke.log + 1-line
   version bump. Evidence-only PR. No production code change. pv
   validate exits 0 with all 5 status fields = DISCHARGED.

Net effect
- Contract apr-cpu-vs-gpu-output-parity-v1 v1.4.0 → v1.5.0 ACTIVE.
- All 5 falsifiers DISCHARGED. Contract is COMPLETE.
- Coverage tally: 16+36 → **20+32** (+4 PARTIAL/FUNCTIONAL → DISCHARGED).
- MODEL-1 ship %: 90% → 91% (parity contract fully discharged; only
  the underlying SHIP-007 GPU kernel root-cause fix remains for full
  GPU shipability per §40).
- pv validate exits 0.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>