# Phase C+24 — escalation summary

## Headline
The 105,286 first-divergence is **NOT** a guest control-flow branch. It
is a **scheduler-cadence divergence**: ours fires the first VSYNC
graphics-interrupt callback (`sub_824be9a0`, armed via
`VdSetGraphicsInterruptCallback`) immediately after `VdSwap.return` at
`cycle=5,584,980`, inserting 6 events (KeAcquire / KeRelease pair).
Canary fires the SAME interrupt body with the SAME `r3=0` (VSYNC)
argument, but ~80ms wall-clock later, at idx 106,805. Both engines
execute the SAME guest code path; only the timing of the first VSYNC
interrupt delivery differs.

## Why escalation (per tripstone #5)

- ours uses `tick_vsync_instr` (guest-instruction-count threshold,
  150k) to pace VSYNC; canary uses a dedicated host frame-limiter
  thread on wall-clock (`Clock::QueryGuestTickCount`).
- Aligning the two would require either adopting wall-clock pacing in
  the lockstep diff harness (invalidates 23 phases of digest stability)
  or pinning first-VSYNC to a guest-instruction landmark (requires
  engine + canary changes).
- A naive 6-event diff-tool absorber realigns for 24 events then
  re-diverges (canary: `MmFreePhysicalMemory` vs ours:
  `KeEnterCriticalRegion`); chain of downstream timing-induced
  divergences would each need separate analysis. Risks reading-errors
  #23 and #32.
- MEMORY.md (review_a_boot_state_2026_05_21) explicitly defers
  "scheduler-determinism" alongside audio/HID/XAM.

## Per-chain delta

| chain | C+23 baseline | C+24 outcome | delta |
|---|---|---|---|
| main (canary tid=6 → ours tid=1) | 105,286 | 105,286 | 0 |
| sister 11/32/4/41/16 | (unchanged) | (unchanged) | 0 |

## New cold digest

NONE captured — no engine change, no re-run.

## Next target (post-C+24)

Methodology pivot to scheduler-determinism (separate phase, NOT C+25).
Three options written up in `investigation.md` §"Recommended next
action". Until then, the matched-prefix is effectively capped at
105,286 by VSYNC-cadence offset; further C+nn progression on guest
logic alone will not advance the main chain past this point without
first resolving the cadence issue.

## Files

- `investigation.md` — full analysis (this dir)
- NO source files touched.
- NO test edits.
- NO diff-tool edits.
- Phase B image hash `ea8d160e…` UNCHANGED.
- xenia-kernel tests 226 PASS (unchanged).