Glossary

Each entry gives the mechanism, not a paraphrase, and links to the page that owns the term. Where a word is overloaded elsewhere in the industry, the entry says what Veritio specifically means by it.

Protocol and chain

AuditEvent — Portable, normalized application statement containing actor, action, target, scope, and minimized context. It is an input, not a stored record. See audit events.

AuditRecord — Stored envelope: the normalized event plus authoritative sequence, previousHash, hash, appendedAt, hashAlgorithm, canonicalization, and idempotencyKeyHash. Only a store can produce one.

Canonical JSON — Deterministic serialization used as the byte input to every protocol hash. veritio-json-v1 normalizes the supported JSON domain and sorts object keys recursively before serializing. See hash chain.

Hash chain — Ordered records where each record stores the prior record hash, making later mutation, deletion, or reordering detectable. Detection, not prevention.

Idempotency key — Host-owned retry identity. The store hashes it with tenant scope and rejects reuse for different canonical event content. The raw key is never stored.

Tenant chain — Independent sequence and hash-link state for one tenant. Two tenants may both hold sequence 1; their records must never be joined into one chain for verification.

Redaction — Deterministic minimization of metadata keys before canonicalization, so the same input always hashes the same way. See redaction.

Governed changes

Governed change — Veritio’s model for one authorized mutation, split into three linked records — a Change (declared intent), an Activity (execution), and a Revision (resulting state) — instead of a single flat event. See changes, activities, and revisions.

Change — The declared intent: what was asked, by whom (initiatedBy), under which optional authorization or delegation assertion, carrying a tenant-scoped idempotency-key hash. Reference kind change, id prefix chg_.

Activity — The execution record: who or what actually performed the change (performedBy) — a service, an operator session, an agent. Reference kind activity, id prefix act_.

Revision — The resulting governed state of one entity: a stateCommitment, sorted changedPaths, optional parents, and generatedBy. Reference kind revision, id prefix rev_.

State commitment — { algorithm, canonicalization, schemaRef, fieldSetRef, fields, digest }. The digest is sha256 over the canonical JSON of the post-policy fields object, so it commits to the minimized projection Veritio actually ships — never to the source database row. Anyone holding the evidence can recompute it from fields alone.

Capture mode — The per-field policy declared in defineEntity. Four modes are implemented — full, content_digest, keyed_digest, omit — and four names are reserved (randomized_digest, reference, redact, encrypt). Selecting a reserved mode fails at draft time rather than degrading to a weaker commitment. See the governed-change API.

Governed action draft — The output of createGovernedActionDraft, the host-boundary helper that derives change and activity ids, the tenant-scoped idempotency hash, and changedPaths, then delegates to createGovernedChangeDraft for protocol event and edge semantics. The draft holds evidence inputs: three AuditEventInputs, the evidence edges, and an outboxEntry. It carries no sequence and no record hash until a store appends it.

EvidenceRef — Authority-qualified pointer { authority, kind, type, id } used everywhere a record names another record. The authority is what makes an id safe to join across systems.

Reserved context key — A key in VeritioContextMetadata — activityEpisodeId, authSessionId, traceId, changeId, capturePolicyId, and others — that mergeVeritioMetadata applies after caller metadata. Governed changes reject a caller-supplied reserved key rather than replacing it silently.

One draft materializes most of these terms at once:

verified output

{
  "derivedIds": {
    "changeId": "chg_subscription_sub_9f31_312ca4bde590b545",
    "activityId": "act_subscription_sub_9f31_312ca4bde590b545",
    "entityId": "sub_9f31",
    "revisionId": "rev_subscription_sub_9f31_a71e2768812c_fe34f6d0",
    "idSeed": "312ca4bde590b545",
    "changeAndActivityShareOneSeed": true
  },
  "changedPaths": [
    "/plan",
    "/seatCount"
  ],
  "stateCommitment": {
    "algorithm": "sha256",
    "canonicalization": "veritio-json-v1",
    "schemaRef": "acme://schemas/subscription@3",
    "fieldSetRef": "acme://fieldsets/subscription-governed@1",
    "digest": "sha256:a71e2768812cca4e3609ce7e24460967d253e1ddab13d9a8898f4fd31a3564cb",
    "committedFields": [
      "accountEmail",
      "id",
      "plan",
      "seatCount",
      "status"
    ],
    "omittedFieldPresent": false,
    "accountEmailCommitment": {
      "captureMode": "content_digest",
      "digest": "sha256:aa69b0bc0b21a0ca7b5b5d1beb7556eb7d598f21d638db3eb9770ddd4fb30e45"
    }
  },
  "eventActions": [
    "change.declared",
    "activity.recorded",
    "entity.revision.created"
  ],
  "edgeRelations": [
    "has_activity",
    "has_output",
    "performed_by",
    "generated"
  ],
  "draftIsInputOnly": {
    "note": "createGovernedActionDraft returns evidence INPUTS, not persisted records. Append draft.outboxEntry through a conforming AuditStore inside the same mutation to make it evidence.",
    "eventsCarryStoreAssignedSequence": false,
    "eventsCarryRecordHash": false,
    "outboxMutationBinding": "same_transaction",
    "outboxSchemaVersion": "2026-06-23"
  }
}

Activity episodes

Activity episode — A Layer-1 grouping: a named span of work whose events all carry the same opaque metadata.activityEpisodeId. It is not an event-schema field, which is why an SDK that has never heard of episodes still hashes and verifies these records correctly. See activity episodes.

Episode stamp — The assignment of metadata.activityEpisodeId after caller-supplied metadata, so code under audit cannot choose which episode its own evidence lands in. Templates and the provenance recorder overwrite a caller’s value; governed changes throw instead.

Session id — The narrower sibling stamp, metadata.sessionId, scoping records to one agent session. One episode may span several sessions.

Evidence graph and commits

Evidence entity — A node from the closed type vocabulary: agent_session, pull_request, deployment, activity_episode, data_subject, and the rest. See the evidence vocabulary.

Evidence edge — Portable directed relation between two entities, stored in EvidenceEdgeRecord envelopes with their own independently sequenced hash chain and their own verifyEvidenceEdgeRecords pass. See the evidence graph.

Evidence commit — A separate record binding an ordered manifest of already-persisted records under one Merkle root, chained per stream. Members are references — { index, recordType, recordId, recordHash } — never copies, across six record types: audit.record, evidence.edge.record, entity.revision.record, activity.record, assertion.record, change.record. See evidence commits.

Records root — The Merkle root over a commit’s normalized member leaves. A one-member commit’s records root is its leaf hash unchanged.

veritio-merkle-v1 — The tree algorithm behind the records root: ordered leaves folded pairwise left to right, with an odd final hash duplicated as its own right sibling at every level. Leaf, node, and commit digests each use a distinct domain separator so they cannot collide. See evidence commit hashing.

Commit stream — The streamId a commit chains on. A valid stream starts at sequence: 1 with previousCommitHash: null; verifying one stream never reads another’s state.

verified output

{
  "recordChainVerification": {
    "ok": true
  },
  "suppliedOrder": [
    {
      "index": 2,
      "recordId": "evt_member_promoted_01"
    },
    {
      "index": 0,
      "recordId": "evt_member_invited_01"
    },
    {
      "index": 1,
      "recordId": "evt_member_joined_01"
    }
  ],
  "canonicalMemberOrder": [
    {
      "index": 0,
      "recordType": "audit.record",
      "recordId": "evt_member_invited_01",
      "recordHash": "sha256:9a753cb23031b9c49445207da15e758613573de613c503ce4b758b2ced783c98"
    },
    {
      "index": 1,
      "recordType": "audit.record",
      "recordId": "evt_member_joined_01",
      "recordHash": "sha256:376f6f2ea018a9fc6c946fcc7d61e358f8fc1ff82960bd66e0ff83c09327d300"
    },
    {
      "index": 2,
      "recordType": "audit.record",
      "recordId": "evt_member_promoted_01",
      "recordHash": "sha256:2fc2218e51e289d169e9de8d6915702c2b5c422789450c2bd3f7098d40f5a88f"
    }
  ],
  "recordCount": 3,
  "treeAlgorithm": "veritio-merkle-v1",
  "recordsRoot": "sha256:681c3111295b88bd29d3f15a4ab1db830cd1c78fc984989b3590e9db3504c55a",
  "commitHash": "sha256:739c10b06dccc577aa0ae9c38bd61ae204e6044f9ffdda7161142a00d0cd90be",
  "hashSelfConsistent": true,
  "orderIndependent": true,
  "commitVerification": {
    "ok": true
  }
}

Risk

Risk signals — The closed, non-PII vocabulary describing one operation: required operationType, optional reversibility, envCriticality, and the non-negative integer magnitudes dataVolume, fanOut, referenceCount. No field is a place for an identifier, path, or free text. normalizeRiskSignals fails closed on an unknown enum member or a non-integer magnitude rather than scoring low. See risk scoring.

Risk assessment — The result of scoreRiskSignals: a score in [0,1], a level, a policyVersion, and exactly six factors in fixed order, each with kind of base, additive, or multiplier. The factor list lets a reviewer recompute the score without holding the policy.

Risk band — The named level derived from a score by bandOf using half-open thresholds: none, low, medium, high, critical. Under veritio.reference.v1 the cut points are 0.05 / 0.25 / 0.50 / 0.75.

Episode rollup — rollupEpisodeRisk folding many step scores into one episode summary: peak, velocityScore, stepCount, and the banded result. Momentum decays by repeated multiplication, never exponentiation, so the three SDKs agree digit for digit.

Policy version — The string stamped into every conclusion so a score and the constants that produced it travel together. DEFAULT_RISK_POLICY is veritio.reference.v1; a derived policy gets a deterministic +tempX.XX suffix; any hand override makes an explicit policyVersion mandatory. See the risk policy reference.

Temperature — The single tuning knob on riskPolicy({ temperature }). A multiple of 0.01 in [0,1] rescales exactly nine pinned fields by two-segment linear interpolation, where 0.5 reproduces the reference policy byte for byte. It never adds or removes frequency rules. See tuning risk policy.

Frequency rule — A sliding-window burst rule { actions, windowSeconds, threshold, boost }. It fires at most once per episode when qualifying steps inside any window reach the threshold, and contributes to frequencyScore. Because that score joins a final max(), a rule can only raise an episode score, never lower it.

Security risk assertion — The append-only assertion.recorded envelope of type security.risk that stamps an already-computed conclusion onto an evidence subject. Its producer authority is fixed to veritio.detectors, and the builder never recomputes a score. hashAssertionRecord mirrors hashAuditRecord. See security risk assertions.

Storage and delivery

Authoritative store — A component that atomically owns tenant ordering, idempotency conflicts, expected-tip checks, and hash-revalidated reads. Only an authoritative store answers verify, DSAR, and definitive export requests. See the storage overview.

Derived tier — A copy that never owns sequence: the object archive in R2, S3, or MinIO, and the ClickHouse read model. Both keep canonical record bytes opaque and rehash on read, and both remain eventually consistent, so they serve recovery, long-range scans, and operational views only.

Conformance suite — createAuditStoreConformanceTests from @veritio/storage/conformance: the reusable checks a store must pass to be called authoritative — tenant-scoped ordering, idempotent append with conflict rejection, cloned reads, fail-closed missing tenant scope and expected-tip mismatch, and fail-closed corrupted-record integrity. See storage conformance.

Transactional outbox — A durable queue row committed inside the host’s own mutation transaction, drained later by a restartable dispatcher. It does not make evidence appending atomic with the mutation; it makes the intent to append atomic, so a crash cannot leave a mutation with no evidence. See transactional outbox.

Mutation binding — The honesty field on an outbox entry: same_transaction, not_transaction_bound, or best_effort, defaulting to not_transaction_bound because the SDK cannot observe whether the host truly enrolled the append. It is copied to metadata.captureAssurance.

Tip cache — A validated cached last sequence and hash. Redis support is a cache helper, never durable evidence storage.

Verification and exports

Verification — Recomputing declared invariants and returning an explicit pass or the first failure with a stable reason. It does not establish that a recorded claim was truthful or authorized. See the verifier reference.

vevb-1 — Veritio Evidence Export Bundle v1: a canonical container with manifest, file payloads, hashes, a verification report, and an optional signature. See the export format.

Chain scope — The claim a bundle makes about its own completeness, written into manifest.chainScope and hashed with the rest of the manifest. It is what a valid: true verdict must be read alongside.

Full chain — chainScope absent. Every included tenant chain starts at sequence 1 and is gapless. Evidence commits may only travel in a full bundle.

Windowed chain — A contiguous partial-chain claim with an allowed mid-chain starting boundary and strict linkage from there on.

Filtered chain — A partial-content claim that must declare filters. It cannot prove completeness of excluded records, and the verifier rejects filters without the scope or the scope without filters rather than falling back to full.

Governance and product

Evidence support — Technical records and checks that can support review, audit, or data workflows. Veritio supports compliance evidence; it is not legal advice and does not decide a legal outcome.

Retention label — An application-declared policy key on an event. It deletes nothing on its own and requires an operator-owned enforcement workflow. See retention.

Veritio Cloud — The optional hosted operating path. Open-source use requires no account, project, key, or proprietary store.

If a term would imply a guarantee, hidden behavior, or an unsupported Cloud feature, describe the concrete technical mechanism instead. Continue to the event schema, the parity matrix, or the documentation overview.