11 — Errata (2026-09-23)¶

Three independent audits against VSS 1e94133b4 (08, 09, 10) and in-session verification of this repository corrected claims in docs 00-07. This file is the single place those corrections live. Docs 00-07 keep their original text and carry a banner pointing here, so their evidence history stays readable.

Check here before relying on any claim in docs 00-07. Line-number moves with no change in substance are not repeated here. See the stale-citation tables in 08 §8 and 09 (final section).

Index by document¶

Corrections that change conclusions¶

E1. "Two vLLM engines cannot share one GPU" is not a VSS-wide rule. [V]

• Claimed in: 04 §3, 05 "structural advantage", 07 recommendation 4, and the old README summary.
• What's true: the quote is a comment in the search-on-edge block, measured on AGX Thor unified memory (deploy/docker/scripts/dev-profile.sh:1211-1216, moved from :1161-1165). VSS documents LLM + RT-VLM sharing one GPU at 0.40 + 0.40 on H100 and RTX PRO 6000 (skills/vss-build-vision-ai/references/sizing.md:98-100,106,109), and at 0.3 + 0.2 on GB300 (:136-142). The only enforced same-GPU ban is L40S, a capacity rule (dev-profile.sh:1376-1387).
• What actually blocks consumer cards is capacity:
• the LLM NIM's INT4 profile requires ≥32 GB/GPU (nim/nemotron-3.5-lightning-30b-a3b/hw-OTHER.env:25-27);
• RT-VLM reserves 0.7 of VRAM by default (start_rtvi_vlm.sh:119-124).
• What changes: our contribution is no longer "a topology VSS can't do". It is no ≥32 GB floor, idle unload, still-image ingest, graded risk plus verification.
• Sources: 08 §2.2, 09 contradiction 1, 10 §9.1.1, re-verified in-session.

E2. VSS's smallest "tier" is not a single 32 GB card. [V]

• Claimed in: 00, 02, the old README.
• What's true: the RTX PRO 4500 tier requires alerts only, a remote LLM, at least 2 GPUs, and driver ≥ 595.58.03 (dev-profile.sh:1037-1051,1161-1179). The smallest validated configurations are 2×32 GB with a remote LLM, or 1×48 GB L40S with one model remote (docs/prerequisites.mdx:370-395). The consumer gap is larger than first stated.
• Source: 08 §0.

E3. This repo's ai/ tier describes the shape of a single-card system, not a shipped configuration. [V]

• Claimed in: 00 ("designed to fit a 24 GB budget"), 05, the old README.
• What's true:
• Production is dual-GPU: the LLM on the A5500 (24 GB) and the Triton ai-gateway on an A400 (4 GB) (docker-compose.prod.yml:139,153,159,322-323,351).
• The 30B-A3B Q4_K_M GGUF alone is 24.57 GB (08 §2.5), so a single 24 GB card works today only through partial CPU offload.
• On 2026-09-23 the owner retired the A400. The design targets a single A5500.

E4. Production has no duty cycling for perception models. [V]

• Claimed in: 05 ("duty-cycle gap": model_zoo LRU as our advantage).
• What's true:
• The production gateway starts Triton with --model-control-mode=none (ai/gateway/entrypoint.sh:131), which loads every model at boot and never unloads.
• The LRU manager lives in the standalone enrichment server, which isn't a production service.
• llama.cpp idle sleep is unused.
• What stays true: VSS model services have no unload path either (09 §1f, §4f). The differentiator is real once it is built, which the design does in Phase 1.4.

E5. This repo's structured risk output is probably not enforced. [V code / ? runtime]

• What's true:
• nemotron_analyzer sends NIM's nvext.guided_json to llama.cpp's /completion, whose native parameters are json_schema/grammar.
• Its capability probe counts any 2xx as "supported" (backend/services/nemotron_analyzer.py:462-483, :593).
• Unparseable output falls back to score 50 → medium (:4392, :2884-2885), which is the empty-porch failure.
• One request on the A5500 settles whether b7972 ignores nvext.
• Also: 06 §4's plan to demand Event JSON through response_format: json_schema works only in RT-VLM integrated mode; openai-compat mode drops it (09 contradiction 9).

E6. VSS's "always-on" alert route is not model residency. [V]

• Claimed in: 05, as [A].
• What's true: it is a disabled-by-default VIOS webhook that auto-attaches rules to new streams (docs/release-notes.mdx:161,170-172). The residency point stands on other evidence (docs/real-time-vlm.mdx:1535-1536; 09 §1f).

E7. VSS's uppercase AlertSeverity is dead code. [V]

• Claimed in: 06 §4, as [A].
• What's true: the live wire is a lowercase binary verdict, confirmed / rejected / verification-failed (09 §5, §9). There is no severity scale to align with.

Sizing figures that were not measurements¶

E8. RT-Embed's "fixed 10 GB, no knob" is a planning reserve. [V]

• What's true: "Reserve about 10 GB" is a Search starting value (sizing.md:290-291).
• There are knobs: COSMOS_EMBED1_TRT_PRECISION int8/fp8 (docs/real-time-embedding.mdx:351), and the batch size auto-drops on small cards.
• The weights are 2.39 GB [E].

E9. RT-CV's "≈3.0 GB (1.7-4.5)" and "95-96% SM at 2-3 streams" are not consumer-GPU measurements.

• 1.7 GB comes from an illustrative render box in a skill template (skills/deployment/vss-deploy-detection-tracking-2d/references/next-steps.md:217-218).
• 95% is DGX Spark max-stream data (docs/performance-rt-cv.mdx:66-67); L40S runs 15 streams at 87% (:57).
• 3.0 GB has no in-repo source. Treat both figures as [?].

E10. Nano-9B FP8's "13.39 GB actual [V]" is really [C].

• It is the 10.30 GB blob × 1.3. VSS itself says 11.7 GB (sizing.md:77).

Smaller corrections¶

(09 c.N = 09 "Contradictions with the existing docs", item N.)

Dated additions (2026-09-24) — corrections to the design spec itself¶

From Phase G0 execution; evidence lives in docs/plans/2026-09-23-vss-gaming-gpu-ledger.md (row refs in parentheses).