Domains connect. They do not leak.
Two things are true. Inside your own organization, areas can be connected: a problem in one (say, inventory) can raise pressure in another (say, logistics). Between different customers, nothing connects at all: no signal, no data, no learning crosses over.
In plain termsYour own departments can be linked together. Different companies are completely walled off.
“Cross-domain” and “cross-tenant” are not the same thing
| Meaning | Shipped | |
|---|---|---|
| Cross-domain | Between business units within one tenant: inventory to logistics to churn | Yes |
| Cross-tenant | Between two customer organizations | No. There is no path. |
Everything cross-domain runs against a tenant-scoped pool with isolation enforced in the database. A cross-domain rule is a rule between your domains. There is no configuration that reaches another customer’s world, and no shared calibration store to reach it through. That is a structural property, not a policy.
What connects today: two mechanisms, both inside your tenant
Cross-domain bridges. A declarative rule: when a source domain’s entity emits a signal above a threshold, inject pressure into named entities in a target domain. Inventory to logistics to churn is the canonical cascade. Propagation is deliberately acyclic: a bridge that would close a loop is refused, because a cascade that can revisit itself has no defined end and no bounded cost.
Evidence transfer observers. A watchdog over a source domain’s aggregate evidence. When it crosses a threshold, an observation is written into the target domain’s evidence ledger, where it fuses with everything that domain already knows.
Both are tenant-scoped, both are governed objects with an audit trail, and both are rate-limited: an observer that stays over threshold cannot fire on every tick.
What does not transfer yet, stated because you will ask
That is a real saving. It is a smaller claim than “the model transfers”, and it is the one we can evidence.
| Reusable across domains | Notes |
|---|---|
| Structure | Entity types, state dimension shapes, relationship patterns, intervention shapes |
| Dynamics libraries | Declared behaviors: seasonality, wear, decay, throughput, contract cycles |
| Connectors and ingest | The same paths into a new world |
| Evaluation harness | The same horizon discipline and null-baseline comparison |
| Governance | Policies, limits, budgets, audit and the promotion gate apply unchanged |
| Learned calibration | Does not carry over today |
The estate effect
- Marginal cost falls. Each new domain reuses the platform work rather than starting from zero.
- Cross-domain prioritization becomes possible. Once several worlds are modeled, the same currency (value at stake, cost to act, cost of waiting) puts a payment case, a churn case and a degrading machine in one queue.
- A shared ontology prevents drift. Consistency across the estate is an architectural property, not a governance aspiration.
Connect two of your domains and watch the cascade
Pick two worlds you already run. We will show how pressure in one reaches the other, and where the cascade stops.