Show the work once, and get rules someone answers for

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.

Most of what a company knows about how a task really goes is in the heads of the people who do it. Writing it down as a rule takes someone who understands both the work and the configuration, and the time to do it. GembaOS has a third way in besides writing the rules and describing them to the organization architect: an employee does the task once, the way they normally would, and GembaOS helps turn what it saw into rules that someone answers for.

Watching work and drafting a process from it is familiar ground. What we built is the part after the recording, and this note follows it on the reference order screens that ship with GembaOS, which play the company’s own CRM and ERP: order search, order detail, payment lookup, a refund exception request and its approval, and the refund entry itself.

1. The company says what may be recorded

On the employee page, Show how I do this opens a demonstration record. The employee names the task, for example “Handling a refund exception”, and picks the applications to record from the list the company declared in its configuration. They cannot add one, and with no applications declared there is nothing to record. The company can also name fields whose values are never kept.

GembaOS then issues a recording code. It works for one recording and lapses after two hours, and it cannot be shown again. The record runs nothing: no approval, no clearance, no call to any system.

2. Do the work as usual

The employee enters the code and the GembaOS address in the browser recorder and works as they normally would. The recorder keeps, on the declared applications’ pages only, the page, what it shows under its labels, the controls the person used and the values they committed. It never keeps a password field’s value, a field a page marks as card data or a one-time code, cookies, stored browser data, network traffic or the clipboard. It has no code that clicks, types, navigates or submits, so it cannot act in the application.

Whatever it cannot or may not record becomes a marked gap rather than a guess: a stretch on another site, a pause, a control with no readable name, a part of the page embedded from elsewhere. When the person stops, they see every step. They delete what should not go, each deletion is itself kept as a gap, and they send or discard. Nothing leaves the browser before then.

On arrival GembaOS does not trust the recorder. It holds the recording to the company’s declaration again, dropping steps from other addresses and removing values from password fields. It keeps the rest as what it is: an observation, with a hash, of what the screen showed. A page that says “submitted” is not a settled payment, and the record says so.

The recording is stored beside the work item’s record, not in it. The work item’s record keeps where the recording came from, when, how many steps and the hash. The person can take a recording back after sending; the drafts read from it are deleted with it, and rules already confirmed stay. The company can set a number of days after which recordings are deleted, and without one they are kept until the person takes them back.

3. What the assistant understood

The employee’s assistant reads the recording as data and produces My understanding of the workflow: business steps, each resting on recorded steps; candidate rules, each with what is still unknown; and at most three questions, the ones about a wrong payment and about who decides first. GembaOS holds the proposal to the record: anything that points at nothing recorded is dropped, every step that writes to another system is marked as staying with a person, the numbers on the page are counted by GembaOS, and a rule counts as explained only when it quotes the person’s own answer. “I don’t know”, “that was a one-off” and “ask my manager” are answers.

In one run on 30 September 2026 against a real model (DeepSeek), on a single recorded refund exception, the assistant returned nine business steps, each on recorded steps, with the refund entry marked as staying with a person. It read the refund page as acceptance, not settlement, and noticed that the applicant and the approver were the same person. It proposed seven candidate rules with their boundary and currency unknowns, and three questions. After one answer, two rules became explained, and the assistant noted by itself that the answer had not addressed the question it was asked.

With several recordings of the same work, the differences are kept side by side. On three recordings on the reference screens (an ordinary member’s partial refund with an exception and a supervisor’s approval, a Gold member’s direct full refund, a disputed order left unrefunded), the assistant said the first two were handled differently and that the recordings could not show whether the member tier or the amount decided it. Its first question asked exactly that. After the answer it added a new unknown: whether 50,000 yen meant the order amount or the refund amount.

With no model connected, or one not approved for the data on those screens, a stand-in splits the steps by screen, proposes no rule and says so. The person then writes the steps and rules themselves, and everything after is the same.

4. The owner confirms, in those words

Candidate rules stay candidates. The person asks for confirmation, and the people who answer are the holders of the position the company named for that application (the CS supervisor, for the reference screens), or the demonstrator’s line manager where none is named. Each rule is confirmed or passed on, with a note. Nobody confirms a rule taught from their own demonstration.

A confirmation is pinned to the rule’s exact wording. If the person rewords a rule afterwards, the new wording carries no confirmation. A confirmation is a recorded act under the confirmer’s own name; it authorizes nothing to run by itself.

5. From confirmed rules to a release

The organization architect can be given a record’s confirmed rules, with what was unknown when they were confirmed and what the record leaves open (unanswered questions, rules nobody adopted, stretches the recordings do not cover). It quotes them as the basis of a draft. The approver sees “a rule a manager confirmed on a demonstration”, with the confirmer’s name and position, and what was left open.

The assistant also says where each taught step lands: an operation the company has, a signature, a confirmed rule, a system not yet connected, or the person. GembaOS accepts only a landing that fits. A step that reads lands only on an operation that reads. A step that changes a system lands only on an operation that changes a system and goes through an approval route, so a taught write never runs without signatures. A decision lands on a rule only when a rule confirmed on the same record is part of the draft. Everything else stays with the person, and the release page says why.

The release page draws each route the change moves, before and after, from the configuration. It can run the declared cases of the changed businesses on the draft’s own files in a runtime that cannot reach a live system; the release page calls this a shadow run. There the model is a scripted stand-in and every outside system answers from test data, and a connection with no test data answers as unreachable and is counted. It also takes cases from a second person who neither drafted the release nor demonstrated the work, judged on the candidate’s rules and the live rules side by side, with a table of which situations the rules’ conditions divide (below, at and above a limit; a flag raised or not) those cases reach. A case given before the files changed no longer counts as unseen.

A second person approves, and GembaOS publishes. If the owner takes a confirmation back in the meantime, the release stops: it can be neither approved nor published.

What GembaOS checks, and what it does not

What it does not do yet

• Browser applications only. The recorder is a prototype browser extension. Desktop applications are not recorded; we rehearsed reading them on two test applications of our own, not on a real business application.
• It does not replay clicks. Letting an agent carry out a taught step is outside this. Writes stay with a person until the system is connected as a governed operation.
• One demonstration is not a company rule. It is an employee’s experience. What a person could do in a system never becomes permission for anyone else, and a bypass seen once is not learned as routine.
• Recordings are stored in the company’s own storage with restricted file permissions. The company can have GembaOS seal those files under a key it holds itself, kept apart from the data; that is a setting, off until it is set, and it covers these files only. Encryption at rest of everything else is the company’s disk encryption.
• The trial run exercises GembaOS’s decisions, not a model’s reading, and the held-out cases cover the conditions written in the rules. A currency, an earlier refund or a duplicate submission remain for the declared cases.
• What has already been sent to a model provider follows that provider’s retention terms.

How we test it

What needs no model is covered by automated tests: what GembaOS keeps and drops from a recording, who may confirm, what a release refuses, and what a person’s withdrawal removes. A scripted rehearsal also loads the real extension into a browser and works a refund exception on the reference screens, stepping out to another site once and typing a password, then checks that no password is anywhere in the record. The step that uses a model was run by hand against a real model, as above; we do not claim a measured accuracy for it.