Open decisions and required metrics
Tracks unresolved numerical targets, reference choices, benchmark thresholds, and evidence needed before implementation commitments.
Section relationships
These open items must be resolved before the associated requirement can be accepted. Candidate values are starting points, not commitments. Stable IDs for resolved cross-cutting decisions are retained after the open table with their selected value and rationale.
| ID | Decision or metric | Candidate starting point |
|---|---|---|
| TBD-REFERENCE-ROVER | Reference digital rover definition | Select a versioned, redistributable or reproducibly obtainable rover model with documented geometry, mass properties, drivetrain, sensors, controller interfaces, provenance, and license; a physical counterpart is optional. |
| TBD-REFERENCE-MISSION | Reference digital mission | Select a versioned digital outdoor mission with slope, stopping, turning, payload, dry/wet surface, and wind cases; optional independent datasets may map to a documented subset of conditions. |
| TBD-REFERENCE-MOTOR | Reference drivetrain motor family | Select brushed DC or behavioral BLDC using the reference model and available analytical, published, manufacturer, community, or independent evidence before fixing the MVP motor equations. |
| TBD-DESIGN-VARIABLES | Modeled pilot design choices | Gear ratio, motor, battery, payload, wheel or tire parameters, controller gains, and sensor quality. |
| TBD-OBSERVABLES | Required reference observables | Simulation outputs and optional evidence-comparison observables: pose/trajectory, speed, slip onset, stopping distance, stability margin, torque, current, voltage, energy, and temperature where modeled. |
| TBD-EVIDENCE-CORPUS | Reference qualification evidence | Select the mandatory analytical and digital benchmark sources plus any applicable optional standard, published, manufacturer, community, independent-reference, or physical sources; record provenance, licenses or access terms, conditions, supported claim classes, and the explicit absence of unavailable evidence classes. |
| TBD-PORT-MATRIX | Supported MVP systems | Candidate: Linux x86-64 and macOS arm64; Windows x86-64 in beta. |
| TBD-PERF-HARDWARE | Performance reference machine | Name exact CPU, core count, memory, OS, compiler, power profile, and optional GPU. |
| TBD-PERF-RTF | Reference interactive real-time factor | Candidate: at least 1.0x with the MVP sensor set. |
| TBD-PERF-HEADLESS | Reference headless throughput | Define simulated seconds and controller steps per wall second. |
| TBD-PERF-START | Startup budget | Candidate: under 3 seconds after warm filesystem cache. |
| TBD-PERF-MEM | Reference memory budget | Candidate: under 2 GiB peak resident memory. |
| TBD-PERF-TRACE | Default telemetry overhead | Candidate: no more than 10%. |
| TBD-PERF-SCALE | Independent-world scaling | Define efficiency at 1, 2, 4, 8, and 16 workers. |
| TBD-PERF-ENV-MEM | Memory per additional world | Measure after model and immutable asset sharing design is known. |
| TBD-PERF-SENSOR | Bulk sensor throughput | Define after MVP camera and LiDAR scope is fixed; not an MVP gate if those sensors remain beta. |
| TBD-PERF-REGRESSION | Automatic performance gate | Candidate: 5% regression in stable benchmark medians. |
| TBD-PILOT-COUNT | Independent pilot participation | Select the number and robot-domain mix of independent roboticists or teams required for Beta acceptance. |
| TBD-PILOT-TIME | Pilot completion budget | Define the maximum elapsed effort from installation through a documented design comparison. |
| TBD-PILOT-HELP | Pilot assistance budget | Define permitted documentation, support interactions, and developer intervention for an accepted pilot. |
| TBD-REL-ENDURANCE | Endurance workload | Candidate: 10 million kernel steps and repeated reset cycles without invalid state or growth. |
| TBD-REPRO-CRITERION | Portable reproducibility | Candidate: bitwise on the same release binary and platform; tolerance-based across approved platforms. |
| TBD-TRAJECTORY-ERROR | Optional trajectory-evidence criterion | Before any trajectory-accuracy claim, define evidence provenance, conditions, alignment, metric, and envelope; otherwise mark the capability unqualified. |
| TBD-ELECTRICAL-ERROR | Optional electrical-evidence criterion | Before any current, voltage, or energy-accuracy claim, define evidence provenance, conditions, measures, and envelopes; otherwise mark the capability unqualified. |
| TBD-STABILITY-ERROR | Optional stability-evidence criterion | Before any stability-accuracy claim, define tip-over, slip-onset, and stopping-distance events, evidence, conditions, measures, and envelopes separately; otherwise mark the capability unqualified. |
| TBD-VAL-ANALYTICAL | Analytical benchmark criteria | Approve versioned analytic cases, compared observables, tolerances, precision, and pass aggregation before implementation. |
| TBD-VAL-CONTACT | Contact benchmark criteria | Approve versioned restitution, incline, stack, penetration, friction, and repeatability cases with per-observable tolerances. |
| TBD-VAL-JOINT | Joint benchmark criteria | Approve versioned kinematic, limit, drive, drift, and articulated-chain cases with per-observable tolerances. |
| TBD-VAL-DEVICE | Device benchmark criteria | Approve versioned motor, transmission, battery, power, saturation, and latency cases with per-observable tolerances. |
| TBD-VAL-SENSOR | Sensor benchmark criteria | Approve deterministic and statistical procedures, sample counts, seeds, and tolerances for each MVP sensor stage. |
| TBD-VAL-WEATHER | Weather benchmark criteria | Approve field, wind-load, wet-friction, and rain-degraded range-sensor cases with per-observable tolerances. |
| TBD-VAL-CONVERGENCE | Convergence criteria | Approve observables, timestep sequence, solver settings, expected order or plateau rule, and pass statistic. |
| TBD-IMPORT-CORPUS | Asset compatibility corpus | Select representative URDF and SDFormat assets and required element coverage. |
| TBD-SCENE-SCALE | Supported MVP scene size | Define bodies, joints, colliders, contacts, sensors, telemetry channels, and trace rate. |
| TBD-API-DEPRECATION | API and schema deprecation window | Candidate: two minor releases or six months, whichever is longer. |
| TBD-HIL-SAFETY | HIL qualification criteria | Define supported hardware, latency, jitter, watchdog, E-stop, and output-energy limits before implementation. |
| TBD-BETA-REGRESSION-SUITE | General Robotics Beta user-regression fixture | Approve versioned rover and manipulator cases, declarative assertion classes, expected-baseline identities, stochastic seed and repetition policy, pass aggregation, machine-report expectations, and an intentional divergence that the suite must detect. |
| TBD-VAL-DYNAMIC-ANALYSIS | Dynamic-analysis qualification criteria | Approve reference mechanisms, coordinate conventions, smooth and constrained regimes, compared mass, force, inverse-dynamics, derivative, linear-prediction, and identifiability quantities, perturbation sequences, tolerances, conditioning thresholds, and pass aggregation. |
Change rationale (TBD-REFERENCE-ROVER, TBD-REFERENCE-MISSION, TBD-REFERENCE-MOTOR, TBD-DESIGN-VARIABLES, TBD-OBSERVABLES, TBD-EVIDENCE-CORPUS, TBD-TRAJECTORY-ERROR, TBD-ELECTRICAL-ERROR, TBD-STABILITY-ERROR): The reference program now selects a distributable digital rover and qualification corpus rather than an instrumented in-house counterpart. Accuracy criteria become conditional on adopted independent evidence; absent evidence is disclosed as unqualified rather than creating an implicit physical-testing obligation.
Change rationale (TBD-BETA-REGRESSION-SUITE, TBD-VAL-DYNAMIC-ANALYSIS): The v0.4 Beta gates require concrete fixtures, observables, stochastic policy, numerical procedures, and pass aggregation. These rows expose those decisions without silently converting candidate cases or tolerances into approved commitments.
Resolved architecture decisions
| ID | Resolution |
|---|---|
TBD-CANONICAL-IDENTITY | Resolved on 2026-08-06 by accepted ADR-0003: canonical logical identity classes are distinct typed ProjectId, DocumentId, DefinitionId, EntityId, FrameId, ParameterId, PortId, and AssetId values with canonical lowercase RFC 9562 UUID spelling; authored, copy/fork, and plan-declared spawn identities use UUIDv4; fresh imported object identities use the accepted domain-separated JCS/SHA-256 UUIDv8 profile; persisted allocation/source mappings govern reimport; collisions fail; and retired IDs are not silently reused. |
TBD-CANONICAL-FRAMES | Resolved on 2026-08-06 by accepted ADR-0004: canonical frames are right-handed; the canonical robot base uses +X forward, +Y left, and +Z up; a georeferenced local world uses ENU; a non-georeferenced world declares its horizontal basis, origin, and yaw provenance; T_parent_from_child maps child coordinates into the parent; and named Hamilton {w, x, y, z} quaternions and typed spatial values follow the accepted direction. |
TBD-CANONICAL-CONTENT-IDENTITY | Resolved on 2026-08-06 by accepted ADR-0005: semantic identity uses closed schema-owned projections over validated, default-materialized, SI-normalized, frame-explicit logical data; exact binary64 and Unicode rules; versioned RFC 8785 JCS/SHA-256 domain separation; distinct closed raw-byte, semantic-content, and tagged identity records; and a self-verifying derived-artifact identity whose descriptor binds schema, producer, ordered typed inputs, options, target capabilities, and payload identity. |
TBD-NUMERIC-REPRESENTATION | Resolved on 2026-08-06 by accepted ADR-0006: ordinary canonical continuous values use validated finite IEEE 754 binary64 and fixed-shape collections of it; full-range ticks, steps, order values, seeds, revisions, and counters use typed u64 domains with one canonical decimal-string JSON spelling when persisted; bounded smaller exact fields may use schema-typed integers; dimensions and other exact ratios use canonical reduced rationals; authoritative virtual time uses integer ticks under a positive reduced rational SI-second time base; UUIDs and SHA-256 digests remain typed non-numeric domains; source lexical/unit/conversion context remains distinct from canonical and compute representation; every alternate precision conversion is explicit and diagnosed; and higher precision is a versioned opt-in capability rather than a Portable MVP default. |
Change rationale (TBD-CANONICAL-IDENTITY, TBD-CANONICAL-FRAMES, TBD-CANONICAL-CONTENT-IDENTITY, TBD-NUMERIC-REPRESENTATION): ADR-0003 resolves the logical-ID taxonomy and allocation rules because names, paths, content hashes, and backend handles cannot preserve engineering identity through edits, imports, or backend replacement. ADR-0004 resolves the spatial convention because silent differences in handedness, ENU/NED, transform direction, quaternion ordering, and body or optical axes can produce plausible but incorrect results. ADR-0005 resolves content equivalence because byte equality, logical identity, normalized meaning, and derivation context require distinct typed contracts. ADR-0006 resolves numeric categories because continuous approximations, exact discrete values, clocks, ratios, identities, digests, source spellings, and solver compute profiles cannot safely share one floating representation. These accepted directions constrain the still-draft normative designs; they do not approve schemas, arithmetic implementations, dependencies, or product code.
Generated from the canonical specification. Edit section metadata or prose in docs/requirements.md; the website rebuilds this page and its relationships automatically.