XZBT/reviews/.completed-artifacts/00-triage.md

# XZBT 0.1 Format Specification §§14–16 — review triage

Inputs: `01-grok-4.6.md`, `02-kimi-k3.md` (two outputs, same seven findings), `03-deepseek-v4-flash.md`.
GLM review not received.

Every claim below was checked against `docs/XZBT_0-1_Format_Specification.md` as it stands on disk
(1499 lines). Line numbers are that file's. Nothing in the spec was edited.

**Result: 13 distinct defects. All 21 reported findings are real** — none is a false positive —
but only **4 of 13 were found by all three reviewers**, and **5 of 13 were found by exactly one**.
Four proposed fixes are wrong or incomplete and are corrected below. Two defects that no reviewer
found are added.

---

## Scorecard

| | Grok 4.6 | Kimi K3 | DeepSeek v4 Flash |
| --- | :---: | :---: | :---: |
| Findings reported | 6 | 7 | 8 |
| Real | 6 | 7 | 8 |
| Overstated | 0 | 0 | 1 (D8) |
| Unique catches | 0 | 1 | 2 |
| Of the 13 confirmed | 6 | 7 | 8 |
| Proposed fix wrong/incomplete | 2 | 1 | 2 |

DeepSeek is the strongest pass: it is the only reviewer to unify the bus-gain defect (T1) instead of
splitting it, and the only one to catch the eviction defect (T3) and the modulated-delay bound (T8).
Kimi is the only one to catch the component-parameter defect (T2), which is the second-largest hole
in the section. Grok found nothing the other two missed, and split T1 into two half-findings whose
fixes contradict each other.

The overlap pattern is the argument for having run multiple models: **9 of 13 defects would have been
missed by any single reviewer.**

---

## Tier 1 — Unimplementable: a required acceptance trace cannot pass as written

### T1. Bus gain claims automation and modulation with no authoring surface; no target in the document exposes both automation and override; trace 16.11.8 cannot be implemented

*Reported by: DeepSeek F1 (complete). Grok #4 and #5 are the same defect split in two. Kimi missed it.*

**Confirmed.** Three independent statements are orphaned:

- 8.1 (line 314) gives `audio.buses.<id>.gain` Automation = Yes and Additive modulation = Yes.
  15.17 (line 1230) and 16.2 (line 1330) repeat both claims.
- Automation tracks live only in a graph object's `automation` array (14.3 line 606, 16.1 line 1265).
  Graph objects exist at exactly three places (lines 610–612); a bus is not one of them, and 15.17's
  bus table (line 1228) allows only `gain`, so an `automation` key on a bus is `ERR_UNKNOWN_FIELD`
  under the strict unknown-field policy.
- 16.1 line 1286 restricts `target` to `<node-key>.<property>` "resolved in the same graph", and
  line 1293 restricts it to the 15.13 registry. A bus is not a node and bus gain is not in that
  registry (lines 1073–1085). **No legal `target` can name a bus.**
- Modulation has the same problem: the only modulation syntax is a 15.12 route whose `to` is
  `<node-key>.<property>` in the same graph. **Nothing can modulate a bus gain either.**

Consequences:

1. 16.2's second consequence (line 1332, override masks automation, releases to the track's current
   value) describes a situation no legal document can produce. Node properties take automation
   (16.1) but are barred from override (14.4 line 631, `ERR_UNSUPPORTED_TARGET`); `parameters.<id>`
   and `state.<id>` take override but have Automation = No (8.1 lines 312–313); bus gain is the only
   row with both, and its automation is unauthorable. **No target exposes both stages.**
2. Required trace **16.11.8** (line 1485) is therefore unimplementable, and Phase 3c cannot be
   accepted as written.

**Fix — all three reviewers get this wrong.**

- Grok #4 proposes keeping override-vs-automation "only for `audio.buses.<id>.gain`". That fails for
  the same reason: bus gain has no automation surface.
- Grok #5 offers "add an `automation` array on the bus object, or strike automation from 16.2" and
  says not to leave both standing — correct as far as it goes, but it treats only the automation half
  and leaves the modulation half untouched.
- DeepSeek F1 correctly identifies both halves and both options, then says **"Option (a) is the
  smaller change."** *That is wrong.* Deleting additive modulation from bus gain would orphan
  **§8.5 required trace 6** (line 409, "A target has legal additive modulation → Modulation follows
  the winning override; safety clamp runs last"), because bus gain is the **only** row in the entire
  8.1 table with Additive modulation = Yes. Option (a) does not shrink the problem; it moves it into
  §8, a contract §11 line 513 already marks **Complete (Rev 0.3 / GC3)**.
  §8.3 line 370 ("Underlying binding and **automation** stages continue to evaluate while masked")
  is orphaned by the same gap.

**Recommended fix:** option (b). Give `audio.buses.<id>.gain` a real authoring surface for automation
and modulation, and make 16.1's target rule name it. Concretely: allow an `automation` array on the
bus object with `target` fixed to `gain`, and add a bus-addressed modulation form. This keeps 8.1,
8.3, 8.5, 15.17, 16.2 and traces 16.11.8 and 8.5-6 all consistent, and it is the only option that
does not reopen a completed contract.

**Out of scope but worth recording:** §8.5 trace 6 and §8.3's masking sentence are *already*
unimplementable today, independent of §§14–16. All three reviewers scoped to 14–16 and so could not
see this. It should be logged against §8.

---

### T2. Component exposed parameters are legal modulation and automation targets with no defined effect; trace 15.19.4 cannot be implemented

*Reported by: Kimi #1 only. Grok and DeepSeek both missed it.*

**Confirmed.** 15.13 line 1085 lists `component` / `<exposed-parameter-id>` in the modulatable
registry; 15.11 line 1045 repeats it; 16.1 line 1293 inherits it for automation. But the only path by
which a component's internals read a parameter is `{ "ref": "inputs.<id>" }` in a node field
(15.15 line 1166), and 14.4 line 629 resolves every node field **once** at instantiation, "constant
for that node instance's lifetime". 15.11 line 1039 resolves the supplied `values` once as well.

So a modulation sum or automation curve applied to an exposed parameter changes a value that nothing
ever reads again. Required trace **15.19.4** (line 1250, "an exposed parameter is a legal modulation
target") cannot be satisfied without inventing behavior.

**Fix — Kimi offers two options and correctly says the first is smaller. It is also the only correct
one, for a reason Kimi does not give.** Option two (make `{ "ref": "inputs.<id>" }` fields track the
parameter live, as an exception to 14.4) would let a modulation route reach *any* internal node field
through a parameter — including `reverb.decay`, `compressor.threshold`, `waveshaper.amount` and every
other property 15.13 line 1087 deliberately excludes ("Merely being numeric does not grant modulation
support"). That silently defeats the registry's whole purpose and breaks 15.11's encapsulation claim.

**Recommended fix:** delete the `component` row from the 15.13 registry (line 1085), delete the
modulation-target sentence in 15.11 (line 1045), and drop the exposed-parameter clause from trace
15.19.4.

---

### T3. 16.6 eviction step 3 frees no budget slot; the outcome is undefined and trace 16.11.10 is ambiguous

*Reported by: DeepSeek F2 only.*

**Confirmed.** Line 1406: "A voice counts against its ceiling from `CREATED` until `DISPOSED`."
The eviction policy (lines 1408–1413) "stops at the first candidate":

1. Dispose the oldest `FINISHED` instance — frees a slot.
2. Evict the oldest `RELEASING` instance by advancing its ramp to completion **and disposing it** —
   frees a slot.
3. For a one-shot request only: evict the oldest `ACTIVE` one-shot **by starting its release** —
   moves it `ACTIVE` → `RELEASING`, which still counts (line 1406, reinforced by line 1372 and trace
   16.11.11). **Frees nothing.**
4. Otherwise refuse.

With the ceiling full of `ACTIVE` one-shots, the policy stops at step 3 having freed no slot.
Admitting the new instance puts the count at 65; refusing it contradicts having stopped before step 4.
Neither is defined. Step 2's explicit "and disposing it" makes step 3's omission conspicuous rather
than incidental.

A weak defense exists — line 1399 calls the ceilings "approximate" — but line 1406's counting rule and
trace 16.11.11 both insist on exact accounting, so this does not resolve it.

**Fix — DeepSeek offers two options without ranking them; the first is correct.** Making step 3
behave like step 2 (complete the release immediately and dispose) contradicts line 1415, "Eviction
always releases; it never hard-stops an active voice" — an instant ramp on an audible voice *is* the
click that 16.4's single-code-path design exists to prevent. Step 2 does it only to voices already
decaying.

**Recommended fix:** state that an `ACTIVE` one-shot evicted under step 3 stops counting against the
ceiling at the moment of eviction, its release running outside the budget, so the new instance is
admitted and the ceiling is never exceeded. Add the matching exception to line 1406.

---

## Tier 2 — Real defects with clear fixes

### T4. `ERR_INVALID_RANGE_ORDER` is filed Semantic-only but the sample-hold rule needs instantiation-time values

*Reported by: all three (Grok #1, Kimi #2, DeepSeek F4). Unanimous, and unanimously right.*

**Confirmed.** 14.12 lines 815–816 make `min`/`max` full ValueSpecs in 14.4 scope — resolved once at
instantiation. Line 819 makes inverted resolution `ERR_INVALID_RANGE_ORDER`. §7 line 286 files that
code **Semantic** only, with a cause that says "after resolution" — the table concedes the problem in
its own text. 14.5 line 645 states semantic validation checks only values that resolve to a literal
and never opens an `AudioContext`; 9.3 line 445 puts the root seed at performance start, not import.

`{ "min": { "random": {...} }, "max": { "random": {...} } }` is import-legal and its order is
undecidable at the only stage the code is filed under.

**Fix:** all three converge and all three are right. Refile as `Semantic / Runtime` in §7 (mirroring
`ERR_OUT_OF_BOUNDS`, line 272, which is already dual-filed), and state in 14.12 that literal bounds
are rejected at import and resolved bounds at instantiation.

**Note:** §7's cause text mentions only `sample-hold` `min`/`max`. 16.1 line 1299 uses the same code
for automation `at` ordering, which *is* purely semantic because `at` is a literal by construction
(line 1297). The revised cause text must cover both without implying `at` is a runtime check.

---

### T5. Automation point `value` draws from a seeded stream with no documented sampling boundary or order

*Reported by: all three (Grok #3, Kimi #4, DeepSeek F6).*

**Confirmed.** 16.1 line 1289 makes each point `{ "at": <literal>, "value": ValueSpec<number> }`, and
line 1297 says "A track's *values* remain full ValueSpecs and may be random."

9.3 line 457 requires sampling at "the containing object's **documented** instantiation or invocation
boundary". No such documentation exists for `automation`:

- 14.4 line 629 documents the boundary for fields on **node objects**. A track is on the graph object.
- 15.12 line 1067 documents the order for route `depth` only.
- 14.12 line 825 is the only documented child key, and it is `sample-hold` only.

Two conforming implementations can consume the sound instance's stream in different orders and
diverge for the same seed, breaking 9.3's reproducibility promise and 14.6's restatement of it.
16.8 line 1445's guarantee that a partially elapsed continuous sound has "a procedural sequence
identical to an unbroken run" has no defined meaning for automated tracks.

**Fix:** all three propose the same one-sentence addition to 16.1 and all are adequate. Kimi's and
DeepSeek's are the more precise, because they fix the position of `automation` in the depth-first
order relative to `nodes` and `routes`, which Grok's leaves open:

> A track's point values are resolved once at the owning sound instance's instantiation boundary,
> sampled from that instance's stream in depth-first, property-document order, with `automation`
> taken after `nodes` and `routes`.

---

### T6. 15.14 calls the automation track/point limits runtime ceilings; 16.1 enforces them with a Semantic code

*Reported by: all three (Grok #6, Kimi #3, DeepSeek F5).*

**Confirmed.** Line 1132 groups automation tracks (`64`) and points (`256`) with the voice ceilings as
"runtime ceilings rather than document properties". Line 1318 makes exceeding either
`ERR_NODE_LIMIT_EXCEEDED`, filed **Semantic** at §7 line 285, and trace 16.11.6 (line 1483) sits in
the "Automated, and executable without an audio device" group. Track and point counts are decidable
after component expansion, which trace 15.19.7 confirms runs with no `AudioContext`. The voice
ceilings in the same sentence *are* correctly runtime.

**Fix — Grok's first option is wrong.** Grok #6 offers "move tracks/points into the authoring-limit
table with expanded nodes/routes". That table is headed "The authoring-time limits enforced in
**Phase 3b**" (line 1122), and automation is Phase 3c — 16.1 line 1261 states that the current
validator rejects any document declaring `automation` with `ERR_UNKNOWN_FIELD`. Putting them in the
Phase 3b table asserts enforcement that cannot exist. DeepSeek F5 offers the same wrong option
alongside the right one.

**Recommended fix (Kimi's):** delete "automation tracks (`64`), and automation points (`256`)" from
line 1132, leaving the voice ceilings. Optionally add a pointer that 16.1 enforces them semantically.
Separately, extend §7 line 285's cause parenthetical — it currently reads "(oscillator partials,
resonator modes, expanded nodes or routes per sound)" and omits the automation limits entirely.

---

### T7. 16.5's resonator contribution is undefined when every mode is omitted at instantiation

*Reported by: all three (Grok #2, Kimi #5, DeepSeek F7).*

**Confirmed.** 16.5 line 1387 gives a resonator "the longest `decay` among its **retained** modes".
15.10 line 1024 omits, at instantiation and with no diagnostic, any mode whose resolved frequency
exceeds `audioMaxFrequency`. Mode entries are omitted rather than clamped — 14.7 line 690 is explicit
that omission "is not the `WARN_AUDIO_RATE_CLAMP` case of 14.5, which applies to the node's own
`frequency`".

A single-mode resonator can therefore retain nothing, and "longest decay" becomes a maximum over an
empty set — feeding the one-shot ending bound, which 16.5 line 1376 requires to be computable "from
the resolved graph alone".

All three examples check out arithmetically. The cleanest is Grok's: a mode with absolute
`frequency: 20000` is import-legal against the device-independent ceiling `24000` (14.5 line 645) and
omitted on a 44.1 kHz device, where `audioMaxFrequency = min(24000, 19845) = 19845`.

**Fix:** DeepSeek's wording is the tightest — extend the row to "the longest `decay` among its
retained modes, **or zero when no mode is retained**".

**Downgrade:** Kimi #5 and DeepSeek F7 also raise the all-partials-omitted custom oscillator. That one
is materially weaker: an empty sum of partials is silence by construction, and `oscillator` is
**unbounded** in the 16.5 table regardless, so no bound is left undefined. Worth one clarifying
sentence in 14.7, not a Tier 2 defect.

---

### T8. The 16.5 ending bound is not an upper bound when `delay.time` is modulated

*Reported by: DeepSeek F3 only.*

**Confirmed.** 16.5 line 1376 defines "determinable" as a finite upper bound computed at instantiation
"from the resolved graph alone"; line 1385 computes the delay contribution from the **resolved**
`time`. But `delay.time` is modulatable (15.6 line 943; 15.13 line 1082) and 15.6 line 949 clamps a
modulated delay only to `[0ms, 10s]`. A legal `oneshot` may route an `lfo` or `sample-hold` at
`delay.time`; the actual feedback tail can then run far past the computed bound, and the runtime tears
the instance down while it is still ringing — contradicting 16.3 line 1360, which asserts that at a
determinable ending "the envelope has already returned to zero". Trace 16.11.9 passes only for graphs
whose bound-contributing properties are unmodulated.

`delay.feedback` is not modulatable (line 944), so `time` is the only exposure.

**Fix — DeepSeek's is incomplete, and T9 is why.** It proposes bounding the contribution by the
largest reachable `time`, "source outputs are bounded — `lfo` by its resolved amplitude, `sample-hold`
by its resolved `min`/`max`". That list omits `oscillator`, which 15.13 line 1089 also permits as a
modulation source and whose output magnitude the spec never states (see T9). Until T9 is fixed, the
proposed bound cannot be computed for an oscillator-modulated delay.

**Recommended fix:** fix T9 first, then bound the delay contribution over the property's reachable
range given its modulation routes. Alternatively — and this is the genuinely smaller change — exclude
a `oneshot` whose bound-contributing property is modulated from determinable-ending status, i.e.
`ERR_INDETERMINATE_ONESHOT`. Note that an *automated* `delay.time` is exactly boundable once T5 lands,
since `at` values are literals and point values resolve at instantiation; only modulation is open.

---

### T9. An `oscillator` used as a modulation source has no defined output magnitude

*Not reported by any reviewer.*

**Confirmed.** 15.13 line 1089 permits a modulation route's `from` to be "a control source
(`constant`, `lfo`, `sample-hold`) **or an `oscillator` used at audio rate** (PRD 41)". The summation
rule at line 1094 is `value = clamp(b + sum(s_i x d_i), ...)`, and line 1097 defines `s_i` only for
control sources: "**A control source's** output is its own value in its own units before scaling: an
`lfo` with `amplitude: 1` and `polarity: "bipolar"` contributes `[-d, +d]`."

An `oscillator` is not a control source (14.7 line 678; 15.14 rule 5 lists only `constant`, `lfo`,
`sample-hold`), and 14.7 gives it no amplitude field and no stated output range. For a `custom`
waveform with up to 64 partials at `gain: 1` each (line 685), the peak is not even conventionally
`[-1, 1]`. So `s_i` is undefined for the one source type the registry explicitly admits alongside the
control sources.

**Recommended fix:** state the oscillator's modulation output range in 15.13 — e.g. that a non-`custom`
oscillator contributes `[-d, +d]`, and a `custom` oscillator's output is normalized to peak `1` before
scaling by `depth`. Normalization is the safer choice; without it, `depth` means something different
for every harmonic table.

---

## Tier 3 — Editorial and low-severity

### T10. 16.2's "For a node property" pipeline includes an override stage that is always absent
*Grok #4's residue, after T1 absorbs the rest.* Line 1322 introduces the pipeline diagram at line 1325
with "For a node property:", and the diagram includes `winning override`. 14.4 line 631 makes an
override on a node field `ERR_UNSUPPORTED_TARGET`, and 16.2 line 1330 reaffirms it for binding but is
silent on override. Per 8.1 line 308 the stage is "absent, not an identity hook", so the diagram
should say so. **Fix:** annotate the diagram or add one clause to line 1330 noting that the override
stage is absent for node properties.

### T11. 14.9's "Value at `p = 1`" column contradicts the exponential row's own annotation
*DeepSeek F8 — real, but overstated.* Line 741 defines the envelope over `0 <= p < 1`; line 749 then
says "The envelope is exactly `0` for `p >= 1`", which makes the column's three zeros defensible for
the piecewise function. The genuine inconsistency is narrower and internal to one row: the
`exponential` row's Envelope cell is annotated "(`-60` dB at `p = 1`)", i.e. `0.001a`, while its
"Value at `p = 1`" cell says `0`. The same table then supports line 749's "Because `flat` and
`exponential` do not reach zero on their own" — which is false of a column reporting `0` for both.
No implementation ambiguity survives, because the terminal fade is normative either way.
**Fix:** relabel the column "Value as `p → 1⁻`" with `a`, `0`, `a x 0.001`, or delete it.

### T12. `sounds.<id>.name` and `tags` length caps name no diagnostic
*Kimi #6.* Lines 1197–1198 cap `name` at 128 characters and `tags` at 16 entries of 32 characters
with no code. Every other quantitative limit in §§14–16 names one, and no §7 entry covers string or
array lengths: `ERR_INVALID_ID` (line 268) is identifier-scoped, `ERR_OUT_OF_BOUNDS` (line 272) is
numeric min/max, and `ERR_SCHEMA_VALIDATION` (line 265) covers "malformed top-level shapes", which
`sounds.<id>` is not. **Fix:** name the code — `ERR_SCHEMA_VALIDATION` is the closest fit.

### T13. 16.2 line 1332 mis-cites §8.1
*Kimi #7.* The cited "parameter-masking rule of section 8.1" is not in 8.1 — its only masked-override
text (line 318) is about the UI override indicator. The behavior lives in **8.3** (line 370, masked
stages continue) and **8.4** (line 392, `currentLowerValue` recomputed every tick), with the trace at
8.5 line 406. **Fix:** cite 8.3/8.4.

### T14. An exposed component parameter with no `min`/`max` has no clamp range
*Not reported by any reviewer.* 15.15 line 1163 makes `min` and `max` optional on an exposed
parameter, but 15.13 line 1094 clamps a modulated property to "the property's declared range from its
node contract". For `{ "type": "number", "default": 220 }` there is no such range.
**Moot if T2's recommended fix lands** (deleting the `component` row removes the only path here); if
option two is chosen instead, this must be fixed alongside it.

---

## Findings checked and cleared

- **Class 1 (prose vs JSON in the same section):** all three reviewers reported none, and that holds.
  Every example and invalid case in 14.3–14.13, 15.2–15.17 and 16.1 matches its section's tables.
  One editorial note nobody raised: 14.3's canonical graph example (lines 589–600) is
  `oscillator → gain → output`, which is **not** a legal `oneshot` recipe — as a recipe it would be
  `ERR_INDETERMINATE_ONESHOT` (16.5 line 1393), and `mode` defaults to `oneshot` (line 1208). It is a
  bare graph-object example, so this is not a defect, but it is an unfortunate thing to copy.
- **Class 2 (field missing from its container's allowed-field table):** none, confirmed. The 15.13
  registry matches the "Modulatable" columns of 15.2–15.10 exactly; T1's bus-gain case is a missing
  *surface*, not a missing table row.
- **Diagnostic codes used but absent from §7:** none. All codes in §§14–16 appear in the §7 table, and
  the 15.18/16.10 tables match it. Mis-staging is T4 and T6; an incomplete cause list is folded into T6.
- **Cross-references:** all internal references resolve. The only defect is a *mis*-reference, T13.
- **Non-termination:** 16.5's longest-path terminates on the acyclic expanded graph (15.14 rules 7 and
  11). The delay formula `ceil(log(1/1000)/log(feedback))` is well-defined on the legal `(0, 0.95]`
  and correctly branches at `feedback > 0`.
- **Modulation-only `oscillator` and the one-shot bound:** an oscillator used purely as a modulation
  source has no audio-route path to `output`, and 16.5 line 1393 keys `ERR_INDETERMINATE_ONESHOT` to
  the *audible* path, so it does not make a `oneshot` indeterminate. Correct as written.
- **Deliberate-design exclusions** (node `id`, the 14.4 bindable surface, noise/impulse
  non-reproducibility, provisional master-protection values, absent `audio.master`, literal automation
  `at`, the GC4 stall bound, bus processing beyond gain) were respected by all three reviewers and are
  not defects.

---

## Recommended edit list

Ordered by severity. Items marked **(design)** need a decision before an edit can be written.

| # | Location | Change | Kind |
| --- | --- | --- | --- |
| T1 | 8.1, 15.17, 16.1, 16.2, 16.11.8 | Give bus gain an automation/modulation authoring surface and name it in 16.1's target rule | **(design)** |
| T2 | 15.13 line 1085, 15.11 line 1045, 15.19.4 | Delete the `component` modulation-target row and its two restatements | Delete |
| T3 | 16.6 lines 1406, 1412 | Evicted `ACTIVE` one-shot leaves the ceiling count immediately | One sentence |
| T4 | §7 line 286, 14.12 | Refile `ERR_INVALID_RANGE_ORDER` as `Semantic / Runtime`; split literal vs resolved | Restage |
| T5 | 16.1 | Document the automation point `value` sampling boundary and order | One sentence |
| T6 | 15.14 line 1132, §7 line 285 | Remove the two automation limits from the runtime-ceiling sentence; extend the cause list | Delete + edit |
| T7 | 16.5 line 1387 | "…or zero when no mode is retained" | Clause |
| T8 | 16.5 line 1385 | Bound the delay contribution over the reachable `time`, or exclude modulated bound-contributors | **(design)**, blocked on T9 |
| T9 | 15.13 line 1097 | State an `oscillator`'s modulation output magnitude and `custom` normalization | **(design)** |
| T10 | 16.2 lines 1325, 1330 | Note that the override stage is absent for node properties | Clause |
| T11 | 14.9 lines 743–747 | Relabel or delete the "Value at `p = 1`" column | Editorial |
| T12 | 15.16 lines 1197–1198 | Name the diagnostic for the `name`/`tags` caps | Editorial |
| T13 | 16.2 line 1332 | Cite 8.3/8.4 instead of 8.1 | Editorial |
| T14 | 15.15 line 1163 / 15.13 line 1094 | Only if T2 takes option two | Conditional |

**Outside §§14–16, log separately:** §8.5 trace 6 and §8.3's masked-automation sentence are already
unimplementable for want of a target with those stages (see T1).