language / reference / public reference

2ok terminology explained

Short explanations and concrete examples for the governance and developer terms used across 2ok.

Terms here describe concepts and possible designs, not proof that 2ok has a deployed policy, approval or protected-execution service.

Each highlighted term has a short explanation and a concrete example. The same reviewed words appear in site tooltips and the machine-readable glossary.

agent governance

Rules, reviews and independent controls that limit consequential actions by an AI agent.

Example: An agent may draft a deployment change, but an independently controlled system should decide whether that exact change may proceed.

authorization

A decision that a particular action on a particular resource is permitted. An agent's request is not permission.

Example: A successful review of a proposed action is not authorization unless resource-side controls accept an exact, valid permission.

checkpoint

A saved point where a task can stop, be reviewed and safely resumed with its context intact.

Example: A long-running task could pause before an action. Durable 2ok task checkpoints remain planned.

CLI

Command-line interface: a way to run software by typing commands in a terminal.

Example: A developer may invoke a local CLI command to inspect a build or generate a preview.

delegation

Giving someone or something limited permission to act without sharing every privilege.

Example: A service may be allowed to propose one project update without receiving the human operator's other permissions.

digest

A compact data fingerprint for detecting changes, not proof that the content is true.

Example: A file digest lets a reviewer notice that bytes changed; it cannot show whether the content is correct.

evidence

Recorded observations or checks supporting a claim. Evidence does not grant permission.

Example: A passing test supports a claim about the tested input, not a claim that an agent is safe to execute a different action.

execution lease

A short-lived, narrowly scoped permission a protected resource can verify before acting.

Example: A planned protected connector might accept a permission valid for one approved action and reject a second use. 2ok does not yet run this service.

FFmpeg

A widely used local tool for editing and combining audio and video.

Example: The creative lab documents local FFmpeg production; the public website never processes uploaded footage.

FFprobe

A companion tool that inspects media metadata such as duration and tracks.

Example: A local editor can check a clip's duration with FFprobe before planning the edit.

immutable

Not changeable in place. Updates create a new version so earlier reviewed content remains identifiable.

Example: Reviewing version 4 of a proposal should not silently authorize an edited version 5.

MCP

Model Context Protocol: a standard way for AI software to discover and invoke structured tools.

Example: An assistant can use MCP to discover a tool's arguments; permission to invoke it is a separate question.

OIDC

OpenID Connect: a common identity standard for signing users in.

Example: An app can use OIDC to learn which user signed in, but identity does not automatically authorize every operation.

OPA

Open Policy Agent: software for evaluating policy rules separately from an application.

Example: A proposed policy service could ask OPA whether an action is allowed; the resource must still enforce that decision.

passkey

A phishing-resistant cryptographic sign-in credential, often unlocked by a device.

Example: A person may use a passkey to sign in, while a separate authorization decision still governs a protected action.

policy

A set of explicit rules used to decide which actions are allowed or need review.

Example: A policy might require review of a high-impact action; 2ok's independent policy service is planned.

principal

The named person, agent or service to which an identity, request or permission is attributed.

Example: A principal identifies who is asking; it says nothing by itself about what they may do.

protected connector

A separately controlled component that holds resource access and verifies permission before executing.

Example: In a proposed design, the connector—not the agent's prompt—holds credentials. 2ok has no deployed protected connector.

receipt

A record of what a system reports performing and the outcome observed.

Example: An execution receipt should identify the request and report whether the resource confirmed success, failure or an uncertain result.

replay

Trying to reuse an earlier valid request or permission. Protected actions should reject unintended reuse.

Example: A previously approved transfer should not be accepted as approval for the same transfer a second time.

scope

The limits of permission, such as which action, target or revision it covers.

Example: A request scoped to one file should not permit editing every file in the workspace.

storyboard

An ordered plan of video scenes, timing, and optional titles.

Example: A storyboard might specify scene order and a two-second title before rendering a local preview.

trust boundary

A separation between components with different privileges or responsibilities.

Example: Keeping approval decisions outside an agent process avoids treating the agent's own request as trusted approval.

WebMCP

An experimental browser interface for exposing website tools to compatible AI clients. Here the tools only read public information.

Example: This site's WebMCP search helps compatible agents find public pages; it does not approve or execute a protected task.

WSL2

Windows Subsystem for Linux 2: a Linux environment running on Windows.

Example: A developer may run Linux tooling through WSL2 on Windows; this alone does not create an independent security boundary.

Read the glossary as Markdown

Updated 2026-10-25 · Public reference, not an operational service