Product governance

Why the system does not change behaviour without you knowing

A system that decides where the sales team spends its time can damage an operation in three ways: giving access to the wrong people, changing its criteria without warning, or erasing the trail of what happened. This page describes what exists against each one.

A permission is not a hidden button

Hiding an option from the screen prevents nothing — it only makes it harder to find. In Stonen the server is what refuses: the screen hides what a person cannot do because the server would already refuse it.

For your operation that means a salesperson does not reach another's book through an alternative route, and the technology role — which handles integrations — does not see price, margin or customer book.

The table of who may do what is generated from the code, not written by hand. A hand-written permissions document ages silently; this one cannot diverge without the generator saying so.

The decision stays human

The system does not send messages on its own, does not close deals on its own and does not change the owner of an opportunity on its own. It prepares, explains and waits.

When a manager acts outside their own book, that requires a declared reason, does not transfer ownership, and the responsible salesperson is notified. The exception exists so the manager is never blocked — and it is visible rather than silent.

The original recommendation is preserved alongside the person's decision, including when they disagree. That is what later makes it possible to ask whether following or overriding the system paid off.

The past is not rewritten

Each recommendation round keeps a snapshot of what was known at that moment: the material, the universe of customers considered, the evidence and the policy applied. Outcomes that only appeared later do not go back inside that snapshot — they are linked to it from outside.

This avoids the easiest mistake to make and the hardest to notice: recomputing an old recommendation with today's rules and concluding that the system was right all along.

In practice, it is what will allow the engine to be evaluated honestly six months from now — and it is also what makes it possible to say that it has not been evaluated that way yet.

The criteria do not change in silence

The prioritisation policy is versioned. Changing the criterion that orders the queue is a recorded and approved change, not a parameter tweak that shows up on a Monday.

Three statistical mechanisms run in parallel, without touching the queue the team uses, precisely so the comparison can be made before any switch. If one of them fails, the system does not publish a partial result: the known queue stays.

The "learned" mode is refused by the system until a trained, evaluated and approved model exists. It is a lock in the code, not an intention written in a document.

Nothing ships without checks

Every change to the product goes through a set of automated checks before it can be published: types, code rules, more than 1,500 tests, and a suite that opens the system in a real browser and replays the main flows.

Each published version carries the identification of which code it contains, and going back to the previous one is a matter of seconds, documented and already performed.

A test count is not proof of quality, and it is not here as if it were. What it gives is something else: when someone changes something, what broke shows up before it reaches your operation — not after.

How decisions are recorded

Decisions that change the product's behaviour are recorded in writing, with a date, the problem that motivated them and the alternatives rejected. When a decision is superseded, the old one is not deleted: it is marked as superseded, pointing to the one that replaced it.

For whoever uses the system, the effect is simple: the answer to *"why does it work this way?"* exists and can be found, without having to ask someone.

That record is internal to product development, not a contractual commitment. What it guarantees is continuity of understanding — not a customer right.

Page last updated September 22, 2026.