Step 8 — Target-specific Product translation
BlockedProduct converts the accepted target into bounded requirements without changing Science claim states. It freezes intended information routes, accepted source classes, functional states, common versus person-specific responsibilities, lifecycle expectations, exclusions, safe-state semantics, and the matched comparator obligation.
Completion condition: exact target tuple, Product translation, applicable Legal/Ethics review, fresh QA, Integrator acceptance, and explicit founder authority for the next bounded scope.
Step 9 — R0 technical inputs and synthetic reference vectors
BlockedBackend proposes the concrete choices needed to implement a local deterministic simulator. Science separately defines and accepts synthetic reference vectors that test route identity, artifact, provenance, invalidity, calibration, command, acknowledgement, and fail-closed behavior without pretending the records are biological measurements.
Completion condition: all ten technology decisions selected and accepted; exact synthetic vectors accepted by Science; no dependency or implementation begins before authorization.
Step 10 — R0 software-only simulator
BlockedR0 is an isolated, offline, non-actuating software system. It processes only accepted synthetic records, preserves source and route identity, rejects ambiguous or invalid inputs, executes deterministically, denies network and device access, and produces append-only auditable outputs.
What it may prove: conformance to its frozen software contract. What it cannot prove: neural detection, stimulation delivery, biological validity, chronic stability, safety, efficacy, feasibility, selectivity, encoding, or comparator advantage.
Step 11 — R0 verification and kill decision
BlockedIndependent verification must cover golden vectors, negative vectors, deterministic replay, serialization identity, resource limits, path containment, device/network denial, audit-chain integrity, crash and cancellation behavior, state priority, stale calibration, provenance loss, aliasing, and command inhibition.
Completion condition: frozen implementation, executable test matrix, reproduced results, Independent QA, Integrator acceptance, and a decision to stop, correct, or consider R1.
Step 12 — New non-biological R1 gate
DeferredThe rejected R1_BENCH_V1 is not a shortcut. A new R1 question may be opened only if accepted R0 evidence shows a non-biological bench can answer a specific remaining engineering question and the founder explicitly authorizes that scope.
Kill condition: if simulation already answers the question, or the bench would imply unsupported biological behavior, do not create R1.
Step 13 — R1 engineering package
BlockedA legitimate R1 package would require selected non-biological functions, official component datasheets, calculations and uncertainty budgets, interface contracts, power and signal containment, native editable CAD/EDA, bill of materials, fixtures, passive loads or phantoms, test points, configuration control, and a verification plan. No anatomy, implant geometry, biological stimulation prescription, or surgical design belongs here.
Blueprint gate: only exact accepted inputs, native sources, calculations, and executable verification can justify the term “engineering blueprint” for R0 or a strictly non-biological R1.
Step 14 — R1 construction and verification
UnauthorizedPurchasing, assembly, energizing, and testing require separate authorization after the engineering package and its QA close. Results must remain limited to the passive non-biological bench. Failures, rework, substitutions, calibration, and uncertainty stay in the evidence record.
Limit: a passing electronics bench does not establish compatibility with a nerve, tissue, person, implant, or clinical use.