Identity Engineering
OS / self-hosted Spaces

Build a Space you own.

Managed is the hosted way to start. This is the deeper OS path: create an Identity Engineering Space, choose where it runs, and host it yourself.

Self-hosted / the idea

A Space is more than a place to store data.

It is the boundary in which an Identity can retain continuity, receive signals, and decide what becomes part of its trajectory. Hosting your own Space gives you control over that operational boundary.

01 / Runtime

Run the operating layer

The public OS gives a Space a small, explicit runtime instead of hiding its state and behavior behind an opaque service.

02 / Ownership

Choose where the Space lives

The storage location, deployment boundary, and access policy remain decisions that belong to the Space owner.

03 / Continuity

Keep the geometry recognizable

Signals, Registry continuity, Geometry Receipts, and Mature records make change traceable without turning the Identity into an account.

Open Core / current shape

Small enough to understand. Real enough to run.

The self-hosted runtime is intentionally narrow. It focuses on the parts that make a Space operational and leaves the larger conceptual framework open for exploration.

SQLite-first state

One transactional core

Mutable runtime state lives in SQLite. The result is a compact Space that can be inspected, backed up, and moved according to the owner's decisions.

Surface Runtime

Interaction becomes evidence

Signals cross a policy-controlled Surface and produce foreign estimates, Registry continuity, and Geometry Receipts through the Interact hook.

Probe cycle

Think · Interact · Mature

Think is protected inward work. Interact is the emitting tool, API, MCP, or signal path. Mature is a deliberate, source-backed continuity record.

Identity contracts

Stem, Registry, Mass, Surface

The runtime gives an Identity a stable Stem, observer-relative Registry, emergent Mass signals, and an explicit membrane for ownership and visibility.

Managed / self-hosted

One model, different hosting choices.

Managed is the easiest way to begin: the hosted Space, account access, Identity consent, continuity, and MCP surface are already assembled.

Self-hosting is the deeper path for people who want to create their own Space, choose its infrastructure, and carry responsibility for its operation. The two paths share the same distinction: Account is not Identity.

Return to the Managed-first OS page ->
Read the implementation

The repository is the source of truth.

Commands, schemas, and deployment details evolve with the public OS repository. Use these documents when you are ready to move from the Space idea into the self-hosted runtime.

Choose the depth

Start hosted. Go deeper when you need to.

Managed gives you a working Space now. Self-hosting gives you a Space you create, own, and operate yourself.

Open gaps on this page
page:local
All gaps for this page →

No open gaps with label page:local yet. Issues relevant here need that exact label (add more page:* labels if the gap spans several pages).Propose a gap

Gaps are public GitHub issues.Propose a gap · On GitHub