Problem

Services on 6PN read secrets from bao over plaintext HTTP. The root token in 1Password is for emergencies; sharing it with services is the credential distribution problem bao exists to solve. Any 6PN neighbor can observe or modify traffic to the listener.

The FDB root CA key is lost a second time (the replacement from RFD 2141 was stored via op item create, which returned an item ID but did not persist the item). Chaining under that CA is not possible without rotating FDB again.

Decision

Bao’s PKI secrets engine becomes a standalone root CA for service auth. The FDB CA (fdb-ca.chibifire.com) stays separate for cluster mutual TLS.

1. Mount pki/ and generate a root CA inside bao.
2. Issue a listener cert; enable TLS on :8200.
3. Enable the TLS cert auth backend. Each service presents a client cert signed by bao’s PKI and receives a scoped token for its KV paths.
4. Elixir services use libvault (hex.pm) as the vault client.

Gate: bao rejects a plaintext request to :8200. Negative control: a request with no client cert, or with an expired cert, returns 403.

Related

RFD 2140 (bao on FDB), RFD 2141 (FDB TLS rotation).

Details

The measurements and the retractions

Problem

The CA private key from RFD 2134 is not recoverable, so no new leaf can be issued. bao needs a client cert, and the machine certs expire in two years. RFD 2134’s reset path wipes data, which was acceptable at initial setup and is not acceptable now.

Decision

A three-phase rolling rotation using FDB’s automatic TLS certificate refresh. The cluster stays available and data stays intact at every step; each phase is gated on fdbcli status reporting healthy.

Phase 1 (dual-CA trust). Generate a new CA with the RFD 2134 profile. Set FDB_TLS_CA_B64 to old + new CAs concatenated. Rolling restart. Every machine trusts certs from either CA.

Phase 2 (new leaves). Mint new certs under the new CA for all three machines and for bao (fdb-bao.chibifire.com). Replace each machine’s cert/key secrets. Rolling restart.

Phase 3 (drop old CA). Set FDB_TLS_CA_B64 to the new CA only. Rolling restart. Store the new CA key in bao and in 1Password.

The cluster file does not change (addresses keep :tls), so no coordinator reset is needed.

The rotation tool is an Elixir TUI in weft-warp-burrito, packaged via Burrito. It walks the phases, gates each on cluster health, and stores the CA key on completion. The procedure is in DETAILS.md.

Related

RFD 2134 (initial TLS), RFD 2140 (OpenBao on FDB).

Details

The measurements and the retractions

Problem

OpenBao dropped every storage plugin when it forked from Vault v1.14.x. The weftspun-fdb cluster already runs three machines with double redundancy, TLS, and backup, and raft on a single shared-cpu machine has no replication path.

Decision

Restore the FoundationDB backend from Vault v1.14.8 (last MPL-2.0 release), connecting to the existing weftspun-fdb cluster over 6PN. The port rewrites three interfaces that diverged after the fork: ListPage, interactive transactions (BeginTx/BeginReadOnlyTx with Commit/Rollback), and pins the FDB 7.3.79 Go binding (headerVersion = 730). Build tag foundationdb, CGO_ENABLED=1.

Deployment files in weftspun/service-openbao. The bao machine carries only the FDB client library and connects to the cluster via a TLS client certificate. Interface details and deploy measurements are in DETAILS.md.

Verification

bao status: Storage foundationdb, unsealed. KV v2 at secret/, anchor creds written from weftspun-fdb over 6PN. Root in 1Password.

Related

RFD 2109 (FDB as the store), RFD 2134 (cluster TLS).

Details

The measurements and the retractions

Problem

The MaskScore extraction pipeline (RFD 1173) needs seven models co-resident on GPU. At published precision (bf16), VoxHammer alone requires 40 GB. QAFT to NF4 is required before extraction can begin. Condition 5 permits this: QAFT makes NF4 the published precision.

Decision

QAFT all seven pipeline models to NF4. Fork each upstream model on HF.

Related

RFD 1173 (the pipeline design), RFD 1143 (keypoints to ANNY).

Problem

uro held V-Sekai users and served content; spot-broker held the vast.ai key and posted double-entry entries for spend. Both needed GitHub sign-in, both wanted the same TigerBeetle-shaped ledger, and neither could hand a stranger a downloadable VRM without the other: two GitHub OAuth apps, two Fly apps, two deploy pipelines, one user story.

Decision

They merge as interactor-shuttle at 3-interactor/interactor-shuttle. Interactor because the primary role is user-facing (GitHub sign-in, landing page, roll button, VRM download); spot-broker’s keeper policy, the TigerBeetle accounting on ecto_sqlite3, and the FoundationDB event ledger become internal modules rather than peers. shuttle fits the weaving vocabulary the workspace already uses (weftspun, sinew, taskweft). spot-broker’s Fly URL and repo become redirects; RFDs 2133-2137 stay as written, naming the predecessor service, per the retractions-stay-in-place rule.

Migrating unchanged: one holder of the vast.ai key (the shuttle process); keeper singleton-with-hysteresis (RFD 2133); mutual-TLS FoundationDB cluster plus Tigris backup (RFDs 2134-2135); TigerBeetle-shaped Account and Transfer tables, sum-to-zero by construction; GitHub OAuth via oauth_mcp_bridge with a new SH_GH_* credential set, so spot-broker’s SB_GH_* credentials rotate out with the rename.

Operator questions and verification

Org: recommend v-sekai-fabric since the V-Sekai user record is the load-bearing state, though uro lives at v-sekai/uro and spot-broker at weftspun/spot-broker. Cutover: land the code merge with both old services running, then keep spot-broker’s Fly app alive one week so pinned callers see 410 Gone rather than timeouts. Done when one Fly app serves both the landing and the GPU spend API, one GitHub OAuth app authenticates both, one deploy pipeline builds one release image, and the predecessor RFDs are not backfilled. Move-cost inventory in DETAILS.md.

Details

The measurements and the retractions

Problem

RFD reports published as pages have no shared shape: each one reinvents its header, its tables, and its palette, and the working agreements the documents encode (retractions in place, baselines beside numbers, controls named) have no slot a page reminds an author to fill.

Decision

One template, template.html in this directory, in the PERT sheet’s design system: Libre Franklin over IBM Plex Mono, the paper/ink/critical/done/steel tokens, light and dark themes resolved at the token level. To publish a report, copy the file, replace every bracketed slot, and keep the worked example’s shape.

The layout encodes the agreements rather than describing them:

• the serial header and stamps mirror the RFD frontmatter;
• every measurement table carries its baseline row, and the chosen row takes the green rail;
• the figure is an inline SVG in currentColor with labelled arrows, one claim, stated again in its aria-label;
• the retraction block is bordered in the accent and sits in place, next to what it retracts;
• the controls card lists each planted defect the gate caught;
• the provenance foot points at the logbook, the PRs, and the command to re-run, and pairs physical measurements with a household-object equivalent.

Verification

The worked example filling the slots is RFD 2134, so the template is demonstrated by a report that shipped rather than by lorem.

Problem

The prior draft of this RFD ran a PERT network with a chain A → I → D → E → G, and I → D skipped every step that turns a text prompt into a mesh good enough to skin: no image-to-3D via Pixal3D, no EditScore judge, no repair loop. A pull is not a gacha item without those, so the network was drawing a schedule around a pipeline that did not yet exist end to end.

Decision

Rebuild the plan as a ladder, in Gall’s Law’s sense: each rung is a small working system that the next one extends, and no rung is added until the one below it demonstrably runs. That replaces the parallel tracks with a sequence where every step shows something, and it puts Pixal3D and EditScore on the spine where they belong.

The ladder, bottom to top:

0. Language prompt → image. OmniGen2 renders a reference image from a text prompt. Pixal3D takes an image, not text, so this rung is the ground the rest stands on. An image comes out.
1. Image → mesh. Pixal3D renders one mesh from the reference image on the desk 3090. A mesh comes out. Whether it is good is the next rung’s problem.
2. Prompt → mesh → judged. EditScore scores the mesh against the prompt. A number comes out. Whether the number is trusted is the next rung’s problem.
3. Prompt → mesh → judged → repaired. VoxHammer runs the repair pass on below-threshold meshes; they are rejudged and the loop bounds to N attempts. Every prompt yields a mesh with a passing score, or a recorded refusal.
4. Prompt → passing mesh → skinned. SkinTokens runs in skin-mode against the canonical ANNY skeleton and produces a rig that bends without collapsing (EditScore on posed frames is the QA gate).
5. Prompt → skinned mesh → tagged. The canonical See-Through partition (VALID_BODY_PARTS_V3, 23 tags; RFD 1121 audited) is recovered on the mesh by treating the mesh’s partition as corruption: VoxHammer proposes repairs toward the canonical partition, EditScore judges each proposal, the loop bounds to N attempts. Written to the mesh as a per-vertex tag primvar. Parts are addressable.
6. Prompt → tagged rig → VRM. The seed-to-VRM assembly runs end to end from a single command: a portable, editable character file.
7. Prompt list → pool. The seed-to-VRM command runs against a list of prompts, gated by rent from the spot-broker when the desk is not enough. About 50 VRMs, judged and reproducible by seed.
8. Pool → roll button. A page with a roll button dispenses one VRM per pull, downloadable.
9. Public. The page is hosted with a sponsor link and an automation-disclosure page.

Each rung is a demo you can show. A rung is “done” when it produces its output from the previous rung’s output, and a control run on a known-broken input fails. The order stays fixed: skipping a rung is the failure mode this RFD replaces.

Verification

page.qmd beside this file draws the ladder and pairs each rung with its inputs, its output, and the negative control that certifies it. The spend infrastructure the higher rungs lean on is live (RFDs 2133–2135); the two operator-side blockers (vast.ai key, broker token) bite at rung 7, not before.

Figure

The report as a page

Problem

The weftspun-fdb backup needed a staleness gate, and the two obvious homes were both wrong. CI has no production access, and granting it some means a new credential with a new blast radius. The spot-broker keeper holds spend authority, and an admin service that accumulates monitoring scripts becomes the home of every capability.

Decision

A production check runs on the machine being checked, because that is the one place the credentials already are: nothing new is granted anywhere. It publishes a health file over a local httpd, and a Fly machine check turns the file into a pass or fail in fly status.

Two reference cases ship, both on weftspun-fdb. backup_fresh reads the backup layer’s own metadata; a backup is fresh only when it is running and its restorable point is close. cluster_health fails until the data state is healthy and a zone can be lost without losing data, so a rolling deploy waits out re-replication after each restart, the way the Kubernetes FDB operator gates its own rolls.

Every check refuses to arm unless its self-test controls fire in both directions, and an unreadable signal always reads as failure. The measurements behind both checks, including the two backups that silently self-completed and the curl signing limits that reshaped the probe, are in DETAILS.md and the logbook.

Verification

The roll gate’s first live exercise was its own deploy: after each machine restart the check held red (data_healthy=no) through re-replication and the roll waited, then all three machines converged to 2 of 2 checks passing.

Details

The measurements and the retractions

Problem

The weftspun-fdb cluster came up plaintext, and its backup could not reach the blob store: FoundationDB uses one TLS policy for peers and for S3, so a cluster with no trust store cannot speak HTTPS to Tigris. Turning TLS on after the fact hit two walls, one known and one new.

Decision

Mutual TLS from a private CA, per-machine certificates named by Fly machine ID, and one client certificate per consuming service, all carrying X.509v3 extensions, because FoundationDB’s preverification rejects a bare openssl req -x509 CA as invalid CA certificate. The profile, the local Docker proof with its negative control, and the full procedure are in DETAILS.md.

The known wall is recorded in datasource-store’s fdb-entrypoint and held exactly: there is no in-place path from a plaintext cluster to a TLS one, because :tls is part of a coordinator’s address and the coordinated state on disk names addresses that no longer exist. The gated WEFT_FDB_RESET=1 wipe is the remedy, so TLS is decided before there is data worth keeping; this cluster held one test event.

A client is a TLS peer like any other: it presents its own leaf (CN=fdb-spot-broker.chibifire.com) through the FDB_TLS_* env vars libfdb_c reads, and verifies the cluster with the same rule the cluster uses (Check.Valid=1,S.CN>=fdb-,S.CN<=.chibifire.com).

Verification

A matched pair in local Docker before any push: v3 certificates form a database; the previous extension-less certificates reproduce the production failure on the same server and rule. In prod, a ledger event survived a full machine replacement and read back over TLS.

Details

The measurements and the retractions

Problem

Pool generation wants days of GPU that the desk card should not give up: the 3090 is the interactive seat for rigging and judging, and a batch that owns it for two days stalls the critical path it feeds.

Decision

Rent single RTX 4090s from the vast.ai book, requirements before price. A qualifying host carries CUDA at 12.8 or newer, 100 GB of allocatable disk, 32 GB of RAM, and 200 Mbit/s down; the measurements behind each gate are in DETAILS.md, with the price distributions that show what the gates cost. The gates exist for the cheap unqualified boxes: the sub-15-cent listings that flicker through the book bought their price with 52 GB disks and 16 GB hosts, and a model pull over a starved link is paid idle time.

Interruptible is the planning tier, near 20 cents per hour at the qualified p25; on-demand is bought when a qualified outlier dips, and sub-floor outliers were measured living minutes, not hours. Pool work is seed-checkpointed, so an interruption costs one pull.

The RunPod teardown rule applies unchanged: results are pushed when produced, the instance is destroyed after use, and the destruction is double-checked. The API key lives in the user environment, read from the password manager, never in a repository or a transcript.

Related

RFD 1163 keeps the desk card for the loops this rule protects. The demo plan this feeds is charted in the Gacha Critical Path artifact; pool generation is its activity E.

Details

The measurements and the retractions

Problem

The workspace’s rules live in CLAUDE.md and BLOCKLIST.md. An outside reader who asks “do you meet SOC 2?” or “which ISO 27001 controls apply?” receives a paragraph, not a control identifier. Coverage the rules already give reads as absent.

Decision

Publish the rules against two known frames: SOC 2 (2017 Trust Services Criteria, revised 2022) and ISO/IEC 27001:2022 Annex A. Neither replaces a rule; each names one under an identifier the outside reader already knows. Documentation-only, FOSS: no auditor, no certified ISMS, no third-party attestation.

The mapping lives in a new SECURITY-CONTROLS.md. Each row cites its rule by file and line and its control by identifier and version. A row without a rule states a gap and holds no identifier.

scripts/check_security_controls.py gates it: resolve every citation, verify every identifier against a machine-readable register beside the mapping, fail on either miss, negative control included. DETAILS.md carries the coverage table, the gap list, and the argument for two frames rather than one.

References

1. Coverage table, gap list, and the two-frame argument: DETAILS.md
2. Unwritten until committed, and costed in DETAILS.md: the gate scripts/check_security_controls.py and both control-register CSVs

Related

RFD 1000 (conventions). RFD 1125 (AI-trope gate).

Details

The measurements and the retractions

Problem

A real-time avatar demo (Gemma Avatar architecture, 9k+ robots) needs sub-500ms first-packet latency with text + image + audio. MaskScore (self-supervised edit scoring) needs models that handle all modalities to construct training data.

EditScore is functionally complete in the NAND-gate sense: every generation task reduces to an edit. One reward covers every modality.

Decision

Qwen3-Omni for understanding, text, and speech. Wan-VACE for image generation and editing. Qwen3-Omni outputs text and audio only; it does not generate images.

thinker     Qwen3-Omni thinker         Apache 2.0   text + image + audio + video → text
talker      Qwen3-Omni talker          Apache 2.0   voice-cloning speech
image gen   Wan-VACE                   Apache 2.0   text/image → image
3D stage    Pixal3D → VoxHammer        Apache 2.0   image → mesh
scoring     MaskScore + EditScore      n/a           self-supervised reward

MaskScore constructs edit triples by masking, reconstructing, and scoring on decoded outputs. The reward model RL fine-tunes the generators via EditScore.

VRAM budget, sweep results, and the LLaDA retraction are in DETAILS.md. The eight MaskScore dataset stubs are in MASKSCORE.md.

Related

RFD 1172, RFD 1166, RFD 1170.

Details

The measurements and the retractions

Problem

Diffusion language models generate text by unmasking a full sequence over repeated denoising passes instead of decoding one token at a time. The strongest one whose weights we could hold is LLaDA2.1-flash: a 100B mixture of experts with 6.1B active parameters, Apache 2.0, ungated, with the best benchmark table any dLLM has published (MMLU-Pro 76.6, HumanEval+ 89.6). The question was whether it, or any dLLM, could run on the laptop’s NPU.

Decision

It cannot, and the XDNA blocklist row stands unchanged.

Three facts settle it, each sourced in DETAILS.md. The vendor’s LLM flows exclude this NPU generation: every supported path requires the newer 50 TOPS part, and the one prototype flow that reaches ours measured 2.3 tokens per second on the NPU against 7.8 on the CPU beside it. The inference pattern is heavier than autoregressive decoding: bidirectional attention over the full sequence, dozens of passes, no KV cache in the standard formulation. The one published NPU deployment of a dLLM anywhere runs an 8B model on a phone accelerator in the 45 TOPS class, and it rewrote the algorithm to get there. Ours peaks at 10.

If diffusion text generation earns a place in this workspace, it runs on the 3090 or a rented GPU. DiffusionGemma 26B-A4B and LLaDA2.1-mini, both Apache 2.0, are the sizes that fit a desk card.

References

1. Candidate table, sources, and the throughput numbers: DETAILS.md
2. The XDNA row in BLOCKLIST.md carries the standing toolchain argument.

Details

The measurements and the retractions

Problem

RFD 1166 ranked twelve models against each other and never says what any of them is for, so a reader cannot tell which stage is missing. Ranking stages of one pipeline against each other was the error.

Decision

One loop, four movements, and each runs both ways:

forward                     inverse

make    a description -> a body   fit      a picture -> the body
dress   a layer onto the body     recover  the body out from under
be it   a person supplies motion  friend   a model supplies it

Each inverse is under-determined, which is why every one has a checker and why Kimodo sits beside rf-detr rather than behind it.

The See-Through taxonomy is the vocabulary. VALID_BODY_PARTS_V3 names 23 parts, nine worn and the rest body, and that line is the try-on axis. A try-on is then masking treated as corruption: remove topwear and LaMa fills the hole the garment leaves.

The boundary is subtraction, not segmentation. The posed ANNY mesh gives the body outline through silhouette.py; MoGe depth gives the person’s outline and the camera both project through. What lies between is worn — no taxonomy-aware segmenter, so no labelled corpus. contour.py makes either a fixed ring. DETAILS.md places every candidate and names the empty stages.

Related

RFD 1166 has the measurements; 1168, 1169 and 1170 the mechanisms.

Details

The measurements and the retractions

Problem

victor/gemma-avatar runs the loop this workspace wants — speak, be understood, be answered by a lip-syncing face — and states no licence. Its integration code cannot be taken.

Decision

Study it, take nothing, rebuild from the components it names — cheap, because every component is separately licensed and clean; only the glue is unlicensed.

their stage        licence      ours

silero-VAD         MIT          keep
parakeet-tdt-1.1b  CC-BY-4.0    Qwen3-ASR-1.7B, Apache-2.0
gemma-4-31B, API   Apache-2.0   Qwen3-VL-8B, local
Qwen3-TTS 12Hz     Apache-2.0   already ours
TalkingHead        MIT          keep, or ANNY through Godot
three.js           MIT          Godot, with Mitsuba as oracle

Their TTS choice is ours, independently — the same Qwen3-TTS-12Hz-1.7B-CustomVoice RFD 1166 seated at 4 the same day.

Two stages swap for reasons already held here. Parakeet is licence-clean but has no compiled path, while RFD 1169 puts Qwen3-ASR’s encoder inside DEVICE_OPS. Gemma 4 is Apache-2.0 — RFD 1155 abandoned it on shape, not licence — but 31 B does not fit 8 GB and a hosted API cannot be a corpus source. The lip-sync is the part we lack, and DETAILS.md carries what TalkingHead does and what is unknown.

Related

RFD 1169 supplies the ear and the voice. RFD 1155 abandoned Gemma 4.

Details

The measurements and the retractions

Problem

RFD 1155 abandoned Gemma 4 and left one thing open: what Qwen3-VL does not carry is sound. An AuT encoder with an MLP projector, taking 128-bin log-mel into the decoder’s 4096 space, closes that — the pattern RFD 1157 established for vision.

Decision

The tower is a plausible device half. A Whisper-shaped encoder is Conv, MatMul, Softmax, LayerNormalization and gelu’s Erf, all inside DEVICE_OPS, and PROJECTOR_TYPE_QWEN3A’s conv2d front end shows the log-mel is a single-channel image — escaping the input-rank refusal that stopped Pixal3D.

The blocker is our own fork. clip_init_hailo hardcodes CLIP_MODALITY_VISION; the mtmd around it already carries CLIP_MODALITY_AUDIO and PROJECTOR_TYPE_QWEN3A.

No projector transfers, and the AuT source is old. Qwen3-Omni is 1280 wide over a 2048 decoder, has no standalone checkpoint, and predates Qwen3-VL-8B. Qwen3.5-Omni has no official release. Take Qwen3-ASR-1.7B instead — Apache-2.0, ungated, 128-bin, newer than our base, 2.04 GB at eight bits.

A voice is available; it is the acceleration that is not. Qwen3-TTS-12Hz-1.7B-CustomVoice is Apache-2.0 and clones. Its autoregressive stage is RFD 1126’s obstacle and runs on the host — at 12 Hz, 120 steps for ten seconds of speech. DETAILS.md has the widths, the dates and the fixed window.

Related

RFD 1155 left this open. RFD 1157 holds the vision tower.

Details

The measurements and the retractions

Problem

RFD 1166 dropped See-Through, so layer decomposition has no model. The obvious 3D replacement is gone too: P3-SAM / Hunyuan3D-Part is blocklisted on a territory-restricted licence.

Decision

Segment in 3D, from parts already held. RF-DETR-Seg has a SegmentationHead that convert_segmentation_to_gguf.py converts, so the segmenter is the one model at rung 3. VoxHammer’s extract_feature.py:96 projects per-view tensors onto voxel centres with F.grid_sample, over the sphere_hammersley_sequence views CLAUDE.md mandates. The lift is that call with a different payload: class logits where DINOv2 patch tokens go now.

3D is the right place: front hair against back hair is a depth relation, and a rendered view is where it is destroyed.

Masking is corruption. A layer is only a layer if it is whole, so emitting back hair means restoring what front hair hid.

LaMa fills the hole, and is the licence-clean half of See-Through — dreMaz/AnimeMangaInpainting, MIT over Apache-2.0, tuned for this domain. It will not compile: its Fourier convolutions call rfftn, and no Fourier operator is in DEVICE_OPS. CycleGAN is the opposite trade.

Unbuilt. DETAILS.md bounds the COCO classes and the resolution, supplies the corpus from corrupt-clean render pairs, and gives two tests costing no training.

Related

RFD 1166 drops See-Through. RFD 1167 places rf-detr at rung 3.

Details

The measurements and the retractions

Problem

RFD 1166 ranks what is worth doing and not what has been done. The two are read as one: a model near the top looks advanced when it may never have been exported, and one near the bottom may be further along than anything above it.

A rank is a judgment and a rung is a fact. One table for both lets an opinion about value borrow the authority of a measurement.

Decision

Six rungs, each a thing that either happened or did not:

0  assessed    blocklist clear, checkout present
1  exports     reaches ONNX at a fixed shape
2  operators   the operator set is known and compared
3  translates  the Dataflow Compiler accepts the graph
4  quantises   optimize completes and writes a HAR
5  runs        a HEF executes on the device

A model sits on the highest rung it has reached, and the rung below a failure is where it sits: reaching 2 and failing 3 is rung 2.

DETAILS.md carries one table per rung. Most of the field is on rung 0, which is the finding rather than an embarrassment: eleven of twelve candidates have never been exported, so the ranking beside them was built from reading rather than running. RFD 1129’s skill gives the procedure for climbing and its order is this order.

Related

RFD 1166 ranks the same models. RFD 1129 asks whether operators compile. RFD 1130 measures the device.

Details

The measurements and the retractions

Problem

Eight RFDs cite a score out of 25 and no document says what the 25 measures, so a reader cannot reproduce it or tell which scores rest on measurement. It was also applied before it was written.

Decision

Eight dimensions, each scored 0 to 100:

fit        headroom at a workable precision
shape      is the graph fixed-shape
reference  does a working precedent exist
clear      is anything else blocking it
value      what accelerating it buys
adapt      can this desk train, tune or LoRA it
ask        can we get an answer out of it
wanted     does anyone want the thing it does

adapt and ask are duals. check_rfd1166_rank.py recomputes the STAR order with starvote.

ABANDONED 2026-08-29, and RFD 1171 replaces it. The ranking asked which candidate is most worth accelerating, and that was the wrong question: these are stages of one loop, not competitors for one device, and a stage does not outrank the stage it feeds. Qwen3-ASR entering at seat 2 made it plain.

DETAILS.md keeps the table and the measurements that RFD 1171 cites.

Related

RFD 1154 to 1162 hold the candidates; RFD 1167 says where each is.

Details

The measurements and the retractions

Problem

Two walls stopped this compile, and they are different walls.

The first was system memory. Statistics Collector took SIGKILL at Docker’s 30.26 GiB; raising .wslconfig to 48 GB cleared it and the stage completed in 14:58. The run peaked at 39.87 GiB, 85 per cent of the new ceiling and well above the old, so the lift was load-bearing.

The second is video memory, and no amount of system RAM answers it:

AccelerasResourceError: GPU memory has been exhausted. Please
try Quantization-Aware Fine-Tuning with lower batch size.

QAFT ran about thirty minutes of epoch 1 of 4 on 1024 frames and exhausted 24 GiB. RFD 1140 says match the card to the wall you hit; clearing the RAM ceiling only bought the right to meet this one.

Decision

RETRACTED 2026-08-29: this said batch size was the lever, and it is not. A probe at batch_size=1, epochs=1 on 64 frames raised the same AccelerasResourceError after 44 minutes.

The requirement is measured: QAFT needs 32.5 GiB, on an A40. The desk 3090 holds 24, so the shortfall is 8.5 GiB and no batch size closes it. Separately, a16_w16 is refused by this part outright – twelve precision_change layers the target will not take – so a8_w8 is the precision ceiling. DETAILS.md carries both.

Related

RFD 1140 rents the card. RFD 1163 divides the work. RFD 1164 says what the calibration set becomes. RFD 1167 places the rung.

Details

The measurements and the retractions