Glossary

Veritas is the product for repo and AI-agent governance. Surface is the transparency layer Veritas is built with. Veritas users should think in repo-native language; Surface-format claims and evidence are emitted at the boundary.

Canonical Veritas Terms

Term Meaning
Veritas A repo and AI-agent governance product for earning trust in AI-authored code changes.
Repo Standards The maintained definition of what good looks like for a repository.
Standards File The repo-local machine-readable artifact that stores repo standards.
Repo Standards Template A reusable starting point for repo standards, tailored to a repo type, language stack, or workflow.
Repo Map The repo-local model of work areas, change boundaries, protected areas, ownership context, and dependency relationships.
Work Area A meaningful part of a repository with a purpose, ownership context, and change expectations.
Change Boundary A coordination or risk threshold around a work area. Crossing it can add evidence, guidance, authority, or coordination requirements.
Boundary Crossing A change that touches a work area outside the expected scope, authority, or dependency path for the current work.
Protected Area A high-risk work area where changes require stronger authority or evidence.
Requirement A condition in the repo standards that must be satisfied, evidenced, or accepted by exception.
Requirement Applicability The condition that determines when a requirement matters for a change, repo state, release, recurring interval, work area, or boundary crossing.
Enforcement Level How strongly Veritas applies a requirement: Observe, Guide, or Require.
Observe Records evidence and outcomes without guiding or blocking work.
Guide Gives just-in-time correction or review feedback without by itself preventing merge readiness.
Require Requires fresh evidence or authority-backed exception before merge readiness or repo conformance is complete.
Evidence A traceable result, observation, artifact, attestation, or record that supports, challenges, or qualifies a requirement.
Evidence Check A runnable or inspectable check that produces evidence for one or more requirements.
Evidence Freshness Whether evidence still applies to the current change, including commit, diff, files, standards version, authority state, dependencies, and time policy.
Recheck An action that verifies evidence, authority, freshness, or integrity again for the current change.
Verification Authority A person, system, tool, environment, or policy source trusted to verify a specific requirement.
Authority Evidence Evidence explaining why a verification authority was allowed to count for a requirement.
Attestation Evidence from a verification authority asserting that something was verified, accepted, approved, or reviewed. Every attestation may carry an authorizing block (collection provenance) recording how the act was authorized: explicit-statement (standalone named act), exchange (prompt/response pair from a delegated approval conversation), or authorized-action (UI-driven control action with prompt ref, rendered prompt, action type, and authority ref). Old records without an authorizing block remain valid.
Exception An authority-backed decision to accept an unmet or failing requirement for a specific change.
Change Guidance Just-in-time instructions for a developer or agent when a requirement, work area, boundary, or evidence result matters.
Merge Readiness The per-change trust state that says whether a change has enough current evidence to merge under the repo standards.
Readiness Report The human- and agent-facing report that explains a change’s merge readiness.
Readiness Coverage The current evidence state for the requirements that apply to a specific change.
Repo Conformance Whether the repository as a whole currently satisfies standing requirements in its repo standards.
Protected Standards The parts of the repo standards and repo map that define what good looks like, where boundaries are, or who is trusted to verify requirements.
Standards Growth Additive improvements to repo standards that do not weaken protected standards without required authority.
Generated Evidence Readiness reports, evidence records, conformance outputs, feedback, and other artifacts generated by Veritas.
Standards Feedback Observed evidence about whether repo standards are helping, missing coverage, creating noise, or failing to catch issues.
Standards Recommendation A suggested change to repo standards based on standards feedback.
Built with Surface The product signal that Veritas uses Surface for portable transparency state.

Implementation names that predate this glossary are not canonical Veritas vocabulary. Track renames in Migration Guide, not in the product glossary.

Surface Mapping

Veritas emits Surface-format trust state as a producer. The mapping is intentionally one-way: Veritas owns repo governance language and Surface owns portable transparency primitives. The canonical mapping with artifact contract details is in Surface-Veritas Boundary.

Veritas concept Surface projection
Requirement evaluation Claim, evidence, policy, and event describing whether the requirement was satisfied
Evidence Check result Evidence and verification event
Verification Authority Authority trace, policy context, or verifier metadata
Attestation Evidence with authority and integrity context
Evidence Freshness Freshness, Changed Since Verified, or Expired Verification
Exception Authority-backed evidence plus metadata explaining the accepted unmet requirement
Merge Readiness Domain validity claim or trust snapshot summary emitted by Veritas
Readiness Coverage Claims, evidence, gaps, conflicts, and freshness outcomes
Repo Conformance Standing claims and evidence about repo-wide requirements
Protected Standards Claims and evidence about standards/map integrity and authority
Standards Recommendation Proposed claim and evidence supporting a standards change

Surface terms such as Claim, Evidence, Policy, TrustBundle, TrustReport, and Transparency Gap are valid when documenting the Surface boundary or API. They should not replace Veritas’ user-facing terms in normal product docs.