Family & Passport

This is the domain where Emofy's product thesis becomes code. The family domain models guardians and children; the passport is the parent-owned, portable record of a child's development. Together they implement the dual-ledger model.

Guardian ↔ child relationships

The family domain links guardians to children and records the authorizations that flow from those links:

A guardian's link to a child is the basis for row-level access: a parent does not see "all children in the org" — they see their children, and only the data classes they've consented to.

Relationship-based permissions

Recall from Authorization that RBAC decides what kind of action a role may perform. For child data, that is not enough — access is further narrowed by relationship and consent (ADR-021):

effective access = role  ∧  active relationship/enrollment  ∧  consent

Routes that touch child data are tagged with the @DataClass decorator, which classifies the data "C1"–"C4" per ADR-022:

@DataClass("C2")                      // child-scoped developmental data
@Get("children/:id/observations")
getObservations(@Param("id") id: string) { /* ... */ }

Two guards then enforce access after RBAC:

• RelationshipGuard — reads the @DataClass metadata and checks that the caller has the required relationship to the subject (guardian ↔ child).
• ConsentGuard — checks that the necessary guardian consent exists for the higher-sensitivity classes, failing closed when it doesn't.

The consequence is the product promise in enforcement form: a teacher's access to a child ends when the child un-enrolls; a parent's access persists — because the parent's relationship and consent persist even as the child moves between institutions.

The dual ledger

The same child activity is recorded twice (ADR-020):

   institution operations              parent-owned passport
   (org-scoped, institution-owned)     (portable, follows the child)
            │                                    │
   teacher logs activity ──────projection───────▶ passport entry
            │                                    │
   removed if child leaves              persists across institutions,
   the institution                       consent-gated

• The org operational ledger belongs to the institution and is org-scoped. If the child leaves, the institution keeps its operational record but the child's presence in that org ends.
• The passport ledger belongs to the parent. Entries are projected from operational events under consent, and the passport travels with the child to the next institution.

This is the switching cost and long-term value at the center of the product: the child's development history is not locked inside any one school.

Child-data auditing

Because child data is sensitive, access is audited. The ChildDataAuditInterceptor records child-data access (fire-and-forget) into the partitioned audit log, giving a who-saw-what trail for compliance (KVKK/GDPR, via the legal domain).

Next