/feature-flags
A feature flag answers one question: is this available here? It is how a new module goes live
for one branch, is watched, and is then extended — rather than appearing for everyone at once.
How flags resolve
Flags resolve through the same scope chain as settings, most specific first:Managing a flag
1
Decide the scope
Almost always a branch. Organisation-wide is for capability everyone should have.
2
Turn it on
The module or behaviour becomes available to users with the right permission in that scope.
3
Tell the users
A module appearing without warning generates support calls, not adoption.
4
Watch before extending
Give it a full cycle in one branch before enabling it elsewhere.
Flags, permissions and jobs
Three different things can make a screen or behaviour unavailable. Check them in this order:
A collections module that is flagged on, permitted, but whose sweep job is off will show an empty
worklist forever — and none of the three layers is broken.
Flags and shadow mode
A flag makes a module available. It does not authorise it to act autonomously. Engines that touch money or reach residents also carry an enforcement mode setting that starts in shadow — staging actions for a human to confirm. Enabling the flag and switching enforcement to autonomous are two separate decisions, taken at two different times, on purpose.Rollout pattern
1
Enable in one branch
Ideally one with an engaged team who will report problems.
2
Run in shadow for a full cycle
Read what the engine would have done.
3
Enable action, still supervised
Humans confirm each action.
4
Extend to more branches
Once the first branch is boring.
5
Consider autonomy last
And per branch, never globally.