How Family Manager Became the Proof App for the Platform
Draft, deploy-gated. The full narrative publishes with the Lab launch; the sections below are content-free by construction.
Family Manager is the consumer proof of the Curate-Me platform. A parent forwards a school flyer; the same governed runner and human-in-the-loop spine that power the platform turn it into proposed calendar events, deadlines, and checklist bundles, proposed, never silently committed. Nothing about that loop is bespoke to families. It is the platform’s generic machinery, pointed at a household.
One loop, many destinations
The product is a single loop with one spine:
- Capture, a parent forwards an email, snaps a photo, dictates a note, or types a request.
- Extract, the platform turns the input into a structured proposal: a title, a resolved absolute date and time, who it is for, a confidence band, and the source it came from.
- Approve, the parent reviews and approves. This is the spine. The agent never changes the world on its own.
- Route, on approval, the result is written to its destination. The first destination is the parent’s own calendar.
Every feature is a thin addition to that one loop. Build the loop once, and a new capability is a new kind of proposal, not a new app.
Why it is a proof app, not a fork
Family Manager does not run its own brains. Scheduling, governance, memory, and extraction live on the platform; the app is a thin capture, render, and approve surface that talks to a generic mobile facade. The platform never knows it is serving a “family.” It serves a generic organization with members, an agent identity, approvals, a knowledge base, and templates.
That is the point of a proof app: if the household use case works on the generic platform with only configuration and templates, the platform’s claim, that it is a general substrate for governed agents, is demonstrated rather than asserted.
Propose, never silent
The category’s most common failure is an app that says it acted and did not. Family Manager is built so that cannot happen quietly:
- Every side-effecting action moves through explicit states: proposed, approved, executing, then confirmed or failed.
- Confirmation comes from re-reading the destination (the event exists), never from the agent’s self-report.
- A write that cannot be verified shows a loud, explicit failed state, never a silent wrong success.
What the Lab shows, and what it never will
The public Lab renders the loop from a redaction-safe projection. It is content-free by construction: it carries identifiers, closed-enum source and proposal kinds, coarse confidence and outcome counts, coarse resource bands, and timestamps. It carries no real family data, no emails, child names, addresses, or event titles. It looks right with sample data and leaks nothing.