Cold start

Context

A two-minute cold start for the Pre system.

canonicalfilesystempre.page.v1

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

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:

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:

/<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:

Markdown -> PageDocument JSON -> one server renderer

Step 1 proves a storage-neutral action protocol:

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:

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

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.
Replace HARnest's inherited whole-ledger checkpoint with independently transacted normalized entities or another conforming HarStore.
Implement the canonical Pre Account and hostname-binding contract in HARnest.
Provision one real account manually with isolated data, a bounded *.pre.bi binding, account-scoped HARnest work, and a complete export.
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.