site: 2026-10-30 wiki refresh - new Project Goals, Performance and Interfaces and Stability pages; GSP explainer expanded (bare-metal behaviour + the two emulation modes); graphics pages (Graphics Execution, OpenGL, Vulkan, DirectX) with two new diagrams; status refresh across 15 pages; canonical docs updated (README status table, purpose-and-scope, performance contract); published to open-iov.org (67 pages, 0 problems)

3 files changed, 67 insertions, 53 deletions

diff --git a/docs/01-orientation/01-purpose-and-scope.md b/docs/01-orientation/01-purpose-and-scope.md
index ef4b258..242f470 100644
--- a/docs/01-orientation/01-purpose-and-scope.md
+++ b/docs/01-orientation/01-purpose-and-scope.md
@@ -131,20 +131,26 @@ document:
 
 * **Working today**: the virtual device, the GSP boot handshake, the RPC
   transport, the resource-manager emulation surface the guest driver needs to
-  probe and enumerate, guest `nvidia.ko` and `nvidia-smi`, and the full CUDA
-  driver-API path through context creation, allocation and verified copies
-  (the driver-API smoke passes).
-* **Needs improvement**: engine execution first — the backend is live and
-  CE-class copies and their releases are forwarded to the physical copy engine
-  (default off) with a fault relay, but for CUDA kernel execution the guest's
-  launch now reaches the front-end and the inline launch-descriptor install has
-  not been observed (context validity at dispatch is ruled out; see
-  [`../04-implementation/03-execution-frontier.md`](../04-implementation/03-execution-frontier.md))
-  — then the remaining reply fidelity (some consumed
-  fields are still generic fallbacks), the memory/page-table model, Windows
-  guest support, non-KVM hypervisors, and performance instrumentation. Each of
-  these is tracked with explicit "known-unknowns" in
+  probe and enumerate, guest `nvidia.ko` and `nvidia-smi`, the full CUDA
+  driver-API path, and **CUDA kernel execution on the physical GPU** —
+  verified guest clients (vector-add, matrix-multiply, transformer) execute on
+  the engine with engine-authored completions relayed to the guest. On the
+  graphics side, the X server and GLX run on the emulated vGPU, the engine
+  executes GL method streams (verbatim 3D replay and synthesized launches),
+  and the guest Vulkan pipeline runs end to end.
+* **Needs improvement**: the staged-transfer class (some large multi-chunk
+  CUDA clients still mis-verify; failure modes proven), the every-boot
+  acceptance campaign, per-guest execution isolation for simultaneous guests,
+  the rendered-pixel frontier for OpenGL/Vulkan (program delivery plus
+  program-VA mapping), the remaining reply fidelity (some consumed fields are
+  still generic fallbacks), Windows guest support, non-KVM hypervisors, and
+  performance instrumentation. Each of these is tracked with explicit
+  "known-unknowns" in
   [`../04-implementation/01-known-knowns-and-unknowns.md`](../04-implementation/01-known-knowns-and-unknowns.md);
+  execution detail:
+  [`../04-implementation/03-execution-frontier.md`](../04-implementation/03-execution-frontier.md)
+  and
+  [`../04-implementation/05-graphics-execution-plan.md`](../04-implementation/05-graphics-execution-plan.md);
   for the CUDA analysis area, start at
   [`../../userspace/cuda/READ-ME-FIRST.md`](../../userspace/cuda/READ-ME-FIRST.md).
 
diff --git a/docs/05-operations/01-performance-correctness-security.md b/docs/05-operations/01-performance-correctness-security.md
index 2f10b35..1391426 100644
--- a/docs/05-operations/01-performance-correctness-security.md
+++ b/docs/05-operations/01-performance-correctness-security.md
@@ -17,26 +17,32 @@ Rung 4  SUSTAINED         workloads run for hours; faults/errors recoverable
 Rung 5  MULTI-TENANT      N VMs, isolation + fairness + no cross-talk
 ```
 
-**Current rung (2026-10-02):** Rungs 1–2 are green: the stock driver probes,
-`nvidia-smi` enumerates, and the full CUDA driver-API smoke passes
-(`ALL OK` 64/64, copies matched) — `cuInit`, device queries, context creation,
-allocation, copies, free and destroy complete, and the copies are verified
-byte-for-byte. **Rung 3 is partial:** CE-class copies execute on the physical
-copy engine (default off) with engine-authored releases and a fault relay; for
-GR kernel execution a forwarded guest launch now reaches the front-end but the
-inline launch-descriptor install has not been observed (no grid dispatched;
-context validity at dispatch is ruled out —
-[`../04-implementation/03-execution-frontier.md`](../04-implementation/03-execution-frontier.md)).
-Before Rung 3
-is claimed, the
-**reply-fidelity gate** applies: a control whose reply fields the driver
-consumes is not implemented until the reply is coherent (status-only →
-coherent zeroed params → coherent values for consumed fields → exact values) —
-see
-[`../../userspace/cuda/docs/04-virtualization-and-emulation.md` §6](../../userspace/cuda/docs/04-virtualization-and-emulation.md).
-New to CUDA analysis here: start at
+**Current rung (2026-10-30):** Rungs 1–3 are green for the verified CUDA
+clients: the stock driver probes, `nvidia-smi` enumerates, the full CUDA
+driver-API smoke passes (`ALL OK` 64/64), and guest kernels **execute on the
+physical engine** — vector-add, matrix-multiply and transformer clients verify
+on fresh boots with engine-authored completions relayed to the guest. What
+remains before Rung 3 is claimed outright: the staged-transfer class (some
+large multi-chunk clients still mis-verify; failure modes proven) and the
+every-boot acceptance campaign — plus the **reply-fidelity gate** below. Rung 4
+(sustained) has partial evidence (a 100-launch loop, long soak pending); rung 5
+(multi-tenant) is partial: two mediated devices and two guests coexist, and
+per-guest execution isolation plus fairness measurement are in progress. On the
+graphics side, the X server/GLX run on the emulated vGPU, the engine executes
+GL method streams, and the guest Vulkan pipeline runs end to end; rendered
+(non-black) frames are the frontier
+([`../04-implementation/05-graphics-execution-plan.md`](../04-implementation/05-graphics-execution-plan.md)).
+**No performance numbers are published yet**; the A/B programme in §3 is the
+next measurement step, and the first scheduled public measurement is the
+graphics 60 fps target (no forcing). New to CUDA analysis here: start at
 [`../../userspace/cuda/READ-ME-FIRST.md`](../../userspace/cuda/READ-ME-FIRST.md).
 
+The **reply-fidelity gate** applies to every emulated control: a control whose
+reply fields the driver consumes is not implemented until the reply is
+coherent (status-only → coherent zeroed params → coherent values for consumed
+fields → exact values) — see
+[`../../userspace/cuda/docs/04-virtualization-and-emulation.md` §6](../../userspace/cuda/docs/04-virtualization-and-emulation.md).
+
 ## 2. Correctness
 
 ### 2.1 Test corpus
diff --git a/docs/README.md b/docs/README.md
index b423762..95ef85c 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -98,7 +98,7 @@ and [`01-orientation/02-the-ai-edge-and-ecosystem.md`](01-orientation/02-the-ai-
 
 ## 3. Where is the project today?
 
-**Honest status (2026-10-02):**
+**Honest status (2026-10-30):**
 
 A dated snapshot of this status, refreshed on every progress check, is kept at
 [`../STATE-CURRENT.md`](../STATE-CURRENT.md).
@@ -111,28 +111,30 @@ A dated snapshot of this status, refreshed on every progress check, is kept at
 | GSP-RM controls: device/fb/bus tables, CE caps, vaspace, GMMU static info | 🟡 Mostly — the engine inventory now includes the async copy engine and the CE capabilities match the device; reply fidelity for the remaining consumed fields is still being tightened |
 | Guest `nvidia.ko` probe, `nvidia-smi` | ✅ Working (TU104) |
 | Guest CUDA driver (`libcuda`) startup | ✅ Driver-API baseline — `cuInit`, device enumeration, `cuCtxCreate`, `cuMemAlloc`, copies, free and destroy complete end to end; the smoke test prints `ALL OK` and the 64-byte payload round-trips exactly (64/64, re-verified 2026-10-02 on the current build). See [`04-implementation/01-known-knowns-and-unknowns.md`](04-implementation/01-known-knowns-and-unknowns.md) and [`../userspace/cuda/READ-ME-FIRST.md`](../userspace/cuda/READ-ME-FIRST.md) |
-| CUDA kernel execution | 🟡 A stock guest program now reaches its kernel launch and submits it through the forwarding path; the front-end fetches the ring entry and executes methods, but the inline launch-descriptor (QMD) install has not been observed and no grid has dispatched yet. Context validity at dispatch is ruled out; the frontier is the launch method-stream form. Copy-engine-class work, its releases and its fault relay remain forwarded (parameters default off). See [`04-implementation/03-execution-frontier.md`](04-implementation/03-execution-frontier.md) and [`03-architecture/11-physical-backend-guest-wiring.md`](03-architecture/11-physical-backend-guest-wiring.md) |
-| OpenGL / Vulkan | 🔴 Not yet |
-| Windows guest | 🔴 Not yet |
-| Multi-tenant isolation (VFs, mdev-per-VM) | 🟡 Designed, partially implemented |
-
-We also know exactly where the CUDA bring-up stands and what the next step is:
-the userspace `libcuda` segfault was fixed (an RM allocation reply now echoes
-the request parameters instead of returning zeros), the engine inventory is
-complete, and the driver-API smoke test now completes end to end — `cuCtxCreate`
-returns and the 64-byte payload round-trips exactly (64/64, re-verified
-2026-10-02 on the current build). The full
-mechanism, with offsets and the decompiled call path, is in
+| CUDA kernel execution | ✅ Working — verified guest clients execute kernels on the physical GPU with engine-authored completions relayed to the guest: the vector-add (`VADD n=32768 bad=0`), matrix-multiply (`MATMUL n=256 bad=0`) and transformer (`dh=256 seq=64 bad=0`, `FFN4 layers=4 bad=0`) clients print `STATUS OK` on fresh boots, and `vecadd_loop` passes 100 launches. Remaining: the staged-transfer class (some large multi-chunk clients still mis-verify; failure modes proven), the every-boot acceptance campaign, and per-guest execution isolation. See [`04-implementation/03-execution-frontier.md`](04-implementation/03-execution-frontier.md) and [`03-architecture/11-physical-backend-guest-wiring.md`](03-architecture/11-physical-backend-guest-wiring.md) |
+| OpenGL (3D graphics) | 🟡 In progress — the X server and GLX run on the emulated vGPU with the stock driver; the engine executes real GL method streams (verbatim 3D replay and synthesized launches); a direct GL client creates its channels and its readback path returns clean. Rendered (non-black) frames are the frontier. See [`04-implementation/05-graphics-execution-plan.md`](04-implementation/05-graphics-execution-plan.md) |
+| Vulkan | 🟡 In progress — the guest Vulkan pipeline runs end to end on the emulated vGPU (device, allocation, pipeline, command buffer, fence, queue submit, readback); frames are still black — program delivery and program-VA mapping are the frontier |
+| Windows guest | 🔴 Not yet (target) |
+| Multi-tenant isolation (mdev per VM) | 🟡 Two mediated devices with different emulated VRAM sizes and two guests coexist; per-guest execution isolation for simultaneous CUDA guests is in progress |
+
+Guest CUDA now executes on the physical GPU: the driver-API path completes end
+to end, forwarded launches reach the engine, the grid dispatches, the engine
+authors the completion and the host relays it, and the guest's synchronisation
+waits resolve (verified with vector-add, matrix-multiply and transformer
+clients on fresh boots). The mechanism, with offsets and the decompiled call
+path, is in
 [`../userspace/cuda/docs/05-570.144-decompilation.md`](../userspace/cuda/docs/05-570.144-decompilation.md).
-The remaining frontier is guest-facing execution. Copy-engine-class copies and
-their releases are forwarded to real hardware with release relay and fault
-relay in place (parameters default off). For GR (graphics/compute), the guest
-now reaches and submits a real kernel launch: the ring entry is fetched and
-front-end methods execute, but the inline launch-descriptor install has not
-been observed and no grid has dispatched yet. The wall is the form of the
-forwarded launch method stream — not context validity, which is ruled out at
-dispatch. The chain, the evidence and the live investigation lines are in
-[`04-implementation/03-execution-frontier.md`](04-implementation/03-execution-frontier.md).
+The remaining CUDA work is breadth and hardening: the staged-transfer class
+(some large multi-chunk clients still mis-verify; the failure modes are
+proven), the every-boot acceptance campaign, and per-guest execution isolation
+for simultaneous guests. Graphics shares the same submission machinery and is
+the other active frontier: the X server and GLX run on the emulated vGPU, the
+engine executes GL method streams, and the guest Vulkan pipeline runs end to
+end — rendered (non-black) pixels are the wall. The chain, the evidence and the
+live investigation lines are in
+[`04-implementation/03-execution-frontier.md`](04-implementation/03-execution-frontier.md)
+and
+[`04-implementation/05-graphics-execution-plan.md`](04-implementation/05-graphics-execution-plan.md).
 The backend, a module-owned GPU running its real GSP firmware as the
 resource-manager server, is specified in
 [`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md);