Data Definition Document: Community Registry

Domain: Community (governance, occupancy, registry, financials) Logical Sub-Domain: Registry (People Management) Physical Packages: @sd/mod-community/registry Related Documents: Process Blueprint Context: This document defines the Data Structures for the central Member Profile. Source: packages/modules/community/src/types.ts

0. Entity Relationship Diagram (ERD)

erDiagram
    DIRECTORY_PROFILE ||--o{ IDENTITY_ITEM : "authenticates_with"
    DIRECTORY_PROFILE ||--o{ PERSONA : "acts_as"
    DIRECTORY_PROFILE ||--o{ VAULT_REF : "verified_by"

    DIRECTORY_PROFILE {
        string id PK
        enum type "individual, legal_person"
        string[] types "resident, staff"
        json contexts "Role Specific Data"
        json lifecycle "Forensic State"
    }

    IDENTITY_ITEM {
        string email
        string provider "google"
    }

    PERSONA {
        string type
        string subtype
        boolean isVotingMember
    }

1. Primary Entities

Entity: DirectoryProfile

The unified record of a human or company.

Field	Type	Required	Description
id	string	Yes	Unique ID (User ID).
displayName	string	Yes	Preferred Name.
email	string	Yes	Primary Contact.
types	string[]	Yes	Enum: resident, staff, vendor, guest.
contexts	json	Yes	Polymorphic data buckets (see below).
lifecycle	object	Yes	State (provisioned) and Recertification dates.

Entity: DirectoryProfileContexts

Polymorphic buckets for role-specific data.

Context	Fields
resident	role (Primary Owner, Tenant), interests, pets.
staff	department (Security, Maint), title, employerId.
vendor	companyName, serviceCategory, insuranceExpiry.

Entity: IdentityRegistryItem

Authentication links.

Field	Type	Required	Description
email	string	Yes	Login Email.
provider	string	Yes	google, firebase.
isPrimary	boolean	Yes	If multiple emails exist.

4. Changelog

Date	Author	Description	Reference
2026-01-24	Antigravity	Initial creation	Implementation Plan