Product/Module Invariant Boundary
A module may own behavior, but the product owns the invariants. Modules can add workflows, templates, drafts, recommendations, and local operating state; they must inherit the product's truth plane, governance domains, event spine, approval model, kill-switch model, audit model, and recovery discipline.
Problem
Growing products often let modules become small independent products. Each module invents its own truth, settings, permission checks, queues, audit trail, and stop path. The product keeps a clean architecture in principle, but production behavior becomes a set of local exceptions.
Context
Use this pattern when a platform supports modules, plugins, addons, vertical workflows, optional capabilities, or assistants that can act inside the product.
Forces
- Modules need room to introduce domain behavior.
- Product invariants must remain true across every module.
- Plugin boundaries can make packaging look clean while governance remains local and weak.
- Operators need one way to stop, inspect, recover, and explain capability behavior.
- Acceleration and workers are useful only if durable work remains recoverable from truth.
- A module that can act on behalf of users inherits product risk.
Solution
Draw the product/module boundary around authority, not packaging. Let the module own behavior, but require it to inherit product-level invariants: durable truth, governance, eventing, approval modes, disablement, audit, observability, and recovery.
The module can prepare work, but platform approval decides whether consequential effects may happen. The module can use queues and caches as dispatch hints, but durable work records must be recoverable from product truth. The module can register capabilities, but control-plane facts decide whether they may act. The module can introduce new workflow facts, but it must not create a second source of durable truth for product facts such as orders, rights, ownership, approvals, or money.
Consequences
The product can grow without every module becoming its own architecture. Module teams keep local behavioral autonomy, while operators keep one truth model, one governance model, one recovery model, and one way to prove a capability can or cannot act.
Failure Modes
- The module owns a second durable truth store for product facts.
- Plugin packaging is mistaken for architectural integration.
- Module queues, locks, or caches cannot be rebuilt from product truth.
- Approval, disablement, or audit exists only in module-local settings or UI state.
- Incident response requires a bespoke stop path for each module.
Proof Points
inherits Ampriot's truth plane, acceleration discipline, event spine, approval gates, workers, and kill switches.
the invariants SADIE must inherit.
- SADIE — a workflow assistant module inside Ampriot that
- Ampriot — the product-level architecture that supplies
Full source pattern: product-module-invariant-boundary.md.