Platform
Architecture
Livemore Bio is infrastructure, not a web app. Three independent services run from the terminal, and every interface (the terminal, the interactive shell, the web console, the Python SDK, the REST API and Jupyter) sees the same twin, cohort, device and evidence identities.

The three services
| System | Port | Role | What runs today |
|---|---|---|---|
| Aegle | 8850 |
Person state and simulation. Also serves the console | Governed twins and frozen cohorts, glucose–insulin and cardiac engines, the whole-human manifest, Atlas and Biology views |
| LIFE | 8851 |
Measurement and data plane | Reference population substrate, the LIFE Patch v2 device contract, the virtual patch, and an encrypted admission journal |
| Cendos | 8852 |
Experiments and evidence | Six reference programs, Human-GEM protocols, immutable protocol runs with CSV and notebook export, and a counterpart and qualification gate |
How the services work together
- The three services find each other through a shared registry at
~/.livemore/registry.json. - They share one authoritative active twin.
- Aegle and LIFE communicate through the virtual-patch session.
- Cendos gets its twin and cohort context from Aegle.
- The same observation contract is ready for the physical LIFE Patch once it exists.
Start, stop and inspect the services with livemore start, livemore stop and livemore status. start and stop accept one or more service names: LIFE, Aegle, Cendos. See the terminal reference.
Where the data lives
The data directory ~/.livemore holds the shared registry, the API token and both LIFE Patch keys, and is kept owner-only at mode 0700. The product enforces owner-only permissions across the registry, execution and evidence stores, protocol runs, model assets, anatomy cache and patch journal. Service logs are written to ~/.livemore/<Service>.log. See security and data protection.
Questions about this page?
Email us