Family Members
One sub-profile per family member — each with their own tier, their own rulebook overlay, their own last-modified state. Tatty's filter doesn't have to look like Yossi-13's.
▸What this page does
Per-family-member sub-profiles partition one customer org's filter into per-person overlays. Each member starts from the household default tier and accumulates their own additions / removals / domain overrides in customer_rulebook, scoped by family_member_id.
Why it matters: The kid going to yeshiva needs Shomer Eynayim; the parent running a business needs Bayis Ne'eman or Kavod HaBayis. One global tier per household is not enough. Sub-profiles let the operator (or the reseller's appointed mashgiach) compose the right filter per person without spawning multiple customer accounts per family.
Related pages: Customers · Groups · Tier Templates
Tatty
Mommy
Yossi (13)
Sara (9)
Stream 3A status — honest scope
Schema contract: public.customer_rulebook grouped by family_member_id within owner_org_id.
Server-side reader: src/lib/data/family-members-query.ts — queries customer_rulebook + kolbofilter_customers with 500-row hard cap and canonical seed mock-fallback.
Schema readiness: The family_member_id / family_member_tier / family_member_label columns are NOT yet present in the 0003 migration; the migration extension is Phase 2 work. Live queries against the present schema will surface a column-missing error and fall through to mock-fallback honestly per Cardinal #84 — no fabrication.
Render gate: firing — list surface shaped per contract.
Mutation gates: still blocked — adding / removing sub-profiles + applying overlay rules deferred to a Phase 2 vessel rep.