Family AI Provisioning — the family's own governed AI
Status: CONCEPT (Sandon, 2026-07-29). Not built. A strategic direction + a potential hardware partnership, captured so it's a shareable artifact.
The one-line: enterprises adopted Bedrock/proxy layers over Claude not for the model but for the governance — visibility, policy, audit, cost control over employee AI. Families face the identical need with their kids and AI, and there is no consumer product for it. Family Wall is the natural console; a local hardware partner (Matt / Cicero) is what makes it defensible.
The insight
"Parental controls for the AI age" is a real, unserved category. Kids are using AI; parents have no visibility, no policy, no data ownership, and no product that gives it to them without handing a vendor even more of the family's private life.
The enterprise analogy is exact. Companies didn't put a proxy in front of Claude because they distrust the model — they did it because they needed:
- Visibility — what's being asked, by whom.
- Policy — what's allowed, for which role/age.
- Audit + data control — where the conversations live, who owns them.
- Cost control — a governed, metered gateway.
A family needs the same four things, pointed at their kids instead of employees.
Nobody sells it. Family Wall is a credible console because it's already the
family's shared, PIN-gated trust surface, with kid-chat + parental-oversight
primitives in place (see family-kid-chat-core, family-kid-safety-core).
What it is
A family AI gateway — family members' AI conversations route through a family-controlled proxy — plus a management layer on the Family Wall giving parents:
- Visibility — age-graded (see the design law below), not a surveillance feed.
- Policy — allowed topics, time windows, per-child settings, escalation rules.
- Data ownership — conversations stored in the family's own space, not a vendor's cloud. This is the load-bearing differentiator.
It is a provisioning / governance layer, not a new model — "Bedrock for families."
The Matt / Cicero dovetail — the defensible part
The proxy needs somewhere to run and store family data.
- Cloud-only recreates the surveillance problem — a vendor holds the family's conversations. That's the thing families are (rightly) wary of.
- On local family hardware (Cicero's box — storage + on-device AI), the family's AI and data stay physically in the home, under the family's control. That is the honest version of "the family owns its data," and no big player will ever offer it — their entire model is your data in their cloud.
So the split writes itself:
| Layer | Owner |
|---|---|
| Software: management layer, UX, AI orchestration, the Wall console | HiveJournal / Family Wall |
| Substrate: local storage + on-device AI | Cicero (Matt) |
Together: the family's own private, governed AI — run from the wall, stored at home. It also gives the Sophia / cicero.sh local-NLU thread its use case, and its personal/household-only license fits a family product exactly, where it never fit a SaaS one (see the Sophia licensing gate).
Matt's reply (2026-07-30) — integration confirmed, three specs are ours to answer
Matt replied to the dovetail pitch. Substance:
- His NLU is done and he's confident in it. GitHub + an open-source, reproducible test suite land "in a day or two" — which is exactly what de-risks the Sophia licensing gate's "verify the benchmark before shipping" step: we run his suite ourselves rather than trust a number. Wait for it, run it, then proceed on the near-term path.
- "What you said slides in perfectly with my tech." The Sophia-as-decide- locally + Bedrock-for-families framing fits his engine; he wants our implementation details to build against.
- His end-to-end direction: integrate soniqo/speech-core
- bundle micro wake word → a fully local STT → wake → NLU → TTS pipeline, ~1.2 GB CPU, no GPU. The standalone NLU alone is ~160 MB.
- The moat thesis, his words: everyone's chasing transformer/probabilistic intent; nobody wants deterministic NLU because it's hard — the field is wide open. That's the same bet our owned-hardware plan already makes.
His three questions — our answers (pending Sandon's confirm)
He asked three implementation questions. They're ours to answer, and the answers are path-dependent — which is the useful part, because it forces the two-path split to be explicit:
| Matt asks | Near-term: glasses (Mentra) | Endgame: family box (Cicero) |
|---|---|---|
| What architecture do I compile for? | x86-64 Linux. The Mentra app is an AppServer that runs on Railway, not on-glasses (glasses are a thin BLE client → phone → our server; see apps/glasses/README.md + the src/sophia.ts seat already stubbed). So Sophia/his NLU runs server-side first. | The box's arch (likely ARM64 — Pi/mini-PC class). Add ARM64 once the box path is real; don't block on it. |
| Is 160 MB OK? | Yes, trivially — a Railway container has GB. Even his 1.2 GB end-to-end build is fine server-side. | Yes — a home box handles 1.2 GB CPU/no-GPU comfortably. 160 MB is a non-issue on both targets. |
| Do you need me to bundle STT/TTS, or are you set up? | NLU-on-text is enough here. We already have TTS (ElevenLabs) and a cloud STT path via Mentra/phone — so for the glasses path he can take text in, intent out, and skip STT/TTS. | Yes — bundle local STT/TTS (his soniqo + micro-wake-word plan). Round-tripping audio to ElevenLabs would break the whole data-stays-home promise, so the box wants his end-to-end 1.2 GB pipeline. It's overkill for the server path and exactly right for the box. |
The honesty correction this forces on our own plan
Near-term, "decide-locally" on glasses is really "decide-on-our-server" — because Mentra runs the app in our cloud (Railway), not on the frames. That's still a real win (faster than a frontier round-trip, our infra not a third party's LLM cloud, most data stays our side, deterministic on intent), but it is not the "conversations physically stay in the home" story. That story only becomes true on Matt's box. Keep the two claims distinct — the mesh's own honesty discipline (attributed, never overclaimed) applies to our own architecture too: server-side deterministic NLU now, genuinely-local family AI on the box.
Net effect on build order: the glasses NLU seat (apps/glasses/src/sophia.ts,
x86-64, text-in) can proceed as soon as his suite verifies — independent of the
box. The box stays the endgame (step 3 below), now with a concrete substrate
(his 1.2 GB local STT+NLU+TTS pipeline) instead of a hand-wave.
The design law: loving oversight, not surveillance
This is the whole ballgame, and it's the same consent-first line the mesh keeps hitting (Lovio, Lighthouse, kid-chat-safety, "read-only for the dead").
"Parents can read their kid's AI chats" is legitimate for a 7-year-old and corrosive for a 15-year-old. The version families trust rather than resent is:
- Age-graded visibility that decays toward autonomy. Full transparency for little kids; for teens, the parent sees that the AI is being used and any flagged concerns, not a transcript.
- The AI flags a genuine safety concern (self-harm, grooming, dangerous instructions) rather than parents reading everything. Oversight is exception- based, not ambient.
- The child can see what's shared with whom. No covert monitoring — the same "attributed, never covert" rule as the audio-honesty standard, one surface over.
Get this wrong and it's a creepy product families uninstall. Get it right and it's the one they trust with the thing they trust least.
Architecture sketch
- Gateway/proxy — family AI requests route through a family-scoped endpoint (policy + logging + metering applied here).
- Decide-locally, escalate-when-needed — a local model (on Cicero hardware, or a small hosted model) handles most turns and the intent pre-filter; a frontier model (Claude) is called only for the hard asks. This keeps most data local and sidesteps most of the frontier-reseller cost/ToS weight.
- Family-owned conversation store — home hardware (privacy-max) or a family-encrypted cloud space (software-first tier).
- Wall console — parents configure policy + see the (age-graded) oversight surface from the Family Wall they already have.
Business model
- Family Wall Plus is the obvious home for the software tier (see
FAMILY_WALL_MONETIZATION.md). "Keep your kids' AI safe + your family's data in your own home" is a strong emotional + privacy pitch and a natural premium. - Hardware bundle / privacy-max tier — the Cicero local box as an upsell once the software proves appetite.
- Enterprises pay for AI governance because of compliance; families' willingness to pay is unproven — this is the #1 thing to validate before hardware spend.
- Deal structure with Cicero: licensing only. Engage Matt/Cicero purely as a licensor of the NLU (an OEM/license deal, consistent with the household-only license) — not a partnership, equity, or joint-entity arrangement. This is the cleaner IP/liability structure regardless, and it's a firm constraint: if any plan drifts toward co-ownership, steer it back to a license.
Build order (software-first — do NOT gate v1 on hardware)
Same lesson as the QuickSites "don't build layer 3 on an assumption": Matt's box may not ship on your timeline, so don't make the MVP hostage to it.
- Software gateway + Wall console + family-owned (encrypted) conversation store. Prove the governance value + willingness-to-pay via Family Wall Plus.
- Age-graded oversight + AI safety-flagging — the design law, built in from the start (it's not a later feature; it's the trust foundation).
- Cicero local-hardware tier — the privacy-maximal dovetail, once the software proves the appetite. This is the endgame, not the MVP.
Open questions
- Which model(s)? Local-only (weaker, fully private) vs. frontier-proxied (stronger, ToS/cost weight) vs. the hybrid above. Recommend hybrid.
- Reseller shape — proxying Claude for families has a licensed-reseller flavor (like Bedrock); clarify terms before it's a product.
- Willingness to pay — validate before any hardware commitment.
- Regulatory — kids' data + AI is a COPPA / child-safety surface; the age-graded design helps but counsel is needed before launch.
Connections across the mesh
- OWNED_HARDWARE_HORIZON.md — Sophia / cicero.sh local decide-locally NLU; the licensing gate whose household-only EULA fits here.
FAMILY_WALL_MONETIZATION.md— Family Wall Plus, the software tier's home.- Lovio / JQ Bridge — the "loving oversight" pattern this inherits.
family-kid-chat-core/family-kid-safety-core— the existing kid-chat + safety primitives to build the oversight surface on.