Approving a replacement shipment and restarting a failed service require different knowledge. The shipment depends on the order, the delivery problem, and the company's commitments to the customer. The restart depends on the affected service and the risk of interrupting other work. Yet both processes need someone to assess the request, the right permission to act, and a record of the result.
The domain pack model in Synedrix OS separates that business knowledge from the common responsibilities around it. A domain pack is a package of business-specific information, agents, rules, tools, and workflows that uses the shared platform. The platform coordinates and controls the work; the pack supplies what the work means in its business area.
The point of reuse is to share the machinery without confusing the responsibilities. A commerce rule should remain understandable as a commerce rule. A common approval mechanism should remain usable outside commerce. The platform is in active development, so the examples below explain the architectural split rather than describe a deployment or an available product package.
Follow one action through the three parts
Consider an illustrative delivery exception. A customer reports that an order has not arrived. The business needs to establish what happened and decide whether a replacement is appropriate. The eventual action may involve updating the order and instructing a delivery service.
The domain pack supplies the order and delivery concepts, the tasks that assess the case, and the rules governing a replacement. Its tool adapters connect those tasks to the relevant business systems. The pack also defines the events and measures needed to describe its work, such as the progress of a delivery case.
Synedrix OS supplies common mechanisms for assigning tasks, checking permissions, handling approvals, and recording execution. Those mechanisms must remain useful even when the business task is an operational incident rather than a delivery. They should not need a built-in understanding of parcels to carry an authorised decision through to an outcome.
The business instance combines the platform and selected packs for a particular company, team, or unit. It holds the applicable configuration, including credentials, approval thresholds, and approver assignments. Two companies can use the same pack while configuring different settings within the range the pack permits.
That distinction prevents a common source of confusion. The business instance is more than a settings file, because it is the configured runtime in which work happens. Its settings still cannot grant a pack permission to ignore the platform's controls or invent a capability the pack does not provide.
Use the rule of inclusion to place a change
The rule of inclusion asks what kind of knowledge a capability needs. If it can be reused across business areas without domain knowledge, it belongs in the shared platform. If it depends on domain entities, tools, or policies, it belongs in the relevant pack. A company-specific value or deployment setting belongs in the business instance.
For the delivery exception, deciding whether an order qualifies for a replacement requires commerce knowledge. The rule must account for the order and the evidence about delivery. That decision belongs in the pack. The mechanism that sends a decision to an approver and records the answer can be shared.
The approval threshold illustrates the distinction between a mechanism and its value. The platform provides a controlled way to apply a threshold. The pack declares where approval is required and which settings it exposes. The company supplies an allowed value through its business instance. Changing the value should not require a separate implementation of approval handling.
The same reasoning applies to tools. A common framework can check and record a tool invocation without knowing how a particular delivery provider represents an order. The provider-specific adapter needs that knowledge and belongs with the domain capability. Credentials for the company's account remain with the instance.
Classify the responsibility before choosing where to implement it. A component used by two projects is not automatically a platform capability if both projects depend on the same business assumptions. Reuse across domains requires removing those assumptions from the shared mechanism while preserving them with the business rule that needs them.
Give the pack enough information to participate
A pack needs more than an agent that can answer questions about deliveries. It must describe the work it contributes in terms the platform can use. That includes the tasks, their expected inputs and outputs, the tools they require, and the conditions under which an action may proceed.
For the replacement assessment, the next task needs a result tied to the relevant order and evidence. A plausible paragraph saying that a replacement seems reasonable leaves too much for the recipient to infer. The result should make the recommendation and its supporting facts usable by the approval and execution steps.
The pack also needs to declare the permissions its agents require. The company then grants the actual permissions appropriate to its instance. A declaration is a request within the platform's model, not permission to reach every system holding related information.
A shared record format helps connect these tasks. Commerce can use its own event types and business measures while preserving the identifiers and execution records needed to follow the work across the platform. Operations can describe different work through the same common standards. The business meaning varies, but the organisation can still examine who acted and what happened next.
This is where the boundary becomes useful to an engineer. The pack defines the business behaviour and connects it to common interfaces. It does not supply a private approval path or an unrelated audit mechanism that the rest of the platform cannot examine.
Configure a company without copying the platform
Two companies may reasonably handle the same delivery problem differently. One might require a manager to approve a replacement above a particular amount. Another might allow a different threshold or assign the decision to a different role. Those differences belong in configuration where the pack explicitly supports them.
The business instance owns the company's choices within the permitted configuration. It selects enabled workflows, supplies the relevant secrets, and assigns approvers. The pack retains ownership of its reusable business logic. The platform retains ownership of the rules and mechanisms every pack must follow.
This does not mean every requirement can be expressed as a setting. A new business rule may require a pack change. A company-specific integration may need a governed extension. Treating all such work as configuration would hide real changes in behaviour behind values that were never designed to carry them.
The architecture provides a business instance extension for a customer-specific addition. Such an extension remains scoped to that instance and must use extension points the pack declares. It passes through the common registration and control requirements. It cannot create an informal route around them simply because only one company needs it.
The practical benefit is clearer ownership of a difference. A threshold change, a reusable pack feature, and a one-company integration can each follow an appropriate path. Copying the whole platform for one exception would make those differences harder to locate and maintain later.
Change a pack without changing every running instance
Reuse also raises a question about updates. A pack maintainer may improve the delivery assessment or add support for another tool. The fact that the new version exists does not establish that every company should begin using it immediately.
A business instance pins the pack version it uses: it explicitly records which version should run. Publishing another version makes it available; using it in that instance requires an explicit change to that recorded choice. The organisation can therefore assess the proposed change and its consequences before adopting it.
Testing still needs to follow the business outcome. If the assessment returns a new field or interprets delivery evidence differently, later approval and execution tasks must remain compatible. A matching format helps, but it does not prove that the recommendation is correct or that the company's settings still express its intended policy.
Shared platform changes need similar attention across the capabilities that depend on them. Improving a common approval mechanism can benefit several packs, while a mistake there can affect several uses. A shared owner makes that responsibility visible; sharing does not eliminate the need for careful review and verification.
Version boundaries therefore support the broader model. The platform, pack, and instance can evolve with explicit responsibilities instead of relying on every team to notice every change elsewhere. That coordination has a maintenance cost, which needs to be considered alongside the duplicated work it can remove.
Examine the boundary through a real business capability
The delivery example provides a practical way to assess the model. Follow a replacement request and identify which part owns each decision. The pack should explain the business rule. The instance should supply the applicable company settings. The platform should provide the common checks and connected execution record.
Then examine an exception. If the delivery evidence is incomplete, the request needs an owner and a defined next action. If a proposed replacement exceeds the permitted scope, changing an instance setting should not silently make an otherwise forbidden action acceptable. Those cases reveal whether the boundaries are enforced or merely described.
The previous post, Introducing Synedrix OS: the governed operating layer for agentic business, introduced the shared responsibilities. The next post, The 12 principles that make agentic systems trustworthy, examines the requirements that this separation, and every other part of the architecture, must satisfy.
Related reading
- Introducing Synedrix OS: the governed operating layer for agentic business — introduces the common platform responsibilities used by each pack.
- Next in the series: The 12 principles that make agentic systems trustworthy — explains the requirements that apply across the three parts of the model.
Documentation
- Taxonomy & Platform Spec: the platform, pack, and business instance definitions and boundaries.
- Responsibility Matrix: ownership of shared mechanisms, business logic, configuration, and version activation.
- Domain Pack: the capabilities a pack contributes and the shared services it uses.
Synedrix OS — rule of inclusion
