Consistency
The same inputs and rules produce the same committed outcomes — across time, teams, and channels
One implementation of each rule, one authoritative interpretation, one audit trail — not N parallel versions that drift with every team and release.
Consistency is the aim that the same rule applied to the same facts yields the same committed decision — regardless of which channel, team, or release cycle initiated the process.
The aim
Inconsistent enforcement is what happens when cross-cutting invariants are re-implemented in every product team (Article 19). Each team interprets ambiguous cases differently; each maintains its own audit fragment; each updates on its own schedule. The organisation appears to be checking everywhere while holding nowhere authoritative.
Consistency requires platform domains as single writers for shared invariants — one stream, one interpretation, one trail.
In software systems
Consistent systems centralise invariant enforcement in designated writers. Product services publish events and consume committed platform decisions — they do not embed divergent copies of compliance, credit, or KYC logic.
In human organisations
Consistent organisations name one authority per cross-cutting obligation. “Everyone checks KYC” is replaced by “the KYC domain commits; everyone consumes.”
In socio-technical systems
Consistency at scale uses reservations and asynchronous platform decisions (Article 19) — not global locks or standing approval queues that serialise all work.
What threatens this aim
Failure modes: Impossible simultaneity presents inconsistent aggregate views. Bundled events obscure partial failure across combined commitments.
Anti-patterns: Diffuse write authority guarantees N implementations. Locking organisation substitutes serial approval for single authoritative interpretation.
Principled support: Single writer principle at product and platform layers — stratified, not abandoned at scale.