/lab-team-review MERGED VERDICT (v2, post-fix) — D-A4 LogSensor + :sensorium organ

verdict: PASS evidence_class: C supersedes: none (first review pass for this item)

/lab-team-review MERGED VERDICT (v2, post-fix) — D-A4 LogSensor + :sensorium organ

• Base SHA: 85b0e8c (working tree, spec-correction pass applied on top, uncommitted)
• Mode: real (5 independent persona agents re-reviewing the corrected spec)
• Files reviewed:
  • production\mcp\SPEC_log_sensor_organ.md

Fix summary (what changed before this re-review)

Summary

Fixed [redacted: operator-path]\repos\UNI.MineCraft\production\mcp\SPEC_log_sensor_organ.md. Only this file was edited (verified via git diff --name-only — no .ex/.exs/.py/.cjs touched). Re-verified every citation against live repo state before rewriting.

What I found had shifted / was fabricated (re-verification, before fixing):

• Findings #1 and #3 citations were still accurate: lib\sp\runtime\log_sensor.ex (SP.Runtime.LogSensor install/log/drain) is live and wired at lib\sp\producer.ex:151,227; test\sp\runtime\log_sensor_test.exs still tests exactly that API.
• Finding #2 confirmed: SP.Brain.Genome.add_organ/2 exists nowhere except the old spec text (repo-wide grep). Real pattern found in lib\sp\brain\genome.ex: a @prereqs map entry (auto-populates organs/0) + a constructor like metabolism_primary/0 (lines 271-274) or homeostat_l1_phase0/0 (298-316) that appends to growth_plan and calls repair/1. Also confirmed no generic "rows into qo at a coupling knob" mechanism exists in card/1/Designer.compile today.
• Finding #4 confirmed: docs\specs\sensorium.md (A4 binocular-vision effort) is real and separate, and evidence\gates.ndjson line 10 carries a depth-red-b gate, verdict PENDING, pre-registered at docs/specs/sensorium.md:5-40.
• Two additional, previously unflagged defects found during re-verification and fixed in the same pass: SP.Runtime.Board.put/2 (lib\sp\runtime\board.ex:17-21) is a per-agent single-row overwrite table (put(username, row)), not a keyed multi-row ring — the old spec's Board.put(key: {:sensorium, source, i}, row) neither compiles nor behaves as claimed. And assert_frozen/1, used in the old byte-identity test, doesn't exist anywhere in the codebase.

Section-by-section changes:

• Title/Status/Purpose — renamed process to SP.Runtime.SpoolSensor, organ atom to :os_sensorium; added an explicit "untouched" note for the real SP.Runtime.LogSensor with its live citation lines; added a disambiguation paragraph pointing at docs/specs/sensorium.md.
• Signatures — rewrote the Genome section around the real growth_plan/@prereqs/repair pattern with a new os_sensorium_primary/1 constructor and a new sensorium_spools struct field (precedent: nursery); rewrote SpoolSensor to own its bounded ring in its own GenServer state with a recent/2 read API instead of the broken Board call.
• Byte-identity invariant — kept the section (per finding #5) but fixed the accessor (growth_plan, not the nonexistent .organs) and replaced the fabricated assert_frozen/1 with the real, existing golden-file mechanism in test/sp/brain/decider_byte_identity_test.exs; strengthened the claim (v1 is byte-identical unconditionally, since no @modalities entry is wired yet — stronger than "coupling 0.0").
• Row lifecycle — rewritten around the internal ring; step 6 now explicitly states v1 ships no consumer.
• New "Coupling (future work, not in v1)" section — explicitly re-scopes the qo-folding capability out of v1, names it as new work for a follow-up spec (D-A4b) with an exact 3-step signature (discretization function, new @modalities entry, sensorium_coupling field following the slow_context_coupling/novelty_gain precedent), and cites the closest real precedent (SP.Producer.Codec.error_rate/1) while being explicit it lives in a different system.
• Test coverage — test/sp/runtime/log_sensor_test.exs marked unchanged; new tests renamed to test/sp/runtime/spool_sensor_test.exs; added test/sp/brain/os_sensorium_organ_test.exs (naming convention matched to the real metabolism_organ_test.exs precedent) instead of duplicating byte-identity coverage.
• Cross-references — kept both real files (sensorium_envelope.schema.json, OS_SPOOL_POLICY.md), flagged the unrelated A4 gate.
• New "Corrections from prior draft" section — documents all 7 fixes (the 5 findings + 2 additional) with citations.

Could not fully resolve within given scope: production\docs\OS_SPOOL_POLICY.md:28 still says SP.Runtime.LogSensor (planned per D-A4) as the heartbeat-spool reader, which is now stale under this rename. I did not edit it because the task's file list authorized only SPEC_log_sensor_organ.md — I flagged it explicitly in the spec's cross-references instead of silently leaving it uncorrected or silently editing an unlisted file.

Persona verdicts (re-review)

math-breaker

• Verdict: SIGN_WITH_CHANGES
• Rationale: Independently re-verified every load-bearing citation in the corrected spec against the live repo (not the spec's prose) rather than trusting the "Corrections from prior draft" section at face value. All 5 original BLOCKED findings and the 2 additional defects the spec says it found during its own re-verification check out as genuinely fixed: (1) SP.Runtime.LogSensor (lib/sp/runtime/log_sensor.ex) confirmed live with install/0, log/2, drain/0, wired at lib/sp/producer.ex:151 (install, inside init/1) and :227 (drain, feeding build_telemetry's log: key which becomes the error_rate modality via lib/sp/producer/codec.ex:139 and lib/sp/producer/genome.ex:65) -- the new module is genuinely renamed to SP.Runtime.SpoolSensor and nothing in the spec touches log_sensor.ex; grep confirms zero occurrences of SpoolSensor/os_sensorium/sensorium_spools anywhere in live .ex files, so no collision exists. (2) Genome.add_organ/2 confirmed absent from the codebase; the replacement pattern (@prereqs entry at genome.ex:19-39, a growth_plan-append constructor, optional @modalities entry at 49-130 gating active_modalities/1 at 490-494 and card/1 at 438-488) is real and the cited exemplars metabolism_primary/0 (271-274) and homeostat_l1_phase0/0 (298-316) exist exactly as described; Designer.compile/1 (designer.ex:31-65) confirmed has no generic exteroceptive-coupling mechanism today, so scoping that out as new D-A4b work is honest, not a fabricated citation. (3) test/sp/runtime/log_sensor_test.exs confirmed exists, tests only install/log/drain, and is untouched; the new test path test/sp/runtime/spool_sensor_test.exs is genuinely distinct. (4) docs/specs/sensorium.md confirmed exists (binocular Eye/depth work) and evidence/gates.ndjson's depth-red-b row confirmed verdict:PENDING, last_updated 2026-07-13, pre-registered at docs/specs/sensorium.md:5-40 -- the spec's citation is exact; :os_sensorium is a genuinely distinct, unclaimed atom. (5) The byte-identity section's struct-field correction is accurate -- I read the defstruct (genome.ex:140-215) directly and confirmed there is no :organs field, only growth_plan, and confirmed slow_defaults/1 (604-620) back-fills nursery/severed_limbs/max_phase exactly as described, none of which card/1 reads. The two 'found during re-verification' items also check out: Board.put/2 (board.ex:18-21) is exactly (username, row) two-positional-arg ETS overwrite as claimed, and assert_frozen/1 is confirmed absent from the tree. Given this level of citation fidelity, the fix pass is real, not cosmetic. What I found beyond the named list: the spec's strongest remaining claim -- that the organ-PRESENT lineage (os_sensorium_primary/1) is unconditionally byte-identical to default -- outruns what its cited test (decider_byte_identity_test.exs) and its own proposed test (length-only arm-integrity check) actually establish; the underlying math is very likely correct by inspection but is not yet held to the same MAD<1e-12 falsifiable bar this codebase applies everywhere else to byte-identity claims. Plus one small citation overclaim (metabolism_primary/0 doesn't call repair/1 despite being cited as matching 'the exact shape of every constructor above'). Neither is a live-code-breaking defect like the original BLOCKED findings; both are named, concrete, cheap to fix (one test assertion, one sentence edit), so SIGN_WITH_CHANGES rather than REVISE or REJECT.
• Concerns:
  • Byte-identity claim overstates what's actually tested for the organ-PRESENT lineage. The spec asserts (SPEC_log_sensor_organ.md ~160-169) that 'SP.Brain.Genome.os_sensorium_primary/1's compiled model is identical to default/0's unconditionally' and that this is 'verified the same way every other opt-in organ's default-off byte-identity is verified... via decider_byte_identity_test.exs'. I re-read test/sp/brain/decider_byte_identity_test.exs in full: it only ever calls Plan.action_values on Genome.default() / implicit-default MC.new(seed:7) and diffs against the frozen golden (test/fixtures/decider_golden_seed7_d5b3.bin) -- it never constructs or runs os_sensorium_primary() (or metabolism_primary()/homeostat_l1_phase0() for that matter). That test proves 'organ ABSENT (default) is byte-identical to golden', not 'organ PRESENT-but-zero-wired is byte-identical to default'; those are different claims. For :metabolism the codebase never claims the ON lineage is byte-identical to default (it isn't -- 14 vs 12 factors, per metabolism_organ_test.exs), so 'exactly as it does for :metabolism' is not a valid precedent for the stronger ON-lineage claim this spec is making. The proposed new test (os_sensorium_organ_test.exs) only checks subs LENGTH equality (12==12), which is necessary but not sufficient for 'compiled model is identical' -- two models can have equal factor counts with different A/B/C/pb contents. I traced card/1 + active_modalities/1 (genome.ex:438-494) by hand and the claim is almost certainly true (active_modalities filters the fixed @modalities list by organ-membership, and no @modalities entry names organ: :os_sensorium, so mods is content-identical regardless of growth_plan order/position), but 'almost certainly true by code-reading' is not the same as a falsifiable MAD<1e-12 test, which is the bar this codebase holds every other byte-identity claim to (CLAUDE.md Hard Invariant #2). Required change: either (a) soften the claim to what's actually proven ('organ absent from default_genome -> default remains byte-identical', which IS covered) and drop 'unconditionally... verified', or (b) add one direct assertion in the new test file: assert mad(Plan.action_values(MC.new(seed:7, dna: Genome.os_sensorium_primary()).model, depth:5, beam:3), Plan.action_values(MC.new(seed:7, dna: Genome.default()).model, depth:5, beam:3)) < 1.0e-12 (or an equivalent direct .subs equality check), matching the rigor decider_byte_identity_test.exs applies to the default-absent case.
  • Minor citation overclaim: 'Add a constructor that starts from default(), appends the new atom to growth_plan, sets whatever struct fields the organ owns, and calls repair/1 ... -- the exact shape of every constructor above' (SPEC_log_sensor_organ.md ~97-99, citing metabolism_primary/0 at genome.ex:271-274 as the first exemplar). I re-read genome.ex:271-274 directly: def metabolism_primary do; d = default(); %{d | growth_plan: d.growth_plan ++ [:metabolism]}; end -- it does NOT call repair/1 (default() is already repaired and :metabolism's only prereq, :interoception, is already present earlier in the plan, so this is harmless in practice, but it contradicts the spec's own 'exact shape of every constructor above' claim). homeostat_l1_phase0/0 (298-316), vision_primary/0 (236-240) and motor_primary/0 (248-252) DO call repair/1, so 3 of the 4 cited exemplars match the claimed shape but the first one cited does not. Not functionally risky -- the new os_sensorium_primary/1 constructor itself does call repair/1, the safer pattern -- but the citation should be corrected (either drop metabolism_primary/0 from the 'exact shape' list or note it's the one exception) so a future reader doesn't trust an inaccurate generalization the way the prior draft's fabricated add_organ/2 was trusted.

aif-core-theorist

• Verdict: SIGN
• Rationale: Independent re-verification against the live repo confirms all five prior BLOCKED findings are genuinely resolved, plus the two additional self-caught defects (Board API mismatch, assert_frozen fabrication) check out too -- I did not take the spec's "Corrections from prior draft" section at its word and instead re-derived each citation myself. Line-for-line checks: lib/sp/runtime/log_sensor.ex (install/0, log/2, drain/0) is live and untouched; lib/sp/producer.ex:151,227 call it exactly as cited; SP.Brain.Genome.add_organ/2 does not exist anywhere (repo-wide grep confirms it appears only inside the spec doc itself); @prereqs (genome.ex:19-39), @modalities (49-130), metabolism_primary/0 (271-274), homeostat_l1_phase0/0 (298-316), card/1 (438-488), active_modalities/1 (490-494), slow_defaults/1 (604-620) all match the spec's citations exactly; SP.Runtime.Board.put/2 is confirmed (username, row) two-positional-arg per-agent overwrite table with no :key option, so the spec's rationale for giving SpoolSensor its own ring is sound; SP.Runtime.Supervisor's three children (Registry, PartitionSupervisor, Board) match exactly; test/sp/runtime/log_sensor_test.exs is untouched and still targets install/log/drain; no file exists yet at the new spool_sensor_test.exs / os_sensorium_organ_test.exs / spool_sensor.ex paths, so no new collision was introduced; test/sp/brain/decider_byte_identity_test.exs and metabolism_organ_test.exs match their cited content (golden-file MAD<1e-12 mechanism, "Byte-identity... gated by DeciderByteIdentityTest" comment); docs/specs/sensorium.md and evidence/gates.ndjson's depth-red-b PENDING row match the disambiguation claims; SP.Producer.Codec.error_rate/1 (codec.ex:139, "0 clean/1 warnings/2 erroring") and producer/genome.ex:65 match. On my specific mandate -- claim-fence discipline and felt-state-language containment -- this spec is clean and, in fact, exemplary: no feel/emotion/experience/aware/conscious language anywhere in the doc; v1 deliberately touches zero generative-model surface (no @modalities entry, card/1 output proven unconditionally identical, not merely 'at coupling 0.0'); nothing is exposed to any reader, output, overlay, or broadcast surface ('v1 ships no reader'); and the spec explicitly refuses to smuggle a fake qo-coupling citation, instead naming the real gap and deferring the actual FE-touching mechanism (discretization function + new @modalities entry + sensorium_coupling knob) to a properly-scoped follow-up spec (D-A4b) that will itself owe its own /lab-team-review before any qo change lands. That is exactly the theorist's required posture: name the generative model (or explicitly name its absence), don't conflate novel plumbing with a new preference/C term, and don't collapse 'organ present on genome' into any claim about belief or experience. The only defect I found under my own independent check is a single trivial prose imprecision (noted above) that does not affect the actual proposed code, byte-identity, or claim-fence discipline -- not something that needs to gate shipping. Readiness: SIGN, no changes required before landing."
• Concerns:
  • Minor prose imprecision only (non-blocking): production/mcp/SPEC_log_sensor_organ.md line ~98 says the new os_sensorium_primary/1 constructor 'calls repair/1 ... the exact shape of every constructor above,' citing metabolism_primary/0 and homeostat_l1_phase0/0 as the two named exemplars. Verified against lib/sp/brain/genome.ex:271-274: metabolism_primary/0 does NOT call repair/1 (plain %{d | growth_plan: ...} struct update) -- only homeostat_l1_phase0/0 (lines 298-316) does. The spec's actual proposed code for os_sensorium_primary/1 does correctly call repair/1, matching the safer precedent, so nothing is functionally wrong -- the supporting sentence is just slightly over-general about which of the two cited constructors it mirrors.

systems-architect (docs/lab_team/03_systems_architect.md) — role 3 of 5, speaks after the math survives: can this be built, typed, validated, and inspected in pure Elixir without breaking the engine?

• Verdict: SIGN_WITH_CHANGES
• Rationale: Independently re-verified every citation in this corrected spec against the live repo (not just the spec's own 'Corrections from prior draft' section) and every one of the five original findings plus the two bonus findings the rewrite claims to have caught are genuinely fixed, with citations accurate down to the exact line number:

(1) Module collision — confirmed live: lib/sp/runtime/log_sensor.ex defines SP.Runtime.LogSensor (install/0, log/2, drain/0), wired at lib/sp/producer.ex:151 (install()) and :227 (drain(), inside build_telemetry) exactly as cited. New process correctly renamed SP.Runtime.SpoolSensor; explicit untouched-module note present and accurate. (2) add_organ/2 fabrication — repo-wide grep confirms it appears nowhere except inside this spec's own prose describing the prior draft's error. Replacement pattern verified real: @prereqs map at genome.ex:19-39 (exact), @modalities at :49-130 (exact), metabolism_primary/0 at :271-274 (exact), homeostat_l1_phase0/0 at :298-316 (exact), vision_primary/0 and motor_primary/0 both exist. card/1 at :438-488 (exact) and active_modalities/1 at :490-494 (exact) read as described. Designer.compile/1 (designer.ex:31-65, exact) confirmed to have no generic 'fold an exteroceptive row into qo at a coupling weight' mechanism today — the spec correctly scopes that as new D-A4b work rather than citing a fake accessor. (3) Test-file collision — test/sp/runtime/log_sensor_test.exs confirmed live and exactly tests install/log/drain as described; ls confirms test/sp/runtime/spool_sensor_test.exs does not yet exist (genuinely new path, no collision). (4) :sensorium name collision — docs/specs/sensorium.md confirmed live (binocular vision, Eye pipeline, :depth factor); evidence/gates.ndjson's depth-red-b row confirmed verdict PENDING with notes 'Pre-registered in docs/specs/sensorium.md:5-40' — an exact match to the spec's citation. Organ correctly renamed :os_sensorium with an accurate disambiguation note. (5) Byte-identity invariant — confirmed %SP.Brain.Genome{} defstruct has no :organs field (organs/0 is a module function returning Map.keys(@prereqs)); growth_plan is the real varying field. test/sp/brain/decider_byte_identity_test.exs confirmed live and does exactly the golden-file MAD<1e-12 comparison described; assert_frozen/1 confirmed to not exist anywhere in lib/ or test/. (6-7 bonus) SP.Runtime.Board.put/2 confirmed live as (username, row) — a two-arg ETS overwrite table with no :key option, exactly as the spec describes (would not have compiled as originally drafted). SP.Runtime.Supervisor confirmed to list exactly three children (Registry, PartitionSupervisor, Board), supporting the spec's architectural reasoning for why SpoolSensor should own its own ring rather than misuse Board.

Every cross-reference I spot-checked outside the 'Corrections' section also held exactly: lib/sp/producer/genome.ex:65 is the :error_rate modality; lib/sp/producer/codec.ex:139 is def error_rate/1; production/docs/OS_SPOOL_POLICY.md:28 literally still says 'SP.Runtime.LogSensor (planned per D-A4)' as a heartbeat.ndjson reader — the spec's flagged-but-not-fixed staleness note is accurate and honestly scoped as out-of-file-list. production/schemas/sensorium_envelope.schema.json exists.

This is unusually rigorous work — every single citation I checked, including ones outside the five-plus-two 'corrected' list, was accurate to the exact line number, and the spec is honest about what it is and is not shipping (e.g., explicitly deferring the qo-coupling mechanism to D-A4b rather than hand-waving it). The one place that rigor lapses is the actual OTP process-registration mechanics for the new SpoolSensor GenServer itself: the spec names the module, the genome field, and the tests, but never names the boot/supervision call site that would make an opted-in agent's SpoolSensor actually start — and its own moduledoc oversells the pure-DNA constructor as if it performs that start. That is a concrete, narrowly-scoped gap (not a correctness bug that would corrupt or break anything live, since an un-started process is inert, not harmful) — appropriate for SIGN_WITH_CHANGES: land once the spec either (a) names the exact start_link call site + supervision strategy + per-agent naming scheme as in-scope v1 work, or (b) explicitly re-scopes process-starting out of v1 the same way it already re-scopes the Coupling work, and corrects the moduledoc line that currently claims otherwise.

• Concerns:
  • Boot-time/registration wiring for the actual SpoolSensor process is never named. SP.Brain.Genome.os_sensorium_primary/1's own moduledoc claims the organ 'starts a supervised SP.Runtime.SpoolSensor tailing opts[:spools] for this agent,' but the constructor code shown directly below it is a pure DNA-builder — repair(%{d | growth_plan: ..., sensorium_spools: ...}) — the exact same shape as the real lib/sp/brain/genome.ex:271-274 (metabolism_primary/0) and :298-316 (homeostat_l1_phase0/0), neither of which spawns anything. Grepping the live tree (lib/sp/brain/mc.ex:207,363,467; lib/sp/runtime/agent.ex:132,136,444) confirms every existing opt-in organ (metabolism, homeostat, motor_cortex) is consumed via Genome.active_organs(dna) checks INSIDE the same agent GenServer's own step logic — none of them spawns a new child process. SpoolSensor would be the FIRST organ requiring a genuinely new OTP process, and the spec never names where start_link/1 actually gets called: not in SP.Runtime.Agent's init, not as an addition to SP.Runtime.Supervisor's children list (lib/sp/runtime/supervisor.ex:50-56, currently exactly [Registry, PartitionSupervisor, Board] — verified live), nowhere. The line 'runtime-only (read by whatever process-supervision code starts the agent's SpoolSensor, not by card/1)' is a hand-wave with no named callee — contrast with how rigorously the spec's own 'Coupling (future work, not in v1)' section explicitly re-scopes the qo-folding gap to a named follow-up (D-A4b); this boot-wiring gap gets no equivalent explicit deferral, so 'v1 ships the tailer' (Purpose) currently means 'ships a tailer MODULE that compiles and passes its own unit tests,' not a tailer that actually runs when an agent's genome carries :os_sensorium.
  • Cardinality of SpoolSensor (per-agent vs. fleet-global) is unaddressed, which is both a design question and a naming/registration-collision risk once wiring is added. The moduledoc's 'for this agent' implies one process per opted-in UNI, each independently tailing the SAME global fleet-wide files (heartbeat.ndjson, prod-mcp.ndjson) — redundant if multiple UNIs opt in. The Signatures section's start_link(opts :: keyword()) documents no :name option or uniqueness strategy, so if/when the missing wiring above is added, a second opted-in agent starting a second unnamed GenServer is fine (anonymous), but a per-agent named SpoolSensor (needed if any future reader wants to address 'this agent's SpoolSensor') would need a registration scheme (Registry-based, mirroring SP.Runtime.Agent's own registry use) that isn't specified.
  • Minor/cosmetic: the new defstruct field is named sensorium_spools, which still carries the bare word 'sensorium' the rest of this spec went to real lengths to disambiguate away from (organ atom → :os_sensorium, module → SpoolSensor, test file → os_sensorium_organ_test.exs). Low risk since it's an internal struct field, not operator-facing or MCP-facing language, but worth a one-word rename (e.g. os_sensorium_spools) for consistency with the disambiguation already done everywhere else in this same PR.

red-experimentalist

• Verdict: SIGN_WITH_CHANGES
• Rationale: Fresh, independent re-verification against the live repo (not the spec's own claims) confirms all five original BLOCKED findings are genuinely resolved, plus two additional self-caught defects (Board API mismatch, assert_frozen fabrication) are also correctly fixed:\n\n1. Module collision: lib/sp/runtime/log_sensor.ex is confirmed live (install/log/drain, wired at lib/sp/producer.ex:151 and :227 exactly as cited), untouched by this spec; new module is SP.Runtime.SpoolSensor with no collision (file doesn't exist yet).\n2. Genome.add_organ/2: repo-wide grep confirms it appears ONLY inside the spec doc's own 'does not exist' citation -- nowhere in real code. The replacement pattern (append to growth_plan + @prereqs entry + repair/1) is verified against the real metabolism_primary/0 (genome.ex:271-274) and homeostat_l1_phase0/0 (genome.ex:298-316) -- exact line ranges match. The claim that no generic qo-coupling mechanism exists in card/1 (genome.ex:438-488) / Designer.compile/1 (designer.ex:31-65) also checks out -- I traced both functions myself.\n3. Test-file collision: test/sp/runtime/log_sensor_test.exs exists and tests exactly install/log/drain as described (read in full); new tests correctly routed to a new path that doesn't yet exist.\n4. :sensorium collision: docs/specs/sensorium.md exists; evidence/gates.ndjson's depth-red-b row (verdict PENDING, pre-registered at docs/specs/sensorium.md:5-40) matches the spec's citation verbatim. Organ renamed to :os_sensorium with a clear disambiguation note.\n5. Byte-identity invariant: correctly fixed to the real growth_plan field and the real decider_byte_identity_test.exs golden mechanism (the nonexistent .organs field and assert_frozen/1 helper are gone).\n6/7 (self-caught): SP.Runtime.Board.put/2 (board.ex:17-21) is confirmed (username, row) two-arg overwrite table, not a keyed ring -- SpoolSensor correctly owns its own ring instead. assert_frozen/1 confirmed absent from the codebase.\n\nThis is a careful, well-verified rewrite -- every citation I independently checked (line numbers, function names, file existence) was accurate, which is itself the right discipline for landing near live production code.\n\nHowever, my persona's specific mandate is testability against a fabricated-but-schema-valid implementation and named FALSIFIES conditions, and on that axis I found three concrete, unaddressed gaps (detailed in concerns): the byte-identity claim's ONLY test checks factor count, not value equality, and the cited backstop test never touches the new lineage at all; the schema-validation claim names no mechanism in a codebase that has zero JSON/JSON-Schema precedent (mix.exs is deliberately dependency-free) and no named test exercises schema-invalid-but-syntactically-valid rows; and the spec asserts per-agent auto-start of SpoolSensor as v1 behavior with no actual wiring point in the live supervision tree and no test verifying it happens. None of these are fundamental -- they're closable with either added assertions/citations or honest re-scoping (the spec already knows how to do this well, per its own 'Coupling (future work, not in v1)' section) -- so this lands as SIGN_WITH_CHANGES, not REVISE or REJECT.
• Concerns:
  • TESTABILITY GAP #1 (byte-identity claim under-tested): SPEC_log_sensor_organ.md's headline invariant is that os_sensorium_primary()'s compiled model is 'identical to default/0's unconditionally' (spec lines ~160-165), but the only named test for it (test/sp/brain/os_sensorium_organ_test.exs, 'Arm integrity', spec lines ~227-229) checks length(model.subs) == 12 for both genomes -- a cardinality check, not a value-level equality check. I independently re-traced the real code path (lib/sp/brain/genome.ex:438-494, active_modalities/1 filters the fixed @modalities list by organ-in-growth_plan, order fixed by @modalities's own declared order) and confirmed the claim IS analytically true today, but the cited backstop test/sp/brain/decider_byte_identity_test.exs never constructs os_sensorium_primary() -- I read the file; it only ever calls Genome.default(). So a future regression that keeps the factor COUNT at 12 while silently changing which/how factors compile (e.g. a repair/1 stable-sort assumption breaking, or an accidental @modalities edit that swaps but doesn't add/remove a factor) would pass every named test. This is exactly the 'fabricated-but-schema-valid' failure mode this review is supposed to catch. Fix: add an explicit value-level assertion (e.g. Plan.action_values(MC.new(seed:7, dna: Genome.os_sensorium_primary()).model, depth:5, beam:3) MAD<1e-12 vs the default/golden value), mirroring decider_byte_identity_test.exs's own 'explicit Genome.default() matches the implicit default genome' pattern (test file lines 25-28).
  • TESTABILITY GAP #2 (no FALSIFIES condition for the schema-validation claim, and no named mechanism): the spec's Row lifecycle (lines ~175-177) claims SpoolSensor 'Parses each complete line as JSON' and 'Validates against production/schemas/sensorium_envelope.schema.json. Drops malformed rows silently.' I checked mix.exs (deps do [] end, with an explicit comment that the codebase is kept dependency-free 'so mix test is fully offline and deterministic') and grepped all of lib/ for JSON usage -- there is zero precedent anywhere in this codebase for JSON decoding OR JSON-Schema validation in pure Elixir. The spec names no dependency and no hand-rolled mechanism for either. The one relevant named test, 'Malformed-row drop (does NOT crash the sensor)' (spec line ~220), is satisfiable by decode-error handling alone -- nothing in the named test list exercises 'syntactically-valid JSON that violates the schema' (missing required field, wrong kind enum, wrong schema_version const -- all present as required/enum/const constraints in production/schemas/sensorium_envelope.schema.json, verified). A stub that JSON-decodes but never actually schema-validates (accepts every row that parses) would pass every named test while the moduledoc's 'schema-validated rows' claim would be false. Fix: name the concrete decode/validate mechanism (and any new dependency, surfaced to the architect persona given the zero-deps invariant), and add a named test asserting a valid-JSON-but-schema-invalid row is excluded from recent/2's output.
  • SPEC GAP #3 (the actually-functioning v1 behavior is unwired and untested): spec line ~118-119 states os_sensorium_primary/1 'starts a supervised SP.Runtime.SpoolSensor tailing opts[:spools] for this agent' as a v1 behavior, but no per-agent supervision wiring point is named anywhere in the spec -- the 'NEW defstruct field' note (line ~137) explicitly hand-waves this as 'read by whatever process-supervision code starts the agent's SpoolSensor' (unnamed). I checked the live supervision tree: lib/sp/runtime/supervisor.ex:50-54 has exactly 3 fixed children (Registry, PartitionSupervisor, Board -- confirmed via source read, matches the spec's own citation elsewhere), with no per-organ dynamic-child hook; lib/sp/runtime/agent.ex is a single GenServer per UNI with no existing precedent for an organ-gated child process. SpoolSensor appears nowhere in the repo outside this spec doc (grep-confirmed), so there is genuinely no wiring point today. None of the named tests (spec lines ~218-231) verify that an agent whose genome carries :os_sensorium actually gets a live, supervised SpoolSensor -- the SpoolSensor unit tests presumably call start_link directly with explicit opts, and the organ test only checks genome/model shape, not process supervision. A fully-working, well-tested SpoolSensor module that is never actually started for any real agent would pass every named test in this spec -- i.e. v1 could ship and do literally nothing at runtime while every gate is green. Fix: either name the actual wiring point + add a supervision test, or -- consistent with how the spec already honestly re-scopes qo-folding into 'Coupling (future work, not in v1)' -- explicitly re-scope per-agent auto-start out of v1 too and say so in Purpose, rather than asserting it as settled v1 behavior in the constructor moduledoc.

embodiment-designer (docs/lab_team/05_embodiment_designer.md) — non-saturable organs/drives reviewer, this pass focused on embodiment exposure/redaction per the orchestrator's specific ask

• Verdict: SIGN_WITH_CHANGES
• Rationale: Independently re-verified every citation in the corrected spec against live source and found all seven named corrections (five original + two found-during-re-verification) accurate, with no new fabrications introduced by the fix:
• lib/sp/runtime/log_sensor.ex confirmed live and untouched: install/0, log/2, drain/0 exactly as described; lib/sp/producer.ex:151 (install() in init/1) and :227 (log: SP.Runtime.LogSensor.drain() inside build_telemetry) confirmed exact.
• lib/sp/runtime/board.ex:18-21 confirmed put(username, %{} = row) — two positional args, per-agent single-row overwrite table, exactly as the spec's rebuttal of the prior draft's Board.put(key: {:sensorium, source, i}, row) describes. SpoolSensor correctly avoids Board entirely.
• lib/sp/brain/genome.ex: @prereqs (lines 19-39), @organs = Map.keys(@prereqs) (line 40), metabolism_primary/0 (lines 271-273), homeostat_l1_phase0/0 (line 298), growth_plan defstruct field (line 140), nursery: nil (line 206), slow_defaults/1 (line 604) with Map.put_new(:nursery, nil) (line 618) — all confirmed at the cited or immediately-adjacent lines, and the pattern the new os_sensorium_primary/0 / sensorium_spools field is modeled on is real.
• %SP.Brain.Genome{}'s defstruct (lines 139-215) confirmed to have NO :organs field — the spec's correction from .organs to .growth_plan for the byte-identity test is accurate.
• assert_frozen/1: zero hits repo-wide — confirmed fabricated in the prior draft and correctly removed.
• test/sp/brain/decider_byte_identity_test.exs confirmed to be exactly the golden-file MAD<1e-12 mechanism described; test/sp/brain/metabolism_organ_test.exs:6 independently confirms the citation pattern ("Byte-identity with the organ OFF is gated by DeciderByteIdentityTest").
• evidence/gates.ndjson confirmed to carry a depth-red-b row, verdict PENDING, pre-registered at docs/specs/sensorium.md:5-40 — matches the spec's disambiguation citation exactly.
• card/1 (lines 438-488) and active_modalities/1 (lines 490-494) confirmed at the cited lines; confirmed card/1's Map.take(m, [:name, :no, :ns, :init_a, :b_init, :pb_seed, :learn_b, :couple]) is the real, existing field-level allowlist gating what a modality spec contributes to the compiled Function-Card — and confirmed this spec's v1 never touches it (zero @modalities entries for :os_sensorium).
• Test file paths (test/sp/runtime/spool_sensor_test.exs, test/sp/brain/os_sensorium_organ_test.exs) confirmed to NOT already exist — genuinely new, no collision.

On my assigned focus (exposure/redaction, field-level allowlist for public surfaces, path/host-layout leaks): v1 as specced has zero public exposure — independently confirmed no wiring to Board, no HTTP/web route, no qo/logits path exists for this organ at all in v1. The codebase has a real, pre-existing discipline of hand-curated field allowlists for anything reaching the public Board//stream surface (agent.ex's publish/1, mind.ex's of/2), and this spec is consistent with — does not weaken — that discipline. The one gap is forward-looking: the data this organ tails is confirmed genuinely host/path-shaped (schema + visualizer both confirm real hostnames and a 'relay path' field), it is stored unredacted in the organ's own memory starting in v1, and the future coupling section names a qo-bound reducer but is silent on the free-text Mind.report path that already reaches the public stream today. That's a one-sentence, in-scope, cheap fix to this file — hence SIGN_WITH_CHANGES rather than a blocking REVISE.

• Concerns:
  • production/mcp/SPEC_log_sensor_organ.md 'Coupling (future work, not in v1)' section (lines 184-211) does not yet pre-commit D-A4b's future discretization/report path to a field-level redaction rule, even though the data it will read is confirmed host/path-shaped. Grounded in three independently-verified facts: (1) production/schemas/sensorium_envelope.schema.json:34-36 defines provenance.server as literal internal box names ("uni-lab | uni-lab-79740c | thinker | uni-tab-arm-1"), and the row payload is an open, unredacted object (schema comment: "consumers should tolerate unknown keys"); production/overlays/status/index.html:46 independently confirms heartbeat rows carry a 'relay path' column, i.e. real network-topology-shaped content. (2) The spec's own 'Row lifecycle' (steps 3-5) stores these rows FULLY UNREDACTED in SpoolSensor's ring — correct for v1 since nothing reads them, but it means the raw host/path content is already resident in a live process's memory the moment this organ is opted in. (3) The one existing public-facing channel this data could eventually reach is NOT qo (which is structurally safe — a bounded categorical no-sized slot cannot hold a hostname string) but Mind.report — a free-text field (lib/sp/runtime/mind.ex:29, report: safe(fn -> bc && Awareness.report(bc) end, nil)) that IS published to the public Board//stream surface every tick (lib/sp/runtime/agent.ex:404-416 merges mind into the row; lib/sp/runtime/board.ex:4-9's own moduledoc names '/stream UI' as a reader). D-A4b's proposed 'discretization function' (Coupling item 1) constrains what reaches qo via a bounded index, but says nothing about report/explanation text derived from the same rows never echoing provenance.server or payload path fields verbatim. Ask: add one sentence to the Coupling section now, while the data shape is fresh in scope, naming this exact constraint as a prerequisite for D-A4b (mirrors the existing hand-curated-field discipline this codebase already practices at agent.ex:404-414 and mind.ex:19-31, where DNA/state is never dumped wholesale onto the Board — only specific named scalars are). This is not a v1 blocker (v1 wires nothing to Board/qo/HTTP — independently confirmed: zero grep hits for SpoolSensor/sensorium/os_sensorium anywhere under viewer/, production/mcp/, or lib/sp_web-equivalent code, and zero @modalities entries gated on :os_sensorium), but it is a cheap, concrete addition that closes the one exposure question this spec's own re-verification pass didn't ask.

MERGED VERDICT

SIGN_WITH_CHANGES

(Merge rule: the worst verdict wins.)

Honesty note

This is a v2 receipt following a spec-correction pass driven by the v1 review's own findings. This is the first formal review this spec has received. No FE source code (.ex/.exs/.py/.cjs) was written or modified by either the fix pass or this review -- only spec/schema/policy documents. If this verdict is SIGN or SIGN_WITH_CHANGES, implementation may proceed through this repo's normal ship gate; if REVISE or REJECT, further spec work is needed before any code diff.

Addendum — named changes applied (pass 3)

This is a direct-apply pass, not a fresh independent persona re-review. One session read every "Concerns:" bullet under all five personas above (including the two SIGN/SIGN_WITH_CHANGES personas' non-blocking notes) and applied fixes directly to production/mcp/SPEC_log_sensor_organ.md. It re-checked each concern's cited file:line against the live repo before editing (in one case this caught the pass's own drafting error — see math-breaker item 1 below — and the fix was corrected before landing). Nothing in this pass constitutes a new, independent verification verdict; treat the MERGED VERDICT above (SIGN_WITH_CHANGES) as still the operative review outcome, now with its named changes applied. Only production/mcp/SPEC_log_sensor_organ.md was edited; no .ex/.exs/.py/.cjs file was touched.

math-breaker

• FIXED: Byte-identity claim for the organ-PRESENT lineage was under-tested (length-only check). Rewrote "Byte-identity invariant" to name it as two separate claims, and added an explicit mad(...) < 1.0e-12 value-level assertion (mirroring decider_byte_identity_test.exs's own mad/2 helper) to the os_sensorium_organ_test.exs bullet list in "Test coverage," plus a matching entry in a new ## FALSIFIES section.
• FIXED: metabolism_primary/0 does not call repair/1 despite being cited as "the exact shape of every constructor above." Corrected the citation in Signatures §2 to name homeostat_l1_phase0/0 as the accurate exemplar and to state the metabolism_primary/0 exception explicitly (re-verified directly against lib/sp/brain/genome.ex:271-274 and :298-316). Also fixed the same overclaim in the os_sensorium_primary/1 moduledoc's "Modeled on" line.

aif-core-theorist

• FIXED: Same prose imprecision as math-breaker item 2 above (this persona flagged the identical citation, non-blocking) — resolved by the same edit.

systems-architect

• FIXED: Boot-time/registration wiring for the actual SpoolSensor process was never named, and the os_sensorium_primary/1 moduledoc oversold it as v1 behavior. Took the persona's option (b): added a new "## Process wiring (future work, not in v1)" section explicitly re-scoping per-agent auto-start out of v1 (re-verified live: every existing opt-in organ is consumed via an inline Genome.active_organs(dna) check in SP.Runtime.Agent, lib/sp/runtime/agent.ex:132,136,444, none spawns a process; SP.Runtime.Supervisor's children are fixed at [Registry, PartitionSupervisor, Board], lib/sp/runtime/supervisor.ex:50-54), and corrected the moduledoc line that claimed the constructor "starts a supervised SpoolSensor."
• FIXED: Cardinality (per-agent vs. fleet-global) was unaddressed. Named it explicitly as one of the three things the "Process wiring" follow-up must define (start site, registration/naming scheme, cardinality), rather than leaving it silent.
• FIXED: Cosmetic — renamed the new defstruct field sensorium_spools → os_sensorium_spools throughout the spec (and, for the same consistency reason, the proposed D-A4b sensorium_coupling → os_sensorium_coupling in the Coupling section) so no struct field in this spec carries the bare, collision-prone word sensorium.

red-experimentalist

• FIXED: TESTABILITY GAP #1 (byte-identity under-tested) — same fix as math-breaker item 1 above.
• FIXED: TESTABILITY GAP #2 (no named mechanism or FALSIFIES condition for the schema-validation claim). Named the concrete decode mechanism (Jason via dynamic dispatch — re-verified this exact precedent already lives at lib/sp/show/overlay_publisher.ex:107-113 for the identical dependency-free-root-app reason) and the concrete validation mechanism (a hand-rolled check against the four constraint families sensorium_envelope.schema.json actually declares — re-read the schema directly to confirm those four families and that no JSON-Schema library exists anywhere in this codebase). Added a named "schema-invalid-but-JSON-valid row is dropped" test to "Test coverage" and to the new ## FALSIFIES section. Also named, as an honest side-effect of tracing this precedent carefully, the resulting root-app-vs-ui-app test-location boundary (test/sp/runtime/spool_sensor_test.exs is the first file in that directory whose JSON-path tests need Jason loaded) rather than leaving it implicit the way SP.Show.OverlayPublisher (which simply has no test file) does. Self-caught correction during this pass: an earlier draft of this exact fix additionally claimed SP.Runtime.Supervisor's "one live caller today is the ui app's LiveView code path via ensure_started/1" — re-checking that specific claim against a repo-wide grep for ensure_started showed it was wrong (the real caller chain is SP.Runtime.Lineage.init/1 → SP.Brain.Colony, not LiveView directly). Replaced it with the narrower, actually-verified structural fact: SpUi.Application is the only module in the repo with an OTP mod: application-start callback (repo-wide grep "mod: {" confirms this), so any BEAM node running SP.Runtime.* code today is necessarily booted via the ui release, which loads Jason — this is the fact the argument actually needs, and it is one that held up under its own re-check.
• FIXED: SPEC GAP #3 (v1 behavior unwired and untested) — same fix as systems-architect item 1 above (explicit re-scope in "Process wiring," plus the spec's ## FALSIFIES section now explicitly states that auto-start is NOT a falsifiable v1 claim, so nothing can silently ship implying it is).

embodiment-designer

• FIXED: The "Coupling (future work, not in v1)" section did not pre-commit D-A4b to a field-level redaction rule despite the data being confirmed host/path-shaped. Added a "Redaction prerequisite for D-A4b" paragraph naming the exact constraint (re-verified sensorium_envelope.schema.json:34-36's provenance.server field, lib/sp/runtime/mind.ex:29's free-text report field, and lib/sp/runtime/agent.ex:404-416's whole-mind-map merge into the publicly-read Board row) — D-A4b must not let any future report/explanation text echo provenance.server or raw payload fields verbatim.

Summary

All ten named concerns across the five personas were genuine spec-document fixes (missing test assertions, an inaccurate citation, an unspecified registration step, a naming inconsistency, an unnamed mechanism, and a missing prerequisite note) — none required editing real .ex/.exs source, because none of them named a bug in code that already exists and runs today; every one was about what this not-yet-written spec should specify, test, or defer. So there are no "pre-existing code gap" prerequisites to name in this pass, and no items were left as an unresolved judgment call for the owner. The spec's own "Process wiring" and "Coupling" sections still leave two pieces of NEW work genuinely unscoped for a follow-up spec (D-A4b for qo-coupling, an unnamed follow-up for process-supervision wiring) — that is a deliberate re-scoping this pass applied per two personas' own suggested resolution, not an unresolved concern.