Governance is Discovered, Not Designed
Most systems start clean.
- entities are defined
- workflows make sense
- rules are added where they seem necessary
On paper, everything lines up.
Then the system is used.
That’s when things start to shift.
Where governance actually shows up
Not in the model.
In behaviour.
- a user overrides something because “it’s close enough”
- data passes validation but breaks reporting
- a transition is technically allowed but operationally wrong
- a required field gets filled with placeholder values
None of this is unusual.
It’s the system being exercised.
What this exposes
The original model usually captures:
- structure
- intent
- expected flow
What it doesn’t capture is:
- how often exceptions occur
- where users apply judgement
- which rules matter in practice
- which ones just get in the way
Those only become visible after use.
The problem with getting governance “right” upfront
Early governance tends to reflect assumptions:
- this field should always be required
- this transition should always be blocked
- this value must always be present
Some of those are correct.
Some are not.
Without real usage, it’s hard to tell the difference.
What actually happens
Two patterns show up repeatedly.
1. Over-constrained systems
- too many hard stops
- users work around them
- data quality doesn’t improve, it just becomes less visible
2. Under-specified systems
- rules exist in documentation
- not enforced in the system
- behaviour varies by user
Neither is stable.
A more reliable pattern
Start with:
- a clear structure
- a working system
- minimal but sensible constraints
Then observe.
- where do users hesitate?
- where do they override?
- where does data drift?
- where do downstream issues appear?
Those points are not noise.
They are signals.
Where governance should be applied
Once those signals are visible, governance becomes easier to place.
At specific execution points:
- before a record is saved
- before a state changes
- after a commit
- when data is displayed
At those points, the system can:
- allow
- warn
- block
- require approval
- record an exception
What changes when you do this
Governance becomes:
- targeted
- explainable
- based on actual behaviour
Instead of:
- broad
- assumption-driven
- inconsistently applied
A useful way to think about it
The model defines how the system should behave.
Usage reveals how it actually behaves.
Governance sits between the two.
Not fully defined at the start.
Refined as the system proves itself.
Where this tends to hold
This shows up consistently in:
- legacy migrations
- systems replacing spreadsheets
- partially understood workflows
- environments with a lot of manual intervention
In those cases, the structure is usually there.
It just hasn’t been tested under real conditions.
Closing thought
Governance isn’t something you get right once.
It’s something you place, adjust, and tighten as the system is used.
The system will show you where it needs control.
You just need to pay attention.