Ownership and governance

The operating model is only useful if people trust it. Governance is what keeps a single, reliable map while still letting the people closest to the work keep it current. This page is for admins and core team members deciding who owns what, and how changes get made.

​

Open to read, scoped to edit

The model has one simple rule at its core:

Everyone in your organization can read the whole map. You can edit only the parts you own.

Open reading is deliberate. Transparency is what fuels the opportunity flywheel: trained people spot gaps across the whole company, not just in their own silo. Scoped editing is what keeps the map trustworthy: a process has one owner and one definition, not fifty divergent copies.

​

Ownership

Two kinds of ownership decide edit scope. Process ownership is assigned independently of the org chart. This matters because real processes cross org lines. Group Finance can own the definition of month-end close even though it is run in sixty country units, each with its own local leader. The owner of the definition holds edit rights over it; the units that run it can suggest changes.

​

Edit versus suggest

What a person can do to a given process depends on whether they own it. Core team and admins hold edit reach across the map; owners hold edit reach over what they own; everyone else suggests. This is the default, and it is safe: nothing changes a process without its owner’s agreement.

​

The suggest-then-approve flow

When someone who runs a process proposes a change, it does not apply straight away. It becomes a suggestion routed to the process owner. This is how ground truth from the frontline reaches the map without anyone losing control of it. The people who run the work know when a process has drifted; the owner decides whether the map should follow.

​

Granting direct-edit rights

The propose-then-approve default is right for most teams, but some move faster with direct editing. As an admin, you can grant direct-edit rights to specific people on a per-client basis, so a trusted manager can edit processes they run without waiting for approval. Use this where the team prefers speed and trust is high, and keep the safe default everywhere else.

​

Revision history keeps it safe

Every process and unit keeps a full revision history: who changed what, when, field by field. Changes are attributed to your team members, to your Kowalah partner, or to the system, so there is always a clear record. Any change can be reverted in one click. This is what makes the map safe to keep current: because nothing is ever truly lost, there is no risk in editing. A wrong change is a quick revert away, not a support ticket.

​

What’s next