Wirespeed Computing

Help that remembers
what needs doing.

The aim is practical help that knows the context you allow, connects plans with follow-through, and keeps you in control. Your knowledge should stay useful when you change AI tools.

See the everyday purpose ↓

Household OS

Less context to repeat.
More help carrying it forward.

Household OS is being built as a lasting place for household knowledge and work. With permission, it should retain preferences, responsibilities, available resources, and history so people and agents can coordinate without making you pass every detail between them.

Calendar intake is an early piece. The broader direction includes preparing for tomorrow, planning meals and errands, tracking maintenance, and following through on events.

The useful result might be an answer, a calendar entry, a task, a reminder, or a request for approval. Sometimes it should be silence.

Working foundations

Demonstrated pieces.

Persistent knowledge and evidence, assisted calendar intake, and a public delivery reconciler with stable IDs, receipts, and retries. Display integration is experimental.

These pieces do not establish a continuously running service or finished consumer product.

Being built

Make it repeatable.

Setup that can be repeated, routine reconciliation, preparation linked to events, and execution governed by explicit permissions and review.

Longer-term direction

Help at the right moment.

Contextual proactive assistance, overnight preparation, and authorized actions across replaceable tools. Meal ordering, device control, and full household automation are not delivered.

Read the Household OS project ↗

Synthetic example

A school notice should become
something you can act on.

Imagine a notice about a school trip. It includes the date, what to bring, and a permission deadline. This illustrates the intended experience, not a working end-to-end service.

  1. Working building block

    Keep the source with the dates.

    Assisted intake can turn a notice into event information while retaining its context. Fully repeatable, low-input intake is still being built.

  2. Public implementation

    Put the event where it belongs.

    The calendar-delivery reconciler uses stable IDs, records receipts, and supports retries. Those records do not prove that a service runs continuously.

  3. Being built

    Connect preparation to the event.

    The intended next step is to turn “bring a packed lunch” into preparation work and a useful reminder, with responsibility made clear.

  4. Longer-term direction

    Ask before consequential action.

    Submitting a form, ordering something, or acting through a device would require appropriate authority and approval. These actions are not delivered here.

Read the calendar implementation notes ↗

Business use / Sovereign Vault

The same need for continuity,
with different permissions.

A business also needs decisions to stay connected to their evidence and ongoing work. Sovereign Vault explores that setting with its own data, roles, and permissions.

Household and business applications are peers. Each should adapt the shared foundations to its own needs without mixing their records or authority.

Read the business project ↗

Sovereign Memory Protocol / Public draft

Keep authority over
the information.

Sovereign Memory Protocol (SMP) is the original foundation of this work: keeping authority over your information and preserving where it came from, how it changed, and what supports it when tools or providers change.

It is being developed as shared rules that different systems can implement. Those rules cover provenance, custody, authority, integrity, and portability without requiring PostgreSQL or a particular provider. The public draft remains under development; it does not establish complete implementation conformance.

Read the SMP protocol repository ↗

The protocol repository defines the draft rules. For Core’s separate implementation results, read the v0.3-alpha release evidence.

Discuss protocol work ↗

How the pieces fit

  • SMPShared meaning and rules, independent of an implementation.
  • Sovereign Memory CoreThe PostgreSQL reference implementation and its bounded evidence.
  • Supabase User MCPPrivate-alpha testing of bounded data access, including Cursor and Claude Code CLI.
  • Household OS & Sovereign VaultPeer applications for household and business work, each with its own data and permissions.

These are complementary roles, not a mandatory installation sequence. Applications can use appropriate implementations and access paths while keeping their own policy boundaries.

Development update · September 8, 2026

User-scoped reads tested with two AI clients.

A separate Supabase User MCP private-alpha candidate passed controlled tests with Cursor and Claude Code CLI: permitted reads, denied cross-user access, revocation and recovery. The public baseline remains local and read-only.

Broader application permissions and independent security review are next. This is not a public beta or production service.

Read the results and limits ↗

Development blog

Why this work starts
with continuity.

What this site will document ↗

How useful everyday help connects to user-owned knowledge, evidence, and the ability to change tools.

Read the introduction

Get involved

Review a design or propose a focused change.

Collaboration & support ↗