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 the host verified, 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.
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.
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 ledger 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.
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. GembaOS probes and records what the sandbox allows rather than trusting its name.
In the third demo act the bug fix is prepared in a sandbox and only the reviewed change leaves it.
official_answerThe Official Answer is the single response a customer or requester receives at the end of a work item: written by the host 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.
Last updated: · GembaOS v0.2