W/Wirespeed ComputingBuilding in publicFollow the build ↗
Menu
What works / everyday life

Less to remember.
More to get on with.

The school day changes. Lunch needs sorting. The spare room is still half finished. Useful AI should help you pick up the thread—and carry it forward.

We already use Wirespeed’s foundations to keep household knowledge, school and lunch records, project work, and calendar delivery history. These four fictional stories show what that makes possible, what we have checked, and the connections we are building next.

Kids’ schedules / fictional household example

Early pickup. Fewer last-minute surprises.

A school-day change should reach the plan before it reaches your afternoon.

It is Friday. School finishes at 12:30, but the familiar 3:15 pickup time is still the one in your head. There is also an appointment that afternoon. The difficult part is carrying the change from a notice into the rest of the day.

In this fictional example, the accepted school event keeps the new time and the notice together. Its managed calendar copy can be updated without creating a second, competing pickup. You can return to the source when someone asks what changed.

Fictional household record

Friday · Early dismissal

Was
Pickup at 3:15 p.m.
Accepted update
Pickup at 12:30 p.m.
Keep with it
The revised school notice
Next question
Who can cover the earlier pickup?

Illustration of a record and delivery pattern; this is not a live calendar.

Used in our setup

School records and calendar delivery are already foundations.

Our household setup contains active school-event records and recorded delivery outcomes. The public reconciler gives an event a stable identity, updates its calendar copy, and records what happened.

Current limit: The check establishes stored records and recorded outcomes. It did not inspect the current provider calendar or prove an always-running intake service.

Used in our setup

Keep one accepted school event

The new time has a durable record. The calendar is a useful view of that record, and the original notice remains part of the explanation.

Reproducible today

Update the existing calendar copy

The independently exercised synthetic fixture covers identity, corrections and retries with a simulated provider. The same event identity is used when delivery is retried.

Future direction

Bring the rest of the afternoon along

Notice the appointment clash, propose pickup coverage and move preparation earlier. The person chooses the arrangement; a recorded date alone does not solve the transport.

A correction worth keeping / fictional example

The time changes again.

BeforeThe reviewed notice says 12:30.

AfterA later notice says 1:00. Review the correction and update the same event.

The delivery foundation can reconcile an accepted update. Reliably detecting a new notice and proposing its meaning is a separate connection in development.

Why ownership matters here: A different assistant should be able to explain the current time and its source. The family’s plan belongs in its records, where a better calendar or assistant can use it.

The relief: one current school plan, less hunting through notices, and a clear next question.

Evidence behind this example

Checked 2026-10-16. Sanitized household observation, 16 October 2026; Household OS d45894c723733534bcfdcce4691860138b4a7761

The household and its details are invented. Status labels apply to each specific foundation or proposed connection.

School lunches / fictional household example

Tomorrow’s lunch shouldn’t be a research project.

The right menu, for the right day, with room for the correction that changes the answer.

The menu is in a PDF. There is a photo of the replacement menu in another conversation. One child wants a packed lunch, and tomorrow’s trip has its own requirements. At 7:15 a.m., finding the current answer is already another job.

Start with a smaller useful foundation: keep the accepted school menu against the date it belongs to. The public lunch query is date-specific. A lunch entry can be available for an authorized reader without filling the family display with every menu item.

Fictional question and record

What’s for lunch on Thursday?

Accepted menu
Vegetable pasta · Thursday
Source
The revised menu, not last week’s photo
Separate requirement
The class trip needs a packed lunch
Preparation to connect
Make one extra wrap with Wednesday dinner

The menu is illustrative. Connected preference and preparation suggestions are future behavior.

Used in our setup

Dated lunch records already have a place to live.

The read-only check found active school-lunch records and recorded calendar delivery outcomes. Public code includes a canonical lunch query for a requested date, private non-blocking calendar copies, and a display choice that keeps a lunch record queryable when it is hidden.

Current limit: The check did not qualify a voice-assistant response, inspect today’s provider state, or establish connected preferences, pantry estimates or meal planning.

Used in our setup

Give the day a current menu record

Keep the date-specific lunch information in the household’s records. Display visibility and availability to a permitted query can have different jobs.

In development

Correct it once, then check the answer

A replacement menu should supersede the old answer, and the next permitted reader should get the correction. Reliable correction and readback is the next concrete milestone.

Future direction

Turn the answer into an easier evening

Connect the trip, preferences and a busy Wednesday. Suggest an extra wrap while dinner is being made, ask about uncertain supplies and prepare a reviewable shopping list.

A correction worth keeping / fictional example

“There are already apples in the fridge.”

BeforeThe proposed preparation list includes buying fruit because the estimate is uncertain.

AfterKeep the packed-lunch requirement. Remove fruit from the proposed shopping list.

This is the connected experience we are building: a correction changes the useful plan, and the person can see why. No inventory check or purchase runs on this website.

Why ownership matters here: A preference should not disappear when you change assistants. A corrected menu should remain distinguishable from the stale version that prompted the question.

The relief we’re aiming for: tomorrow’s lunch takes less thought tonight.

Evidence behind this example

Checked 2026-10-16. Sanitized household observation, 16 October 2026; Household OS d45894c723733534bcfdcce4691860138b4a7761

The household and its details are invented. Status labels apply to each specific foundation or proposed connection.

Home improvement / fictional household example

Pick up the project. Keep the backstory.

The room is still unfinished. Restarting the conversation shouldn’t be another task.

The spare room started as a simple weekend project. Now the measurements are in a message, two quotes are in email, the flooring decision is in a chat, and the shelves are arriving late. Before doing anything useful, you have to reconstruct what you already know.

Open a useful project view and the next step should be visible: keep the existing floor; confirm the wall measurement before choosing a desk; the delayed shelves block their installation; choosing the quote is still your decision. That accumulated understanding is the valuable part.

Fictional project snapshot

Goal: spare room ready for visitors

Decided
Keep the existing floor
Ready next
Confirm the wall measurement
Waiting
Shelves arriving later than expected
Still yours to decide
The quote, budget and installation date

A fictional example of recorded work. It is not proof of a completed renovation.

Used in our setup

Home-project work and activity are recorded.

The bounded check found home-project-related work with linked activity after excluding ordinary fixture and demo markers. We also use durable context and correction records to carry development work forward. These are practical foundations for returning to an unfinished project.

Current limit: The check did not establish completed or accepted home-project outcomes, a fresh assistant handoff, contractor coordination, or automated purchasing. The public planning candidate is unmerged.

Used in our setup

Keep the unfinished work somewhere durable

Work records and activity are present in the household setup. The record is a place to keep the next question and carry the project’s context forward.

In development

Connect the project’s moving pieces

The public review candidate implements work proposals, references, dependencies and outcome-acceptance primitives. Connecting everyday research, quotes and delivery updates still needs its own acceptance.

Future direction

Replan when the shelves slip

Show which jobs can continue, propose a revised weekend and prepare the decision that needs attention. Contacting a contractor, accepting a quote or spending money follows the person’s authority.

A correction worth keeping / fictional example

A measurement changes the next step.

BeforeThe illustration’s plan assumes the proposed desk fits the wall.

AfterA checked measurement says it does not. Choose a different desk before ordering it.

The useful future keeps the source of that correction beside the decision it affects. A tidy project summary is not evidence that an installation has been completed.

Why ownership matters here: The measurements, rejected options, accepted decisions and remaining questions should stay useful across conversations and tools. Better intelligence should inherit a project’s backstory.

The relief: open the project and know where to start.

Evidence behind this example

Checked 2026-10-16. Sanitized household observation, 16 October 2026; planning candidate 9b265859a1b301340f2f9c7698fd2344d13715b0

The household and its details are invented. Status labels apply to each specific foundation or proposed connection.

Email to events / fictional household example

Let the school email become the plan.

Read it once. Keep the date, the requirements and the questions together.

A class-trip email arrives while you are doing something else. Leave at 8:45. Return time to follow. Bring a packed lunch and a blue shirt. Submit the permission form by Tuesday. The message is short; the remembering lasts all week.

The experience we are building turns a permitted message into a checkable proposal: one trip, one form deadline, the preparation it creates, and a question about the missing return time. Accepted details can then use the record and calendar-delivery foundations that already exist.

Fictional email · proposed interpretation

Thursday’s class trip

Trip
Thursday · Depart at 8:45 a.m.
Before then
Permission form due Tuesday
Pack
Lunch + blue shirt
Keep open
Return time has not been provided

Email watching and automatic extraction are in development. This browser example reads no inbox.

In development

Email intake is the connection to build.

The public intake design includes email as a source type. The downstream school records and calendar-delivery foundations exist, but this review did not find an executable mail-intake or recurring unattended worker on Household OS main.

Current limit: No email-source row was present in the inspected intake table. That bounded absence does not rule out manually assisted email use elsewhere, and does not qualify continuous inbox monitoring.

In development

Select a relevant message and propose events

Work only within the configured message scope. Keep the source, separate dates from requirements, and leave the missing return time as a question for review.

Used in our setup

Give accepted details a durable home

School-event records and recorded delivery outcomes are present. Once details have been accepted, the existing delivery pattern can use one event identity and a recorded result.

Future direction

Connect it to the rest of the week

Bring the form forward before Tuesday. Fold lunch preparation into Wednesday dinner. Put the shirt beside the bag. Surface a transport conflict while there is still time to solve it.

A correction worth keeping / fictional example

A follow-up email fills the gap.

BeforeReturn time is unknown. It should not be invented.

AfterA later message says 2:30. Propose the correction; after acceptance, update the same trip.

Automatic detection and interpretation remain in development. Stable identity, retries and receipts are the working delivery machinery underneath the larger flow.

Why ownership matters here: The useful result is an owned plan with an inspectable source. Another assistant should be able to explain the trip without asking you to search your inbox again.

The value of the connection: a message stops being a week-long memory task.

Evidence behind this example

Checked 2026-10-16. Household OS d45894c723733534bcfdcce4691860138b4a7761; sanitized household observation, 16 October 2026

The household and its details are invented. Status labels apply to each specific foundation or proposed connection.

02 / Inspect the foundations

A useful story needs
something under it.

These are the records, delivery mechanisms, history, and access paths behind the examples. A dated observation stays dated; each test keeps its scope attached.

PROJECT / FICTIONAL EXAMPLEThe spare room

Keep the floor. Measure the wall. Shelves later.

The decision survives the conversation. ↗
Used in our setup

Pick up the home project with the backstory.

Our setup holds home-project-related work with activity, alongside durable development context and correction records. The fictional room project shows the value of keeping a decision’s backstory within reach.

See the household example ↗
Evidence & scope

Checked 2026-10-16 · evidence dated 2026-10-16

The bounded review found recorded work and activity. It did not establish completed home-project outcomes or independently replay a fresh two-assistant handoff. A self-serve home-project assistant is still being built.

Source revision: Public-safe observations, 15–16 October 2026

Next: Make ordinary retrieval and correction dependable through the bounded user path.

FICTIONAL SCHOOL EVENTEarly pickup · Friday↓ reviewed correction
12:30 → 1:00 p.m.
↓ stable identity
Update the same event ↗
Used in our setup

Keep the school day in one current plan.

The household setup contains active school records and recorded school-calendar delivery outcomes. Public delivery code uses stable identities, updates, retries and receipts, so an accepted change can target the existing calendar item.

See the household example ↗
Evidence & scope

Checked 2026-10-16 · evidence dated 2026-09-04

The delivery demonstration remains dated 4 September. The October check establishes stored records and outcomes, not today’s provider state or an always-running intake service.

Source revision: Household OS d45894c723733534bcfdcce4691860138b4a7761; September delivery demonstration; October record-presence check

Next: Reliable school-menu correction and readback, then calendar failure and recovery checks.

01 / source02 / accepted record03 / correction04 / package → restore
Reproducible today

History you can inspect. A restore you can test.

Core preserves sources and corrections, and tests the boundaries around accepted records. The immutable v0.3-alpha synthetic restore recipe was independently reproduced on PostgreSQL 16 during the 15 October review.

Evidence & scope

Checked 2026-10-15 · evidence dated 2026-10-15

Synthetic restore evidence establishes that tested mechanism. Independent live recovery acceptance remains open.

Source revision: v0.3-alpha / c96b9da749b2d95661973485b2a026897329c8cd

Next: Complete the owner-defined live recovery and independent acceptance work.

Verified callerBounded memory toolAuthorized recordsDenied outside the scope
Reproducible today

Useful access with a smaller boundary.

User MCP provides a supported experimental local-stdio path into application data. It makes a useful starting point for testing authorized and denied reads.

Evidence & scope

Checked 2026-10-15 · evidence dated 2026-10-13

POSIX local development and synthetic data only. Hosted OAuth and governed writes have their own acceptance work.

Source revision: User MCP 5dbb82e735a808948e4b3de9eaa19ed04b7bfa3d; accepted local profile

Next: Bind the serving source to the tested identity and correction workflow.

LUNCH / FICTIONAL EXAMPLEThursday is trip day.

The menu says pasta. The trip needs a packed lunch.

One date. Context worth keeping. ↗
Used in our setup

Know where Thursday’s lunch answer lives.

Active lunch records and recorded delivery outcomes are present in our setup. Public code defines a date-specific lunch query and lets a lunch remain queryable even when it is hidden from the family display.

See the household example ↗
Evidence & scope

Checked 2026-10-16 · evidence dated 2026-10-16

This check did not qualify a voice assistant or connected preferences, pantry estimates, shopping or meal preparation. Reliable menu correction and readback remains the next milestone.

Source revision: Public-safe household observation, 16 October 2026; Household OS d45894c723733534bcfdcce4691860138b4a7761

Next: Correct the menu once, then verify the next permitted reader receives the current answer.

03 / Follow a school notice

From “remember this”
to a plan you can inspect.

Follow the accepted event, its calendar copy, and a recorded outcome. Then switch to Future preview to explore the preparation we want to connect around it. All examples are fictional and run locally in your browser.

A fictional notice / a concrete path

Working foundations · fictional recreation of documented behavior

SOURCE / FICTIONAL

Example Primary · school email

Class trip

Thursday, 22 October
  • Updated departure: 8:45 a.m.
  • Bring a packed lunch
  • Wear a blue shirt
  • Permission form due Tuesday
  • Return time not stated
Fictional email. A follow-up changed the departure time. This browser demo does not read an inbox or write a calendar.
01 / In development

Review the change.

The school trip is Thursday. A follow-up moves departure from 9:00 to 8:45. Assisted intake should present that change with the original email, keep the lunch and shirt requirements, and ask about the missing return time before a person accepts the plan.

  • Proposed correction: 9:00 → 8:45 a.m.
  • Keep: packed lunch, blue shirt, permission deadline
  • Question: what time do we collect them?

Email extraction and dependable intake are in development. This fictional review illustrates that next connection; accepted records and downstream delivery have separate evidence.

02 / Used in our setup

Keep the accepted context.

After review, the accepted event has a durable place in the household record. The date and preparation details need not disappear into a chat. When the plan changes, there is a current record to correct and a source to explain it.

  • Accepted event: Thursday’s class trip
  • Current departure: 8:45 a.m.
  • Keep the notice and requirements with the event

School-event records are present in the inspected setup. This fictional record illustrates the pattern; it is not a live household event or proof of an automatic email-to-record path.

03 / Used in our setup

Deliver a calendar copy.

The public reconciler carries accepted event state to a managed calendar copy. A stable identity lets the corrected departure update the same event. If a provider request fails, a retry has an existing identity to use.

  • Owned event → delivery outbox
  • Same event identity → corrected departure
  • Retry the update without inventing a second trip

The provider demonstration is dated 4 September. The independently tested provider-free fixture covers updates and retries with simulated delivery. This replay makes no provider request.

04 / Used in our setup

Record what happened.

A delivery receipt separates ‘we tried’ from a recorded result. The inspected setup has recorded synchronization times and provider event identifiers. The next useful question is whether delivery succeeded, rather than whether an assistant sounded confident.

  • Recorded outcome: delivered or unresolved
  • Provider event identifier retained
  • Unresolved delivery stays available for retry

Recorded delivery does not verify current provider state or continuous service. It cannot tell us that the child attended, the form was signed, or the lunch was packed.

Future preview · proposed connected experience

01 / Future direction

Prepare the morning.

On Wednesday evening, bring together tomorrow’s earlier departure, the blue shirt and the return-time question. Tuesday’s form deadline has passed: if submission is unconfirmed, flag it for follow-up instead of treating it as done.

Trip at 8:45. Pack the shirt and lunch tonight. Confirm the form’s submission and tomorrow’s pickup.
02 / Future direction

Connect the meal plan.

The usual menu says pasta, but Thursday’s trip needs a packed lunch. Use an accepted preference and tonight’s cooking time to propose one extra wrap. Keep pantry estimates uncertain until checked.

Make tomorrow’s wrap with dinner. One preparation step, while you’re already in the kitchen.
03 / Future direction

Carry a correction forward.

The proposal includes fruit on a shopping list. You say there are apples in the fridge. Remove that proposed purchase, keep the packed-lunch requirement, and preserve the reason the plan changed.

Use the apples already at home. Keep the wrap. No fruit purchase needed.
04 / Future direction

Keep the person in charge.

If pickup conflicts with an appointment, show the clash and propose arrangements. Prepare any shopping or schedule changes for review within the person’s permissions. Leave unresolved questions visible.

Pickup still needs an answer. Review coverage and any proposed changes. You decide what happens next.

This preview illustrates the direction. These connected actions are being built. No message, calendar change, or purchase is sent.