Skip to content

03. Domain Atlas: Business Logic & Rules

Status: Active / Golden Version: 1.0 (Consolidated Jan 2026)

"The definitive guide to the Business Logic of Singular Dream. How the world actually works."


1. Identity & Access (Unified Directory)

Reference: packages/modules/unified/directory

The "Pivot" Model (MPD)

The Directory is not a flat list; it is a Graph. * Profile: The Human/Legal Entity. * Unit: The Physical Asset. * Context: The connecting edge (Owner, Resident, Staff).

Detailed Implementation: Cortex Engine Design Spec

Navigation is Graph-Driven. Users navigate to an entity (Person or Unit), and actions are "injected" based on their relationship to that entity.

Dynamic Groups

We do not maintain static "Distribution Lists". Groups are defined by Live Queries. * Group: "All Owners in Tower A". * Usage: When a Deed is recorded, the owner automatically gains access to this group's permissions and emails.


2. Property Domain (The Cornerstone)

Reference: packages/modules/property

The "Two-Truths" Model

We distinguish between: 1. Physical Reality (The Asset): The Unit exists, has 3 bedrooms, and is on Floor 3. (Immutable-ish). 2. Legal Reality (The Deed): Who owns it right now? Who is liable for dues? (Transactional).

Subdomains

  • Registry: Deeds and Title Transfers.
  • Tenancy: Leases and Occupancy.
  • Security: Digital Keys and Gate Access.

3. Governance Domain (Digital Democracy)

Reference: packages/modules/governance

Weighted Voting

Votes are not 1-per-person. They are weighted by Indiviso (Ownership %). * Logic: VoteWeight = Sum(Deed.indiviso) for all units owned by the voter.

The Authority Chain

  1. Ownership: Proven by the Property Registry.
  2. Eligibility: Calculated by Finance (Good Standing).
  3. Power: Executed in Governance (Voting).

Subdomains

  • Assembly: The supreme authority event.
  • Elections: Digital ballot configuration and result certification.
  • Committees: Delegated oversight bodies (e.g., Vigilance).
  • [FIN-AUDIT-TRAIL] Immutable Log: Permanent record of every financial mutation (who, when, why).

4. Operations Domain (The Service Mesh)

Reference: packages/modules/operations

The "Stateless Dispatch" Pattern

The Operations module does not hoard state. It delegates the lifecycle of a request to the Universal Workflow engine. * Intake: Resident creates request. * Dispatch: Auto-routed to Staff/Vendor based on Category. * Execution: Vendor completes task -> Workflow signals completion.

The Accounting Bridge

Rule: No money moves in Operations without a signal to Finance. * Event: "Fob Key Sold" (Ops). * Signal: OPS_TRANSACTION_COMPLETE. * Event: "Fob Key Sold" (Ops). * Signal: OPS_TRANSACTION_COMPLETE. * Result: Finance automatically posts a Charge to the Resident's Ledger.

Subdomains

  • Work Management: Tickets and Bookings.
  • Vendor Network: Compliance and Dispatch.
  • Personnel & HR: Staff Roster and Shift Management.
  • Physical Intelligence: IoT and Telemetry.

5. Data Loading Pipeline (DLP)

Philosophy: "The CSV Bridge".

We democratize data entry using spreadsheets. 1. Download Template: Admin downloads a CSV based on the current Zod Schema. 2. Fill & Upload: Admin fills data offline. 3. Validate & Commit: System runs Zod validation row-by-row before committing.

Dependency Order: 1. Assets (Units/Areas) 2. People (Profiles) 3. Relationships (Deeds/Leases)