Architecture whitepaper

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. This page is the public reading edition of the GembaOS enterprise architecture whitepaper (document GEMBA-WP-2026-PUB, v1.17.1, 1 October 2026), written for CISOs, CTOs, CIOs, enterprise architects and risk, compliance and audit professionals.

Why do enterprises keep agents out of production?

GembaOS starts from one observation: what keeps agents out of ERP systems, production databases and privileged domains is not the model’s reasoning, but that the existing stack cannot answer four questions a risk committee asks.

1. Authorization: who authorized each write and each configuration change the agent made?
2. Accountability: when prompt injection or a hallucination causes a loss, who is the accountable person?
3. Data boundary: which sensitive fields did the agent read across its turns without authorization?
4. Evidence: how do we show a regulator or legal audit what was decided, under which rule and by whom, and that the record was not altered afterwards?

Guardrails and system prompts work on text, and an API gateway checks keys and traffic. On their own, none of them expresses the company’s chain of authority for one business act: who may decide it, what exactly was approved, and whether the facts still hold when it runs. While an agent only produced text, the reader carried the risk; once it can call APIs, text-level defenses are not enough: a guardrail that is bypassed exposes every API behind it, and an agent holding a long-lived credential can write beyond its brief while planning on its own.

These questions sit on four layers. Products for AI discovery, runtime gateways and business workflow each cover some of them, and several have approval steps and parameter controls of their own; the table says where GembaOS stands on each.

What are the architecture principles?

GembaOS assumes no implicit trust: instead of relying on the model’s good behavior, it compiles the company’s authority rules, maker-checker review, separation of duties and regulatory baseline into rules a machine enforces deterministically. These principles run through the runtime.

• Strict on-behalf-of delegation: when an agent acts for an employee, its effective permission is the intersection of the agent’s role, the employee’s own authority and the boundary the current playbook declares. Financial data the employee may not see, the agent cannot read for them; a purchase order the employee may not approve, the agent cannot approve for them. This is On-Behalf-Of.
• No accountability gap: there is no unowned autonomous action. Every work item, every read and every approval request is bound to a natural person in the company’s IAM or SSO.
• Data boundary at the gateway: unauthorized fields and unnecessary context are trimmed at the capability gateway and never enter the model’s context; database reads go only through read-only views with a declared column list and parameterized procedures, never free-form SQL.
• Controls aimed at the agent, not at the employee: an autonomous agent has no employee number and nothing to lose, so it wears all four gates. A qualified administrator acting under their own credential is a different case - they already carry the accountability, and the target system already logs them by name. There GembaOS records the act rather than queueing it: an approval band can be signed by the person performing it, in one step, and an emergency band executes first and attests immediately afterwards to the security roles it names, with a hardware key and a written reason. A control that stands in the way during an incident is a control people learn to route around.
• Model-agnostic authority: approval rules, business contracts and security boundaries are independent of the model. Replacing a self-hosted model with a cloud frontier model, or the reverse, leaves who may do what unchanged. What the model does inside those limits - its quality, its choice of tools - still changes, which is why shadow replay and golden tests show the differences before the switch.
• A vendor’s change is a review, not a surprise: an interface contract declares the shape a vendor answers, and a scheduled probe asks the vendor’s sandbox whether it still answers that way. What the vendor actually answered becomes a pending candidate schema; the GembaOS governance kernel walks its own declared contracts - preconditions, field lists, approval conditions - and prints what would stop working and whether the failure would be silent. The review opens under a named owner’s explicit authorization and needs the signatures the route names; a variable nobody set is recorded as skipped, never as passed. Once accepted, the fix is assigned to an accountable engineer, and a pull request drafted in the sandbox is reviewed and merged by an engineer under their own account.

How does the four-gate engine work?

GembaOS passes every sensitive state change through four gates in order: policy decision, signature chain, single-use clearance, and the preflight reality check.

• Two ways, and no third: an act is either decided by a named person, or let through by an automatic rule the company declared in advance and a named person in the company confirmed. A band nobody signs must be declared as an automatic rule, or the playbook does not load; an automatic rule that came with a template does not apply until someone in your company confirms it, and any change to it needs confirming again. When a rule lets an act through, the signature chain says which rule, which version and who confirmed it - never that a manager approved it.
• An AI’s stamp is advice: an AI reviewer reads the request ahead of the people who decide and gives its reasons. When it recommends rejecting, the request does not end there; it goes on to the person who decides. On a band with no person left, the AI’s objection brings in the person the route names, and the rule no longer lets the act through. A customer hears “declined” only when a named person rejected the request; a request the system refused, a model outage or repeated returns go to a person instead.
• Nothing nobody judged takes a band nobody signs: a proposal the system filled in from the record because no AI made one, and a work item the system opened by a rule because nobody asked for it, always need a person’s signature.
• What the gates do not cover: only calls that pass through GembaOS are governed. The re-read covers the facts the playbook declares, or the record the approver saw, not every fact in the world. Against writers outside GembaOS, only the target system’s own version or conditional writes stop a stale write; GembaOS’s own lease orders only the writes that go through it. A single-use clearance is not exactly-once delivery across systems: the target’s idempotency, the read-back and the handling of a write with no answer are part of go-live acceptance, and an acceptance suite runs those cases against the runtime.

What happens when the approver is away, or someone else should decide?

GembaOS records the human routes around a pending approval request as governed actions (consult, transfer, escalate, take over), each with a reason on the record, over an org chart imported from the company’s own directory.

• Only ever stricter: none of the four actions is a signature. None removes a required signature, and none lets one person hold two roles on the same request.
• A reason on every action: each action is an event on the work item’s hash-chained record. Returning and rejecting also require a reason; an approval may carry a note.
• The signer is accountable: a stand-in, an escalation target or a superior who takes over signs with their own passkey, and the signature chain records on whose behalf.
• Org chart from existing sources: managers, employment status and leave come from an export of the company’s identity provider or HR system. GembaOS keeps only the governance rules on top.
• Stand-in rules: set by amount threshold, risk or business type, for example “below the limit, the deputy signs” or “contract terms go to legal first”. A rule that matches produces the same consult or stand-in record a person would.
• Authority offboarding: when someone leaves, no new signatures are assigned to them; their pending requests go to the nearest available manager or wait for assignment, as the company decides; their delegations are revoked; their open work items are cancelled with a prompt to restart; approved actions not yet executed - including those no clearance has been issued for yet - can have their clearance voided and go back for approval, by approval band or classification; a run the leaver held goes to their nearest available manager or back to its own holder.
• Team Desk: beside their own desk, a manager sees what is waiting on their reports (pending signatures, overdue ones, requests nobody holds, absences being covered, high-risk items) and filters by person, department, business type, deadline, risk and age.
• One named handler on a running agent: a run that goes on for hours or days has one handler at a time, by default the person it runs for. Anyone allowed to see it can watch it live; who is watching is shown, not recorded. Only the handler can steer the agent (add context, narrow the scope, or redirect it within the playbook), and the agent reads the instruction at its next step: it changes what the agent tries, never what it may do, and its text passes the same injection checks as any incoming message. A login with no named person behind it can watch, but cannot be the handler. At the end of a shift the handler offers the run to a colleague, and nothing moves until the colleague accepts; an offer nobody accepts lapses after a day. A superior can take a run over under the company’s takeover rule. Hold, release and cancel carry the person’s name and a reason. None of this changes who signs: the signature stays with the role the route names, and someone who became the handler by a handover or a takeover cannot also sign that request on an ordinary band. Anyone watching may ask the assistant about the run; the answer is made with their own permissions and only they see it, and the handler may use it as their own instruction.
• The approval screen speaks business first: the first screen of an approval request answers “what approval sets in motion”: the effect and whether it can be undone, the target, the amount, the ceiling with the numbers checked, how long the clearance lasts and how many times it can be used, what is re-checked before it runs, and who runs it. Technical identifiers such as the clearance id and hash are folded away for auditors. What the system checked and what it did not are listed apart: a risk nothing scored is never shown as passed, and whether the stated reason is true and what attached files show are marked as not checked by the system, left to the person signing.

How does a case that takes weeks end as one approval?

A claim can run for weeks, gather a dozen files and pass through claims, medical review and legal. GembaOS keeps such a case on the work item, not on the approval request.

• Long work item, short approval request: after intake the case waits for the person handling it. They ask the applicant for documents (kinds from a closed list, a due date, a limit on rounds); the applicant uploads files and adds a sentence on the ticket page; a missed due date is recorded, and what follows is the playbook’s setting (by default, the person handling the case decides). Only when the file is complete is the approval request drafted: one request, signed once.
• The applicant sees and confirms, but cannot edit: GembaOS renders the statement from the record (their own words, the files, the subject, when it arrived). The applicant can confirm it or say what is wrong; a correction is added to the record and the original stays as it was. The confirmation is pinned by a hash, and the approval request states that the applicant confirmed this statement on a given date.
• A consulted finding is data: roles consulted along the way, such as medical review or legal, pick a finding from a closed list the playbook defines before they sign. The finding enters the signature chain, and the next signer signs over it.
• The finding decides what comes next: the playbook assigns each finding one action from a closed list: another role signs right after, the request goes back to the person handling the case, or it goes back and the applicant is asked for named documents. The approver picks the finding; the playbook decides what follows.
• What changed since you last looked: the approval request remembers where each viewer left off. On their return it shows the change first (days waited, signatures and findings added, new files, document rounds, corrections, the confirmation), then the one decision left: the pending role, the question the playbook sets for that role, and the latest finding still open. What is signed does not change.
• Facts derived by the playbook: days since the incident or the purchase, rounds answered, files on record, whether the applicant confirmed. GembaOS computes them from values the role may already see, on the company’s business calendar; approval bands and stand-in rules can use them. A playbook writes no free expressions, and a person’s stand-in rule is still a form.
• A whole case over email: for a case that arrives by email, GembaOS mails the applicant the recorded statement with a confirmation code. Replying with the code confirms it, and any other reply is recorded as a correction. Each document round is mailed too, and the applicant replies with the files attached.
• An agent may ask for documents, but only by kind: when a playbook turns this on, the specialist agent may ask the applicant for documents from the list. The applicant is told only which documents are needed; the agent’s reason goes to the person handling the case. New pictures are first described once at intake, and the other agents see only that description.
• The model investigates, people decide: a case playbook may declare an investigator, a model that reads the statement, the files, the answered document rounds and the records the playbook lets it read, and hands the signers a typed brief: the values the documents give, a chronology, issues from a closed list (a policy clause cited as the record gives it), the documents still missing and who is worth consulting. Like a capable staff officer, it also recommends: which outcome, up to three reasons (a cited clause is checked against the clause’s text like any other), the alternatives it weighed and what each would lead to, and the risks. The approval screen shows the recommendation in its own section, marked as the AI’s view for the signer to decide on, and says whether it agrees with what is being approved. It proposes no amount and signs nothing; its recommendation only ever raises risk flags and never changes what would be carried out, and a recommendation that differs from the default outcome closes the fast lane, so a person decides. GembaOS compares every value that has a counterpart in the record and marks it as matching or differing; a cited clause the record does not carry is marked as such. A difference, an issue or a missing brief is a risk flag that only ever adds a person to the route.
• A fast lane for small, clean cases: a playbook may let its own rule sign a small case once the applicant has confirmed the statement (a rule your company has confirmed), but only within the tenant’s authority matrix and only when nothing is flagged, the brief included. Every other case stays with the person handling it, and the reason is on the record. A case can also run without an investigator: the runtime then takes it in and drafts it on its own.
• Required documents, asked for by the runtime: a case playbook may name the documents a case must have, by a field of the record such as the claim’s category. The investigator only sorts the files into kinds; GembaOS checks each against the files the case actually has and works out what is still missing, and a required document that is missing is a risk flag. When the playbook turns it on, GembaOS asks the applicant for the missing kinds itself, at intake and after every answer, within the playbook’s limit on rounds and with one reminder before the due date. When the documents do not come, the playbook’s own setting applies: the person handling the case decides, the case goes to a named role, it is closed as incomplete (which is not a decision on the claim), or a decline is put to the people who sign it. A decline is never executed on a missed date alone.
• A cited clause carries the clause’s own words: where a playbook names the list of clauses a case may cite - a policy’s exclusions - it may also name the read that returns those clauses’ text. An issue that cites a clause then has to quote it, and GembaOS holds the quote to the text of the clause cited, as the investigator’s own read returned it: words that are in it, words that are not, or a citation with nothing behind it, each said on the form, and anything but the first a risk flag. The clause is printed in full beside the quote with the quoted sentence marked. The check proves the words are the clause’s - never that the clause carries the point, which stays a person’s judgment.
• What the customer reads: a fixed phrase, openable sentence by sentence: the official answer on a ticket is wording the company wrote, and which sentence is sent is decided by the runtime from the record, never by a model. A playbook may open a named sentence to a plainer rewrite. The writing model is given that one sentence and nothing else - no case, no records - and its draft is checked before it leaves: GembaOS itself refuses a number the phrase did not carry and a draft that runs long, and a second model reads the draft back against the phrase (same outcome, no added fact, no promise, no instruction, nothing beyond this matter) and answers only with the ids of what it finds broken, never with prose. A draft that does not hold is replaced by the fixed phrase, or rewritten once - told only which ids failed - and replaced by the fixed phrase if it still does not hold. The ticket marks a rewritten answer and shows the phrase it was written from, so the reader can check it themselves. The official answer states what was decided, such as the refund amount; a decline quotes only the reason the signer wrote, and nothing an AI reviewer or the specialist wrote reaches the customer.
• A customer who writes again reaches their own ticket first: when a customer writes again, in a new chat too, the assistant reads the verified facts on that customer’s own tickets and decides what they want: the status, to send documents, something new, or a person. A status question is answered at once, without opening a second ticket. Every number in the reply must appear in those facts, and a screening model checks it for a new promise, a changed decision, an invented reason or anything disclosed beyond the matter; a reply that fails is replaced by the fixed phrase. Disputes, exceptions, compensation, legal claims and anything that changes the customer’s rights become a task on the desk of the person accountable for the ticket, and their answer reaches the customer’s ticket under their own name.
• Five case desks built in: claims, procurement exceptions (where the applicant is an employee), warranty replacements, company-secretary changes (a client company’s director, secretary, registered office or significant controller, with the registry deadline and the client’s due diligence as facts) and nonconformance disposition (a quality engineer’s use-as-is, rework, scrap or return for a lot on hold). An applicant can open a case only on a record that belongs to them; someone else’s claim, serial, requisition, change or report number is treated as if it did not exist. Every case desk has an investigator that reads the record and the files, photographs included, checks the key values, lists the issues and recommends with its reasons: the warranty desk tells a fault from misuse in the photographs, and the nonconformance desk weighs use-as-is, rework and scrap. Who signs, and the rules they sign under, stay as they were.
• What is signed is what runs: what a case does is a field of the record the applicant named (the change type and the registry form, the proposed disposition), never a signer’s choice. The runtime reads the record again right before it acts; if the record was edited after a signature, the approval request goes back and nothing runs.

Can a business start with no agent in it?

Yes, and it is not a separate mode. Every step of a playbook names who does it - a person, the AI, GembaOS itself, or a rule the company confirmed - with a default. The AI is one of the actors a step may name, not the premise of the playbook.

• A person may write the brief: the same form the AI investigator fills on a case desk, checked against the record the same way. What the person wrote is recorded under their name; GembaOS does not screen a person’s own words.
• A person may fill in the proposal: the fields they enter are bounded by the same rules as an agent’s (not above the record’s value, one of the record’s options); the approval request names the proposer, and the proposer does not sign it.
• A person may carry the action out by hand: once the signatures issue the clearance, GembaOS calls nothing. The work item waits for a holder of the named position, who does the work in the system under their own login and reports done with the evidence the playbook asks for, under their own name. The report spends the clearance once; where the playbook names a read, GembaOS reads the system back and records whether it shows what was approved, or that it was read and recorded; without one, the record says it holds only what the person reported. A report of “could not” hands the request back.
• An operation a person carries out is still an operation of a pack: it has fields, a classification and field-level rules; it is declared as one nobody calls. GembaOS refuses a playbook that names a person for an operation a system could also perform.
• The route map draws every step in the lane of whoever does it, and a release that moves a step from a person to the AI, or back, lists it on its own line.

The reference company ships a business with nobody but people in it - the contract sealing desk: legal reads the contract and writes the brief, the operations lead and the finance director sign, legal applies the seal by hand and reports the seal register number, GembaOS reads the register back. Handing one step to an agent later is one release on the same playbook. GembaOS is not a replacement for a workflow tool: what it sells is the four gates and the record, and people were always one of the actors in them.

How are data, artifacts and the audit record governed?

GembaOS labels every record with a classification, a business domain and a data residency, and keeps every event of a work item in an append-only hash chain.

• Artifact classification: code changes and reports an agent drafts are managed as governed artifacts. A ChangeSet takes the highest classification of the files it touches; an artifact leaving the sandbox (a merge, a delivery, an outbound message) is a governed action that passes the same policy decision and signature.
• Meeting room and knowledge boundary: a raw meeting transcript never becomes an instruction directly; only the scribe agent drafts minutes, and only after the chair signs them off do they become a work item. A confidential document the caller may not read answers “not found”, exactly as a document that does not exist, so nothing can be probed.
• The room assistant works as the person asking: anyone in a meeting may ask the assistant, and it reads data with the asker’s own permissions, recorded on the asker’s own record. An answer drawn only from the meeting is posted with the name of who asked; an answer that used the asker’s permissions is a draft only they see, which they send under their own name, as is or edited, or drop. The chair still decides how much of the meeting the assistant sees, and nothing is approved or executed in a room.
• Action items go to the right business: once the minutes are signed off, the assistant suggests, for each action item, one of the businesses its owner may start; the person dispatching confirms or picks another before anything starts, and a business the owner may not start is refused.
• Hash-chained audit record: every event of a work item is appended and linked by a cryptographic hash chain; a modification, deletion or reordering breaks the chain, and integrity can be verified at any time. The chain shows that the record was altered; it does not stop someone who controls all of the storage from rewriting the whole chain, which is what the company’s own WORM storage or an outside anchor is for. The log is an ordinary file the company may keep on WORM storage of its choice for forensic and non-repudiation requirements; GembaOS ships no WORM storage of its own. Audit replay re-runs recorded policy decisions against the current policy; it does not re-run the model or the outside systems.
• The route, readable and comparable: the approval route a playbook declares can be printed as a diagram - in the identifiers and the condition the kernel evaluates, for the implementation and legal reviewers, or in the words the console uses, for the people who have to agree the route. It is one graph read two ways, and both are generated from the configuration rather than drawn, so a picture cannot quietly disagree with what runs. Every step names who acts: the model, a named person, or GembaOS itself, which re-reads the record and executes after the signatures. Two versions of a playbook can be compared, and each difference carries its direction - fewer people or more the rule may do alone, the reverse, or a change in what a role sees - so a change request arrives with the direction already on it.

How do existing systems and existing agents connect?

GembaOS wraps existing systems as governed capabilities through modular adapters, so nothing is rewritten, and interoperates with existing assistants and agent frameworks through MCP in both directions.

A reference playbook for an online marketplace shows the pattern on a price. The depth of the change decides who signs: a small adjustment goes through on its own (the approval request is still on record), a discount down to a fifth off needs the person who runs the storefront, and anything deeper also the person who answers for the money. The offer is read again before the price is written; if a repricer moved it after the signature, the request goes back.

• Outbound: a legacy system becomes a standard MCP tool that the company’s existing Claude Code, Copilot or Cursor can call; every call passes the four gates.
• Built-in agent, declared in the playbook: where the company has no agent of its own, GembaOS’s customer-facing agent is declared in the playbook, not written in code: which record the front desk checks, which record the specialist reads, which fields it may propose, and the rule each proposed value is held to against that record (equal to it, at most it, one of the values it lists, or the value it gives for another proposed field). The tools the model sees are generated from that declaration; a value the rule refuses is sent back to the model and never reaches an approval request. The runtime acts after the signatures, and the model is not on that path. Two reference playbooks use it: refunds, and flight rebooking, where the fare difference of the flight picked decides who signs. The specialist first looks up the policy in the approved knowledge library and reads what the customer actually wrote, and submits with a recommendation: proceed, do not proceed, or a person should decide. A proposal outside the refundable range is sent back with the range, so it can propose again. When the recommendation disagrees with its own proposal, the bands nobody signs close.
• External coding assistant (optional): a company that already runs its own coding agent can let it draft a code fix. It is wired in as a capability, never a role — a role can sign, a capability cannot. It sees only the files the fix plan declared, through the same read path the model uses and with secret paths refused as always; it has no command execution and no clearance. Its one output is patch text, which then travels the same validation, CI and approval path as any other change. It runs inside the company’s own network, so source code does not leave the tenant. It is an external system call, at the level of a REST call to a CRM: how it arrived at that draft is outside what can be replayed — only the hashes of the input and the output are recorded, and a playbook that turns it on has to say so.
• Inbound (bring your own agent): an agent built on LangGraph, Dify or a similar framework points its tool endpoint at the GembaOS gateway and gains approvals and clearances without changing its orchestration code.

Can we start before the SOPs are written?

The GembaOS Gap Register lets a company start safely without a complete set of procedures: when an agent meets an undefined procedure or boundary, it reports the gap and does not overstep.

1. The agent hits an undefined procedure or boundary, records the gap with a proposed draft, and does not guess.
2. The register merges gaps of the same kind and routes them, on a schedule, to the desk of the responsible owner.
3. The owner reviews on the review desk with a passkey; an approved procedure enters the governed knowledge library and the gap closes.

In daily operation the agents thereby turn the company’s scattered tacit knowledge into structured, compliant assets.

Can we describe how the company works instead of writing the configuration?

Yes. You can design the rules yourself beforehand (write the configuration files directly, or hand the built-in documentation to an outside coding assistant), describe in your own words how the company works to the organization architect, or show the work once in a declared browser application. All three lead to a rule release draft that goes through the same check and a second person’s approval. A demonstration is an observation, not a company rule: its owner must confirm the exact wording before it can support a draft. The browser recorder is a prototype and does not replay clicks.

1. It starts empty. A new company carries only GembaOS’s own safety floor and the language packs. Approvers, accountable people and the authority matrix all start blank; nothing is prefilled with a value the customer would later discover was ours. The setup checklist works out the next step from the configuration as it stands.
2. Every change carries your words. The architect reads the built-in documents and the live configuration, then drafts. Every file the draft changes needs a fact that quotes the administrator verbatim; GembaOS checks the quote really is something the administrator wrote and drafts nothing otherwise. An effective date needs your words too.
3. The check runs at once. The draft is compiled on the spot: the version bump, what is looser than before, the organization changes (approvers, teams, the authority matrix, what each role may use, who sees which data) and what they reach, line by line.
4. A person still approves. The architect cannot publish, and cannot change its own model settings or the administrator’s settings. The administrator submits the draft and a second person approves it. A release can take effect on a date: approved beforehand, published by GembaOS on the day.
5. It is refined step by step. Each later addition (a fraud team, keeping payment data from support staff, a higher automatic limit from next month) is a new draft, with its differences and their direction listed the same way.

A scenario suite goes with it: what the administrator said, the architect’s answers (recorded from a real model, or deliberately misbehaving red-team answers) and the properties the draft must have. The properties are read off GembaOS’s actual compile of the draft, never off the model’s description, and the suite reruns offline.

Can the people who do the work show it instead of writing it down?

Yes, for work done in a web application. Beside writing the rules and describing them, GembaOS has a third starting point: an employee does the task once, the way they normally would, and GembaOS helps turn it into rules that someone answers for. Watching work and drafting a process from it is familiar ground. What GembaOS builds is the part after the recording: a demonstration never becomes a rule by itself, it needs the person who answers for that rule, and it reaches the running company only as a rule release draft that takes the same check and a second person’s approval as any other. The note Show the work once follows it on the reference order screens.

1. The company declares what may be recorded. The employee chooses “Show how I do this” in the console, names the task and picks the applications to record from the list the company declared; they cannot add one. The company can also name fields that are never recorded. GembaOS issues a recording code that works once and lapses after two hours.
2. The recorder sees and cannot act. A browser extension records, on the chosen applications’ pages only, what the person does on screen: the page, what it shows under its labels, the controls used and the values entered. Password fields and fields a page marks as card data or one-time codes are never recorded; nor are cookies, stored browser data, network traffic or the clipboard. It has no ability to click, type or navigate. Leaving the chosen applications, or pausing, leaves a marked gap and no content. The person reviews every step, deletes any, and sends or discards; nothing leaves the browser before then. On arrival GembaOS holds the recording to the company’s declaration again instead of trusting the recorder.
3. A recording says what the screen showed. It is kept as an observation, with its hash, and does not claim the system did anything: a page saying “submitted” is not a settled payment. The recording is stored beside the work item’s chain, not in it; the chain keeps where it came from, when, the counts and the hash. After sending, the person can take a recording back; the drafts read from it go too, and rules already confirmed stay. The company can set a number of days after which recordings are deleted; the default is until the person takes them back.
4. “My understanding of the workflow”. The employee’s assistant reads the recording as data and proposes business steps, each resting on recorded steps, candidate rules with what is still unknown, and at most three questions, those about a wrong payment and about who decides first. GembaOS drops whatever points at nothing recorded, marks every step that writes to another system as staying with a person until that system is connected, counts the numbers the page shows, and treats a rule as explained only when it quotes the person’s own answer. “I don’t know” and “that was a one-off” are answers. The assistant receives only what the company’s data ceiling and the model’s approved data allow. With no model connected, a stand-in splits the steps by screen and says so, and the person writes the steps and rules.
5. A rule belongs to its owner, not to the demonstrator. Rules stay candidates until confirmed. The company can name, for each application, the position that answers for its rules (the CS supervisor for refunds, say); otherwise the demonstrator’s line manager confirms. Nobody confirms a rule taught from their own demonstration. A confirmation holds for the exact words: reword a rule and it is unconfirmed again. When an owner takes a confirmation back, a release draft resting on the rule can be neither approved nor published.
6. From confirmed rules to a release draft. The organization architect can be given a record’s confirmed rules, together with what was still unknown when they were confirmed and what the record leaves open, and quote 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. 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 changes a system lands only on an operation that goes through an approval route, so a taught write never runs without signatures; everything else stays with the person, with the reason.
7. What the approver sees. The release page draws each route the change moves, before and after. 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 model is a scripted stand-in and every outside system answers from test data. It 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 and which they do not. A case given before the files changed no longer counts as unseen. A second person approves; GembaOS publishes.
8. Several people can demonstrate one task. Whoever opens the record names up to ten colleagues. Each records under their own code and takes back only their own recordings. The assistant is told “person 1, person 2”, never who, because a difference between recordings may be one person’s habit. None of them confirms the rules or gives the held-out cases.

What it does not do yet. Teaching covers applications that run in a browser; the recorder is a prototype browser extension, and desktop applications are not recorded. A demonstration is an employee’s experience, not authority: one recording does not become a company rule, and what a person could do in a system never becomes permission for anyone else. Nothing replays the person’s clicks; writes stay with a person until that system is connected as a governed operation, and having an agent carry out a taught step is outside this. Recordings are held in the company’s own storage with restricted file permissions; A company can also have GembaOS seal those files under a key it holds itself (a setting that is off until it is set; the key is not kept with the data). 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; currency, an earlier refund and a duplicate submission remain for the declared cases. What has already been sent to a model provider follows that provider’s retention terms.

How does a manager run this day to day?

The four gates answer “may this act happen”. A manager also has to answer, every week, what agents the company has, what they are wired to, what a rule change would do, where the risk sits and how old the credentials are. GembaOS gives a console page for each of those questions, each derived from the configuration and the record rather than kept as a list, and none of them rounds a number up. The note What the manager sees walks six of them with pictures.

What does the company do when a rule outside it changes?

A regulation, a group policy, a supplier’s terms, a price list: when a text published outside the company changes, the question is not what changed but which of our businesses it reaches, whether it applies, and who changes what. GembaOS answers it with a few general pieces, and any outside text goes through them the same way.

• Watched sources: a knowledge source can be a folder or an https page, and any source can be marked as watched. When a scan finds a document created or rewritten, or its approved text changed, GembaOS sends an internal signal; the signal’s declaration decides which business it opens, on whose behalf, and that one document opens at most one review a day. A page is reduced to its text; like a file, it first becomes a draft, and a change takes effect only after review.
• GembaOS reads its own configuration: three read-only operations give each business’s description and who does each of its steps (businesses without AI included), which businesses cite a document or an operation set, and the line-by-line difference between the approved text and a pending revision. All three are tables computed from GembaOS’s own declarations; no model is involved.
• The investigator is held to that table: an AI reads the difference and every business description and hands in the businesses affected. GembaOS’s table of citations is the floor: leaving out a business that cites the document is marked as differing, and so is naming one that does not exist, and a difference closes every automatic band. The number of changed lines and the changed sections are checked the same way.
• A named decision goes into a register: the compliance owner signs whether it applies (consulting legal first if needed), and the decision is written to a general decision register, pinned to the hash of the revision the signers saw, which GembaOS reads again before writing. The same decision twice is refused; a change of mind is a new approval request, not an edited record.
• One task per affected business: each affected business gets a rule-change task for its own owner. The task can be done entirely by people: the owner writes the change, compliance signs, IT publishes it as a release and reports the release number, and GembaOS reads the business’s description back. The work item shows the chain: source document, impact review, register entry, the tasks.

The reference tenant’s regulation and policy change review is such a playbook: it has no code of its own, only configuration and its words in four languages. For a group policy or a price list, another playbook is written.

How do the controls map to compliance frameworks?

GembaOS maps the control requirements of the main cybersecurity, AI and financial-regulation frameworks to the mechanisms it has built; the mapping is our own assessment and has not been reviewed by an audit firm. As of 1 October 2026 GembaOS holds no SOC 2, ISO 27001 or ISO 42001 certification. We provide the design and the test evidence; the assessment is the company’s and its auditors’.

How does the six-week pilot run?

GembaOS proves business value on a standard six-week path with the least organizational friction; this is the design partner program.

How do the terms line up across languages?

GembaOS uses one set of core terms in its console, its policies and its documents in every language; the glossary defines each term once.

Related: security and deployment, the glossary, the FAQ.