# Visual Contract Review — §17–§19 (rev 0.7)

**Reviewer:** Abacus AI Agent (independent adversarial pass, pre–slice 4d)
**Scope:** §17 (scene/primitives/transforms/appearance), §18 (components/procedural systems/behaviors/fields), §19 (automation/lifecycle/camera/effects/ceilings), plus the cross-referenced shared/audio sections (§1.3, §2, §4, §6, §7, §8, §9, §10, §14.4–14.7, §15.11/15.14/15.15, §16.1–16.7) used as consistency anchors.
**Method:** from-scratch read; no other file in `reviews/` was opened before or during this pass.
**Line numbers** refer to `docs/XZBT_0-1_Format_Specification.md` rev 0.7.

Result: **33 defects** (4 high, 13 medium, 16 low). All locked decisions were checked against the text; every one is present as claimed **except** "coherent noise is fully specified," which does not hold (H3).

---

## High severity

### H1. Perspective factor: §17.6 and §19.3 give two different, incompatible compositions

- **Location:** §17.6 "Perspective scaling" (line 1630) vs §19.3 (line 2507).
- **What:** §17.6 says "an object's transform is **post-multiplied** by the uniform factor `focalLength / (focalLength + z)` about the camera's projection center." §19.3 says each object "additionally receives the uniform factor … about the projection center, exactly as 17.6 states, **applied after `V`**." Post-multiplying the object's local matrix by a scale applies the scale in *local* space (about the object's origin, also scaling its own translation); scaling after `V` about the projection center is a *display-space* operation. These produce different pixels whenever the object is off-center, and the projection center is not even expressible in local space, so the 17.6 phrasing is not realizable as written. "Exactly as 17.6 states" is false. A knock-on gap: §19.3 (line 2511) pins stroke/blur/glow/shadow scaling for camera *zoom* only; whether the perspective factor also scales stroke width is undecidable while the composition point is ambiguous.
- **Why it matters for 4d:** the camera/depth path is core renderer work, and acceptance traces 17.16 #6 and 19.7 #14 both assert "the documented factor" — but the document specifies two. Whichever an implementer picks, a second conforming renderer can pick the other and both cite the spec.

### H2. `loop.count: "infinite"` is asserted legal and illegal in the same sentence

- **Location:** §19.1 "Loop modes" (line 2398).
- **What:** "…it is legal **only on a persistent scope**, **and** an `infinite` loop on a spawned system with a finite `lifetime` (19.2) **is legal** and simply ends with the system." The second clause flatly contradicts the first. Remaining holes: an `infinite` loop on a spawned system *without* `lifetime` (which may run indefinitely until removed) is unaddressed, and no diagnostic is named for the illegal case (`ERR_SCHEMA_VALIDATION`? `ERR_VISUAL_LIMIT_EXCEEDED`?).
- **Why it matters for 4d:** automation-track validation ships with the document model the renderer core builds; this rule cannot be implemented, and 19.7 trace 2 cannot be extended to spawned scopes, until the sentence is rewritten with a single rule and a named error.

### H3. Coherent noise is *not* fully specified, despite the locked decision and §18.7's own claim

- **Location:** §18.7 "Coherent noise is normative" (lines 2246–2254); §18.6 `wander`/`twinkle`/`point-wander` (lines 2185, 2189, 2187); 18.10 trace 15–16 (line 2332–2333).
- **What:** The text fixes "3D gradient noise, twelve edge-midpoint gradients, 256-entry permutation shuffled from the field's own stream, quintic fade" — but omits everything that makes two implementations agree: (a) how the permutation table is **indexed** from a lattice coordinate (the hash composition, e.g. `perm[x+perm[y+perm[z]]]`, and any wrapping/doubling); (b) how the hash **selects** one of 12 gradients (256 is not divisible by 12 — `mod 12` biases four gradients); (c) the exact Fisher-Yates loop — "consuming one sample per entry" is 256 draws, which matches neither the standard backward (n−1 draws) nor forward variants, so the *table itself* differs across implementations; (d) the octave normalization — "normalized so the result stays within `[-1, 1]`" states a bound, not a formula (divide by `Σp^k`? by the analytic max?); (e) the derivative method for `curl`/`gradient` modes (analytic gradient of the faded noise vs finite differences, and at what epsilon) — trace 16 requires curl to be divergence-free "to within the documented tolerance," a tolerance documented nowhere. Separately, §18.6's `wander` and `twinkle` are driven by "a value-noise sample (18.7)" — but §18.7 defines **gradient** noise, a different function, and the sampling coordinates for behavior noise (a function of what? `t*rate` alone?) are never fixed.
- **Why it matters for 4d:** reproducibility of identical decisions from identical seeds is the format's core promise (§9.3), and every field-, wander-, twinkle-, point-wander-, and noise-displace-driven fixture depends on this function being byte-exact. Renderer core decides where noise evaluation lives and how the `visual` stream is plumbed; if the function is not pinned before fixtures are written, 18.10 traces 15–16 are unwriteable.

### H4. §18.2's "every ValueSpec resolves once per particle" contradicts itself and §19.1's automation registry

- **Location:** §18.2 "Per-particle resolution boundary" (line 2027) vs the field table it covers (lines 2002–2025) and §19.1 registry (line 2408); parallel text §18.4 (line 2124).
- **What:** "Every ValueSpec above resolves **once per particle, at that particle's creation**." The table above includes `count` and `rate` — which *drive* particle creation and cannot resolve per particle (circular), and `position`, `acceleration`, `drag` — which §19.1 then lists as **system-scope automatable** channels (`rate`, `position.x/y`, `acceleration.x/y/z`, `drag`). Automation is time-varying by definition; per-particle creation-time resolution is fixed by definition. The spec never says which wins: does automating `drag` rewrite live particles' drag each tick, or only re-base future creations? §18.4 carves `rate` and `burst[].at` out as emitter-level ("properties of the emitter, not of an item") but leaves `position`/`acceleration`/`drag` per item, so emitters inherit the same ambiguity. (The registry's omission of `velocity` while including `acceleration` suggests an intent — live channels vs creation channels — that is never stated.)
- **Why it matters for 4d:** who owns these values — the system or the item — determines the runtime data layout and the per-tick evaluation order the renderer core is built around. Guessing wrong here is a structural rework in 4e/4f, not a patch.

---

## Medium severity

### M1. The 128-track/2048-point automation limit is runtime-dependent but classified as an import-time authoring bound

- **Location:** §19.1 "Limits" (line 2431); §19.5 two-kinds table (line 2563) and aggregate row (line 2582).
- **What:** The limit counts "across both scopes and **across every live spawned instance**" — a quantity that only exists at runtime — yet §19.5 lists it as "Authoring bound (19.1), not a shed," and authoring bounds are defined as "checked at import; the exhibit is rejected." Nothing says what happens when a `spawn` action at runtime pushes the live count past the bound: spawn refused (with `WARN_VISUAL_CEILING`? as 19.2's instance ceiling does)? Action failure with `ERR_VISUAL_LIMIT_EXCEEDED`? Exhibit failure? It is also unspecified whether a spawned *template's* tracks count once at import.
- **Why for 4d:** the import/runtime staging split is exactly what the validator half of renderer core encodes; 19.7 trace 6 asserts the numeric boundary but cannot be implemented without the runtime rule.

### M2. §17.12 types `fill`/`stroke` as literal-only, but §18.1's normative example uses a `ref` ValueSpec as `fill`

- **Location:** §17.12 table (lines 1766–1767) vs §18.1 example (line 1945: `"fill": { "ref": "inputs.tint" }`).
- **What:** `fill` is "`color`, paint object, or `null`" — a `{"ref": …}` is none of those. §17.14 licenses ValueSpec "exactly where each field table says so," and 17.12's table does not say so. The same question is unanswered for gradient stop colors (can a stop be `{"ref": "inputs.tint"}`?). As written, the spec's first visual-component example is invalid, and with it the whole `color`-typed component-parameter mechanism (18.1, line 1964) has no legal consumer.
- **Why for 4d:** paint parsing and style resolution are 4d core; the ValueSpec-vs-literal decision determines the shape of the entire style pipeline.

### M3. §19.1's registry automates a repeater `step` block that does not exist

- **Location:** §19.1 registry (line 2408) vs §18.5 field table (lines 2146–2155).
- **What:** "for `repeater`, the numeric fields of its `step` block." §18.5 defines `repeat`, `count`, `distribution`, `position`, `inputs`, `behaviors`, `fields`, `links` — no `step`. The row is dead text (or a remnant of a dropped design), and with it the only repeater automation surface.
- **Why for 4d:** target validation must assign `ERR_UNSUPPORTED_TARGET` vs `ERR_INVALID_REFERENCE` per the registry; a registry entry whose referent doesn't exist can't be classified, and 19.7 trace 4's expectations wobble with it.

### M4. §19.5's "centralized" ceiling table omits enforced ceilings and mis-cites one

- **Location:** §19.5 restated table (lines 2587–2614) vs §17.13 (line 1829: path commands 512), §18.2/§18.4 (lines 2008, 2107: burst entries 16), §18.3 (line 2076: grid columns/rows 256), §15.14 (line 1148: oscillator partials 64), §15.10 (line 1042: resonator modes 16).
- **What:** The table claims "every ceiling the engine enforces appears here," but path commands (512), burst entries (16), and grid dimensions (256) are absent, as are custom oscillator partials (64) from the audio side. The "Resonator modes" row gives the value as "Per section 14" with "Fixed in: 15.10" — the value 16 lives in 15.10; "section 14" is a stale citation.
- **Why for 4d:** 4d implements `path` rendering; an implementer coding limits from the central table — the table's stated purpose — will ship without the 512-command bound.

### M5. The offscreen-buffer ceiling's shed rule doesn't cover layer buffers, and its warning has no rate limit

- **Location:** §17.5 (line 1620) vs §19.5 aggregate table (line 2578).
- **What:** Layers with non-default `opacity`/`blend` "require an offscreen compositing buffer" counted against the 19.5 budget of 16 — but the shed rule speaks only of "the excess **objects**" drawn "without their non-default `blend`, `mask`, `blur`, `glow`, or `filters`, farthest-`z` first." There is no rule for a *layer* whose buffer is shed (draw at opacity 1? drop the blend? in what order relative to object sheds?). The `WARN_VISUAL_APPROXIMATION` this shed raises also has no stated rate (per object? per frame? once ever?) — unlike every other diagnostic in the table, and unlike the conic-fallback and post-effect uses of the same code, which are explicitly "once per instance."
- **Why for 4d:** the compositor's buffer allocator and degradation path are renderer core.

### M6. Emitted items and repeater copies have no draw-order rule in their layer

- **Location:** §18.2 "Drawing" (line 2059) — particles only; §18.4 and §18.5 have no drawing paragraph; §18.8 (line 2294) references "the system's own depth position (18.2)."
- **What:** Particles get an explicit rule: drawn as one unit, system's sort key is its lowest-`z` particle, internal order `z` descending then creation ordinal. Nothing says whether an emitter's items or a repeater's copies draw as one unit (and at what `z`) or interleave per-item with `graphic` objects in the layer's depth sort. §18.8's link drawing rule cross-references a per-system depth position that only §18.2 defines, and only for particles — so links on a repeater (explicitly legal) have an undefined depth position.
- **Why for 4d:** the layer sort and scene-graph structure are built in 4d; the unit-vs-interleave decision is architectural, not a detail.

### M7. §18.3 distribution math has holes that break its own "byte-identical" guarantee

- **Location:** §18.3 (lines 2067–2083); relatedly §18.6 `follow-path` (line 2186).
- **What:** (a) `depth`'s `linear` and `exponential` curves have no formulas — "biasing items toward `near`" admits many functions (`u²`, `1−√(1−u)`, any exponential rate). (b) `ring`/`path` `even` modes have no placement formula at all ("distributes angle evenly by index" — `i/n` or `i/(n−1)`? measured from `startAngle`?); `line` `even` uses `i/(count−1)`, which divides by zero at `n = 1` — NaN, which §2 forbids outright (the `count = 1` guard exists for `repeat.fraction` in §18.5 but was not carried here). (c) The normative sample-consumption order covers `x,y,z` and polar forms but not select-then-place distributions: `rectangle` `perimeter` needs an edge-selection sample and an along-edge sample, in an unstated order. (d) `path` `random` is "uniform by arc length," and `follow-path` moves at scene units/second — both require an arc-length parameterization (flattening tolerance? adaptive quadrature?) that is never fixed, contradicting §18.3's stated goal that placements be "byte-identical across renderers."
- **Why for 4d:** placement resolves at instantiation — a renderer-core code path — and 18.10 trace 10 demands documented positions from a fixed seed; without formulas there is nothing to document.

### M8. `fit`'s default collides with the `viewport` validation rule

- **Location:** §17.4 (lines 1591, 1600).
- **What:** `fit` defaults to `contain`; for `viewport`, "`fit` is ignored and a `fit` other than `stretch` is `ERR_SCHEMA_VALIDATION`." Read literally, an absent `fit` resolves to `contain` — "a `fit` other than `stretch`" — so every viewport-space exhibit that doesn't explicitly write `fit: "stretch"` is invalid. If "ignored" is meant to cover absence, the default never engages and the sentence contradicts itself. Either way it needs an "explicitly authored" qualifier.
- **Why for 4d:** scene/fit resolution is the subject of 17.16 trace 1 — the first acceptance trace of the slice.

### M9. Post-effect `blur`/`bloom` radii are in undefined units

- **Location:** §19.4 table (lines 2534, 2537).
- **What:** `blur.radius` is "Scene units, scaled by camera `zoom`"; `bloom.radius` is "Scene units" without even the zoom note. But post-effects run on the composited *frame* (line 2515) — display space, after `fit` resolution, and after per-object perspective factors that make scene scale non-uniform across the frame. The scene→display conversion for the post chain (fit scale? coordinate space? which layer's parallax?) is never defined. `scanlines` and `grain` in the same table use device pixels, so the scene-unit choice is conspicuous.
- **Why for 4d:** pass sizing and backing-store math for blur/bloom are set up by the renderer core; two renderers will pick different conversions and both will be "conforming."

### M10. §17.16 trace 14 contradicts §8.1/§19.1 (and §19.7 trace 7) as of rev 0.7

- **Location:** §17.16 trace 14 (line 1910) vs §8.1 rows (lines 329–332), §19.1 (lines 2416–2427), §19.7 trace 7 (line 2645).
- **What:** Trace 14: "A binding, `set`, or `override` addressing **any visual property** is `ERR_UNSUPPORTED_TARGET`." That was true when 4a landed; it is false now — `visuals.camera.zoom` et al. are legal binding targets, and 19.7 trace 7 requires them to *work*. §19.1 (line 2425) carefully preserves §17.14 and 18.10 trace 19 ("survive this slice unchanged") but overlooks trace 14's blanket wording, which was not scoped to per-object properties.
- **Why for 4d:** 17.16 *is* the 4d acceptance suite; as written it fails the document model 4d is required to build.

### M11. §18.6 behavior field contracts are incomplete against §12's template, and `oscillate`'s waveforms are undefined

- **Location:** §18.6 table (lines 2179–2197); §12 (line 542).
- **What:** §12 requires every construct to record required/optional fields, ranges, and defaults. The behavior table lists field names only: `oscillate` has no stated default for `center` (0? the authored base?), no requiredness for `amplitude`/`frequency`, no `phase` default; `pulse` never defines how `duty` splits between rise and fall, nor its `curve` default; `wander`, `twinkle`, `noise-displace` give no ranges or defaults (`noise-displace`'s `scale`/`speed`/`octaves`/`persistence` presumably borrow 18.7's — unstated); `rotate.speed`, `orbit.radius`/`speed`/`phase`, `follow-path.offset`, `attract`/`repel.strength`, `morph.curve`, `drift.damping` likewise. And the waveform functions themselves — `triangle`, `square`, `sawtooth` polarity, duty, and phase origin in `w(frequency·t + phase/360)` — are never defined, so even with defaults the behavior is not reproducible across renderers.
- **Why for 4d:** the document parser and object model ship behavior schemas with renderer core; every missing default is a guess two implementers will make differently.

### M12. `vortex` (and `orbit`) direction is ambiguous in the y-down scene space

- **Location:** §18.7 (line 2239), §18.6 `orbit` (line 2184) vs §17.2 (line 1543) and §17.4 (lines 1599–1601).
- **What:** All three coordinate spaces put +y *downward*; §17.2's positive angles turn toward +y, i.e. clockwise *on screen*. `vortex` is "perpendicular to the outward ray, **counter-clockwise** for positive `strength`" without saying whether that is display-visual counter-clockwise or the 17.2 convention — in a y-down space those are opposite vectors. `orbit` never states the direction of positive `speed` at all.
- **Why for 4d:** sign conventions get baked into the field evaluator and behavior math; a flipped sign passes every automated trace that isn't written and fails the visual acceptance that is.

### M13. `links` block: dangling `style` default, undefined fade case, and an over-broad static check

- **Location:** §18.8 links table (lines 2281–2296).
- **What:** (a) `style` defaults to "the system's style" — no system type has a `style` field (§17.7, §18.2, §18.4, §18.5 define none); the default has no referent. (b) `fadeWithDistance` fades "from full at distance `0` to zero at `maxDistance`," but for rule `nearest` `maxDistance` is optional — fading with it absent is undefined. (c) The 256-population validation uses `particles.capacity` as the static proxy, which rejects systems whose live count can never approach it (e.g. `capacity: 400`, `count: 10`, no `rate`/`burst` → rejected at import); the false positive is unacknowledged. And when `repeater.count` is a non-literal ValueSpec, the "statically known" precondition silently fails and the instantiation-time diagnostic is unstated.
- **Why for 4d:** links validation and default-style resolution land in the renderer core's system model.

---

## Low severity

- **L1 — §19.2 vs §10.1 (lines 2444, 2476, 483):** `cancelWithScenario` semantics are hollow. With `ownership: "persistent"` the instance transfers to the performance root, so scenario cleanup would not touch it regardless; meaning is given only to `false`. Either the default `true` lets a scenario cancel a root-owned instance (making the transfer hollow) or the flag is redundant. 19.7 trace 11 tests a distinction the text never defines. *(4d relevance: lifecycle flags ship in the system object model.)*
- **L2 — §19.5 (lines 2564, 2583) and §19.2 (line 2480):** `WARN_VISUAL_CEILING` has two unreconciled triggers — "once per ceiling per second" on any shed, and a separate "120 consecutive ticks" degradation report using the same code; and 19.2's spawn refusal "raises once" without saying whether the 1/sec rate limit applies. *(Renderer core emits these.)*
- **L3 — §17.16 trace 9 (line 1905):** "`9` layer nesting levels" — layers don't nest; presumably group nesting (already trace 4) or the 16-layer count was meant. *(Corrupts the 4d acceptance suite.)*
- **L4 — §19.7 trace 9 (line 2647) vs §19.2:** the trace requires "a second `remove` on a `DISPOSED` instance is a no-op"; §19.2 never states this (§16.3 states it for audio). A trace without normative basis.
- **L5 — §18.2/§18.4/§18.5 `count` fields (lines 2006, 2107, 2149):** integer-typed ValueSpecs with no rounding rule when they resolve non-integer (contrast §8.1's integer-target rounding and §13.2's half-away-from-zero); `burst[].count`'s resolution *timing* (emitter instantiation vs burst tick) is also unstated — §18.4 (line 2124) carves out `burst[].at` only.
- **L6 — §17.9 (line 1704) vs §17.6/§19.3:** per-point `z` "offsets the object's z for depth purposes" but the object "is sorted and drawn as one unit" — with points at differing `z`, which `z` drives the single perspective factor and fog fraction? `z_parent + z_local` (17.11) covers groups, not point offsets. A spline spanning z=0..100 needs one number; the spec doesn't say which.
- **L7 — §18.3 `path` distribution (line 2075):** the sibling-key form ("the key of a sibling `path`/`spline`/`polyline`/`polygon` object in the same container") has no possible referent — distributions live on systems, and systems have no sibling object containers (`render`/`emit`/`repeat` are singular). Dead syntax, or a missing referent such as a graphic system's `content`.
- **L8 — §18.6 `morph` (lines 2197, 2214):** the operand set is undefined for point-less primitives — compatibility keys on point count, which is meaningless for `rectangle`/`ellipse`/`arc`/`ring`/`text` and for `path` (commands, not points); whether morph there is `ERR_INVALID_BEHAVIOR_TARGET` or interpolates `size`/`radius` is unstated. "Reads the target's resolved points" is also ambiguous when the target's points are moving under `point-wander`.
- **L9 — §18.1 (lines 1966, 1976) vs §15.11 (line 1059):** visual component diagnostics diverge from the audio contract they claim to mirror: undeclared `inputs` key → `ERR_INVALID_REFERENCE` (visual) vs `ERR_UNKNOWN_FIELD` (audio); missing required parameter → `ERR_INVALID_REFERENCE` *at instantiation* (visual) vs import-time `ERR_SCHEMA_VALIDATION` (audio); supplied-value-out-of-range is specified for audio (`ERR_OUT_OF_BOUNDS`) and unstated for visual. The instantiation staging also means a persistent system passes import and fails at activation — a new failure mode the strict-validation posture elsewhere avoids.
- **L10 — §18.4/§18.5 (lines 2117, 2152) vs §18.1 (line 1974):** dual `inputs` paths — the `component` object carries its own `inputs`, and the emitter/repeater carries a separate system-level `inputs` "only when `emit`/`repeat` is a `component` object," both sampled per item/copy, with no merge or conflict rule when both are present.
- **L11 — §19.2 (line 2450) vs §1.3 (line 58):** "the `instances.*` runtime namespace section 1.3 reserves" — §1.3's prefix list omits `instances.*`; only §8.1/§8.3 mention it. Dangling cross-reference; the reservation 19.2 relies on doesn't exist where it says it does.
- **L12 — §19.2 (line 2472):** release "ramps the instance's composited opacity linearly from `1` to `0`" — systems have no `opacity` property (§17.7), so where the release factor multiplies the compositing stack is undefined, and "from 1" reads as absolute where audio's 16.4 says "from its current value"; the literal reading pops a 0.5-opacity instance to full before fading.
- **L13 — §19.4 (line 2532) vs §17.12 (line 1799):** `color-adjust` claims "the 17.12 filter semantics" but renames the parameters (`saturation` vs `saturate`, `hueRotate` vs `hue-rotate`) — an unforced inconsistency for implementers mapping one onto the other. §19.4 also never states the resolution boundary for effect parameters (presumably activation; §17.14 covers object fields).
- **L14 — §8.1 (line 329) vs §19.3 (line 2493):** the camera row's safety clamp is "the per-field range of 19.3," but `focalLength`'s range is the open interval "above `0`" — automation or binding driving it ≤ 0 has no finite bound to clamp *to*.
- **L15 — §19.2 (line 2439) vs §17.7 (line 1654):** the `lifecycle` row claims it is "Added to the 17.7 system field table by this section," but 17.7 already contains it in rev 0.7. Stale double-definition; harmless, but it signals the two tables can drift.
- **L16 — §19.5 (lines 2557, 2620) and §17.7–17.9:** no ceiling bounds declared systems per exhibit or authored objects per system, while governance "never sheds an authored persistent object or a declared system." A document can author unbounded per-frame draw load with no runtime recourse (audio bounds nodes per sound and voices; visuals bounds neither objects per system nor systems per exhibit). Deliberate or not, the gap is unacknowledged in a table that claims completeness.

---

## Checked and found sound

Verified directly against the text (presence, internal consistency, and cross-references), no defect found:

- **All locked §17 decisions present and consistent:** degrees/0-+x/positive-toward-+y (17.2, applied to arc/ring/skew/conic); z sign, greater-z-first sort with document-key-order ties and stability (17.6); perspective factor formula and `z <= -focalLength` culling with no diagnostic (17.6, 19.3, traces 17.16#6 / 19.7#14 mutually consistent); orthographic z behavior; keyed objects with no `id` field (17.8); transform order `T(position+translate) × T(origin) × R × K × S × T(−origin)` and `M_parent × M_local`, `z_parent + z_local` (17.11); once-at-instantiation ValueSpec resolution and no procedural stream in rendering (17.14, 9.3); `layer` system-only with `ERR_UNKNOWN_FIELD` on objects (17.10); fog formula exact, per object, no diagnostic (17.6); conic fallback the sole appearance fallback, warn once per paint instance (17.12); three-font `font` enum (17.13); live readouts deliberately deferred (17.13).
- **All locked §18 decisions present:** fourteen primitives + `component` as fifteenth object type (17.9, 18.1); component parameter types number/boolean/string/color vs audio's number-only (18.1, 15.15); `inputs.*`/`repeat.*` construct scope with `ERR_INVALID_REFERENCE` and no §8.1 capability (18.1, 18.5); expansion path as the §9.3 stable key (18.1); the normative integrator `v ← (v + a·dt)·(1−drag)^dt; p ← p + v·dt` (18.2); life ramps interpolating once-resolved endpoints (18.2); fractional accumulator, cumulative `floor(rate·t)`, no reset on automated rate change (18.4); `ERR_UNBOUNDED_EMISSION` with `count`-alone legal (18.2/18.4); oldest-first eviction (18.2/18.4); `ERR_INVALID_DISTRIBUTION` for index-driven placement on continuous emission (18.3); normative sample order x,y,z / angle-before-radius (18.3, as far as it goes — see M7); noise parameters (3D, 12 gradients, 256-entry permutation, quintic fade) present in text (completeness defect H3 notwithstanding); `curl` default (18.7); ribbon as `trail.mode` (18.8); `links` as `ERR_UNKNOWN_FIELD` on emitters (18.8); morph compatibility rule (18.6).
- **All locked §19 decisions present:** exactly four system-level §8.1 rows, verified in the §8.1 table itself (lines 329–332) with `visuals.layers.<id>.visible` deliberately absent (19.1); two automation scopes with spawn-relative time origin and cross-scope `ERR_INVALID_REFERENCE` (19.1); 16.1 track shape plus `loop`, ping-pong count = full round trip (19.1); automatable registry broader than the §8.1 rows (19.1); behavior/track `ERR_AUTOMATION_CONFLICT` with pipeline-then-behaviors array-order composition (19.1); explicit `lifecycle` enum and `ERR_UNKNOWN_FIELD` on persistent systems (19.2, 17.7); spawn stream key `<system-id>#<spawn-ordinal>` (19.2); five states plus `FAILED`, no `SCHEDULED`, with a stated reason (19.2); `release` default `0ms` with one `RELEASING` tick (19.2); spawn-at-ceiling refusal, never eviction (19.2); normative camera matrix with parallax on translation only (19.3 — algebra spot-checked: reduces to `T(c)·S·R·T(−x,−y)` at p=1 and to one-fifth camera translation at p=0.2, matching trace 13); `projection` authored once (19.3); seven effects in normative array order, blur/bloom two passes and the rest one, 4-entry/8-pass arithmetic checks out (19.4); reduced-resolution and unavailable-effect warnings once per effect instance, never substituted (19.4); `grain` the sole reproducibility exemption, consuming no stream, with a correct justification against §9.3/§14.6 precedent (19.4); §19.5 centralization with provisional values and the Phase-6 gap for scenario/timeline ceilings explicitly named.
- **Diagnostic-code parity:** every code introduced by 17.15 (5), 18.9 (7), and 19.6 (2) is present in §7 with matching stage and cause; §7's `ERR_AUTOMATION_CONFLICT` text is already widened to the visual scope exactly as 19.6 claims; §19.6's "two, and no more" holds.
- **§19.5 restated values** match their subsystem sources for every row checked (16 layers, 8 group nesting, 512 vertices, 256 spline points, 16 stops, 4 filters, 8 component nesting, 4096/512 capacities, 1024 repeater count, 8 behaviors, 8/4 fields, 128 trail, 1024 maxLinks, 4 effects, 32 radius, 64 spawned, 64/16 voices, 64/256 audio automation, 1024 dispatch units, 16 event depth, 256 hook actions).
- **§16.1 → §19.1 track-shape reuse:** field-for-field match (target/mode/interpolation/points, duration-literal `at`, strictly-increasing rule, hold-first/hold-last), with `loop` the only addition, as claimed.
- **State machine:** the visual machine is the audio machine minus `SCHEDULED`, transitions otherwise parallel, and the reasoning (no second clock) is stated; cleanup deadline interplay with §10.2 (shorter of authored release and 5s, `WARN_CLEANUP_FORCED`) is consistent.
- **17.16 / 18.10 / 19.7 trace lists** are internally consistent with their sections everywhere except the flagged items (M10, L3, L4).