The architecture of the humanoid robot economy's record layer.
Seven integrated subsystems. One neutral infrastructure. Cryptographically signed. Blockchain anchored. OEM-agnostic. Designed from first principles to serve the five stakeholders of the humanoid robot economy: OEMs, fleet operators, CHRT™ technicians, insurers and lenders, and regulators. This is how it is built.
Four principles. Every subsystem holds to them.
The Robot Health Passport™ is built to serve five different stakeholder groups with opposed incentives. For the platform to be trusted by all of them, four principles govern every design decision, every API surface, and every subsystem.
Not an OEM product. Not a fleet tool. Not an insurer's book. A neutral record layer that all five stakeholders can rely on precisely because no single one of them owns it.
Every service event PKI-signed by a Certified Humanoid Robot Technician and anchored to a distributed ledger block. Tampering is mathematically detectable.
Every automated output that affects capital, including Predictive Failure Alerts and HR IV™ valuations, carries SHAP-based feature attribution. Defensible under actuarial review.
OEM-agnostic from day one. Six normalized telemetry streams map to every platform in the humanoid robot economy. Integration is standardized, not bespoke per OEM.
One record layer, seven moving parts.
The diagram below traces the full data path from humanoid robot hardware, through the seven subsystems, to the five consumer groups who use the signed record to make capital, regulatory, and operational decisions.
A service event, traced end to end.
The best way to understand the architecture is to trace an actual service event through it. Below, a real incident on Sprocket, Unit #000083971, a Gen 3 V3.1 humanoid robot deployed at Crates & Bins in Vernon, California. November 2025. Left ankle actuator thermal event. Caught by the Diagnostic Layer before failure. Eleven steps across all seven subsystems.
Sprocket streams six normalized telemetry channels every 60 seconds: motor torque per actuator, battery cell voltage, thermal profile, IMU drift, vision subsystem health, and network latency. The Telemetry Engine receives the stream from the Gen 3 V3.1 platform API, normalizes the OEM-specific packet format to the unified RobotCare™ schema, and forwards to the Diagnostic Layer.
Left ankle harmonic drive temperature crosses the 95th-percentile threshold of the Gen 3 V3.1 cohort. The Diagnostic Layer computes a SHAP-based feature attribution: primary drivers are cumulative hours (3,847), a 4.2x thermal derivative over the prior 30 minutes, and a known firmware-level vulnerability for left-side actuators. Confidence score: 0.91.
Alert routes simultaneously to Crates & Bins fleet operations (via webhook) and the CHRT™ Credential Directory Interface. The Directory queries the credential registry for technicians with Gen 3 V3.1 tier clearance within a 25-mile radius of Vernon, CA, returns three candidates ranked by proximity, availability, and recent relevant work. Jordan Reyes (CHRT #0004192) accepts dispatch.
Jordan's authenticated session queries RHP Core for Unit #000083971's full signed service history. Returns all prior entries (Registration, First Scheduled Maintenance, Firmware Update v3.1.4) with cryptographic signature chain verified. No tampering detected. Unit's baseline State of Health and prior actuator-side events are visible before Jordan touches the robot.
The AR-Guided Maintenance subsystem loads the OEM-authorized procedure for Gen 3 V3.1 left ankle actuator replacement. Procedure steps are sequenced: Jordan cannot complete step 4 without first completing steps 1 through 3. Every step timestamp, camera frame hash, and torque reading flows back to the system. The procedure is enforceable, not advisory.
Parts Marketplace, triggered by the Diagnostic Layer output at Step 02, pre-ordered left ankle actuator S/N A7-449281 (OEM-certified, Gen 3 V3.1 revision 4) before Jordan arrived on-site. Part ships with cryptographic provenance: factory origin signed, supply chain hash verifiable. Provenance hash binds to the Unit #000083971 record at the moment of installation.
Jordan performs the actuator replacement. Each of the 17 procedural steps is timestamped and PKI-signed with Jordan's CHRT™ credential key. Torque readings from the calibrated hex driver at installation points flow into the record. Total duration: 5 hours 7 minutes. Final load test confirmed within spec.
RHP Core composes a single signed event bundle: incident root cause, diagnostic SHAP output, AR-captured step signatures, OEM part provenance hash, technician CHRT ID and signature, final SoH confirmation. The event is written, SHA-256 hashed, and anchored to distributed ledger Block #4,029,187.
Diagnostic Layer recomputes Sprocket's State of Health trend line using the post-repair telemetry. Sprocket's State of Health stabilizes at 96.4% (vs 93.8% pre-incident trajectory). The fleet-wide root cause (cooling airflow obstruction on this cohort) is flagged for review and shared with Crates & Bins operations.
The HR IV™ algorithm ingests the new signed event and updates Sprocket's valuation. The incident is not a negative signal, it is a positive one: the event was detected, resolved with OEM-grade parts, and attested by a credentialed technician. Bear $42,800, Base $58,400, Bull $71,200. Cohort-relative: above average for units with one resolved incident at 17 months.
Within seconds, robothealthpassport.app/verify/000083971 reflects the new event. An insurer querying the record, a resale buyer validating the history, or a regulator auditing the fleet sees an up-to-date, PKI-verifiable record. The Service Certificate PDF available from the verify page now includes this event.
Seven integrated subsystems, in depth.
Each subsystem below includes what it does (plain language), key responsibilities (for product and integration teams), and a technical reference block (for OEM engineering and security teams). V0 subsystems ship at general availability, Q3 2026. V1 subsystems ship on the next release cycle.
Every humanoid robot generates continuous operational data, but every OEM uses a different format. The Telemetry Engine is the translation layer that turns proprietary OEM telemetry into the unified RobotCare™ schema, one stream structure regardless of platform. Without this subsystem, every downstream component would need 13 different integrations.
The Telemetry Engine also accepts smartphone camera input for visual triage in the field, routing it through AI visual inspection models. CHRT™ technicians without specialized hardware can still capture diagnostic data.
- REST, GraphQL, and WebSocket endpoints for OEM telemetry
- Real-time schema normalization to unified RobotCare™ schema
- Phone-scan visual diagnostic routing
- Rate limiting, deduplication, and source attribution
- Forward valid, normalized streams to the Diagnostic Layer
- MotorTorque / actuator
- BatteryCell voltage + temp
- ThermalFull-body profile
- IMUDrift + accel
- VisionSubsystem health
- NetworkLatency + integrity
Auth: OEM-issued API keys + mTLS
Latency target: < 250ms ingest to normalize
Throughput: 10K events/sec at V0
The Diagnostic Layer is the signal processor. It takes normalized telemetry from the Telemetry Engine and continuously evaluates it against cohort baselines, platform-specific degradation models, and known failure patterns. When anomalies emerge, it fires Predictive Failure Alerts before the unit actually fails.
Every alert carries SHAP-based feature attribution. An insurer underwriting a policy cannot rely on a black-box score. An auditor reviewing a fleet decision cannot accept "because the model said so." Every output is explainable, with feature contributions, confidence intervals, and cohort comparators attached.
- Continuous State of Health trend computation
- Motor torque variance and battery degradation analysis
- Error log pattern recognition against known-failure cohort
- Predictive Failure Alert generation with SHAP / LIME attribution
- Confidence scoring and recommended-action output
unit_id: 9-digit RHP ID
severity: low / medium / high / critical
confidence: 0.0 to 1.0
shap_features: ranked array
recommended_action: structured code
Local explanation: LIME (where applicable)
Cohort comparator: Platform + hours + sector
Required for: All outputs that flow to HR IV™ or alert insurers
Every other subsystem writes to, or reads from, the Robot Health Passport™ Core. It is the central ledger of the humanoid robot economy. One unit, one record, from registration through end-of-service-life. Every event is PKI-signed by the CHRT™ credential responsible, hashed to SHA-256, and anchored to a distributed ledger block.
The Core is the reason the rest of the platform is trustworthy. Without it, a Predictive Failure Alert is advisory, an AR procedure is instructional, and an HR IV™ valuation is estimated. With it, every one of those outputs becomes cryptographically defensible evidence.
- Persistent record per unit from registration onward
- Maintenance history, telemetry snapshots, incident logs
- CHRT™ attestation and parts provenance binding
- PKI signing on every event, block anchoring on event close
- Public verifiable links at robothealthpassport.app/verify
- Role-based access for OEMs, fleets, insurers, regulators
unit_id: 9-digit RHP ID
event_type: registration / service / incident / firmware / calibration
chrt_signer: CHRT ID + pub key
signature: SHA-256 ECDSA
block_anchor: ledger block number
parent_hash: prior event SHA-256
Signing: ECDSA / secp256k1
Anchoring: Distributed ledger
Public verify: Anyone, no account
Retention: Full unit service life + 10 years
A scheduled maintenance procedure written in a PDF manual is advisory. A technician might skip step 4. The AR-Guided Maintenance subsystem runs the same procedure as an enforceable sequence: the overlaid AR instructions on an Apple Vision or Android ARCore device will not advance to step 5 until step 4's required torque reading, visual confirmation, and camera-verified component state are all captured.
This compresses skill threshold (a CHRT Tier 1 technician can execute some Tier 2 procedures) and service time. More importantly, it captures procedure integrity in a way that flows to RHP Core as signed evidence. The service event becomes proof, not a log entry.
- Step-by-step overlaid AR instructions (Apple Vision, Android ARCore)
- Sequenced procedure enforcement with blocker gates
- Per-step timestamping and PKI signing in real time
- Camera-frame hashing and component state verification
- Auto-generation of RHP Core event entries at procedure close
Android: ARCore + major OEM tablets
Enterprise AR: RealWear HMT-1 (hands-free)
Network: LTE fallback + offline queue
timestamp: UTC + device monotonic
camera_hash: Frame SHA-256
sensor_state: Torque + position
chrt_signature: ECDSA per step
When the Diagnostic Layer identifies a failure pattern, two things need to happen in parallel: the right OEM-certified part needs to be in a technician's hands, and the right credentialed technician needs to be dispatched. The OEM Parts Marketplace handles both.
Parts carry cryptographic provenance: factory origin is signed, and the supply chain hash binds to the Unit #000083971 record at installation. Gray-market or counterfeit parts fail provenance verification and are rejected before installation. Technician dispatch is keyed to the CHRT™ Credential Directory: geography, credential tier, platform specialization, and current availability.
- OEM-certified parts catalog across 15 major OEM platforms
- Cryptographic parts provenance at order and install
- SLA-based CHRT™ technician routing and dispatch
- Automated pre-order on Diagnostic Layer alert
- Gray-market rejection at provenance verification
supply_chain: Chained at checkpoints
install_hash: Binding signature to unit
verification: On-site before install proceeds
Credentials: Platform + tier match
SLA tiers: Standard / Expedited / Rush
Availability: Real-time from Directory
A humanoid robot's spec-sheet valuation is what the OEM says the unit can do on day one. The HR IV™ valuation is what that specific unit is worth today, based on verified operational history. The difference between these two numbers is what capital markets need to underwrite, lease, resell, and insure humanoid fleet assets.
The HR IV™ algorithm ingests sixteen input variables from the RHP Core record, computes Bear, Base, and Bull scenario-weighted valuations, and delivers the output as an HR IV™ Report. The methodology is the subject of a US non-provisional patent application (USPTO 2026, Patent Pending). Formal actuarial disclosure ships with general availability Q3 2026.
- 16-variable valuation model with scenario weighting
- Bear / Base / Bull output with confidence intervals
- Degradation curve relative to platform cohort
- Secure API for authorized insurer and lender queries
- Neutral data licensing export at fleet scale
- Formatted HR IV™ Report PDF delivery under NDA
bear / base / bull: USD figures
confidence: Per-scenario interval
cohort_rank: Percentile rank
valid_through: 180 days from issue
Every service event in the RHP Core must be signed by a currently-valid CHRT™ credential. The Credential Directory Interface is the bidirectional real-time link between robothealthpassport.app and chrttechnician.com. When a technician signs an event, their credential is verified; when a new technician passes certification, their credential key is issued and an initial record is created.
The Interface is also how the Parts Marketplace routes dispatch: query the Directory by platform, tier, geography, and availability, receive back a ranked candidate list. This is why the CHRT™ credential must be its own independent public registry: it needs to be auditable, not just usable by internal systems.
- Credential lookup for dispatch eligibility and event signing
- Post-exam results feed for directory updates (Active, Expired, Suspended, tier, sector, location, Service-Ready flag)
- PKI credential key issuance on certification
- Initial RHP record creation for newly-credentialed CHRT™s
- Public lookup API powering chrttechnician.com/verify
Auth: mTLS between services
Latency target: < 50ms credential lookup
Uptime target: 99.95% (signing path)
- ActiveService-Ready
- ActiveIn Training
- SuspendedUnder Review
- ExpiredRenewal Required
- RevokedPermanent
Where each subsystem meets regulation.
Compliance is not an afterthought at the platform edge. Each subsystem aligns to recognized standards during design. This matrix is cited in the compliance section of every HR IV™ Report.
| Standard | Scope | Applies To |
|---|---|---|
| ANSI/A3 R15.06-2025 | Humanoid robot safety standard. Governs operational safety boundaries, risk assessment, and human-robot interaction protocols. | Telemetry Engine Diagnostic Layer AR-Guided Maintenance |
| ISO 13482 | Personal care robots safety requirements. Relevant when humanoid units operate in environments adjacent to humans. | Diagnostic Layer RHP Core (incident logs) |
| EU Machinery Regulation 2023/1230 | Machinery safety and AI governance in operational machinery. Requires explainability and conformity assessment. | Diagnostic Layer (XAI) HR IV™ Valuation Engine |
| GDPR / CCPA / DPA | Data protection and privacy. Governs how fleet operator and technician data is stored, accessed, and shared. | RHP Core CHRT™ Credential Directory All public-facing APIs |
| NIST Cybersecurity Framework | Cybersecurity practices for operational infrastructure. Informs PKI, access control, and audit logging requirements. | All subsystems (baseline) |
| SOC 2 Type II (target) | Service organization controls. Security, availability, processing integrity, confidentiality, privacy. Audit underway for GA. | Full platform |
PKI, anchoring, and isolation.
The security model is structural, not layered-on. Three architectural commitments ensure that what is written to the Robot Health Passport™ is exactly what happened, and cannot be changed after the fact.
Every service event is signed by the CHRT™ technician's ECDSA (secp256k1) key at the moment of capture. Credential keys are issued by the Credential Directory on certification and revocable on credential state change. No event enters RHP Core without a verifiable signature.
Every closed event is hashed (SHA-256) and anchored to a distributed ledger block. Modification detection is mathematical: the parent_hash chain breaks at the point of tampering. Public verification at robothealthpassport.app/verify confirms the chain without requiring account access.
Fleet operator data is logically and cryptographically isolated at the RHP Core level. An authorized insurer querying one fleet cannot observe another. Unit-level public verification is separate from fleet-level analytic access. OEM data access is scoped to their own platforms only.
Architecture questions from OEMs, insurers, and integrators.
Ready to go deeper?
Request an HR IV™ Report sample, verify a live record, or contact the Founder directly for OEM or insurer integration discussions under NDA.