# Progression-metric result — Review A Step 1

**Date**: 2026-05-27
**PRIMARY gate**: `swaps > 1 OR draws > 0 OR unique_render_targets > 0`.

## Composite progression score (per Review A Q5)

```
score = 1*swaps + 10*draws + 100*unique_render_targets
```

| Run | swaps | draws | unique_RT | score |
|----:|------:|------:|----------:|------:|
| OFF-1 | 1 | 0 | 0 | **1** |
| OFF-2 | 1 | 0 | 0 | **1** |
| OFF-3 | 1 | 0 | 0 | **1** |
| ON-1  | 1 | 0 | 0 | **1** |
| ON-2  | 1 | 0 | 0 | **1** |
| ON-3  | 1 | 0 | 0 | **1** |

- **OFF mean**: 1.0
- **ON mean**: 1.0
- **Δ (ON - OFF)**: 0

## PRIMARY gate verdict

**FAIL.** No swap beyond the boot-init swap; no draws; no render
targets.  The crowbar fires successfully (4/4 workers spawned and
resumed) but the workers fault ~159 instructions in on the unmapped
canary VA `0xBCE25640`, before they can advance the wedge or emit
PM4 draw commands.

## What "winning" would have required

Per `shortest-path-roadmap.md` §"What 'winning' looks like":

```json
{
  "draws": >= 1,
  "swaps": >= 2,
  "unique_render_targets": >= 1
}
```

reproducible across 3 cold runs.  Observed: all 0/1/0 across 6 runs
(3 OFF + 3 ON).  Matches v3's 2026-05-21 outcome bit-for-bit at the
progression-metric level (Δ = 0).

## Why the crowbar didn't unblock

Per v3 `investigation.md` §"The fault (v3)" and re-validated this
session: the worker entry stubs at `0x82506528/58/88/B8` dispatch
through `vtable[35..38]` to fns like `sub_82506E08`, `sub_82508520`,
etc.  Those fns immediately load `[ctx+44]` into r3 expecting a
secondary-object pointer (per canary's runtime ctx state).  In v3 the
secondary-object pointer was captured as `0xBCE25640` and installed
verbatim per Option γ.  In ours's address space, `0xBCE25640` is
not allocated (ours's allocator namespace is `0x4000_0000..0x6FFF_FFFF`).
Reading `[0xBCE25640]` returns 0 → CTR=0 → `bctrl` faults at PC=0.

The fault is bit-stable across 3× cold ON runs (deterministic
scheduling under `--gpu-thread`).

## Matched-prefix shift under crowbar (informational only — NOT a gate)

Matched-prefix vs canary was NOT computed in this session because the
crowbar fundamentally alters guest control flow (introduces 4 host-spawned
threads with synthesised ctx state).  Per reading-error #23, matched-prefix
regression under crowbar-on is EXPECTED and not a failure indicator —
the PRIMARY gate is progression metric, not matched-prefix.