Final Architecture Summary

Tov+ is an occasion-first platform. Occasion is the root workspace. Events are scoped subcontexts. Actors unify every participant and operational entity. Modules are the installable feature layer. Permissions centrally govern access. Communications and Assets are shared top-level domains. Localization, Collaboration, and Publishing are reusable capabilities. APIs, Webhooks, and Integrations are external interfaces.

3 min read

System model

Tov+ is an occasion-first platform. Occasion is the root workspace. Events are scoped subcontexts. Actors unify every participant and operational entity. Modules are the installable feature layer. Permissions centrally govern access. Communications and Assets are shared top-level domains. Localization, Collaboration, and Publishing are reusable capabilities. APIs, Webhooks, and Integrations are external interfaces.

Top-level domains

Occasions

The root workspace for shared identity, branding, defaults, installed modules, actor graph context, communications context, asset context, and permission context.

Events

Lightweight time/place/audience scopes within an occasion. Events define where installed modules are enabled and where event-specific visibility and settings live.

Actors

The unified participation model for people, groups, vendors, teams, and households. Actors own identity-in-occasion, relationships, memberships, attributes, and participation references.

Modules

The installable feature layer. Modules are installed per occasion, configured per installation, enabled per event, and authorized through the central permissions model.

Permissions

The cross-cutting authorization domain. It owns grants, roles-as-bundles, scope evaluation, and resource/action authorization.

Communications

The shared messaging domain. It owns templates, deliveries, threads, reminders, preferences, and communication logs for all modules and core flows.

Assets

The shared file/media domain. It owns uploads, metadata, visibility hooks, storage abstraction, transforms, and attachment associations.

Capabilities

Localization

Reusable locale and translation behavior for UI and content. Not a module.

Collaboration

Reusable multi-actor contribution mechanics such as assignment, claiming, ownership, and deadlines. Not a single feature module.

Publishing

Reusable output-generation mechanics for print and digital artifacts such as invitations, signage, QR packages, and seating charts.

Interfaces

APIs

Controlled external access surfaces for frontend apps and external consumers.

Webhooks

Outbound notifications derived from authorized system state changes.

Integrations

Scoped external principals and adapters that connect Tov+ to third-party systems without bypassing permissions.

Architectural rules

  • domain: foundational shared business ownership with durable records and invariants

  • module: installable user-facing feature enabled per event

  • capability: reusable mechanics used by multiple domains/modules

  • interface: external access or connection surface

  • Occasion is the system root.

  • Events are never the root feature model.

  • Actors unify guests, planners, vendors, helpers, groups, and households.

  • Modules may depend on domains, capabilities, communications/assets, and declared modules.

  • Communications and Assets are consumed by modules and must not be reimplemented per feature.

  • Permissions are centrally enforced on the backend.

  • Capabilities support domains/modules but do not replace them.

  • Interfaces expose the system; they do not own core business data.

Scope boundaries

  • occasion scope: shared identity, defaults, branding, actor graph context, installed modules
  • event scope: timing, place, audience, visibility, module enablement, event-specific settings
  • actor scope: actor identity, preferences, memberships, relationships, attributes
  • module installation scope: occasion-module installation record and default configuration
  • module enablement scope: event-module activation and event-level config
  • resource scope: concrete records such as a timeline item, gallery asset, seating chart, or invitation package

Supporting platform concerns

  • audit: change history attached to domain/module actions
  • workflows: multi-step orchestration across domains/modules
  • automation: rule-driven or scheduled triggers against explicit contracts
  • search: authorized indexing and retrieval, never the source of truth
  • analytics: reporting from emitted events, never operational truth
  • background jobs: asynchronous execution for deliveries, processing, publishing, and sync
  • exports: generated data packages from domains/modules
  • tagging/classification: shared labels or classifications, not substitutes for relationships or permissions

Non-negotiable constraints

  • Occasion-first design is mandatory.
  • Users authenticate; actors authorize within business context.
  • Modules are added at occasion scope and enabled at event scope.
  • Permissions are top-level and cross-cutting.
  • Communications and Assets are top-level shared domains.
  • Localization, Collaboration, and Publishing are capabilities, not modules.
  • APIs, Webhooks, and Integrations are interfaces, not source-of-truth business domains.
  • Foundations must not depend on specific frontend apps or module implementations.
  • Guest flows must stay simpler than planner flows and must not require full accounts for basic access.