# BloxCore Technical Specifications

## 1. Purpose
This document defines a realistic engineering baseline for BloxCore. It distinguishes between:

- MVP requirements that should be engineered now
- aspirational features that require later validation

## 2. System Overview
BloxCore is a modular mobile device platform built around a structural core, a managed module bus, and a software layer that can enumerate and govern replaceable modules.

## 3. MVP Hardware Baseline

### 3.1 Core Chassis
- Dimensions target: `150 mm x 72 mm x 2.5-3.2 mm`
- Materials under evaluation: `Ti-6Al-4V` titanium alloy or `7000-series` aluminum
- Function: structural frame, power distribution spine, alignment reference, and thermal spreader
- Integrated control electronics:
  - always-on management MCU
  - protected power-path controller
  - hold-up capacitor bank sized from measured transient load
  - secure element or root-of-trust device

### 3.2 Module Grid
- Baseline grid concept: `6 x 12`
- Standard unit target: `12 mm x 12 mm`
- Allowed module footprints:
  - `1U x 1U`
  - `2U x 2U`
  - `4U x 4U`
  - custom reserved zones for display, antennas, and service access
- Alignment requirements:
  - blind-mate insertion
  - tolerance budget defined before locking mechanism freeze
  - no electrical energization before physical seating is confirmed

### 3.3 Module Classes
Every module must belong to a class with a specific electrical and software contract:

1. Power modules
2. Compute modules
3. Camera and sensor modules
4. Connectivity modules
5. IO and accessory modules

High-speed modules must not rely on the same electrical assumptions as low-speed control modules.

## 4. Interconnect Architecture

### 4.1 BloxLink Layers
`BloxLink` should be treated as a layered interface, not a single connector claim.

- `Layer 0`: mechanical alignment and lock state
- `Layer 1`: protected power and ground
- `Layer 2`: low-speed management bus for identity, health, and policy
- `Layer 3`: optional data lanes assigned by module class

### 4.2 Connector Policy
The original 4-pin universal connector concept is insufficient for all module types. The updated rule is:

- low-power and identification functions may share a compact pad layout
- high-speed modules require dedicated lanes or localized interposer designs
- power delivery capability must be class-specific, not globally assumed

### 4.3 Initial Targets
- low-speed management bus: deterministic discovery and health reporting
- hot-plug detection latency target: `< 20 ms` from seat confirmation to event publication
- power interruption during battery swap: `0` user-visible reboot events in acceptance tests
- connector lifetime target: `10,000` insertion cycles for standard modules

## 5. Power Architecture

### 5.1 Design Rules
- all modules must declare nominal and peak power draw
- power modules require local protection, temperature telemetry, and authentication
- no newly inserted module is fully powered before negotiation completes
- unsafe modules must be electrically isolated by hardware

### 5.2 Battery Hot-Swap Envelope
Battery hot-swap is allowed in MVP only if the following are proven:

- hold-up network maintains critical rails through measured swap intervals
- system can shed non-critical loads during swap
- battery management survives insertion faults and reverse-current scenarios
- user receives clear state feedback during degraded-power mode

### 5.3 Compute Module Policy
Live compute-module swap is out of MVP scope. Compute modules are replaceable only in powered-down or service mode until memory persistence, bus re-enumeration, and brownout resilience are demonstrated.

## 6. Compute Module
- Candidate architectures: ARM first, RISC-V exploratory only
- Cooling:
  - module-local heat spreader
  - thermal coupling into chassis
  - firmware-managed performance throttling
- Required interfaces:
  - display output
  - storage interface
  - management bus participation
  - secure boot chain

## 7. Display System
- MVP approach: fixed display assembly
- Rationale:
  - simplifies thickness and mechanical stack-up
  - reduces repeated flex-cable stress
  - avoids live display-path renegotiation in early phases
- Candidate panels:
  - `1080p OLED 60-120 Hz`
  - `LTPO` only if power and sourcing justify cost

## 8. Software-Visible Module Descriptor
Each module must expose a descriptor containing:

- vendor ID
- product ID
- module class
- protocol version
- firmware version
- nominal and peak power budget
- thermal limits
- required dependencies
- optional capabilities

This descriptor is required for safe discovery and compatibility enforcement.

## 9. Reliability and Environmental Targets
- ingress resistance claims must be validated at assembled-device level, not assumed from module sealing alone
- contact resistance drift must be measured across wear and contamination conditions
- drop behavior must prioritize user safety and battery integrity over module ejection theatrics
- thermal skin-temperature targets must be defined before chassis material freeze

## 10. Acceptance Tests
The platform is not considered viable without these test groups:

1. Power handover during battery removal and insertion
2. Connector wear and intermittent contact behavior
3. Thermal performance under sustained compute and charging load
4. Recovery from invalid, unsupported, or faulting modules
5. Mechanical retention under shock, vibration, and torsion