Households & delegation

Some context belongs to more than one person. That the house is vegetarian, that the kids are six and nine, that everyone flies Delta. There is nowhere good to put it: each adult keeps a private copy and the copies drift.

A household is a separate vault that people join. It is not a link between your vaults and it is not your vault with extra owners. Your own vault stays yours alone, forever, and joining a household cannot change that. You can leave at any time without asking anyone.

Roles

subject is the role that does not exist in a one-person world: someone a vault holds facts about who does not curate it. They can always read what is held about them. There is deliberately no role that can read everything and be invisible.

Who approves what

Every entry is about the household, or about one person.

• Household facts("we are vegetarian") are approved by any owner or curator.
• Facts about a member("Kim is allergic to shellfish") are approved by that member, and by nobody else, whatever role anyone holds.

That second line is the whole design. An owner is not a superuser here. It keeps the product's promise intact inside a shared vault: nobody writes a fact about you that you did not approve, even if they live with you.

How an app says which

Apps declare scope, never identity. One field with two values, on both doors:

POST https://vault.helix.ai/api/propose
{ "category": "preferences",
  "fact": "Runs before work most days",
  "scope": "me" }          // or "household"

"me" means the person who connected this app. The server resolves it from the grant, so an app is never told who the members are and cannot put a fact in someone else's queue. If the field is omitted it defaults to "me", which is the narrower option: a silent integration should never route a fact about one member into another's.

GET /api/context returns vault_kind: "personal" | "household" so an app can set scope sensibly. That is the kind only. Membership is never disclosed.

One review queue

You get a single queue across every vault you belong to, containing what you can actually decide, badged with which vault each item came from. Everything else is a bare count: "3 more items are waiting on someone else to decide." Showing you a greyed-out card would leak the fact in the act of telling you it is not yours to approve.

Delegation

A delegated vault is one whose subject and whose owner are different people. A parent holding context for a child. An assistant curating for an executive. Helix takes a position here that most products do not:

A delegated vault about a competent adult requires that adult's acceptance. Not their awareness.

Until they accept, through their own account, the vault is inert. Its curator can write into it and no app can read it. Both doors refuse:

GET https://vault.helix.ai/api/context
409 → { "error": "vault_awaiting_subject",
        "detail": "This vault holds facts about someone who has
                   not yet accepted that. It cannot be read until
                   they do." }

It is a distinct status rather than a permissions error because the app has done nothing wrong and there is nothing it can change. Over MCP, get_context says the same thing in words and tells the assistant not to fall back on its own memory of the person. An empty vault and a withheld vault produce very different behaviour, and only one of them is honest.

That rule costs one step of onboarding where the delegation is legitimate. It is what stops Helix being a convenient way to build a dossier on somebody.

When a child grows up

A vault created for a nine year old is legitimate. The same vault still being read by a parent when that person is twenty is not, and nothing but a date tells the two apart.

So a vault held on someone's behalf carries a date. When it arrives the vault goes quiet, through exactly the same mechanism as initial acceptance, until its subject takes it over. Accepting also transfers control: the subject becomes owner and whoever held it drops to contributor, keeping the ability to suggest and losing the ability to decide. Nobody has to remember. The date does it.

Safety, stated plainly

A shared vault in a controlling relationship is a weapon. That shaped the design rather than appearing as a footnote. The protections are structural, not policy:

• Joining a household never exposes your personal vault. They are separate objects, and there is no setting that links them.
• Leaving is unilateral and immediate. No owner approval, no notice period.
• Facts about you are approved only by you, so a household cannot accumulate claims about you over your objection.
• On leaving, facts about you are removed from the household vault. Facts about the household remain, since they were never about you alone.
• Every member can see who has been reading, not just owners. In a shared vault the person most likely to look you up is someone you live with.
• No invisible role. Every member can enumerate every other member.

What this does not solve: someone compelled to approve, or to stay. Nothing in software solves that, and Helix should not be described as a safety product.

What is not built yet

Stated here rather than discovered later:

• You can only invite someone who already has a Helix account.
• The nightly freshness sweep does not walk household vaults, so shared facts are not yet checked for staleness.
• There is no way to reassign a fact's subject after it has been approved.