Skip to content

Organization Database Responsibilities

Why This Exists

This document defines conceptual database responsibilities for the Organization Domain.

It does not define SQL implementation, final schemas, indexes, migrations, or storage technology. It defines what data responsibilities the Organization Domain owns.

Owner

The owner is the Chief Product Officer and Enterprise Architect.

The Organization Domain owns persistence responsibilities for Organization-owned business data.

Business Value

Clear database responsibilities protect the source of truth for customer organization data and support reliable cross-domain reference, analytics, audit, and AI memory.

Conceptual Tables Or Collections

Conceptual table or collection Responsibility
organizations Root organization identity, status, and lifecycle metadata.
organization_profiles Legal, trading, descriptive, and operating profile data.
organization_users Organization-to-user associations and organization roles.
organization_directors Director records and verification status.
organization_contacts Business contacts and contact purpose.
organization_addresses Physical, postal, branch, and operational addresses.
organization_services Services offered by the organization.
organization_products Products offered by the organization.
organization_capabilities Capability claims, evidence level, and verification state.
organization_equipment Equipment assets and availability basis.
organization_fleet_assets Fleet assets and delivery capacity indicators.
organization_past_projects Past project records and evidence.
organization_client_references Client references linked to projects or services.
organization_procurement_preferences Sectors, regions, opportunity types, exclusions, and goals.
organization_intelligence_graph Connected organization facts, relationships, and graph metadata.
organization_memory Organization-specific memory records and references.

Relational Model

The initial persistence model should support a relational view of Organization data because many Organization concepts require consistency, auditability, filtering, and reporting.

Relational responsibilities include:

  • Stable primary keys.
  • Foreign key relationships to OrganizationId.
  • Lifecycle state fields.
  • Verification status fields.
  • Created, updated, and actor metadata.
  • Soft-delete or retention markers where required.

Future Graph And Semantic Memory Layer

The Organization Intelligence Graph and Organizational Memory may require graph or semantic memory representations in the future.

Those layers should not replace the authoritative Organization data model. They should connect, enrich, index, and reason over Organization-owned facts with provenance.

flowchart TD
    Relational[Relational Organization Store]
    Events[Organization Events]
    Graph[Organization Intelligence Graph]
    Memory[Organizational Memory]
    AI[AI Reasoning]

    Relational --> Events
    Events --> Graph
    Relational --> Graph
    Graph --> Memory
    Memory --> AI
    Relational --> AI

Indexing Considerations

Future implementation should consider indexes for:

  • OrganizationId.
  • Registration number and tax identifiers.
  • Status and lifecycle state.
  • Geographic coverage.
  • Industry classification.
  • Services and products.
  • Capability names and evidence levels.
  • Verification status.
  • Procurement preferences.
  • Event timestamps.

Audit Requirements

Organization data changes should capture:

  • Actor.
  • Source channel.
  • Timestamp.
  • Change reason where available.
  • Previous and new values for sensitive fields.
  • AI suggestion provenance where applicable.
  • Correlation ID for workflow-driven changes.

Ownership Rule

Other domains may maintain projections or read models. They must not use their databases as the canonical store for Organization-owned facts.