> ## Documentation Index
> Fetch the complete documentation index at: https://docs.visiqlabs.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Glossary
> One place for VisIQ's vocabulary — governance outcomes, operation facets, agent modes, trust tiers, and the audit-trail primitives (record envelopes, Merkle checkpoints, the transparency log) and key audiences.
VisIQ's docs use a dense, precise vocabulary. This page defines every load-bearing
term in one place. Each entry links to the reference where the concept is used in
depth.
***
## Governance outcomes
A single rule engine evaluates every event and resolves it to exactly one
outcome. The same verb set spans both operation facets, though a few verbs only
make sense on one facet (a document can't pause a human; a tool call can't be
"redacted" the way a document is). See the full behavior in the
[SDK Reference](/reference#governance-outcomes).
| Outcome | Applies to | Meaning |
| ------------------- | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `permit` | action | The tool call runs unchanged. On the retrieval facet the passthrough verb surfaces as `allow` — the document enters the context window untouched. |
| `deny` | action · retrieval | The tool call never runs (a block message is returned as its output), or the document is silently excluded from results. |
| `approval_required` | action | The call pauses while a human approves or rejects it over Slack or email (Microsoft Teams coming soon). Times out fail-closed. |
| `mask` | action | The tool runs, but the named sensitive arguments are redacted first (outbound argument masking). |
| `redact` | retrieval | The document passes through with its sensitive fields and patterns masked in place. |
| `escalate` | retrieval | The access is recorded for human review. Retrieval is synchronous and never pauses, so the rule chooses whether the document passes through or comes back masked in the meantime. |
Two verbs name the same idea per facet: an action that proceeds is `permit`; a
document that proceeds is `allow`. The unified engine treats them as the one
"passed unchanged" outcome, split only by which facet produced it.
***
## Operation facets
Every event carries a multi-valued `operations[]` tag describing what the agent
is trying to do. A rule can target one facet or several, and a single hybrid tool
(one that both reads and writes) carries more than one facet at once.
| Facet | What it governs |
| ------------ | -------------------------------------------------------------------------------------------------------------- |
| `action` | What an agent can **do** — every tool call is gated before it executes. |
| `retrieval` | What an agent can **see** — every retrieved document is filtered before it reaches the model's context window. |
| `delegation` | When an agent hands work to another agent or sub-agent — the hand-off itself is a governable event. |
A tool that both retrieves and mutates (for example `retrieve_and_archive`) is a
hybrid: one decision tagged `['retrieval', 'action']` governs both legs at once —
the action side gates the call, the retrieval side filters what comes back.
***
## Agent modes
Every agent runs in exactly one mode. The mode is **server-authoritative** —
resolved on the backend and shipped to the SDK inside the rule bundle, where a
running agent picks up a change within seconds. Set it on the **Harness → Agents**
page, not in SDK config. See [Agent modes](/reference#agent-modes).
| Mode | Behavior |
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `monitor` | **The default.** Every event is evaluated and the would-be decision is recorded, but nothing is blocked, masked, or paused. Observe first, enforce when confident. |
| `enforce` | Decisions are enforced — denials block, masks redact, approvals pause. |
| `off` | Evaluation is skipped entirely: no enforcement and no telemetry. |
A new agent is auto-provisioned in `monitor` on first contact. Each agent's mode
can **inherit an org-wide default** or be **overridden per agent** — and even
pinned per operation facet via `mode_by_operation` (for example, enforce actions
while keeping retrievals in monitor).
***
## Trust tiers
Every agent is assigned a **trust tier** that, combined with its **business
function**, drives the seeded need-to-know defaults (a curated catalog of
35 default rules). Tiers run from most to least trusted:
| Tier | Meaning |
| ------- | ----------------------------------------------------------------------- |
| `tier1` | Highest trust — the broadest need-to-know. |
| `tier2` | Medium trust — access to sensitive categories is escalated or masked. |
| `tier3` | Restricted — no access to categories the agent has no need-to-know for. |
The matrix is need-to-know: an agent that needs a data category for its function
gets it at its tier; an agent with no need-to-know never sees raw values. See
[Retrieval Governance](/rules/retrieval/introduction).
***
## Audit-trail primitives
Every decision emits tamper-evident evidence automatically — no SDK import, no
extra call. These terms describe how a raw decision becomes independently
verifiable. See [Audit Trail](/record/introduction) and
[Decision Receipts](/record/receipts).
| Term | Definition |
| ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Record envelope** | The canonical record of one decision — its `source` (`action` / `retrieval` / `hitl`), the `event` that happened, and the `attestation` metadata. Persisted server-side off the request path, then attested. |
| **Ed25519 receipt** | The envelope's `event` is canonicalized, hashed, and asynchronously signed with an Ed25519 key. The receipt (signature, public key, payload hash) is stored separately from the envelope it attests. |
| **Merkle batch / checkpoint** | A background worker gathers unbatched receipts and commits their leaf hashes to a single **Merkle root**. Each signed batch is a **checkpoint** that commits to the previous batch's root, forming an append-only chain. |
| **Transparency log** | The hash-chained sequence of checkpoints. Its checkpoints are published to write-once (WORM) object storage as an external witness, so deleting, reordering, or backdating any batch breaks the chain detectably — even for VisIQ. |
| **RFC 3161 timestamp** | An independent timestamp authority (DigiCert) countersigns each Merkle root, attesting *when* the batch existed — a third-party clock the operator does not control. |
| **Content hash** | A hash over the envelope's `event`, pinned by the database in a generated column the application cannot write at ingest time. Proves the record was not edited even in the window between ingest and signing. |
***
## Key audiences
VisIQ issues API keys in two **audiences**. Audience is fixed at creation and is
not derivable from the key string — the `vq_prod_` / `vq_test_` prefix encodes
the **environment**, not the audience. See
[Authentication](/authentication) and [Managing API keys](/automation/api-keys).
| Term | Definition |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Harness key** | A runtime credential for the SDK / harness / agents. Confined to the SDK operational endpoints (evaluation, rule bundles, HITL polling, telemetry, record ingestion, agent registration, discovery reporting); not permission-scoped. Minted under **Settings → Harness Keys**. |
| **Management key** | Also called an **automation key** — a bearer credential for the management API (rules, agents, audit log, settings). Carries an explicit `resource:action` permission list chosen at creation. Minted under **Settings → API Keys**, or via the agent device flow. |
A harness key that calls a management endpoint is rejected with
`403 harness_key_not_permitted`; a management key is a superset and may also reach
the runtime endpoints its permissions cover.
***
## See also
Outcomes, framework detection, agent modes, and local evaluation in depth.
Key audiences, permissions, rotation, self-revoke, device flow, and MCP.