Glossary

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.

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.

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.

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.

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 and Decision 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 and Managing 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.

SDK Reference

Outcomes, framework detection, agent modes, and local evaluation in depth.

Authentication

Key audiences, permissions, rotation, self-revoke, device flow, and MCP.

Quickstart

Action Governance

Retrieval Governance

Delegation Governance

Unified Rules

Audit Trail

Discovery

Connectors

API Examples

Platform Automation

Partners

Reference

API Reference

Governance outcomes

Operation facets

Agent modes

Trust tiers

Audit-trail primitives

Key audiences

See also

SDK Reference

Authentication

​Governance outcomes

​Operation facets

​Agent modes

​Trust tiers

​Audit-trail primitives

​Key audiences

​See also

SDK Reference

Authentication

Governance outcomes

Operation facets

Agent modes

Trust tiers

Audit-trail primitives

Key audiences

See also