Advise: add-thor-carrier

ADVISE: send-back READER: sol-arch-review SPAWN: /Users/dukejones/work/ClientProjects/AllSystemsGo/AICamera/.spawns/add-thor-carrier-1789038926-24731-4cd6de4c

Blind take

1. Pin the lab target to the complete AGX Thor Developer Kit, explicitly identifying its T5000 module and kit envelope.
2. Pin production to a T4000 SOM on a compatible carrier, with T5000 allowed only after measured satellite encode demand exceeds the hybrid path.
3. Refuse any wording or purchase path that implies an AGX Thor T4000 developer kit exists.
4. Require the production carrier contract to cover the T4000’s 699-pin interface, 87 × 100 × 15.29 mm envelope, and customer-side thermal stack.
5. Require both SYS_VIN_HV 7–20 V and SYS_VIN_MV 5 V rails, and refuse assumptions about T5000-only SYS_VIN_SV or CAN.
6. Keep module power isolated from satellite PoE so no PoE path can backfeed the kit or SOM.
7. Require a body-camera ingress path, NVMe, and PHY-level MGBE connectivity without treating module MACs as finished copper, fiber, or aggregate 100GbE ports.
8. Treat Rogue-T5 as the preferred current carrier, but keep acceptance capability-based until its design-guide, connector, cooler, and JCB details are verified.
9. Refuse a three-stream HQ encode promise on T4000; the safe baseline is Thor encoding the body while RV1126-class satellites deliver H.265.
10. The tradeoff is buying one T4000/T5000-capable carrier now versus optimizing size and cost later; compatibility reduces lab-to-production risk but may overbuild the final body.

Comparison and steelman

The design answers most of the independent concerns cleanly. It keeps the lab kit and production SOM distinct, records both envelopes, names the 699-pin interface and both T4000 input rails, preserves the single-NVENC constraint, and calls for body-camera ingress, MGBE, NVMe, and a TTP solution. The delta correctly makes the lab brick a T5000-based AGX Thor Developer Kit and makes the hybrid record path explicit: Thor encodes only the body while satellites remain camera-side H.265.

The strongest case for the current delta is that it stays lean and relies on existing living requirements for split power, PoE non-backfeed, and the 70/90 W thermal ceiling. docs/CARRIER.md also carries the fuller carrier guidance, including Rogue-T5 preference, off-module I/O, and the conditional T5000 escape. Avoiding duplicate SHALLs is a valid design choice.

Blocking findings

1. The carrier’s required rails are descriptive, not normative. The proposal identifies rail mismatch as one of the purchase-lock risks, and the design correctly states SYS_VIN_HV 7–20 V plus SYS_VIN_MV 5 V with no SYS_VIN_SV. The production requirement, however, reduces “envelope and power” to dimensions and 70/90 W limits. The existing split-power requirement prevents PoE backfeed but does not require the T4000 rail set. If the delta is folded as written, a carrier can satisfy the SHALL while omitting the required 5 V MV rail. Amend the production carrier requirement or add a scenario that makes the two required rails—and the absence of T4000 SYS_VIN_SV—part of acceptance.

2. The T4000 ceiling has no normative escape criterion. The proposal says T4000 applies “if HEVC hybrid still fits,” and docs/CARRIER.md says satellite count may force T5000. The delta only specifies the successful T4000 case, so it loses the decision boundary that prevents either premature T5000 overbuild or an undersized T4000 commitment. Add a concise scenario that keeps T4000 as the default and permits T5000 only when the required satellite encode load cannot remain camera-side or otherwise exceeds the validated T4000 hybrid budget.

These are narrow specification amendments. The module choice, lab path, and overall architecture do not need redesign.