One substrate, many domains: the domain pack model
The financial services team building an automated risk-assessment system has a specific set of requirements. Decisions must be auditable, high-impact actions must route through a human approval step, and thresholds must be adjustable without code changes. The system must log every action with enough context that a compliance officer can reconstruct, months later, exactly what ran and why.
Three floors up, the commerce team is building an order management system. They have the same list. Different domain, different specialists, different business vocabulary, but structurally identical governance requirements: complete audit records, configurable thresholds, and human approval gates for consequential actions.
The pattern repeats across every vertical where organizations start building software systems that make decisions on their behalf. Each domain brings distinct complexity: risk thresholds and execution speed in trading, catalog management and fulfillment logic in commerce, SLAs and exception workflows in operations. The surface is different. The underlying coordination requirements (routing the right task to the right actor, enforcing the right policy, maintaining a complete record) are constant.
Without a shared substrate, every domain team builds its own version of the same platform, with its own approach to governance, its own observability stack, and its own event format for the things that happen in its workflows. An organization ends up with half a dozen different approaches to the same structural problems, none of which share a language.
This is not a failure of engineering judgment. Each team is making locally rational decisions. Governance for a trading system should reflect trading's risk requirements. Observability for commerce should track commerce metrics. Building domain-specific infrastructure is the sensible choice when no operating substrate exists. The problem is the cumulative cost: duplicated effort, incompatible formats, and a governance model that is only as consistent as the teams maintaining it. This is coordination debt operating at the infrastructure level rather than the operational one.
Synedrix OS addresses this with a three-tier architecture.
The three-tier model
At the foundation is Synedrix OS: the substrate or shared infrastructure that routes and sequences work, enforces policies, provides observability, and maintains every other capability every domain needs but none should own independently. The OS carries no business logic. It does not know what a trade is, or what a fulfillment SLA means. It knows how to route tasks, enforce policies, manage the lifecycle of software actors, and maintain a complete audit trail.
The middle tier is the domain pack. A domain pack is a modular package that contributes everything specific to one business domain: its entities, its specialist software actors, its workflows, its tool connections, its domain-level policies, and its analytical vocabulary. The Trading domain pack knows what a trade is. The Commerce domain pack knows how fulfillment logic works, and the Ops domain pack knows what an SLA exception means. None of them rebuilds the shared infrastructure they run on.
The third tier is the business instance: the deployed runtime for a specific company or team. This is where credentials, approval mappings, thresholds, and environment settings live. It is where the OS and one or more domain packs are composed into a working system for a specific context, without either the OS or the packs carrying that configuration.
Each tier has a clearly bounded role: the OS provides shared infrastructure, the domain pack brings domain knowledge, and the business instance holds tenant-specific configuration.
The rule of inclusion
The model works because there is a clear decision test for which tier owns any given capability. The rule of inclusion provides that test.
If a capability is reusable across domains without domain-specific knowledge, it belongs in the OS. Routing work, enforcing policies, and observability are all domain-agnostic by nature. These belong in the substrate.
If a capability requires domain entities, domain-specific tools, or domain policies to function, it belongs in the domain pack. The logic for validating a trade order requires trading knowledge. The logic for processing a fulfillment exception requires commerce knowledge. That knowledge does not belong in the OS.
If a setting is a threshold, a credential, or an environment configuration that differs per deployment, it belongs in the business instance. Approval thresholds, data provider credentials, and approver assignments are all configuration values, not platform concerns.
The rule of inclusion is also a diagnostic. If a domain pack is building something that does not require domain knowledge, it probably belongs in the OS. If the OS is accumulating logic that only makes sense in one domain, something has been placed incorrectly. The boundary violations are usually detectable before they compound.
A domain pack contributes domain entities, events, specialist software actors, workflows, tool adapters, domain policies, KPIs, and the analytical vocabulary needed to measure and govern that domain's operations. It does not contribute the routing logic, governance, or observability. Those come from the OS. Adding a new domain does not mean rebuilding the platform. It means authoring a domain pack that runs on it.
A business instance configures the platform for a specific deployment without modifying the OS or the domain packs. Approval thresholds, enabled workflows, credential mappings, and environment settings are all business instance concerns. Two companies running the same domain pack on the same OS can configure it entirely differently, without either configuration affecting the other. The substrate is shared, the domain logic is modular, and the configuration is isolated.
This is what the three-tier model makes possible: a platform that can serve multiple domains without fragmenting, and a governance model that holds without being rebuilt from scratch for every new context.
Next post will define the governing principles for all three tiers, the rules that determine what trustworthy behaviour means across every domain Synedrix OS runs.
Synedrix OS is in active development. If you are interested in co-founding or investing, the door is open.
Related reading
The coordination debt that's quietly costing enterprises their edge — the fragmentation trap the domain pack model prevents is coordination debt at the infrastructure level: every domain rebuilding governance, observability, and event formats from scratch, without a shared substrate to anchor them.
From static workflows to agentic operating systems — introduced the operating system concept the domain pack model extends: one reusable substrate, shared coordination infrastructure, modular components that plug in rather than rebuild.
Next in the series: The 10 principles that make agentic systems trustworthy — the governing principles that apply across Synedrix OS and every domain pack that runs on it.
Synedrix OS — rule of inclusion
