Target platform. The vehicle below is factory-standard and under baseline characterisation — no conversion work has started.
Carry.Haul.Work.
A load-carrying work platform being developed from a factory electric utility vehicle: moving material, hauling equipment, and eventually carrying out repetitive physical work around a property without a person walking alongside it.
Sourced from platform metadata and the engineering log — it changes as the work does.
Derived by traversing the knowledge graph: objective, milestones, active areas, blockers, decisions, and risks. Nothing on this panel is written by hand.
Move material and eventually carry out repetitive work around a property without a person walking alongside it. Utility exists to take on the physical, load-bearing tasks that Scout is deliberately too small to touch.
ERDEN program · Ground platform 02
Next
Later
It is the least-advanced subsystem, and platform readiness is bounded by its weakest part.
Records marked provisional in the registries are carrying part of this platform's definition.
A full review assembled from the graph: readiness, risk, milestone progress, period-over-period change, and recommended next actions. Every conclusion cites the records it was derived from.
ERDEN Utility is concept with overall readiness at early. 6 challenges remain open while the platform works towards "Factory baseline characterised".
Move material and eventually carry out repetitive work around a property without a person walking alongside it. Utility exists to take on the physical, load-bearing tasks that Scout is deliberately too small to touch.
3 engineering areas are open on this platform.
9 hardware records referenced; readiness is early.
10 modules mounted or declared compatible; least-advanced state is planning.
3 of 5 decisions are accepted; 5 remain open.
0 of 12 subsystems are operational.
6 challenges referencing this platform are not complete.
2 log entries recorded; newest is 2026-08-08.
Working towards "Factory baseline characterised"; 0 of 3 milestones are complete.
Next
Later
It is the least-advanced subsystem, and platform readiness is bounded by its weakest part.
No milestone is complete yet.
Overall readiness is early.
1 risk condition derived from the graph, alongside 27 validation findings in scope.
Records marked provisional in the registries are carrying part of this platform's definition.
Clears when the provisional flag is removed from the referenced records and real detail is recorded.
Compared against the preceding 30-day window (2026-06-09 to 2026-07-09). Dates come from the engineering log and the decision registry; records without dates are excluded.
Dated by first appearance in the log.
Dated by first appearance in the log.
Nothing closed in this window.
No module appeared for the first time.
No decision was recorded in this window.
Readiness is derived from current record states. The graph stores no history of those states, so a readiness delta cannot be computed without inventing one.
Open challenges are the platform's declared unknowns; each one holds work behind it.
6 challenges referencing this platform are not yet complete.
Reduces the platform's open-question surface and frees the linked engineering areas to progress.
Decisions that are proposed, revisiting, or missing an outcome leave dependent hardware and modules provisional.
5 decisions linked to this platform are unresolved in the decision registry.
Improves decision completeness, which is one of the five readiness dimensions.
It is the least-advanced subsystem, and platform readiness is bounded by its weakest part.
Derived by the platform brief from milestone, roadmap, subsystem, and blocker state.
Advances the earliest incomplete commitment the platform record holds.
Provisional records carry part of the platform definition without confirmed data behind them.
Records marked provisional in the registries are carrying part of this platform's definition.
Removes provisional flags from the definition and strengthens documentation completeness.
The highest gate stage whose conditions currently hold, with every evaluated condition and the records behind it.
Ready for review passes because Mission and current status are recorded on the platform. 9 hardware records referenced. 2 log entries reference this platform. No validation error is reported in scope.
Live graph conditions. There is no completion state: satisfying a condition removes its item.
37 conditions are currently true in the graph across 5 areas; 6 of them block a gate.
gate conditions
The challenge is concept at research and references this platform.
Clears when: The challenge record's status becomes complete.
The challenge is concept at research and references this platform.
Clears when: The challenge record's status becomes complete.
The challenge is concept at research and references this platform.
Clears when: The challenge record's status becomes complete.
The challenge is concept at research and references this platform.
Clears when: The challenge record's status becomes complete.
The challenge is concept at research and references this platform.
Clears when: The challenge record's status becomes complete.
The challenge is concept at research and references this platform.
Clears when: The challenge record's status becomes complete.
The module record carries no hardwareIds, so nothing in the graph states what it physically needs.
Clears when: The module references at least one hardware record.
The module record carries no hardwareIds, so nothing in the graph states what it physically needs.
Clears when: The module references at least one hardware record.
The module record carries no hardwareIds, so nothing in the graph states what it physically needs.
Clears when: The module references at least one hardware record.
No module in the registry references this hardware record, so its purpose is not expressed as a relationship.
Clears when: A module lists this hardware id, or the hardware record reaches complete.
The module record's engineering state is planning and its lifecycle status is concept.
Clears when: The module record's engineering state reaches operational.
The module record's engineering state is research and its lifecycle status is concept.
Clears when: The module record's engineering state reaches operational.
The module record's engineering state is research and its lifecycle status is concept.
Clears when: The module record's engineering state reaches operational.
The module record's engineering state is research and its lifecycle status is concept.
Clears when: The module record's engineering state reaches operational.
The module record's engineering state is research and its lifecycle status is concept.
Clears when: The module record's engineering state reaches operational.
The module record's engineering state is research and its lifecycle status is concept.
Clears when: The module record's engineering state reaches operational.
The module record's engineering state is research and its lifecycle status is concept.
Clears when: The module record's engineering state reaches operational.
The module record's engineering state is research and its lifecycle status is concept.
Clears when: The module record's engineering state reaches operational.
The module record's engineering state is research and its lifecycle status is concept.
Clears when: The module record's engineering state reaches operational.
The module record's engineering state is research and its lifecycle status is concept.
Clears when: The module record's engineering state reaches operational.
The decision registry holds this decision in a non-final status, so everything downstream of it remains provisional.
Clears when: The decision status becomes accepted or superseded.
The decision registry holds this decision in a non-final status, so everything downstream of it remains provisional.
Clears when: The decision status becomes accepted or superseded.
The decision is settled but the record carries no outcome, so its consequence is not in the graph.
Clears when: An outcome is recorded on the decision.
The decision is settled but the record carries no outcome, so its consequence is not in the graph.
Clears when: An outcome is recorded on the decision.
The decision is settled but the record carries no outcome, so its consequence is not in the graph.
Clears when: An outcome is recorded on the decision.
The record carries a placeholder flag, so part of the platform definition has no confirmed data behind it.
Clears when: The placeholder flag is removed once measured detail replaces it.
The record carries a placeholder flag, so part of the platform definition has no confirmed data behind it.
Clears when: The placeholder flag is removed once measured detail replaces it.
No documentation links are recorded on the platform, so reviews have nothing external to cite.
Clears when: At least one documentation link is recorded on the platform.
The record carries a placeholder flag, so part of the platform definition has no confirmed data behind it.
Clears when: The placeholder flag is removed once measured detail replaces it.
The record carries a placeholder flag, so part of the platform definition has no confirmed data behind it.
Clears when: The placeholder flag is removed once measured detail replaces it.
The record carries a placeholder flag, so part of the platform definition has no confirmed data behind it.
Clears when: The placeholder flag is removed once measured detail replaces it.
The record carries a placeholder flag, so part of the platform definition has no confirmed data behind it.
Clears when: The placeholder flag is removed once measured detail replaces it.
The record carries a placeholder flag, so part of the platform definition has no confirmed data behind it.
Clears when: The placeholder flag is removed once measured detail replaces it.
The record carries a placeholder flag, so part of the platform definition has no confirmed data behind it.
Clears when: The placeholder flag is removed once measured detail replaces it.
The record carries a placeholder flag, so part of the platform definition has no confirmed data behind it.
Clears when: The placeholder flag is removed once measured detail replaces it.
The record carries a placeholder flag, so part of the platform definition has no confirmed data behind it.
Clears when: The placeholder flag is removed once measured detail replaces it.
The record carries a placeholder flag, so part of the platform definition has no confirmed data behind it.
Clears when: The placeholder flag is removed once measured detail replaces it.
The Phase 1 inspection procedure and its derived completion gate. Vendor figures stay vendor figures until a physical observation replaces them.
No finding has been inspected yet. 11 evidence areas are required before drive-by-wire architecture can be argued.
Phase 1 remains open
Required before Phase 2
Across every section
Return visits or better tooling
A recorded result, not a failure
Both values preserved
Every compute, sensing, and actuation power budget starts from the pack. Without chemistry, voltage, capacity, protection, and a measured resting voltage, an auxiliary power architecture cannot be specified.
Missing: Battery chemistry · Nominal voltage · Capacity · Main fuse / breaker and wire gauge · Resting pack voltage · Charger specification
Drive-by-wire cannot be scoped without knowing what the motor is, how it is driven, and how it is mounted.
Missing: Motor identification plate · Drive-wheel arrangement · Motor location · Motor connections
The controller decides whether the drive is commanded, intercepted, or replaced. That choice needs the controller's identity and its connector set.
Missing: Motor controller identification · Motor controller · Battery input to controller · Known vs unknown purpose
The accelerator is the most likely interception point. Its type, wiring, and connector must be documented before any approach is proposed.
Missing: Accelerator / throttle · Conductor / pin counts · Wire colours · Connector locations
Direction selection is a separate command path from speed, and its factory behaviour constrains what a commanded system is allowed to do.
Missing: Forward / reverse selector · Forward / reverse switching
The stop path is the foundation of the safety architecture. A documented "unknown mechanism" is acceptable; an untested one is not.
Missing: Normal stopping behaviour · Behaviour on accelerator release · Behaviour when power is switched off · Braking mechanism conclusion
Actuation cannot be sized without the mechanism, travel, and geometry it must drive.
Missing: Which wheels steer · Steering mechanism · Steering travel · Approximate maximum wheel angle · Linkages and tie rods
Mounting, clearance, payload, and localisation work all depend on a measured vehicle rather than a listing.
Missing: Overall length · Overall width · Wheelbase · Track width — front · Ground clearance · Tyre diameter · Cargo-deck dimensions
Any later safety architecture either preserves or deliberately replaces the factory behaviour, and it cannot do either blind.
Missing: Power-on state · Power-off state · Accelerator release · Restart behaviour · Manual movement with power off
Parts, manuals, and later procurement all hang off the exact model and serial of the machine in front of us.
Missing: Complete product / model designation · Manufacturer labelling · Serial / VIN-equivalent number · Photographic label set
The single diagram is what the drive-by-wire phase is argued against, including its explicit unknowns.
Missing: Power path: battery → protection → controller → motor · Control inputs: accelerator, direction, brake, power/enable · Explicit UNKNOWN labelling
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Currently not inspected.
Direct and reverse dependencies for this platform, with the impact radius reachable through the graph.
Records this one points at
Records pointing back
Longest downstream chain
What the platform physically is today, stated without extrapolation.
The base vehicle is a commercial electric utility cart in factory condition. Nothing has been removed, modified, or added, and no compute, radio, sensing, or steering actuation has been selected — let alone fitted.
Phase 1 is inspection, not conversion. Drive signalling, braking fail-state, steering geometry, and the electrical system are measured and recorded before anything is changed, so every later decision is argued against observed evidence rather than a vendor listing.
The vehicle's mass is what sets the engineering posture. At this scale an uncommanded movement is a physical hazard, so the safety architecture is a prerequisite for commanded motion rather than a later phase.
Active engineering work, stated plainly. Entries stay here until they are genuinely resolved.
The vehicle's 500 W brushless drive is commanded by a factory controller with no published interface. Until the signalling between the accelerator, the direction selector, and the controller is measured, there is no way to say whether autonomy commands the existing controller, intercepts its inputs, or replaces it entirely.
The base vehicle steers mechanically and there is no actuation path. Steering geometry, effort, and travel have not been measured, so the choice between actuating the existing column and replacing the assembly cannot be made honestly yet.
The factory electronic brake's behaviour on power loss, on controller fault, and under command is unknown, as is its holding capability on a slope with payload. On a vehicle rated to carry 660 lb, this is the unknown that keeps the platform stationary.
Battery chemistry, pack voltage, capacity, charging behaviour, and the availability of any auxiliary rail are all unknown. Compute and sensor selection cannot be specified against a power budget that does not exist.
A vehicle of this mass and payload rating needs a layered safety architecture — emergency stop independent of software, defined fail-safe states, speed limiting, and specified behaviour on every detectable fault — before any automated motion is attempted. None of it exists.
The flatbed deck carries no mounting pattern, power provision, or data provision. Until a standardised interface is written down, any implement built for this platform becomes a one-off, which is exactly the outcome the module registry exists to prevent.
Move material and eventually carry out repetitive work around a property without a person walking alongside it. Utility exists to take on the physical, load-bearing tasks that Scout is deliberately too small to touch.
Scout is an observation platform. Most of the work that actually needs doing around a property involves moving something heavy from one place to another, repeatedly, and that is a different vehicle.
Starting from a production utility cart means the load carrying, drivetrain, and durability are already solved at a rated payload we would not reach quickly on our own. The engineering effort goes into control, safety, and autonomy instead.
The vehicle's mass changes the engineering posture. On Scout, an uncommanded movement is a debugging problem; here it is a physical hazard, so the safety architecture is a prerequisite rather than a later phase.
Nothing on this platform has been measured yet. The record exists so characterisation is documented as it happens rather than reconstructed afterwards.
Baseline characterisation and architecture definition. The base vehicle is factory-standard and no conversion work has begun. Drive controller signalling, braking fail-state, steering geometry, and the electrical system are all unmeasured, and no compute, sensing, or actuation hardware has been selected. Every specification below is vendor-published unless stated otherwise.
Factory chassis, deck, and wheels as delivered. Frame geometry, mass distribution, and mounting provisions are uncharacterised.
500 W brushless drive under factory control. No commanded interface exists and the controller signalling has not been measured.
Mechanical steering with no actuation path. Geometry, effort, and travel unmeasured; no actuation approach selected.
Factory electronic brake. Behaviour on power loss, on controller fault, and under command is unknown, as is slope holding under payload.
Pack chemistry, voltage, capacity, charging behaviour, and auxiliary rail availability are all unmeasured. No power budget exists.
No compute hardware selected. Selection follows the power and control-architecture answers rather than preceding them.
No operator link, telemetry path, or remote stop. Expected to reuse Scout's independent-stop boundary, but nothing is specified.
No wheel feedback or position sensing fitted. Pneumatic tyres make rolling radius a measured quantity rather than a constant.
Nothing fitted. Sensing requirements follow from the operating envelope, which has not been defined.
No emergency stop, fail-safe state definition, or speed limiting. This subsystem gates every motion test on the platform.
Deliberately untouched. It depends on drive, steering, braking, safety, and localisation all being real first.
Flatbed deck with no mounting pattern, power, or data provision. A standardised interface has not been written.
Measuring what the factory vehicle actually is: drive and controller signalling, braking behaviour and fail-state, steering geometry, pack chemistry and charging, and mass distribution. Every later decision on this platform is waiting on these numbers.
Deciding how the platform will be commanded — whether autonomy talks to the factory controller, intercepts the operator inputs, or replaces the control electronics — and what the steering and braking paths look like in each case. Nothing is selected; the options are being framed against the baseline measurements.
Establishing what has to be true before a vehicle rated for 660 lb of payload is allowed to move without someone on it: an emergency stop that does not depend on software, defined fail-safe states, speed limiting, and a specified response to every fault the platform can detect.
The vehicle carries material under operator control as delivered from the factory. That is the entire current capability of the platform, and it is not ours.
A measured record of drive signalling, braking behaviour, steering geometry, electrical system, and mass distribution — the document every later decision is argued against.
Speed and direction under software control, with a defined command rate, resolution, and latency.
Actuated steering with position feedback, on an architecture that has not yet been chosen.
A stop that brings the vehicle to rest and holds it without depending on the autonomy computer being healthy.
Driving the platform remotely with telemetry and a supervised stop policy, as the first step away from an operator on the vehicle.
Following a known route across a property with obstacle-aware motion and conservative stopping.
Work attachments mounted against a standardised mechanical, power, and data interface rather than integrated one at a time.
Resolved from the shared hardware registry. Components are defined once and referenced by every platform that uses them.
| Component | Description and specifications | Status |
|---|---|---|
| VEVOR 4-wheel electric utility cartVEVOR | Four-wheel electric utility cart selected as the ERDEN Utility base vehicle. It provides the chassis, drivetrain, cargo bed, battery, and factory control electronics; autonomous conversion has not begun. 51.2 × 25.6 in flatbed cart, 660 lb rated payload, 125.7 lb
Baseline figures are vendor-published. Dimensions, mass distribution, steering geometry, and factory safety behaviour all require first-hand characterisation before any conversion work is specified. | Concept |
| Component | Description and specifications | Status |
|---|---|---|
| 500 W brushless drive systemVEVOR (OEM) | Factory brushless drive system responsible for propulsion on the utility cart. Motor count, gearing, and drive layout have not been confirmed by inspection. 500 W brushless, approx. 5 km/h maximum
No torque, current, or duty figures are published here because none have been measured. | Concept |
| 13 in pneumatic wheel and tyre setVEVOR (OEM) | Factory pneumatic wheels and tyres. Rolling radius, pressure, and traction behaviour on the intended ground types are unmeasured and matter for both odometry and payload work. 13 in pneumatic tyres
| Concept |
| Component | Description and specifications | Status |
|---|---|---|
| OEM motor controllerVEVOR (OEM) | Factory controller between the operator inputs and the brushless drive. Its interface, signalling, and protection behaviour are unknown, which is the central unknown in the drive-by-wire question. Factory controller, interface not established
Whether autonomy commands the factory controller or replaces it is an open architectural decision, not an implementation detail. | Concept |
| OEM accelerator controlVEVOR (OEM) | Operator speed input feeding the factory controller. Signal characteristics are unmeasured; it is the most likely first interception point for a throttle-by-wire path. Operator throttle input, signal unmeasured
| Concept |
| OEM forward / reverse selectorVEVOR (OEM) | Direction selector for the drive system. Direction handling under automated control, including whether direction changes are permitted while moving, is undefined. Two-position direction selector
| Concept |
| OEM electronic brakeVEVOR (OEM) | Factory electronic braking. Its behaviour on power loss, on controller fault, and under command is unknown, and the platform cannot be considered for automated motion until that behaviour is characterised. Factory electronic brake, fail-state unknown
Braking is treated as a safety subsystem on this platform, not a drive convenience. The absence of a characterised fail-state is a blocking unknown. | Concept |
| Component | Description and specifications | Status |
|---|---|---|
| OEM battery systemVEVOR (OEM) | Factory battery system supplying the drive and control electronics, with a battery-level indication on the vehicle. Chemistry, voltage, capacity, and charging behaviour are unknown until characterised. OEM pack, specification not established
Every electrical figure for this platform is an open characterisation item. Nothing about auxiliary power for compute or sensing can be planned until the pack and charging system are measured. | Concept |
| Component | Description and specifications | Status |
|---|---|---|
| Flatbed cargo deckVEVOR (OEM) | Factory flatbed cargo surface. It is the physical starting point for the standardised Utility payload and implement interface, but carries no defined mounting pattern, power, or data provision today. Flatbed cargo deck, 660 lb rated payload
| Concept |
Reusable capability packages compatible with this platform, drawn from the module registry.
Commanded propulsion for the utility platform — speed and direction under software control rather than operator input. Depends entirely on how the factory controller can be commanded or replaced.
Blocked on characterising the factory controller interface. Nothing about command rate, resolution, or latency is known.
Steering actuation for the utility platform. The base vehicle steers mechanically; whether that becomes an actuated column, a replaced assembly, or something else is an open architectural question.
Steering geometry, effort, and travel all unmeasured. No actuation approach selected.
Commanded braking and the independent stop path for a vehicle heavy enough to matter. Treated as a safety subsystem, not a drive function.
The factory brake's behaviour on power loss and on controller fault is unknown, and that unknown blocks every motion test.
Pack characterisation, charging behaviour, and the auxiliary rails that compute, sensing, and actuation would eventually draw from. None of it is established.
Chemistry, voltage, capacity, charge behaviour, and available auxiliary power are all unmeasured.
Onboard computing for control, logging, and later autonomy. No hardware has been selected, because selection follows the power and control-architecture answers rather than preceding them.
No compute hardware chosen. Requirements depend on the drive-by-wire and safety architecture.
The operator link and the telemetry path off the vehicle, including the remote stop that must work independently of onboard software.
Expected to reuse the independent-stop boundary established on Scout, but nothing has been selected or specified.
Position and heading estimation for a wheeled work vehicle on outdoor ground. Nothing is instrumented; the vehicle currently produces no feedback of any kind.
No wheel feedback fitted. Pneumatic tyres make rolling radius a measured quantity, not a constant.
The layered safety architecture the platform needs before it moves without an operator on board: emergency stop, fail-safe states, speed limiting, and a defined behaviour on every fault it can detect.
This module gates the platform. A 660 lb-rated vehicle does not get automated motion tests before its fail-safe behaviour is specified and demonstrated.
Route following and obstacle-aware motion for the work platform. Deliberately last: it depends on every other module in this list being real.
No work has started and none will until drive, steering, braking, safety, and localisation exist.
The documented mechanical, power, and data interface that lets payloads be swapped without platform changes. The dependency every other payload module sits behind.
Specification pending: mounting pattern, power budget, and data bus.
What is running today, what is being integrated, and what is only scoped. Engineering state is stated on every item.
Nothing has been written or installed. The vehicle runs factory control electronics only, and will until the control architecture is decided.
Bench tooling to capture and log the factory control signalling during characterisation. Scoped against the same logging approach used on Scout; not written.
Commanded motion for a heavy wheeled vehicle, including speed limiting and rate limits. Cannot be specified before the controller interface is known.
Fault detection, fail-safe state selection, and enforcement of the stop path. Intended to run independently of any autonomy process.
Vehicle state, power, and fault reporting off the platform, aligned to the same channels used on Scout.
Route execution with obstacle-aware local motion. Not started, and last in sequence by design.
What was chosen, what was rejected, and why.
ERDEN Utility begins as a factory VEVOR four-wheel electric utility cart rather than a purpose-built work platform, so the engineering effort goes into control, safety, and autonomy rather than building a vehicle.
Utility is a load-carrying work platform; Scout remains a small observation and development rover. The two platforms share engineering practice, not a mission.
No control, compute, or sensing hardware is specified for Utility until the factory drive, braking, steering, and electrical systems have been measured first-hand.
No autonomous motion is attempted on Utility until an emergency stop independent of software, defined fail-safe states, and speed limiting are specified and demonstrated.
Implements for the Utility deck are to be built against a written mechanical, power, and data interface rather than mounted individually.
The actual engineering plan, in the order the work has to happen. Later phases are deliberately coarse.
Take the factory vehicle apart on paper before touching it: measure what it is, and write down what it does.
Decide how the platform will be commanded, on evidence rather than preference.
Establish the stop path and fail-safe behaviour before the platform moves under anything but an operator's hand.
Get the operator off the vehicle, with telemetry good enough to explain every run afterwards.
Repeatable routes across real ground with obstacle-aware motion and conservative stopping.
Turn the deck into an interface so work attachments stop being one-offs.
Useful work carried out repeatedly, across sessions, without a specialist present.
Drive signalling, braking behaviour, steering geometry, and the electrical system measured first-hand and written down.
Drive-by-wire, steering actuation, and the safety architecture selected and specified against the measured baseline.
The platform moves under software command with an independent stop demonstrated under fault.
Engineering photography from the bench and the platform itself. Frames are reserved and captioned; images are added as the work is photographed.
Engineering photography for this platform has not been published yet.
Written as the work happens, including the parts that failed.
ERDEN Utility is opened as the second ERDEN platform, starting from a factory VEVOR four-wheel electric utility cart: roughly 51.2 by 25.6 inches, 125.7 lb, rated for 660 lb of payload, driven by a 500 W brushless system to about 5 km/h on 13 inch pneumatic tyres. The vehicle is factory-standard. No conversion work has been done, nothing has been measured first-hand, and every figure recorded so far is vendor-published. The purpose of opening the record now is to have somewhere honest to put the characterisation work as it happens, rather than reconstructing it later.
The Phase 1 characterization procedure is written: twelve sections covering platform identification, physical baseline, drivetrain, the control path and connector inventory, battery and power, steering, braking, factory safety behaviour, an observed electrical architecture diagram, an integration space survey, the payload attachment survey, and the evidence standard that ties them together. Every finding starts at 'not inspected' and carries the source of its value, so vendor figures cannot quietly become verified figures. A derived completion gate reads the findings and reports exactly which evidence is still missing before drive-by-wire architecture can start. No inspection has been performed yet — this is the script, not the result.
