PIOS & Personal Core Infrastructure
Building an open framework for owner-controlled personal information infrastructure, agent context, event truth, and portable Core setup paths.
PIOS 2.0 is the public framework work behind peecos: a model for giving a person a durable information Core that can preserve sources, record canonical events, maintain structured knowledge, support retrieval, and let agents operate under governance instead of scattered application memory.
This is open framework work. It is separate from my own private implementation and migration details, but it grows from the same practical question: what does a personal AI system need underneath it to become useful, auditable, portable, and owner-controlled over time?
Sibling framework
Entity Core and EIOS are the organization-scale sibling to this work. Where PIOS centers on a person and an owner-controlled personal Core, EIOS centers on an entity and a governed organizational memory layer: preserved originals, event truth, operating context, and agent-ready governance for teams and institutions.
Problem / opportunity
Most personal AI setups depend on fragmented app state, chat histories, ad hoc notes, or model-side memory. That can be useful in the moment, but it is weak as a long-term foundation: sources are hard to trace, ownership is unclear, retrieval is inconsistent, and moving to another tool or provider becomes painful.
PIOS reframes the problem around the owner. The Core is not one app's database. It is the owner's durable information foundation, with applications, agents, and interfaces operating around it.
What the system does
The PIOS model defines how personal information can be captured, preserved, organized, interpreted, retrieved, shared, exported, and moved without becoming dependent on any one application, cloud provider, database, or agent runtime.
- Preserved originals for source truth
- Append-only event logs for what happened
- Knowledge projections and summaries for retrieval
- History surfaces for time-zoomable continuity
- Cotton as the context model for personal meaning and classification
- Governance gates for sensitivity, approval, correction, and migration
- AWS and self-hosted setup paths for portable Core deployment
My role
I created and developed the PIOS 2.0 framework, the Cotton context model, the peecos public structure, and the current open setup paths. The work combines product architecture, UX thinking, personal AI system design, documentation, implementation planning, governance, and agent-assisted development.
Product / UX perspective
The owner should not need to understand every technical layer to benefit from a personal Core. The product logic is about clear boundaries: what is source truth, what is a projection, what an agent may do, what requires approval, and how the owner can inspect, export, or move the system.
This makes the system easier to explain to people and easier for agents to operate without improvising new rules.
AI / architecture perspective
PIOS treats retrieval, provenance, event history, knowledge structure, and agent governance as first-class architecture. The goal is not to make a folder of files feel like memory. The goal is to create a structure where useful memory-like behavior can emerge from preserved sources, events, summaries, indexes, and correction paths.
Public repositories
peecos/pios
PIOS 2.0 master documentation and framework reference.
pios-core-aws-template
Template-driven setup path for creating a one-owner PIOS Core in the owner's AWS environment.
pios-core-self-hosted
Self-hosted VM template and release tooling for owner-controlled Core setup outside the AWS-native path.
peecos-web
Public website and orientation layer for the open framework.
Key design lessons
- Personal AI needs an information foundation, not only a conversational interface.
- Projection surfaces are useful, but they should not silently become source truth.
- Event logs, source preservation, and summary-first retrieval make agent work more auditable.
- Owner control requires export, deletion, sharing boundaries, and migration paths to be designed in from the start.
- Open framework work becomes more useful when it includes practical setup paths, not only concepts.
Status
PIOS 2.0 and peecos are public as open framework work. The AWS path is a self-setup template, not a hosted account service. The self-hosted path currently provides a signed arm64 release candidate and provider-readiness documentation. Full hosted service operation is outside this open framework release.