Does the rule work? Finding out from the cases, and changing it under a name

GembaOS is a zero-trust governance runtime for enterprise AI agents: policy-decided access, single-use clearance tokens bound to exact parameters, and accountable human approvals, running on-premises or in a private VPC.

An automatic band is a bet the company made: below this amount, at this risk, nobody needs to sign. “Most refunds went through on the rule” is what a working band looks like, and also what a band that stopped gating looks like. The numbers alone cannot tell the two apart. This note is about how GembaOS helps the people who answer for a rule find out which one they have, and how they change the rule when it needs changing.

The line we hold is the one the queryable-company note draws. Inside the authority it has been given, an agent keeps getting better at the work. The authority itself - who signs, which conditions let an act through without a signature, what may be touched - changes only through a release that a second person approves. Everything below produces material for that person. Nothing below changes the authority on its own.

1. Ask the person who owns the decision

GembaOS draws decisions nobody signed by a hash and puts each one to the position that owns it. The reviewer sees what the decision had in front of it: the operation, its arguments, the risk and facts it read, the rule that let it through and who confirmed that rule. They do not see what happened afterwards, because the question is about the decision, not the outcome.

The question is the same every time: if this had been in front of you, would you have agreed to let it through without a signature? There are three answers - yes, no, or can’t judge - and a “no” picks a reason from the list the playbook declares, with a sentence. Each answer is recorded under the reviewer’s name. Two reviewers who disagree are two records, never a vote, and the person who asked for the work item cannot review it.

An answer changes no rule. It is counted.

2. Look at what happened after the close

A case’s record used to end where the action ran. A playbook can now say what to look at afterwards, from one of three sources: a field read once some days after the close, the number of new work items about the same subject, or a value entered by a holder of a named position. Anything not yet due, unreadable or undeterminable stays unknown. It is not counted as a good result. An outcome is counted once and never starts anything.

3. Ask across cases, within what you may read

“How did refunds go last month, and what did the reviewers say?” is answered by read-only operations, made with the permissions of the person asking. The answers are grouped by business, never by person or customer. A business counts only when the person asking may read its data. The company can set the smallest count to show, and below it nothing is shown; with none set, the answer says so. Every answer also states what it cannot see: channels GembaOS is not connected to, businesses the person cannot see, and that the sample is a hash draw rather than a rate.

4. Notice when the inputs move

A release is the only way a band’s conditions change, and a release is checked and signed. What a release never sees is the inputs moving under the same conditions. An upstream system recalibrates its risk score, more cases land below the line, and the automatic share rises exactly as it would if the band were working well.

A playbook can declare how far that share may move. Once a day GembaOS compares, route by route, the share of acts nobody signed in the last window with the window before. A move past the margin opens one row in the gap register for the business owner. The row gives both shares and says whether the rule version was the same in both windows - in which case the inputs moved - or different, in which case a release moved the band and the owner checks that it was meant to. It tightens nothing.

5. Let the rule say when it stops

Rows and answers are advice, and while the owner reads them the band keeps working. So a band’s condition can read two facts GembaOS derives from the register: recent “would not have agreed” answers, and drift rows nobody has resolved. In the reference refund, two such answers within 30 days, or one unresolved drift row, send small refunds to the customer-service supervisor instead of the rule. The pause lifts when the answers age out and the row is resolved. Lifting it sooner, or changing the numbers, is a release.

This is a condition the company released and a second person approved, drawn on the route map like any other. It runs in one direction only: a reviewer’s answer can close a band, and never opens one.

6. Read off the route who does what

Buyers ask for a slider from “people do it” to “AI does it”. We do not have one, because a single notch would bundle together who acts, who signs and what is covered. The route map reads each band instead: who prepares what is decided (the AI, a person in a position, or GembaOS from the record), who decides (the confirmed rule, the signers in order, or the person signing for their own act) and who carries it out. It is read off the route itself, so there is no second setting to disagree with it. A step people run can be handed back to the AI on the guided-change form, with an instruction file the configuration already holds, and the signers stay where they were. Making a band automatic again is a separate change, confirmed by name.

7. Notice what people keep signing

The decisions a rule sends to a person can be counted too. GembaOS groups them by business and band, then by each feature the playbook declares - its facts, the arguments declared as a choice or as yes/no, and the risk flags - and counts how many were approved, rejected, returned or left to expire. Amounts and scores appear only as a range. Next to each feature it says whether the band’s condition reads it, and that answer comes from the rule itself, not from a model.

This is how a pattern nobody wrote down becomes visible. Say supervisors approve nearly every small refund that comes with a photo, and the refund rule never looks at attachments. The count shows the group, and shows that the rule does not read it.

A business review can turn that into a candidate, looser or stricter, at most three per review, naming the group it rests on and what it does not know. GembaOS checks that the group came back from that read, was not hidden for falling under the smallest count, and is not something the rule already reads. It then copies the numbers onto the candidate itself; the model does not type a count. The reference company runs this review once a month.

The candidate goes to the position that answers for the business, who confirms it or passes. Confirming changes no rule. It lets the organization architect quote the candidate, with its numbers, as the basis of a draft, and the draft is checked against the recorded decisions and approved by a second person like any other. The person who confirmed can take it back from their desk, and a draft resting on it can then not be approved.

People approving a group together is not a reason on its own. They may be signing without reading, and every answer says so.

8. Change the rule: check it, try it, then widen it

A rule change is a release. The check judges the recorded decisions again under the draft without re-sending anything. When the draft adds a fact - say, how many files are on the case - GembaOS works that fact out again from each case’s own record as it stood when the decision was made. A case whose record cannot give it is listed as not comparable, not counted as changed.

Two more steps are available if the administrator turns them on. Both are off by default:

• Run the draft on recent real cases. The most recently closed cases of the businesses the draft touches are handled again on the draft by the bound model. Every read is answered from what the case read at the time; a read the case never made is not made, and nothing is written, sent or carried out. The page sets the first act each run proposed beside the act the case actually took. Cases opened by a schedule or a rule, cases with files, and runs that stop before proposing anything are listed with the reason instead. The content goes to the model provider again and is paid for. One run is not a statistic, and nothing here stops the approval.
• Take effect for part of the cases first. A release can carry a scope - a share of applicants, or some teams and departments - signed with its files. While the scope holds, the version in force is untouched and the rest of the cases stay on it. A new work item is placed on one version when it starts and stays there. For a share, the placement is a hash of the release and the applicant that anyone can recompute, so the same applicant always lands on the same side. The release page sets the two groups side by side over the same period: work done, decisions by the rule and by people, the sample answers and the outcomes. A wider scope, or every case, is another release a second person approves. A narrower scope, or withdrawal, is done directly with a reason. Withdrawn, the cases on the draft follow the version in force from their next decision, their unsigned approval requests go back, and nothing already carried out is undone. See limited release.

What it does not do

• It does not widen anything by itself. No count, answer or outcome loosens a band, and nothing withdraws a release automatically.
• A release in force for part of the cases carries playbook definitions only. Instructions and wording are shared by both versions, so changing them is a release for every case. While one is in force, no other release can change that business.
• Two applicants in the same period can be handled under different rules. A business where that matters should scope by teams and departments.
• It counts only declared features. A pattern written in free text, or in what an attachment contains, is invisible to the count; making it countable is a release that declares a fact.
• The overview, the sample desk and the cross-case answers stay combined. The split by version is on the release page, where the comparison is made.