lower-bound-review

# lower-bound-review — delete layers before adding them Run this before proposing architectural machinery. ## Step 1 — read what is already decided Check: - `docs/CONSTRAINTS.md` - `docs/RESEARCH-INDEX.md` - `docs/PROJECTS.md` - target repo `.project.toml` - target repo `AGENTS.md` Do not repeat prior-art research already indexed unless: - new evidence exists - a relevant standard/project materially changed - the requirement changed - measurements contradict the previous conclusion Record the changed assumption when reopening a conclusion. ## Step 2 — identify the primitive State the desired invariant without implementation vocabulary. Bad: ``` we need an io_uring-like ring ``` Better: ``` nothing may become observably complete before durability is established ``` Then ask whether CPU, cache coherence, DRAM, BSD VM/DMA APIs, filesystem, storage controller, or existing permissive IP already owns it. ## Step 3 — lowest owner Prefer the lowest layer that can own the primitive once. Existing ownership includes: - work/run identity -> BOP - execution -> Moth - runtime/OS/storage research -> smolFire - build/deploy/receipts -> Genoa - policy/workflow -> Skills - UI/control -> VibeCode - durable history/version -> filesystem or lower durable primitive - observation -> Datadog - lineage -> OpenLineage projection ## Step 4 — free primitives inventory Before custom hardware, explicitly inventory what comes for free: CPU/SoC: - atomics - cache coherence - memory barriers - L1/L2 - DRAM - vector execution where available - DMA engines - MMU/IOMMU or capability mechanisms BSD: - mmap/shared memory - bus_dma synchronization - kqueue/AIO where relevant - filesystem durability/history primitives - device mappings Use these before inventing another coherence, queue, DMA, or notification layer. ## Step 5 — ARM/CPU vs FPGA CPU/BSD by default: - policy - branch-heavy logic - orchestration - filesystems - recovery strategy - diagnostics - crypto/PQC initially - bulk/vector work - rapidly changing code FPGA by exception: - small deterministic invariant - high-frequency fixed function - independent trusted state - completion gating - anti-replay/epoch - measured operation that benefits from hard real-time/determinism The FPGA must earn each function. ## Step 6 — trust/storage questions Apply storage-controller and TEE thinking: - what exactly is durable? - who can lie about completion? - can stale state replay? - what survives reset/power loss? - what is immutable? - what is independently measurable? - can the host forge trusted evidence? ## Step 7 — licensing/platform gate Target architecture: - no Linux dependency - prefer FreeBSD/NetBSD/DragonFly/OpenBSD/bare-metal as appropriate - project/dependency preference: MIT/BSD/Apache - reject GPL/LGPL/AGPL dependencies for new core work unless explicitly approved Linux projects may be comparative prior art, not target architecture. ## Step 8 — proposal must delete something Every new architectural layer must answer: 1. What invariant does it uniquely own? 2. Why can't an existing lower layer own it? 3. What duplicated state/layer does it remove? 4. What happens if we do nothing? 5. Can the same experiment be modeled in JS first? 6. Can pure RTL test it before adding RISC-V? 7. What measurement would cause us to delete this proposal? If it only adds another representation of existing truth, reject it. ## Step 9 — preferred experiment order ``` small semantic model -> JS exhaustive/fault model -> formal specification -> native software control -> pure RTL -> FPGA -> optional CPU/RISC-V control plane -> ASIC only if measured advantage ``` ## Output format for reviews Return: ``` Primitive: Existing lower-layer support: Novel missing invariant: Canonical owner: JS model: FPGA minimum: What stays on CPU/BSD: What this deletes: Prior art already checked: New evidence, if any: Measurement / kill criterion: ``` Keep the answer concrete and short.