Domain Ownership¶
Why This Exists¶
This document defines ownership rules for the Algosure Domain Model.
Owner¶
The owner is the Chief Product Officer and Enterprise Architect.
Business Value¶
Ownership prevents duplicated facts, conflicting workflows, unclear APIs, and unsafe AI behavior. It ensures that every concept has one authoritative domain.
Core Rule: One Concept, One Owner¶
Every business concept must have one owning domain.
The owning domain controls:
- Business language.
- Lifecycle.
- Rules and policies.
- Commands.
- State changes.
- Events.
- Source-of-truth records.
- API responsibility.
- Database responsibility.
Other domains may reference the concept, subscribe to events, create derived views, or request workflow action through the owning domain.
Ownership Matrix¶
| Domain | Owns |
|---|---|
| Organization | Organization profile, business context, capabilities, services, products, people, resources, experience, preferences, organization intelligence graph references, organizational memory context. |
| Intelligence | AI orchestration, reasoning sessions, agent registry, cognitive architecture records, memory usage records, execution support, confidence and explainability metadata. |
| Compliance | Compliance requirements, documents, verification, expiry, readiness, evidence, scores, and compliance risk. |
| Opportunity | Tender opportunity records, discovery, indexing, matching, saved opportunities, watchlists, recommendations, and opportunity lifecycle. |
| Bid | Bid workspaces, plans, tasks, proposal artefacts, SBD forms, pricing coordination, approvals, submission packs, outcomes, and lessons learned. |
| Contract | Awarded contract delivery, milestones, deliverables, supplier coordination, variations, invoices, payments, risks, performance, closeout, and contract lessons. |
| Supplier | Supplier profiles, relationships, capabilities, quotes, performance, ratings, reviews, response time, preferred supplier state, and supplier trust state. |
| Marketplace | Listings, discovery, categories, search, visibility, quote requests, marketplace matching, and marketplace workflow records. |
| Funding | Funding needs, products, partners, readiness, applications, cash-flow risk, repayment tracking, and funding recommendations. |
| Learning | Academy content, courses, lessons, quizzes, exercises, certificates, paths, tutor session records, progress, maturity assessments, and learning recommendations. |
| Notification | Notification requests, templates, preferences, schedules, delivery attempts, read status, escalations, and communication history. |
| Analytics | KPI definitions, dashboards, report definitions, analytical views, metric snapshots, insight records, performance summaries, and CEO briefings. |
| Billing | Billing accounts, plans, trials, subscriptions, invoices, payments, payment failures, entitlements, usage limits, renewals, and cancellations. |
| Identity | Authentication identity, user account, memberships, invitations, roles, permissions, sessions, API keys, MFA, tenant isolation, and authorization decisions. |
| Administration | Platform configuration, feature flags, support cases, tenant admin views, policy configuration records, audit review workflows, governance records, and admin workflows. |
Reference Rule¶
Domains reference concepts owned elsewhere by stable identifiers and event metadata.
Examples:
- Bid references OpportunityId but does not own tender discovery facts.
- Compliance references OrganizationId but does not own organization profile facts.
- Analytics references Bid outcomes but does not own bid outcome state.
- Administration references Billing invoices in support cases but does not own invoice facts.
Derived Data Rule¶
Derived views, snapshots, summaries, or recommendations must be labeled as derived data. They do not replace the source domain.
Analytics can own a win/loss report. Bid still owns the bid outcome.
Intelligence can own an explanation of a compliance gap. Compliance still owns compliance state.
Override Rule¶
No domain may bypass another domain's ownership by writing directly to its storage, mutating its aggregate state, or redefining its lifecycle. Cross-domain change must happen through approved commands, events, or APIs.
Architecture Mirror Principle¶
Software architecture must mirror organizational architecture. Domains map to stable business ownership boundaries, not arbitrary technical layers. This keeps the system aligned to the Digital Procurement Company model.