# BloxCore Development Roadmap

## Guiding Change
The original roadmap moved too quickly from concept to mass production. This revision adds explicit validation gates and treats BloxCore as a hardware-software platform program.

## Phase 0: Feasibility and Scope Freeze
**Duration**: Month 0-2

**Objectives**
- freeze MVP scope
- decide module classes
- define testable success metrics

**Deliverables**
- system block diagram
- initial module descriptor schema
- power architecture draft
- ADR set for MVP boundaries

**Exit Criteria**
- no unresolved contradiction about what is and is not hot-swappable in v1
- electrical and mechanical assumptions documented

## Phase 1: Bench Prototype
**Duration**: Month 2-6

**Objectives**
- validate locking, alignment, connector wear, and low-speed module discovery

**Tasks**
- machine early chassis samples
- build dummy and electrical test modules
- prototype management MCU plus power-path control
- measure contact resistance and insertion-cycle behavior
- validate battery handover on bench loads

**Exit Criteria**
- reliable module detection across repeated insertions
- no unsafe power events during controlled battery swaps
- locking mechanism survives defined mechanical test cycle

## Phase 2: Bring-Up Platform
**Duration**: Month 6-10

**Objectives**
- boot compute module and management stack on real hardware

**Tasks**
- integrate a realistic ARM compute module or SOM
- implement module descriptor parsing and registry
- create Linux-based management daemon
- support one battery module, one camera module, and one IO module class

**Exit Criteria**
- system boots repeatedly on hardware
- module insertion and removal events are observable and logged
- unsupported modules fail safely

## Phase 3: Engineering Validation Prototype
**Duration**: Month 10-15

**Objectives**
- validate thermal, power, and software stability under representative use

**Tasks**
- build integrated EVT units
- run sustained charging plus workload thermal tests
- validate user-visible degraded modes
- test driver restart and recovery flows
- define SDK preview for partners

**Exit Criteria**
- power, thermal, and crash recovery behavior meet acceptance thresholds
- SDK semantics are stable enough for limited external use

## Phase 4: Developer Kit
**Duration**: Month 15-20

**Objectives**
- provide a constrained but real platform to selected partners

**Tasks**
- assemble developer kits
- document module class contracts
- ship diagnostics tooling and sample modules
- gather compatibility feedback from early partners

**Exit Criteria**
- developer kit can be used without direct lab supervision
- module policy and versioning can handle third-party experimentation

## Phase 5: Productization Readiness
**Duration**: Month 20-28

**Objectives**
- determine whether the concept can become a real product

**Tasks**
- certification planning for battery, EMC, RF, and transport
- supply-chain review for chassis, connectors, and batteries
- manufacturability and repairability studies
- costed bill of materials and yield analysis

**Exit Criteria**
- unit economics are understood
- certification blockers are known
- platform reliability is credible beyond prototype conditions

## R&D Backlog
These items remain explicitly out of MVP scope until prior phases succeed:

- live compute-module swapping
- full waterproof consumer claims across all module types
- transparent core materials
- medical or bio-sensing modules
- satellite communications modules