We shipped a 1.73× codec. Then we found the product had been dead for five days.

Engineering notes from the Nishi sovereign video codec. Every number was measured against the artifact actually deployed to the family — including the numbers that killed the change we came to ship, and the profile that retired the change we had queued next.

Act I — the win that wasn't

A census of the 207,496 bytes the family's browser actually downloads found zero SIMD instructions. The kernel had been built, proven and merged into the shared toolchain days earlier, and had never reached a single user.

We rebuilt the client with it and proved bit-exactness four independent ways — a kernel gate with a non-vacuity opcode census and a negative control, a VM-vs-native differential across full encode→decode roundtrips, an encoder-recon-equals-decoder-recon check at the shipped geometry, and a decode-parity sweep across the quantiser range. Then the honest A/B in V8, the browser's own engine: two clients from identical source differing only in whether the emitter inlines the SIMD sequence.

1.67× is real, and it answers the wrong question. The family is not running our scalar arm; they run the artifact from days earlier. Against that, the net was 55.82 → 53.94 ms = 1.03×. The reason is worth stating plainly: the refactor that created the SIMD seam also slowed the scalar path. Routing 16-byte rows through a helper call is free when inlined and expensive when not. SIMD spent most of its winnings buying back what its own enabling refactor cost.

Act II — the profile retires the roadmap

The queued next rung was “vectorise SATD”. Before building it we profiled the real client wasm in V8 at the shipped configuration:

SATD does not appear in the profile at all. We would have built it and learned that afterwards. The cost was in the search — and reading the code showed why: every shipped call site searched a radius-16 window, 1089 candidate positions per block, while the code's own comment noted that real call motion lands in the nearest few rings.

Act III — measuring the window instead of assuming it

We made the radius data-driven and swept it. On call-like content the bytes barely move while the time halves:

But a smaller window is not free everywhere: on genuinely high-motion content a bare radius-8 search costs about 2.5% more bytes at matched quality. That is a real loss, and taking it would have been trading the family's picture for frame rate.

So we did not choose. A scan of rings 0–8 followed by a scan of rings 9–16 visits exactly the candidates of a single 0–16 scan, in exactly the same order, against the same tightening bound. That identity means an extended search is candidate-for-candidate identical to the full search — so scanning the near window first and extending only for blocks that failed to find a match can cost time, but never quality.

1.73× faster and 2.6% smaller than what the family runs today — both axes improving at once. On high-motion content the adaptive form costs ~1.2% rather than the 2.5% a bare small window would, and the vcv-10 arm's matched-quality figure is unchanged. Set the near radius to zero and it reproduces the original search byte-for-byte, which is how we proved the refactor is inert before trusting the number.

It is also, deliberately, encoder-only. No new wire syntax, no feature flag, no decoder change: any motion vector reconstructs exactly, so old and new decoders both read the stream.

What the gates caught on the way

The SIMD kernel gate went red, 4 of 6, the moment the search changed — and it was pointing at the wrong thing. Its scalar reference arm was a hand-copy of the production search driver, so the gate silently asserted two claims at once: that the SIMD kernel matches the scalar kernel, and that nobody had refactored the neighbouring code. A maintainer would have gone hunting a lowering bug that did not exist.

We collapsed both duplicated drivers into one probe-owned driver with a kernel selector, so the two arms now differ only in which SAD runs. It returned to 6/6 green with the same corpus checksums as before the change — which is how we know the decoupling preserved what the gate was actually measuring, rather than merely silencing it.

Making the claim falsifiable

The codec domain had long asserted a coverage score that the ecosystem's own honesty gate rated claim-only: an assertion with no executable evidence. Closing it exposed a second defect — every capability came back ungrounded, zero symbol hits, though every symbol genuinely existed. The evidence map cited source paths from one root while the runner resolved another. One corrected prefix took the domain from 0 of 14 grounded to 14 of 14.

A census found 261 rows across 13 domains with the same defect. It is a failure mode worth naming because it runs opposite to the usual one: it makes real capability look unproven, so a reviewer hunting for overclaim will never find it.

What is not done

• The client is staged and gated, not shipped. It ships through the field-probe and call-quality discipline, not off a bench number.
• The published comparison against the reference encoder still reflects an older build and is being re-measured.
• The evidence runner cannot execute the full gate map in one call — the strongest gates are also the slowest. The fix is a detached runner, not deleting the slow gates; trimming the strongest teeth to make a runner finish is exactly the self-deception these gates exist to prevent.

Postscript: the ship that found an outage

The codec work above shipped: the SIMD + adaptive-search client is live, byte-verified against the artifact that was benchmarked. Then we ran the field probe that gates every video ship — two headless browsers making a real call through the production edge — and no telemetry arrived. Not degraded. None.

The call-quality gate had been reporting a benign amber — insufficient evidence, ship unproven, not blocked — for 5.1 days. That reading is indistinguishable from “nobody made a call.” It was actually “nothing can make a call.”

Attaching a debugger to a real browser on the live page gave three errors in a row:

A content-security policy had been tightened across every response. It blocks WebAssembly compilation and blob-backed workers — which is to say, it blocks the sovereign codec and its worker pool. The whole product is built on both.

We confirmed the scope rather than assuming it: instantiating an eight-byte, minimal, valid WebAssembly module from the page context of an unrelated page on the domain fails with the same error. The block is domain-wide, not page-specific. The site ships 44 WebAssembly modules.

A separate defect compounded it. The page loaded its script by a relative path, the edge redirects away the trailing slash, and the <base> tag added to compensate is itself blocked by that same policy — so the browser fetched the app from the site root, received the home page with a 200, and died on SyntaxError: Unexpected token '<'. That part is fixed and verified live.

And one about ourselves: when the page verifier started calling this page broken, the first instinct was that the verifier had regressed — a debt was filed saying so. That was wrong and has been retracted. The verifier was right; memory of an earlier green was the unreliable input. A 200 with the wrong content type looks exactly like success to everything except an engine that parses it.

Act IV — the outage ends, and the search stops paying twice

2026-07-27. The postscript above ended with a product that was provably dead in every browser and a fix that could not be deployed. This act closes it — and adds one more lesson about measuring before believing.

The deploy itself nearly wrote a worse postscript: the NAS came back from a hard wedge on the wrong DHCP address, and when the CSP-fixed daemon was finally promoted, a second, unattributed deploy pass ran minutes later with nothing staged — which renamed the live binary away and installed nothing. The site served zero bytes while the supervisor spun on a file that no longer existed. Recovery came from an artifact staged three days earlier by the same fix session. Two defects are now on the board for that: a promote that can vanish the live binary when nothing is staged (seq1097), and the unknown second trigger (seq1099).

Then the proof, in a real browser against the live page, not a header diff: an 8-byte WebAssembly module instantiates in the page origin, a blob: worker spawns and replies, the actual served codec compiles under the live policy (354 exports), and the page boots with zero console errors. The measured state before this: 100% of wasm modules on the domain refused to compile.

With the product alive again, the encoder got its next honest rung — and its next honest refusal:

• F1112, shipped: the partition-RD trial was running the identical 16×16 motion search the block coder re-ran immediately afterwards on every rejected trial — a full duplicate of the hottest loop, hiding in plain sight since P_8x8 landed. The trial now hands its result back; the re-search is skipped. Bit-exact by identity: same function, same arguments, deterministic. Measured end-to-end: 32.8ms → 31.8–32.3ms P-encode (+1.6–3.0%), streams byte-identical.
• F1111 rung 2, refused: predictor priming — seeding the search cap with the median-predicted MV's SAD — was built in full, with a sharper safety proof than its design note (priming outside the always-scanned ring band can flip the prune decisions, so it refuses there) and a memo that eliminates its own double-evaluation. Three build arms, byte-identical output streams, median-of-25 in V8: 0.999×. The adaptive window had already exhausted the lever. It ships default-off, with the measured verdict written at the constant.

The lesson under the refusal: the 80.6% motion-search profile that motivated priming was taken before the adaptive window landed. After a big rung, re-derive the profile — or you will spend a week optimizing a number that no longer exists.

Field state as of this act: client 211689B, md5 90dcbe92, build 844, byte-verified at the serving path; layout gate 6/6 at the shipped geometry; bgop decode-parity 0 fails; v128 gate 6/6. Still owed: the vqoe flatline alarm (seq1100) — because the deepest failure of this whole arc was not the CSP header, it was five days of telemetry reading "benign" over a product that was completely dead.

Act V — the scoreboard nobody wanted, and the week that moved it

2026-07-27–28. With the product alive again, we finally asked the question the lane had been avoiding: measured honestly, against a properly-tuned x264, where does this codec stand? We built the harness (the exact shipped chain, four classic sequences, x264 at its strongest fair settings, Bjøntegaard over the overlap) and got the answer: +573% BD-rate — 6.7× the bits at equal quality. The previously published number had flattered us against a weaker oracle. A flattering benchmark is a debt, not an asset.

Then the eliminations, each hypothesis measured and most of them killed: skip rate (we already skip more than x264), entropy contexts (within ~20% of the floor), 6-tap interpolation (0–5%), chroma share (normal), intra mode breadth (2%). Two probes lied along the way — one with physically impossible energy, one from a quarter-pel convention trap — and earned a standing rule: an instrument that re-implements encoder internals is a liar until its baseline arm reproduces the encoder itself.

What survived the eliminations was worth the week:

• RD-skip, already built, switched off by a stale fps verdict: +8dB on the test content. Its cost was three-quarters integration bugs — the trial had been force-running partition evaluation and full search on every band block. Fixed, its price fell from 4.5× to 2×.
• Partition-RD: 68% of the encode for ~1.3% of the quality. Retired — the wrong way first (a build-local syntax flip that broke a live family call between mixed builds; rolled back inside minutes), then the right way: generation negotiation, where the room only drops the syntax when every peer says it can.
• A quantizer rounding offset: the quantizer floor-rounded against a lower-edge reconstruction — every coefficient systematically small. One measured constant: −3% BD, and faster, for free.

Standings after three gated ships: +170% — 2.7× — at real-time speed. The remaining distance lives in the transform/quant/RD core, and that is a designed build, not a flag.

The same week gave the call stack its turn: a relay daemon that had leaked itself into a wedge (up, listening, relaying nothing — the health check now has to prove frames flow, not sockets open), a 30fps capture ceiling hiding in one ternary while the send ladder already reached 60, and forward-error-correction that was built and proven but never wired to the codec lane. All three are resolved: the relay bounced and debted, capture runs at 60 with the measured ladder governing send, and FEC now arms itself on loss evidence — proven byte-exact on an 8-of-10 rebuild before it shipped. Lost packets on a jittery uplink become recoverable erasures instead of keyframe storms.

The through-line of the whole act: every ceiling must be measured or negotiated, never assumed — not in the codec, not in the app, and especially not in the numbers we publish about ourselves.

The road past 60 — and toward 4K, measured device by device

2026-07-28. With the 60fps chain unblocked (builds 844–847), the question became: what is the ceiling, on real family hardware, and what is the shortest honest path to 4K? The answer starts with a tool, not a plan: the device capability probe measures each device — wasm SIMD/threads/relaxed-SIMD, WebCodecs hardware encode/decode verdicts at 1080p60 and 4K, WebGPU, camera limits, and the sovereign codec's own software fps — and beacons the results into family telemetry. The roadmap below runs on that census, with a go/no-go gate per rung. Its first datapoint already caught the first blocker.

• R0 — census (live now). Every device opens the probe once. The July-2026 landscape it measures against: WebCodecs is in every major engine, ~88% of sessions can encode AV1 given the right codec string, and every 2023+ flagship phone hardware-decodes AV1 up to 4K60.
• R1 — threads: tile-parallel sovereign encode. The probe's first catch: the engine supports wasm threads but the page is not cross-origin-isolated — two response headers (COOP/COEP) stand between the worker pool and shared memory. The tile/region encoders already exist in the codec; spreading tiles across the measured core count projects 640×480 at 60–75fps in pure software on desktops, 720p-class on flagship phones. Gate: tile-seam parity plus the fps bench.
• R2 — relaxed SIMD. Standardized in Wasm 3.0 and stable across engines in 2026; a second emitter arm for the SAD/transform kernels, fallback intact.
• R3 — the hardware hybrid lane. Where the census shows hardware AV1/H.264 encoders, their payloads ride inside the sovereign wire — same rooms, same relay, same FEC, same chat, negotiated per-room by the same generation mechanism that retired partition. The sovereign codec remains the universal fallback and the archival lane. This is the 1080p60 rung on flagships, and 4K30 where hardware encode exists — at phone-battery power budgets. And it is a bridge, not the destination: the sovereign encoder is the long-term investment — where the platform codecs fall short (older devices, the archival lane, formats we control end to end), our own encoder is what closes the gap, and every rung below feeds it.
• R4 — WebGPU kernels. For devices with a GPU but no usable hardware codec: the sovereign codec's hot loops (SAD, transforms, loop filter) as compute shaders. Software 1080p realtime without ceding the format.
• R5 — layered 4K. Capture at camera maximum where the probe finds it; the existing layer-subscription machinery (receivers already tell the relay which layers they want) becomes SVC-lite: a 4K high layer for strong receivers, the proven tiers for everyone else.

The rule that got us here governs the whole road: no rung ships on an assumption. The census says which devices go first; the gates say whether each rung kept its promise; and the beacons say what actually happened in the field.

Act VI — the door unlocks: isolation live, and the 3.3× that was already shipped

The road-past-60 section above named its first blocker precisely: the page could not use threads because the edge never sent the two cross-origin isolation headers. Landing them took three tries, and the failed tries taught more than the success. A rebuild of the edge daemon from the build tree produced a binary 75KB smaller that served every request through the legacy router — no security headers, dead asset routes. The first diagnosis said stale source. The truth, found by searching the tree instead of trusting the diagnosis, was wrong target: the build tree carries two daemons, the legacy generation-1 organ and the generation-2 daemon the family actually runs, and the rebuild had been pointed at the wrong one. The proof that the tree is healthy is the strongest kind available: rebuilding the generation-2 source reproduces the live binary byte-identical — same md5, live equals source-built.

Headers present is not capability armed — a lesson this page already paid for once with the content-security policy that silently killed every worker. So the claim was proven in a real browser against the live page: crossOriginIsolated === true, a SharedArrayBuffer constructs, a shared WebAssembly memory reports itself shared, the served codec still compiles, and all four workers spawn. And because a header that can appear can also disappear, the health evaluator grew two new teeth that require both isolation headers on every 300-second pass. The teeth were proven the only honest way: a deliberately wrong token first — the canary went red on cue — then the real one, back to 13/13 green. A canary you have never watched fail is a hope, not an instrument.

Then the discovery that reframed the whole rung: the tile-parallel encoder this was all for was already in the field. The band-parallel encode/decode pair — independent horizontal bands, own entropy state per band, intra prediction fenced at the band top, gated long ago as the 720p rung — is compiled into and exported from the exact wasm every client has been downloading. No new codec bits were needed. What was missing was only the permission (now live) and the orchestration (measured below, not yet wired).

3.3× on the wall clock at 640×480, against the live artifact, with the scatter-gather copies included. That puts 640-class encode at 41fps on this hardware with four bands, and the shipped 416×320 geometry deep under the 60fps frame budget. Banding itself costs under one percent in bytes; the band pair rides the older transform chain, which costs about seven percent versus the shipped one — the next measured trade, not a surprise to discover in the field.

One tooth bit during the bench, and what it caught is worth recording. Serial and parallel encodes of the same content produced different bytes — a determinism alarm. Bisection found the cause in one buffer: the encoder's output region. The differing bytes are dead padding bits in the final byte of each entropy section, inherited from whatever the buffer held before — bits no decoder ever reads. The product proof followed: streams from pristine parallel workers decode drift-free in a sequential decoder, every reconstructed plane byte-equal to the encoder's own. The parallel path is wire-sound today; the padding nondeterminism is filed as a small encoder-only cleanup, because reproducible bytes make gates and forward error correction simpler.

What is not done, so nobody mistakes a measurement for a ship: the call application still encodes whole frames on one worker. Wiring the band pool means a banded frame container on the wire — new syntax — and this page's own incident law says stream syntax only changes by negotiated capability, the same generation-gate that retired the partition flag. Banded frames will speak only in rooms where every peer understands them. That build, its gates, and its field beacons are the next act.

Act VII — the parallel encoder reaches the field, and three ghosts leave the machine

Act VI ended with a measurement and a promise. The same night, the promise shipped: builds 848–853 wired the rich band pair into the call application behind a generation gate, and a read-back instrument for the arming decision (NXDBG.band()) turned three invisible field defects into three one-line fixes, one per probe: the capability announce that a second code path kept clobbering back down; every worker pool silently dead on strict engines (a blob-context worker cannot resolve a root-relative fetch — masked for months by the sync fallback, and worker liveness had never been a telemetry field); the relay filing half the banded geometries under a colliding layer bit and forwarding them to nobody; and the worker receive path that never recorded frame geometry — alive, that one turns every P-frame into a dropped frame and a key request, which is the long-documented keyframe-storm crater, finally with a mechanism. The final probe of the night: two peers in a production room, banded frames encoding across four cores each, arriving, and decoding — zero decode failures. A silent gate is not a policy; it is a defect that has not introduced itself yet.

The scoreboard — where this stack is state of the art, where it is not, and the plan

The plan, in order: field evidence for banded auto-arming and the 640@60 rung promotion (the arming is budget-derived: devices band exactly when their measured encode misses the frame budget); the transform/RD generational rung against the 2.70×, gated by the same BD scoreboard that produced every number above; FEC × banded × encryption composition; then the census-gated ladder — relaxed-SIMD, the hardware-hybrid bridge, WebGPU kernels, and layered 4K — each rung shipping only on device census and beacon evidence, never on an assumption.