---
title: "Context"
description: "A two-minute cold start for the Pre system."
navLabel: "Context"
order: 10
nav: true
eyebrow: "Cold start"
status: "canonical"
theme: "main"
visibility: "public"
---

## Thesis

Pre is a user-governed continuity layer for identity, records, knowledge, relationships, and agency across devices, vendors, interfaces, models, and time.

Models and compute are replaceable substrates. Durable identity, authority, context, evidence, unfinished work, and succession live outside any individual execution.

## Canonical distinctions

- **Pre Foundation** is the Missouri 501(c)(3) parent.
- **Pre BI LLC** is Pre Foundation's wholly owned program-service subsidiary.
- **Pre** is the integrated institution and system.
- **`pre.bi`** is the canonical network namespace.
- **A Pre Account** is the durable custody, authority, billing, export, and succession boundary for a person, family, organization, archive, community, or separately governed initiative.
- **A `*.pre.bi` hostname** is a reversible network binding to an account, not identity or authority by itself.
- **Mbuyu** is Pre's Burundi-based preservation lighthouse.

## Functional layers

```text
Pre            identity, custody, provenance, authority, respect
Pre Account    governed record, authority, billing, and export boundary
Presertion     durable knowledge and evidence
HARnest        durable agency and coordination
Har            realtime relational membrane
Stow           browser/local encounter and holonization
pre CLI        shell and local participant interface
*.pre.bi       network bindings and public/private projections
```

## Account and surface model

The canonical account uses a stable opaque address:

```text
account:<stable-id>
```

A readable hostname such as `organization.pre.bi` resolves through an admitted external binding. The hostname may select an account candidate, but it grants no membership, disclosure, or action authority.

An account may produce several purpose-specific surfaces:

```text
/<root>       public or member presence
/inbox        relationship-centered communications
/records      Presertion knowledge, evidence, and chronology
/work         HARnest tasks, approvals, evidence, receipts, and handoffs
/people       people, organizations, and relationships
/files        artifacts, renditions, provenance, and custody
/settings     membership, transports, retention, usage, billing, and export
```

These are projections over one governed relational world, not separate CMS and application truths. Data may remain distributed across encrypted object storage, relational stores, local devices, and external providers while the authorized account view remains coherent.

## The execution model

The execution edge may be stateless; the world is not.

A model, function, browser session, controller, or CLI invocation may appear, identify itself, retrieve bounded context, perform an authorized action, leave events, evidence, a result, and a receipt, then disappear. The participant and its obligations may remain.

Every customer, family, or organization action must resolve account scope before reading or mutating account-owned state. Cross-account access requires an explicit context grant or capability.

## What exists now

Step 0 proves a dynamic surface projection:

```text
Markdown -> PageDocument JSON -> one server renderer
```

Step 1 proves a storage-neutral action protocol:

```text
ActionEnvelope
  -> trusted identity and authority resolution
  -> bounded execution
  -> ordered events and evidence
  -> optional objective verdict
  -> ResultEnvelope + immutable receipt
  -> reconstruction or exact replay
```

Step 2 implements that protocol in HARnest:

```text
human or controller action
  -> HARnest domain transition
  -> canonical Pre request and receipt
  -> request-scoped Instant protocol records
  -> local bounded repository evidence
  -> optional evanescent model synthesis
  -> operator-controlled objective verdict
  -> reconstruction and export
```

The HARnest product source of truth is `prepace/harnest:main`. HARnest pins the canonical protocol in `prepace/main:main` by repository, commit, and schema and fixture blob identity.

The model selected for one synthesis invocation is not the participant. The persistent participant is `agent:pre:repo-auditor-01`; gateway, model, provider, usage, and cost are execution metadata.

The first HARnest handoff is explicitly account-unbound. It distinguishes implementation provenance from workspace, room, task, and run scope without pretending that a customer account or `*.pre.bi` binding already exists.

## Current focus

1. Finish Step 2G operational acceptance with one live Instant-backed task, a two-controller claim race, a deliberate controller restart, evidence-linked operator verdict, and protocol export and reconstruction.
2. Replace HARnest's inherited whole-ledger checkpoint with independently transacted normalized entities or another conforming HarStore.
3. Implement the canonical Pre Account and hostname-binding contract in HARnest.
4. Provision one real account manually with isolated data, a bounded `*.pre.bi` binding, account-scoped HARnest work, and a complete export.
5. Use paid account activation and implementation work to validate the product before public self-service or shared multi-tenancy.

The Pre CLI, Linear, unified communications, Stow, and Presertion integrations remain important, but none should displace the first complete account holon or its operational acceptance.

## Read next

- [Status](/status) for observed reality.
- [Principles](/principles) for the normative foundation.
- [Architecture](/architecture) for boundaries.
- [Protocol](/protocol) for the canonical contracts.
- [Security](/security) for authority and trust rules.
- [Decisions](/decisions) for the account and binding decision.
- [Learnings](/learnings) for implementation pivots.
- [Roadmap](/roadmap) for implementation order.