# Power Architecture Draft

## Objective
Define a power system that allows safe battery replacement and modular expansion without uncontrolled resets, unsafe currents, or battery abuse conditions.

## Power Domains
The initial platform should separate at least four domains:

1. `AON`: always-on management domain for MCU, secure element, and wake logic
2. `CORE`: system rail for compute, storage, and memory support logic
3. `PERIPH`: switchable rail for cameras, sensors, and accessory modules
4. `CHARGE`: isolated path for charging and external power negotiation

## Design Principles
- no module powers itself directly onto the shared rail
- all high-current paths must be controller-gated
- battery insertion must be qualified before full coupling
- brownout protection must be hardware-enforced, not only software-managed

## Battery Swap Flow
During battery removal or insertion the sequence should be:

1. detect latch release or seat event
2. move system into guarded power state
3. shed non-critical loads on `PERIPH`
4. maintain `AON` and minimum `CORE` rail using hold-up capacitance
5. qualify new battery voltage, temperature, identity, and polarity
6. connect through protected path
7. restore normal power budget and release throttling

## Hold-Up Strategy
The hold-up network must be sized from measured load, not marketing targets. Initial engineering assumptions:

- preserve `AON` at all times
- preserve `CORE` long enough to avoid reboot during validated battery swaps
- allow temporary shutdown of display brightness, cameras, radios, and charging

This means the user experience during swap may include temporary dimming or disabled peripherals, but not a device reset.

## Power Budget Policy
Each module is admitted based on:

- nominal power budget
- peak power budget
- startup inrush
- thermal coupling constraints
- charging state

When budget is exceeded, the platform should:

1. deny activation of the new module
2. activate with reduced performance
3. shed lower-priority peripherals

## Protection Requirements
- reverse polarity protection
- overcurrent protection per rail
- short-circuit isolation for modules
- thermal trip points at controller level
- battery authentication for trusted power modules

## Telemetry Requirements
The controller and OS should log:

- rail voltage sag events
- overcurrent events
- thermal trips
- swap timing
- module admission or rejection due to budget

## Validation Checklist
1. battery removal under idle load
2. battery removal under peak camera or modem activity
3. repeated insertion with worn contacts
4. unsupported battery module insertion
5. charger plus battery plus peripheral peak-load interaction