Notes
Describe how your company works, and get rules that actually run
For operations leads and administrators setting up GembaOS for a company, and for the second person who has to approve what gets set up.
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 tools that govern AI agents start by handing you a configuration format. GembaOS gives you three ways in. You can design the rules yourself: write the files directly, or hand the built-in documentation to an outside coding assistant. You can open the organization architect and tell it, in your own words, how the company works. Or an employee can show the work once in a browser application the company declared; the rule’s owner confirms what the assistant understood before it becomes the basis of a draft. All three lead to a rule release draft that GembaOS checks and a second person approves.
This note follows the spoken-description route with a made-up online shop, Northwind Outfitters, starting from an empty company. The captures come from the real console. The architect’s answers were recorded from a live model (DeepSeek) on 27 September 2026 and replayed; the check, the approvals and the publishing ran as they would for you.
1. An empty company
A new company starts with nothing that is yours to decide: no approvers, no accountable people, an empty authority matrix. It carries only GembaOS’s own safety floor and the language packs. The setup checklist reads the configuration as it stands and says what comes next. Here the employee list has been imported and the first business is the open step.
2. Describe how the company works
The administrator, Alex Rivera, writes what they would tell a new operations manager: who handles refunds, how much the AI may settle on its own check, who signs above that, and who is accountable.
The architect reads the built-in documentation, the live configuration, the employee list and the operations the company can use. Then it asks what only the company can decide: how many people each band needs, whether approvers are ranked, what happens at exactly 100,000 yen. It does not pick those answers for you.
After Alex answers, it proposes a draft. Each line under Based on what you said quotes Alex verbatim. A quote that is not in what Alex wrote stops the draft before it exists. What the draft makes looser than before is listed on its own, and the check’s technical notes for whoever maintains the configuration are folded away.
3. The check and the second person
On the release page the same draft shows its organization changes: the new sign-off roles and who holds them, the authority matrix row, what each role may use, the accountable person, and which businesses they reach. The author cannot approve their own release. Jordan Kim, from Finance, approves it, and only then is it published.
4. Refine it, one conversation at a time
Nothing about the first draft is final. Each later sentence is a new conversation and a new draft.
A deadline on waiting sign-offs. “If a refund approval waits more than 24 hours, send a reminder; after 48 hours, pass it up to Alex Rivera.” The draft changes the sign-off deadlines in the organization’s settings and nothing else, and the check says which way each line goes.
Who sees which data, from next month. “Starting next month, people in Customer Support should only see customer data, not payment data. Finance sees payment data.” That becomes a declaration of what people see in the console. Because nobody’s view was limited before, a first declaration is shown as a tightening; what it gives each group is listed for information.
The same draft carries an effective date. Jordan approves it today; GembaOS publishes it at the start of 1 October on the company’s clock, and it cannot be published by hand before then.
The setup checklist now reads the new configuration: the organization, the first business and who decides are done; what people see, cover for absences and real connections are still open, each with a way to take it to the architect.
What GembaOS checks, and what it does not
| Who does it | |
|---|---|
| Understanding what the administrator meant, asking what is unclear, proposing files | The model (the architect) |
| The quote is really in what the administrator wrote; an effective date has words behind it too | GembaOS |
| The draft loads, the version moved, what is looser is listed, organization changes and their reach | GembaOS |
| Files outside the organization’s rules (model settings, the console’s credentials) are refused | GembaOS |
| Whether the words were understood correctly | The second person, who reads the draft before approving |
| Publishing | GembaOS, after the approval, or on the effective date |
How we test it
Every scenario in this note is also a test. A scenario is what the administrator said, the architect’s answers, and the properties the draft must have: a band on the refund route signed by Priya Shah, an automatic band, a customer-support employee who does not see finance data, an effective date of 1 October. The properties are read off GembaOS’s own compile of the draft, never off the model’s description of it, and the suite reruns offline. The same scenario then drives the console, which is where the captures above come from.
Next to the recorded scenarios sit red-team cases that play a model misbehaving on purpose: slipping an automatic band into a requested tightening, rewriting its own model binding, widening what everyone sees while narrowing one department, inventing a quote, backdating an effective date. Each one is caught by GembaOS, not by the model’s good behavior.
Recording the scenarios found real problems, which is why we record them. In an empty company the architect at first could see neither the operations it could use nor the employee list, so it guessed names; both are now part of what it reads, and an unknown operation comes back with the real ones. A new approval band put in front of the others was compared with the wrong band and reported as a loosening; bands are now paired by what they say, not by their position.
Questions this note answers
Does the organization architect change the rules by itself?
No. It can only propose a release draft. It cannot publish, cannot change its own model settings and cannot change the administrator's settings. The administrator submits the draft and a different person approves it; a release with an effective date is published by GembaOS on that date, on the approval already given.
What stops the model from slipping in a change nobody asked for?
Checks in GembaOS, not in the prompt. Every changed file needs a fact quoting the administrator verbatim, and the quote is compared with what they actually wrote. The check lists every change that is looser than before on its own line, even inside a file the administrator did ask to change. Files outside the organization's own rules, such as the model settings or the console's credentials, cannot be drafted at all. What GembaOS cannot check is whether the words were understood correctly; that is what the second person reads.
Can we skip the conversation and write the configuration ourselves?
Yes. The same draft can be written by hand, or by an outside coding assistant using the built-in documentation GembaOS exports. It goes through the same check and the same approval; the architect is one way in, not the only one.
As of September 2026 GembaOS holds no certification; the control mappings on this site are self-assessed, not audited. GembaOS is in its design partner stage. Read about the design partner program.
Last updated: · GembaOS v0.2