[MrDongsls]

Required human contributor answers

1. What outcome are you trying to achieve?

   Answer: Serve the Vela 2.0 4B and 9B decoder members on system1-omni the same way the 0.8B is served.

2. What is the highest-leverage variable for that outcome?

   Answer: Exact-match parity with each member's pinned reference runtime.

3. How will this work move that variable rather than create busywork?

   Answer: The three members ship one byte-identical runtime, so one registry and the shape-derived heads extend the validated 0.8B path to both with no new executor code.

4. Who is the customer or user, and what they actually need?

   Answer: Anyone who wants Vela 2.0 decisions from system1-omni on the larger members, and they need correct answers on all five question kinds.

After answering the four questions: is a PR needed at all to achieve this outcome?

Human decision: Yes, the new members are served only after this registry, tests and docs merge.

For a bug fix: link actual observed failure evidence.

N/A, not a bug fix.

Purpose

Fourth slice of the Vela 2.0 native chain. It serves the 4B and 9B decoder members on the Python reference worker and the native library that already serve the 0.8B, one pinned member per worker process.

• The worker keeps one member registry keyed by the package's config.json model_name. Each entry pins the repo, revision, the ten hashed files and the shard layout, and a package naming an unpinned member is refused by its own name.
• The native bundle gate mirrors that registry as a member table with the exported tensor inventories. The F32 heads derive every width from the tensors' own shapes and the executor cross-checks the backbone hidden size, so one implementation serves hidden 1024, 2560 and 4096.
• Fixtures are relabeled per member and JSON fixtures are committed. The head-input safetensors of the larger members are not committed, about 103 MB of binaries, and are regenerated with recipe/vela/export_head_inputs.py on the pinned package.

Builds on #151, #174, #175, #176 and #177.

Stacked PRs and merge order

This is the fourth slice of one chain and stacks on the open 0.8B native PRs; the branch history contains the #177 head 064244d, so most of this diff's native-crate lines are those PRs' content plus the member-parameterization on top:

Order	PR	Layer
1	#151 (merged)	0.3B Python reference worker
2	#174 (merged)	0.8B hybrid through the reference worker
3	#175	0.8B native bundle export, wire contract, token-level processing
4	#176	0.8B native F32 heads, scoring and span decoding
5	#177	0.8B native response finishing and CUDA executor
6	this PR	the 4B/9B member layer

Recommended merge order is #175 → #176 → #177 → this PR. Once the 0.8B stack lands, this PR's diff collapses to its own layer (the hybrid.py member registry, the per-member fixtures, the member-stamping exporters and the docs); until then, reviewers can treat the files under src/models/vela/native/ as the #175–#177 surface under review there. The branch merges current main in 1b8d025, so it stays conflict-free while the stack lands.

Test Plan

System1-Omni Version / Commit: 7b60e4e on model/vela2-4b-9b, based on the #177 head 65766b8.

• CPU on the branch head: cargo fmt --all --check, cargo clippy --workspace --locked --all-targets --features omni-laya/serve -- -D warnings, cargo test --workspace --locked --features omni-laya/serve, PYTHONPATH=src pytest tests/vela, and mkdocs build --strict. The release build was not run locally and is left to CI.
• Author-run GPU evidence recorded in the recipes, one rented RTX 4090 48 GB, sm_89, driver CUDA 13.3, toolkit 13.2, the bf16 autocast setting: package gate, load and all-kind warmup for both members, nine-case exact-match reference parity against the pinned upstream server, frozen oracle, token-plan and head-input fixtures exported under each member's label, and the native replays with the member-calibrated gates in the tests.

Test Result

• CPU: all checks above pass on 73af078. The workspace tests report 100 test targets ok with no failure, the omni-vela-native crate 30 passed and 4 ignored that need an exported bundle or a GPU, and pytest 160 passed including the member-parametrized oracle cases.
• Reference parity: exact on all nine cases for both members, four 200s byte-equal including key order and agreed 422 and 413. A warm 4B worker answered the example request in about 0.2 s, a single observation, not a benchmark.
• Native heads and response: 4B head logit drift at most 8.97e-5, answer drift at most 5.56e-3, response drift at most 5.56e-3. 9B: 4.20e-5, 6.80e-4 and 5.92e-3. All inside the member gates. The larger ceilings against the 0.8B baseline come from the GPU-recorded fixtures and are documented in the tests and native.md. One divergence is kept deliberately: on borderline span cases the replay flips the discrete span set while its probabilities still match, so the tests assert probabilities there and keep full structural assertion on the 0.8B CPU-recorded fixtures.
• Head updated to b2559fe (independent-review fixes plus the merge of current main): the same CPU checks pass there — fmt, workspace clippy and workspace tests 421 passed / 0 failed / 92 ignored after the merge, omni-vela-native 32 passed / 4 ignored (two new bundle-walk tests), pytest tests/vela 160 passed also re-verified torch-free on system Python, and mkdocs build --strict clean. main merge conflicts (Cargo.toml, README.md, docs/supported-models.md, recipe/README.md) are resolved in 1b8d025; Cargo.lock keeps only the omni-vela-native addition against main.
• Executor on CUDA: 4B replays all four small cases with worst logit drift 0.2271 against the 0.35 bf16 gate. 9B replays all four as well (completed after the PR opened, recorded in 1af69af): 0.1899 (example-request), 0.0403 (set-threshold), 0.2281 (cjk), 0.0199 (score) — worst 0.2281, inside the gate.
• Head updated to 7b60e4e (the span-parity fixes at 71c1894, then the review follow-ups merged down the stack from vela: add the 0.8B native bundle export, wire contract and token-level processing #175 and vela: add the 0.8B native response finishing and backbone execution on CUDA #177: atomic export staging, the tighten-only VELA_GPU_LOGIT_GATE clamp and the bundle-walk hardening). The same CPU checks pass at this head: cargo fmt --all --check, cargo clippy --workspace --locked --all-targets --features omni-laya/serve, cargo test --workspace --locked --features omni-laya/serve (431 passed, 0 failed, GPU-gated ones ignored), PYTHONPATH=src pytest tests/vela (164 passed), PYTHONPATH=. pytest tests/benchmarks (133 passed) and mkdocs build --strict clean.

Demo / evidence

The runs above are author-run and recorded with hardware, revisions and gates in recipe/vela/reference.md and recipe/vela/native.md. No separate raw archive or video. The change is a serving integration and the parity numbers are the evidence. The 4B and 9B executor logit replays are complete and recorded. The larger members' head and response replays were recorded under the earlier structural exemption and stay unverified under the current assertions until rerun with the exported bundles, as native.md states; the claim of verification here covers the executor logit gates.

Self-review

• I have reviewed the full diff and addressed the issues I found.
• I have checked that the change follows the project's architecture and stays focused on the stated purpose.
• I have run the checks appropriate to this change and reported commands, results, and anything that I could not verify above.
• I have checked that the PR description, documentation, and any accuracy or performance claims match the implementation and available evidence.

[MrDongsls]

@psv666 PTAL

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	⚠️ Failed 2026-10-29T18:27:09.917357Z We couldn’t complete this review. Comment @codex review to try again.	1af69af	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[psv666]

Reviewed 22b7717c...1af69af5. I found four issues to address before merging. The span mismatch has a concrete decoding cause, and the current parity exemptions hide it.

Standards / validation

1. [P1] Keep mismatching spans in the parity assertions.

   In native_response.rs:355–364, any structurally different spans[qid] is removed from both responses before computing drift for 4B/9B. native_heads.rs:433–479 has the same unrestricted exemption. This is not limited to particular borderline cases or bounded differences.

   A CPU probe using each member's committed example-request oracle replaced every span array with [], deleting three expected spans per member. After the filtering, both comparisons were exactly equal and the subsequent key-count checks still passed. Also, the response test's span path consumes recorded logits directly, so head replay rounding cannot explain away all differences here. Please retain structural assertions; any necessary numerical exception should identify the exact case and permitted discrepancy while still rejecting other regressions.

2. [P2] Reject non-finite logits before reducing the maximum error.

   native_executor.rs:135–136 and 162–164 accumulate error with f32::max, starting at zero. Rust's max ignores a single NaN operand, so an all-NaN output leaves the measured error at zero and passes the gate. The heads replay has the same pattern. Assert finiteness and expected dimensions before reducing error. This is a static validation defect; no actual GPU NaN output was observed during this review.

Spec / correctness

3. [P1] End the current span when a valid word is below threshold.

   In scoring.rs:355–364, c == -1 does not close the previous span. A later word with the same label then extends spans.last_mut() across the rejected text. The pinned Python decoder maintains a current span and resets it to None at such a word.

   Minimal example: Alice met Bob, offsets [(0,5), (6,9), (10,13)], one label PERSON, probabilities [0.9, 0.1, 0.9], threshold 0.5. The reference returns separate Alice and Bob spans; this loop merges them into Alice met Bob despite identical probabilities.

   The committed 9B CJK fixture shows the same effect: using its recorded logits and threshold, the pinned decoder returns separate address spans 上海市, 世纪, and 100; replacing only the merge loop with the Rust loop's semantics produces 上海市浦东新区世纪大道100. This is a logic difference, not just a floating-point tolerance issue. Please terminate the current span at rejected valid words and add a weight-free regression case. This code is inherited from the native stack but is part of this PR's full diff; the Python reference worker does not use this Rust decoder.

4. [P2] Prevent fixture exporters from creating bytecode that their own package gate rejects.

   export_token_plan.py:133–137 and export_head_inputs.py:175–179 verify the package and then import its runtime with bytecode writing enabled. For a writable package directory, this creates __pycache__, which engine.verify_files explicitly rejects. Consequently, the documented token-plan → head-input export sequence fails on its second command, and a later worker startup against the same package also fails.

   Reproduced through the actual export_token_plan.main with a tiny fake registered package, a loader returning a plain object, and no inference cases: the first invocation returned 0 and created __pycache__; the second raised package verification failed: existing bytecode cache __pycache__/ in the package root is not verifiable against the pin. Disable bytecode writes for package imports, including lazy imports during initialization.

Validation: the CPU suite passed 160 tests with PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 PYTHONPATH=src /usr/bin/python3 -m pytest tests/vela -q. Current-head CI was green. Decoder evidence used the checksum-verified pinned Python decoder and an exact translation of the Rust merge loop, not a compiled Rust execution. Rust checks and GPU parity were not rerun locally because the Rust toolchain was unavailable and no GPU/model workload was launched.

Standards: 2 findings, highest P1 (discarded structural failures). Spec: 2 findings, highest P1 (incorrect span merging).

[MrDongsls]

Thanks for the detailed review. I addressed all four findings in 71c1894:

• decode_spans now ends the current span when a valid word is below threshold; added a regression test for Alice met Bob.
• Removed the unrestricted GPU span exemptions and restored structural span assertions.
• Added finite-value and dimension checks before logit drift reduction.
• Disabled bytecode writes during exporter imports and initialization; added package re-verification tests.

Validation passed:

• Workspace Rust tests: 431 passed, 0 failed.
• tests/vela: 164 passed.
• Strict parity replay passed for the available 0.8B bundle.
• fmt, clippy, release build, and strict docs build passed.

[hsliuustc0106]

Draft review — PR #195 (first-pass review; not posted)

PR: #195 "vela: serve the 4B and 9B decoder members"
Reviewed head: 71c1894088f840df43b52c296fedf29636f76b73 (matches the API head.sha; non-draft, open, base main, mergeable: true)
Raw footprint vs 78fe14378: 184 files, +22351/−916 — but this is misleading: the negative deletions are the old merge-base (≈4 main-syncs behind origin/main e573260c), and most of the raw delta is upstream main absorbed by the branch's own merge 1b8d025b (Clef omni-clef server, benchmarks/traces, valen export checkpoint machinery, cua_s1 prefix cache, qwen3_5 model.rs/prefix work — all from main, none authored here). The authored footprint is the vela member layer: the 46-file 1b8d025b..71c18940 delta plus the five pre-merge vela commits (fb8847cf member registry, ab832bd0, ab382518, 67991a9a, 73af078d).

Stack position

Fourth and final slice; verified 064244db (#177) is an ancestor of this head, so the whole series is linear #175 → #176 → #177 → #195. Merge hygiene: git merge-tree --write-tree re-run on 1b8d025b; the resolution is a careful manual union — keeps vela/native and upstream's clef/native and startlux/native workspace members, dedupes the README/supported-models/recipe rows keeping upstream's newer omni-clef wording alongside this PR's 4B/9B rows. No evil-merge content; the resolutions are exactly what the commit trail claims.

The 4B/9B scale-up (own delta deep-dive)

• Member registry, mirrored across the language boundary: Python src/models/vela/hybrid.py MEMBERS (repo, revision, max_length 16384, per-member shard sizes, 10-file pin tables) ↔ Rust bundle.rs::MEMBERS (model_id, revision, inventory counts 426/272/154 + 37 heads for both 4B and 9B — same 32-layer structure, different widths). Revisions match (d6923941 4B, 068425bb 9B). An unpinned member is refused by name in both. Good.
• Widths: heads.rs now derives every width from the tensors' own shapes (norms → backbone hidden 1024/2560/4096, bilinear → head dim, slot table → slot count), with Linear::from_weight/with_bias shape validation; executor.rs cross-checks backbone hidden vs heads-derived hidden ("a mismatched pair of bundle files is an export error, not a member difference"). The only head constant left is a cross-check, as the doc comment says.
• ABI: no ABI change authored in this PR — the shared qwen3_5 Config::load accepts hidden 4096 (is_multiple_of(8) etc.) from main-merged code; the 4B/9B executor runs through the existing Model::load/forward_batch contract, ops.h unchanged by this series. No new kernel whitelist widths authored here.
• Exporter: export_native.py stamps the manifest from verify_package(package)'s resolved member (model_id/revision/pin table per member); the fixture exporters now call verify_package too (fixes #175's P3), and 71c18940 makes them bytecode-free during lazy imports so the gate (which rejects __pycache__) leaves the package reusable — with a new tests/vela/test_export_fixtures.py proving it.
• Gate: the bundle walk is now genuinely recursive at any depth (8d994e1d), 67991a9a refuses an empty slot table, acabad46 surfaces tokenizer failures as the reference worker's 500 {"detail": "inference failed"} instead of panicking and bounds the encode cache at 4096 (documented divergence from the reference's unbounded cache).
• Span-decode parity fix at the head: 71c18940 — the merge loop now ends the current span at a rejected valid word (scoring.rs decode_spans), matching the reference; previously a labeled word could merge across an intervening rejected token. Logit comparisons (tests/vela/native_parity.rs) now reject non-finite values and dimension mismatches, and the tests "retain every span" with counts/labels/offsets asserted.
• Robustness during scale-up: e5a16849 fixes the NaN-sort panics (total_cmp) and the O(n²) window aggregation (HashMap index) I would otherwise have filed against #176/#177; 73af078d ties the frozen oracles to the recipe examples; 805ec0ba wires PYTHONPATH=src pytest tests/vela into CI (benchmarks job, step "Vela worker tests: success" at this head).

Numerics / evidence at THIS head

• The GPU-recorded 4B/9B head/response drifts (4B ≤8.97e-5 / 5.56e-3; 9B ≤4.20e-5 / 6.80e-4 / 5.92e-3) were recorded under the former structural exemption; 71c18940's native.md states plainly: "Those 4B/9B head/response measurements … do not establish full parity … Full 4B/9B head/response replay under these assertions remains unverified until rerun with the corresponding exported bundles." The executor logit replays (not span-structural) stand: 4B worst 0.2271, 9B all four cases worst 0.2281 < 0.35, recorded at 1af69af5.
• The threshold-adjacent windowed-case divergence is honestly recorded (probabilities match, discrete span set flips on borderline cases) — consistent with the f32 sigmoid rounding vs torch's f32 sigmoid noted in the scoring mirror.

Findings

1. P2 — the PR body's evidence claims contradict the head's own docs, and the primary head pin is stale. The body pins "System1-Omni Version / Commit: 73af078" (two heads ago; it also references b2559fe and 1af69af mid-body) and concludes "The 9B executor replays are complete and recorded; every case of every member is verified." The reviewed head 71c18940 (a) changes span-decode behavior and the test structure (171 lines in native_heads.rs) after all recorded evidence, and (b) its own recipe/vela/native.md declares the 4B/9B head/response parity "unverified until rerun" under the new assertions. Trigger: reading the body instead of the head docs. Consequence: a reviewer or merger could believe full 4B/9B parity is established when the tree itself says otherwise. Fix: update the body to pin 71c18940, state that head/response replays await re-recording, and keep the executor-replay claim scoped to logit gates. The in-repo honesty is good — the body must match it.
2. P3 — wrong repo slug in the recorded-evidence link. recipe/vela/native.md (this head) links https://github.com/InferMatrixLab/system1-omni/pull/195#issuecomment-6516691352; this repository is ThinkFlowLab/system1-omni. Trigger: following the link. Consequence: dead/foreign link for the reported 9B CJK decoding-error finding.
3. P3 (inherited, still open at this head) — exporter writes without atomic staging. recipe/vela/export_native.py:113-118 still mkdir+saves directly into --out (no mkdtemp+rename), deviating from the Kev #170 precedent; contained by the fail-closed bundle gate.

Notes

• Scope/registration: the raw vs-main diff is dominated by absorbed main content — reviewers should treat src/models/vela/native/ as the #175–#177 surface plus the member layer, exactly as the body's "stacked PRs and merge order" section instructs (that section is accurate and helpful). README/supported-models/mkdocs/recipe rows are consistent across the stack at this head, including the 4B/9B rows and the mkdocs rename to "Vela 2.0 decoder native library"; the interim "9B two of four cases" wording in the 1b8d025b resolution was superseded by 1af69af5's completed four-case record.
• The branch still merges main only up to 22b7717c (≈4 syncs behind e573260c); another upstream merge will be needed before/when the stack lands.
• One shared git worktree check at this head during this review (removed after): PYTHONPATH=src pytest tests/vela 164 passed (~9 s, torch-free — confirming the body's torch-free claim; count grew past the body's 160 as later commits added tests), PYTHONPATH=. python -m pytest tests/benchmarks 133 passed, mkdocs build --strict exit 0 (INFO-level warnings only). No cargo/GPU available to this reviewer; the crate's weight-free tests were not re-run locally — CI's rust job (success) covers them.
• CI observed at the exact head 71c189408 (Actions API, ThinkFlowLab/system1-omni): workflow runs CI success (id 41026207762) and Docs success (id 41026207720); check-runs benchmarks/build/cuda-compile/cuda-contract/rust all success, deploy skipped; the benchmarks job's "Vela worker tests" step ran and passed. ThinkFlowLab/system1-agents has no runs for these SHAs (nothing expected there). Combined commit status reads "pending" with zero status contexts — same quirk as the other three heads.

Body / template

• Template answers: present and specific (all four questions answered, PR-needed justified, N/A bug-fix). Checklist: all four boxes checked.
• Head pin: incorrect as the primary pin (73af078 — see finding 1); the merge-order table and stacked-PR description are otherwise accurate.
• Evidence: author-run, hardware/revision/gate-detailed in the recipes; no raw archive (declared); GPU evidence items are appropriately labeled author-run.

Verdict: COMMENTED

The member-parameterization work is the right shape (registry mirroring, shape-derived widths, no ABI change, honest divergence records), and CI + local checks are green. COMMENTED for finding 1: the body must be updated to the 71c18940 reality (stale primary pin + the "every case verified" claim vs the head's own "unverified until rerun" declaration) before this can be considered for approval.

[MrDongsls]

Addressed at 7b60e4e. The body now pins the current head and scopes the verification claim to the executor logit gates, stating plainly that the head and response replays for 4B and 9B await re-recording under the current assertions as native.md does. On the link finding: the repository's canonical name is InferMatrixLab/system1-omni, ThinkFlowLab redirects to it, and the linked issue comment exists, so the native.md link resolves and was left unchanged. The inherited exporter staging item is fixed here by merging the stack down from #175, and the bundle walk item was already covered by this branch's recursive walk with its own tests.

[hsliuustc0106]

Pass-107 fix-delta review — #195 (vela: serve the 4B and 9B decoder members)

Head reviewed: 7b60e4ec1 (model/vela2-4b-9b) — pushed after pass-102's review of 71c189408. OPEN, non-draft. Base: main.

Delta reviewed this pass

Exactly as declared — one absorbing merge, zero authored commits:

• 7b60e4ec "Merge branch 'model/vela2-native-executor' into model/vela2-4b-9b" (parents 71c18940 + 65766b83). Net diff vs first parent: 3 files, +68/−30. The resolution hunk in recipe/vela/export_native.py correctly combines the review follow-ups merged down the stack (atomic stage_into_place for both the bundle and the --bf16-out set, present at lines 70-89 and used at 178/202 of the merged file) with this branch's member-registry exporter (verify_package resolving the member, --executor-only, per-member manifest source pins). bundle.rs and scoring.rs are byte-identical to 71c18940 — this branch already carried the stronger versions (recursive walk_unpinned from 8d994e1d; total_cmp + HashMap window index from e5a16849), so the merge takes them wholesale and no resolution was needed there.

Stack integrity

b9a60c0e (#175) ⊆ 86f689850 (#176) ⊆ 65766b834 (#177) ⊆ 7b60e4ec1 (this head) — all verified with git merge-base --is-ancestor. The series remains a clean linear stack; this head is the superset and carries every fix from the lower reviews.

Prior findings — status at this head

Pass-102 finding	Status at 7b60e4ec1
P2 — body pinned stale 73af078 and claimed "every case of every member is verified" while the head's own native.md said 4B/9B head/response replay was "unverified until rerun"	RESOLVED. The body's primary pin is now "System1-Omni Version / Commit: 7b60e4e on model/vela2-4b-9b, based on the #177 head 65766b8", with a new head-update bullet documenting the absorbed stack fixes and fresh check counts. The "every case of every member is verified" sentence is gone; Demo/evidence now reads "The 4B and 9B executor logit replays are complete and recorded. The larger members' head and response replays … stay unverified under the current assertions until rerun with the exported bundles, as native.md states; the claim of verification here covers the executor logit gates." recipe/vela/native.md:31 still declares the head/response replay "unverified until [rerun]" — body and head docs now agree. The remaining 73af078/b2559fe/1af69af mentions are historical records in the head-update changelog, which is the right treatment.
P3 — dead InferMatrixLab-org link in the body	RESOLVED. No InferMatrixLab links remain in the body.
P3 — inherited the export's no-atomic-staging write	RESOLVED. stage_into_place (sibling staging, non-empty-target refusal, stale-remnant cleanup, one os.replace, except BaseException cleanup) is in the merged export_native.py and applied to both outputs; native.md:70-73 documents it.

Carried fixes re-verified at this head: NaN-safe sorts (total_cmp ×2, partial_cmp ×0 in scoring.rs), O(n) window aggregation (HashMap or_insert index, no position scan), fully recursive bundle walk (walk_unpinned), tighten-only VELA_GPU_LOGIT_GATE (native_executor.rs:72-79, .min(0.35)), fixture recorders calling verify_package (export_token_plan.py:127-133, export_head_inputs.py:169-175).

New findings

None. Non-blocking nit, not counted as a finding: --executor-only without --bf16-out produces a bundle the executor cannot load; it fails closed at load (the manifest simply doesn't pin a backbone), and the flag's help text documents the intended pairing.

Numerics contract

The delta does not touch any measured value: git diff 71c18940 7b60e4ec -- recipe/vela/native.md only adds the staging note and changes the gate wording from "overridable" to "tighten-only … a wider value clamps back down". Recorded ceilings (heads/response ≤1.5e-6, executor worst 0.285 at 0.35, 4/4; 4B 0.2271 and 9B worst 0.2281 from 1af69af5) are unchanged, and the only gate semantics change is a tightening. The honest unverified-until-rerun language for the 4B/9B head/response replay is retained in both docs and body.

Verification (sources kept separate)

• Source inspected: git show --cc 7b60e4ec, full diff 71c18940→7b60e4ec, merged export_native.py, bundle.rs, scoring.rs, native_executor.rs at this head; the current PR body and native.md:31.
• Commands run (local, CPU, miniconda python, worktree at 7b60e4ec1, removed after): PYTHONPATH=. python -m pytest tests/benchmarks -q → 133 passed; PYTHONPATH=src python -m pytest tests/vela -q → 164 passed; mkdocs build --strict → exit 0. All three match the body's claims for this head exactly.
• Observed CI: runs at exactly 7b60e4ec1 on both ThinkFlowLab/system1-omni and InferMatrixLab/system1-omni Actions APIs (identical run IDs — shared backend): CI 41173895523 and Docs 41173895796, both completed/success, 2026-10-31T05:46Z, covering the rust job (fmt, workspace clippy, workspace tests, release build) and the benchmarks/worker-tests job. (The three lower heads have no dedicated runs; see those reviews — their content is contained in this green head.)
• Author-reported (not independently verified): the GPU-recorded replay numbers and the workspace-level cargo counts (431 passed) — the latter corroborated by the green CI rust job at this head.

Template

All four required contributor answers, PR-needed decision, Test Plan with correct head pin, per-head Test Result bullets, Demo/evidence (properly scoped), and Self-review checklist present.

Verdict: APPROVE

The pass-102 P2 is fully resolved — the body is re-pinned to 7b60e4e, the overclaim is replaced with exactly the head docs' scoping, and the inherited P3s are fixed at this head. Numerics contracts preserved, merge resolution correct, CI green on both repos, and local CPU checks reproduce the body's claims. No new findings.

[psv666]

Follow-up at 7b60e4e: the four issues in my earlier review are addressed in the inspected code.

• The decoder now resets the active span when a valid word is rejected, with the Alice met Bob and empty-offset regressions.
• Response/head checks retain span structure instead of stripping divergent spans; missing-span regressions cover both 4B and 9B.
• The shared drift helper checks finiteness and dimensions before reduction.
• Fixture export disables bytecode writes through import and initialization, with repeat-use coverage.

Personally run: 164 Vela Python tests passed, 42 Rust tests passed / 4 ignored, and strict MkDocs passed. I found no additional actionable issue in this follow-up.

The 4B/9B head and response replays under the restored assertions remain unverified, as the body now states; old passes with span stripping do not establish these stronger gates. Also, #175/#176/#177 still lack some of these fixes. I reported the reproduced defects on those prerequisite PRs so they can be synchronized before an earlier slice is merged independently.

Review scope and provenance

Head 7b60e4ec1dff9f7949467be5e0b34133240b55db; PR API base 22b7717c9710de5ac5c6ccba51a6d6686dae90d9; diff merge-base 22b7717c9710de5ac5c6ccba51a6d6686dae90d9. Inspected scope: the four previously reported defects and their subsequent fixes, plus current validation/fixture changes; not a new full review of the entire model stack. Complete changed-file inventory: 89 files, 6,976 changed authored-code lines / 8,558 total text lines (binary fixtures counted as files, not text lines).

Loaded trusted InferMatrixLab/system1-omni@5fa5179d57f9267bb0d20162004d8ce26352aa9d:.agents/skills/system1-omni-review/SKILL.md, SHA256 3a4b876162da14eee8db56af86664576aa5755b8f3e80b3072e944018647c3bc, plus architecture, repository contracts, CONTRIBUTING, self-review artifact requirements and CI/Docs workflows. Personally executed checks are distinguished above from author-reported GPU evidence. No GPU inference was run in this review; no approval or readiness transition is implied.

[Levius-Fubuki]

Independent model/package review and real native GPU replay at 7b60e4ec1dff9f7949467be5e0b34133240b55db. The 4B/9B native small-case GPU gates pass, but changes are still required before this PR can advance.

Environment: RTX 4090 24GB, SM89, driver 580.105.08, nvcc 13.0.88; 16 available CPUs / 120 GiB container RAM; Rust 1.98.0, Python 3.12, Torch 2.11.0+cu130, Transformers 5.19.0. Each head had its own source-verified build target; tracked source files, committed JSON expectations and acceptance ceilings were unchanged.

Pinned members: 4B d692394127f6f87fc581d8634c9558fe4776efce; 9B 068425bb145c05884a98b870c219047da22d9aea; 0.8B control 326b01d81f61fff7fd4ae570e54b87a49119e490. All selected package files were verified against authoritative Git-blob/LFS hashes before use.

Reviewer-run results

Check	4B	9B
Original processing/token-plan replay	5/5 pass	5/5 pass
Original head/scoring replay	4 short cases pass; long-span fails	4 short cases pass; long-span fails
Original response replay	4/4 small cases pass	4/4 small cases pass
Original CUDA executor replay	4/4 pass, max0.2271 <0.35	4/4 pass, max0.2281 <0.35
Sampled device-memory peak	10,615 MiB (~10.37 GiB)	17,975 MiB (~17.55 GiB)

Memory is one-second device sampling, not a minimum-card guarantee. The standard 24GB card is sufficient for these four native cases. Response finishing uses recorded span logits, so its PASS does not establish long-span head parity. Full long-span/broad-head GPU execution, Python 9B FP32-parameter GPU reference, HTTP end-to-end and performance were not measured.

The optional 4B/9B hidden-input binaries were recovered from the tracked Git blobs in #177 at bc0fb9cb27857ae94198e3f79d8acd660736ef0d, with blob IDs, sizes and SHA-256 recorded, then added only as untracked replay inputs to the #195 checkout. The committed #195 JSON expectations were not regenerated.

Blocking fixes

1. [P2] Repair inherited window-call attribution and reconcile the reference recording. At native_heads.rs:331, row_span_calls[1..] is empty for parent row0, because windows were recorded as rows1/2. Original strict head replay therefore returns 0 spans vs76/373, answer drift1 > the unchanged0.008/0.012 limits. The source fix belongs in #176 and must be propagated here.

An external diagnostic supplying those actual window calls, without changing the production library, hidden inputs, JSON targets, numerical gates or structural assertions, yields 79/377, still different from76/373. Crucially, feeding the committed recorded logits through the pinned upstream aggregation/calibration/decoder, with every word covered, also yields 79/377. This independently demonstrates an internally inconsistent fixture target; it does not establish a native-head math defect.

export_head_inputs.py:207–216 records heads through individual engine.run([rec]) calls, then obtains predict from a separate engine._predict(req) execution. Please reconcile their batching/profile/provenance and record inputs/logits/answers from a consistent reference execution. Do not remove spans, widen gates or regenerate expected answers from the candidate merely to pass.

2. [P2] Restore the external manifest anchor and confined path handling. Bundle::load has no external manifest SHA-256 parameter, and line119 hashes dir.join(name) without the current stack's pinned_path checks. A compiled public-API probe returned:

{"initial_bundle_accepted":true,
 "rewritten_file_and_manifest_accepted":true,
 "outside_relative_path_accepted":true}

The second result modifies a file and its self-reported hash; the third is a manifest-only ../outside entry. Preserve #175–#177's external-anchor signatures and relative/no-symlink path constraints when synchronizing, and cover both cases with fail-closed regressions. This is a synthetic gate probe, not a claim of remote code execution.

3. [P2] Make the documented nested BF16 export work. export_native.py:178 stages out/bf16 first; line202 then refuses its own now-nonempty out. The documented command was actually run against the pinned0.8B package:

PYTHONPATH=src python recipe/vela/export_native.py \
  --package "$PACKAGE" --out "$BUNDLE" --bf16-out "$BUNDLE/bf16"

bf16 backbone: 320 tensors -> .../bundle/bf16
output directory .../bundle already exists and is not empty
exit=1; bf16_written=true; manifest_written=false

The current #177 nested atomic export succeeds. For this PR's independent 4B/9B tests I used its unchanged --executor-only export with an external BF16 directory, moved that complete directory into bundle/bf16, and checked the unchanged manifest plus every file hash. That preparation workaround does not qualify the failing documented workflow.

4. [P2] Correct the reference-worker memory guidance. reference.md:136–138 recommends4B≥12GB/9B≥24GB for BF16 autocast, but the pinned runtime retains FP32 parameters. Constructing its actual config_class/model on meta device gives 16,844,728,328 bytes (15.69GiB) for4B and 31,781,492,744 bytes (29.60GiB) for9B before the separately attached broad head, activations and autocast caches. The actual0.8B GPU reference confirms FP32 parameter storage. Please distinguish Python FP32-parameter/BF16-autocast reference from the native uniform-BF16 export. The 24GB native results above cannot justify a24GB9B Python-reference recommendation. The bounds are parameter counts, not claimed4B/9B reference GPU load measurements.

5. Propagate the current prerequisite fixes and qualify0.8B as well. The current #175 canonical-state defect changes token IDs; #176's window attribution defect is inherited here. #195 is not a descendant of current #177; a merge-tree comparison reports16 conflict paths. Restore the latest stack's intended protections during reconciliation. A control using this PR's actual source/library and the unmodified valid0.8B export passes CPU processing/head/response replays, but the original GPU test reproduces #177's CJK0.39117718 >0.35 failure on this SM89 host.

Other verification and advance conditions

• Vela Python: 164 passed; release/locked Rust crate: 42 passed,0 failed,4 ignored in the ordinary run.
• Original opt-in tests above were explicitly executed; ignored tests are not counted as passes.
• fmt, strict crate clippy, strict MkDocs and this head's CUDA build: passed.
• Previous rejected-word span reset, strict span structure, finite/dimension and bytecode-cache repairs are present; this review is not reopening those fixed findings.

After synchronizing #175→#176→#177, repair the recording/replay, manifest gate, nested export and memory documentation, then rerun the original strict member replays with the same ceilings and exact span checks. The4B/9B GPU passes are useful evidence for advancing once these issues are resolved; they do not override the failed long-span acceptance checks.

Scope: API base/merge-base 22b7717c9710de5ac5c6ccba51a6d6686dae90d9;89 changed files,6,976 authored-code /8,558 total changed lines. Current-head CI/Docs are green, independently observed. Full logs, model/source/library identities and probe sources are retained locally in sealed archive SHA-256 c3e490e39b7e234e0bc6f666f7513226aada481cf5fc202ab82892f7efcc349c; raw archive is not attached here. Provisioning-log temporary signed URL queries were redacted with original/delivered hash audit records; numerical evidence was preserved.

Review method: the repository's system1-omni-review skill at trusted main 5fa5179d, SHA-256 3a4b876162da14eee8db56af86664576aa5755b8f3e80b3072e944018647c3bc; contributor self-review/split rationale, component interfaces and complete changed-file inventory checked. Results below are reviewer-run; previous author measurements and green weight-free CI are not substituted for model/GPU replay.

[Levius-Fubuki]

[P2] Preserve the recorder's window ownership. The positive long-span fixtures have parent row0 and window rows1/2, so the already-grouped parent's [1..] is empty. Unchanged4B/9B replay gives0 spans vs76/373. Map and consume the actual window calls, and propagate the repair from #176. A separate reference-recording inconsistency remains after this correction; see the export_head_inputs comment and review body.

[Levius-Fubuki]

[P2] Freeze a self-consistent reference execution. Window head calls above are recorded individually, while predict comes from this separate _predict run. The committed4B/9B long-span logits, aggregated with the pinned upstream rules and decoded by the pinned upstream decoder with full word coverage, produce79/377 spans; their predict fields expect76/373. An external native probe with only window attribution corrected produces the same79/377. Please reconcile batching/profile/provenance and capture matching inputs/logits/answers; retain strict structure and numerical gates.

[Levius-Fubuki]

[P2] Preserve the current stack's anchored, confined bundle verification. Bundle::load(dir) trusts the manifest's own hash table and dir.join(name) accepts paths outside the bundle. A compiled public-API probe accepts both a rewritten file+manifest and a manifest-only ../outside entry. Restore the external trusted manifest SHA-256 parameter and pinned_path relative/no-symlink checks from #175–#177; test that both scenarios fail closed.

[Levius-Fubuki]

[P2] Stage nested BF16 output together with its parent bundle. With the documented --out bundle --bf16-out bundle/bf16, this creates a nonempty bundle; the later stage_into_place(out, ...) then refuses it. Actual pinned0.8B run exits1 after writing BF16, with no manifest. Preserve current #177's working nested atomic-export handling and add a real-path regression for this documented arrangement.

[Levius-Fubuki]

[P2] Size the Python reference for FP32 parameters. The pinned loader retains FP32 weights; BF16 autocast does not halve their storage. Actual config_class/model construction on meta gives4B15.69GiB and9B29.60GiB of default parameters alone, excluding broad head and working caches. Thus12GB/24GB cannot hold the stated4B/9B reference profiles. Separate these requirements from native uniform-BF16: this review's24GB card did pass the four native4B/9B GPU cases.