Glossary
One term, one meaning. These are the words used in the GembaOS console, in its policies and on this site; every other page links here instead of redefining them. 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.
work_itemA Work Item is the persistent record GembaOS keeps for one unit of work: who asked for it, on whose behalf it runs, every agent turn, every policy decision, every signature and every execution, in order and hash-chained.
Everything else in this glossary hangs off a work item. A customer request, a monitoring alert, a pasted list of leavers or a meeting's approved minutes each open one.
approval_requestAn Approval Request is the document GembaOS composes when a policy says an action needs a signature: the facts verified by the governance kernel, the exact arguments, the reasons, and the chain of approvers the route requires.
It is what a person sees on the approval desk. Signing it issues a clearance token bound to the arguments it shows, and nothing else.
clearance_tokenA Clearance Token is a single-use, time-limited authorization that GembaOS issues for one approved action and binds to the hash of that action's arguments (argsHash). Executing the action consumes it; different arguments do not match it.
The token is why an agent never needs a business-system credential: the gateway holds the credential and releases one call for one token.
stale_approvalA stale approval is a human decision that was correct when it was made and no longer matches reality when the action runs: the record was edited, another approved action touched it, a limit moved, or the decision simply waited too long.
It is a failure of timing, not of the agent. GembaOS narrows the window by re-reading the approved facts and the target system's own limits just before the write, holding the record for the duration, and giving every clearance an expiry.
idempotency_keyAn idempotency key is the identifier that tells a target system a write it already accepted is the same write, not a new one. GembaOS derives it within the runtime kernel from the approval and the work item, so the agent never chooses it.
It is what makes one approval at most one write when a call is retried, replayed after a restart, or duplicated by a timeout. The clearance being single-use covers the same ground inside GembaOS; the key covers it inside the system being written to.
signature_chainA Signature Chain is the ordered set of stamps on an approval request: agent stamps for the checks the policy delegates to agents, and human stamps made with a passkey for the steps the route reserves for a person.
Each stamp carries who, when, why and what was seen. The audit view replays the chain against the current policy.
human_routesConsult, transfer, escalate and take over are the four recorded human actions on a pending approval request in GembaOS: ask another role to review first, move the signature to a role with at least the same authority, hand the request to a superior, or take over a request waiting on a report.
None of them is a signature and none removes a required one. Each carries a reason on the work item, and whoever signs in the end signs with their own passkey.
delegation_of_authorityDelegation of Authority is the table that tells GembaOS who may authorize what, up to which limit, by role and by amount or risk class. The policy reads it to decide whether an action passes on agent stamps or needs a named approver.
It is usually a transcription of the authority table the company already has. The first two weeks of the design partner program are spent writing it down.
on_behalf_ofOn-Behalf-Of is the rule that every agent action in GembaOS runs in the name of a specific employee and inside that employee's authority; the agent gains nothing the employee does not have.
It is what makes the audit trail readable to an auditor: the actor is a person, the agent is the instrument.
capability_gatewayThe Capability Gateway is the component of GembaOS that stands between agents and business systems. Agents see capability names and schemas; the gateway holds the credentials, checks the policy, reserves and consumes clearances, and calls the adapter.
Reads pass through it too, under field-level rules, so that an agent sees only the fields its role may see.
policy_replayPolicy Replay is the re-evaluation of a recorded decision against the current policy, producing the same route and rule chain from the same facts. GembaOS records enough of every decision for the replay to be deterministic.
It is how an auditor checks that a decision taken months ago would still be taken the same way, and how a policy change is tested against history.
shadow_replayShadow Replay runs recorded work items through a new model or a new configuration without executing anything, and shows where the outcome would differ.
It is the gate before a model change reaches production, and week five of the design partner program.
golden_testA Golden Test is a recorded conversation with its expected decisions that GembaOS replays offline against the runtime; a change that alters a decision fails the test.
Golden tests and the red-team cases are the evidence reviewed with a partner's security team.
audit_replayAudit Replay is the view that reconstructs a work item from its hash-chained events and re-runs the policy over them, so that the route, the rule chain and the signatures can be verified rather than trusted.
Every capture on the home page's audit tab is this view.
gap_registerThe Gap Register is the authoritative register where an agent files what it lacked to do a task: a missing runbook, an undefined limit, an unknown owner. A gap never widens authority; it names who should decide and waits.
Proposed procedures go to a review desk and become knowledge only after a person approves them.
architectThe Organization Architect is the console assistant an administrator tells, in their own words, how the company works. It reads the built-in documentation and the live configuration and proposes a rule release draft; every file it changes carries a quote of the administrator's own words, which GembaOS checks before drafting.
It cannot publish. The draft is checked at once, listing what is looser than before and every organization change, and a second person approves it. The same draft can instead come from rules written by hand or with an outside coding assistant.
teaching_recordA Demonstration Record is what GembaOS keeps when an employee shows a task once in the applications the company declared: the recordings of what the screens showed and the person did, what the assistant understood from them, and the rules the owner confirmed.
It runs nothing. A recording is an observation, never proof of what a system did, and a rule in it is a candidate until the person who answers for it confirms it in those words. Only confirmed rules can be quoted as the basis of a release draft.
limited_releaseA Limited Release is a rule release in force for part of the cases first - a share of applicants, or some teams and departments - while the other cases stay on the version in force. Each new work item is placed on one version when it starts and stays there.
The scope is signed with the files; a wider scope is another release a second person approves, and narrowing or withdrawing is done directly with a reason. It is off unless the administrator turns it on.
change_setA ChangeSet is a proposed change to a production system, drafted by an agent in a restricted sandbox and submitted as an approval request instead of being applied.
It is the IT operations scenario: the investigation may be autonomous, the change goes through change approval.
sandboxA Sandbox is the restricted environment where an agent reads, tests or drafts without reaching production. What the sandbox allows is recorded on the work item.
A bug fix is prepared in the sandbox and only the reviewed ChangeSet leaves it, through change approval.
official_answerThe Official Answer is the single response a customer or requester receives at the end of a work item: written by the governance runtime from approved facts, separated from the internal approval trail, and cited to the approved knowledge it used.
A classified or failed run produces an error answer, never a guess.
document_roundA document round is one request from the person handling a case to the applicant: the kinds of documents needed (from a closed list the playbook sets), a note, and a due date. The applicant answers on the ticket page, or by email, with files and a sentence.
A playbook limits how many rounds a case may have. A missed due date is recorded for the handler to decide on; nothing closes by itself. The approval request is drafted only once the file is complete, so the rounds happen on the work item, never on a signature.
applicant_confirmationApplicant confirmation is the applicant's own acknowledgement of what GembaOS recorded: their words, the files, the subject and when it arrived, rendered by the governance runtime and pinned by a hash. The applicant can confirm or say what is wrong; a correction is added, the original stays.
Where a playbook requires it, no approval request is drafted until the applicant has confirmed. The request then states on which date the applicant confirmed that exact statement.
consult_findingA consult finding is the conclusion a signer picks from a closed list before signing: covered or not covered, treatment necessary or not, terms acceptable or not. It enters the signature chain with the signature, and the playbook maps each finding to what happens next.
The next signer signs over the finding, not over a free-text comment. A finding such as "needs more quotes" can return the request and ask the applicant for named documents; the person picks the finding, the playbook decides the move.
since_last_viewed"Since you last looked" is the part of an approval request that shows each viewer what changed since their previous visit: days waited, signatures and findings added, new files, document rounds, corrections, the applicant's confirmation. Below it sits the one remaining decision.
The one remaining decision names the pending role, the question the playbook set for that role, and the latest finding still open. The signed content does not change; this is how the same record is presented to someone who comes back after two weeks.
Last updated: · GembaOS v0.2