@kontourai/veritas weekly downloads statistics

Veritas

Documentation · kontourai.io/veritas

Veritas makes configured repo standards executable and reports the evidence behind a change’s merge readiness.

Define what good looks like for your repo. Veritas runs configured checks, gives the agent just-in-time guidance, and reports which applicable requirements are satisfied and which evidence is missing, stale, or failing. Your team sets the review policy and decides whether to merge; a readiness report does not establish code correctness or how much human review is safe to remove.

Engine and Governance Kit. @kontourai/veritas is a standalone evaluation engine — an importable library (engine API at @kontourai/veritas/engine) plus the thin CLIs used below. Its repo-installed product surface — scaffolding standards, wiring hooks, authoring standards, and delivering just-in-time guidance to agents — is packaged in this repository as the Veritas Governance Kit, which wraps this engine via its CLI + recorded artifacts (it never reimplements evaluation). Use the standalone CLI directly, as in the Quickstart, or adopt the kit inside a Flow Agents setup — both drive the same engine. See the Engine / Surface Seam.

Optional Survey plan review lets maintainers inspect proposed standards and record decisions before the existing governance workflow applies them. Local reviews retain their operator identity claim; a trusted host resolves human authority separately.

Quickstart

Inside a git repository:

npm install -D @kontourai/veritas
npx --no @kontourai/veritas -- --version
npx --no @kontourai/veritas init

veritas --version prints the installed package version, so setup records can bind the executable to an approved engine release. --no makes a missing install an error instead of a registry fetch: in a fresh clone it fails with npx canceled due to missing packages, naming the registry's latest version rather than your lockfile's, so run npm install first. init bootstraps repo standards, a repo map, and AI instruction guidance under .veritas/.

Once you've reviewed the generated standards, record an attestation with the attesting actor and a reference to the human approval. Do this before your first readiness check, or readiness reports advisory warnings that no attestation exists yet. By default Veritas checks only that the approval reference is present, not that the approval exists; see Attestation to require a resolved approval record:

npx --no @kontourai/veritas attest bootstrap --actor <authority-id> --approval-ref <human-approval-reference> --non-interactive

Now check the current working tree:

npx --no @kontourai/veritas readiness --working-tree

You'll see output like:

veritas: 8 files changed -> governance.guidance
PASS  evidence-check: node -e "process.exit(0)"
PASS  policy-changes-require-attestation: Active attestation bootstrap-2026-07-20T14-18-01-415Z-ba6e20f3f7ba matches current protected standards hashes.
PASS  required-veritas-artifacts: All required repository artifacts are present.
PASS  ai-instruction-files-synced: All required AI instruction files contain the canonical Veritas governance block.
PASS  prefer-veritas-routed-delivery: All required repository artifacts are present.

0 failures · 0 warnings · run `npx --no @kontourai/veritas readiness --check evidence` for full generated evidence

Governance Kit

This repository is also a root-valid Flow Kit repository. Install the Veritas Governance Kit directly from a pinned Git ref, activate its flows and skills, and then use its setup guidance to install or configure the standalone engine in the target repository:

npx @kontourai/flow-agents kit install \
  https://github.com/kontourai/veritas.git#v1.5.2 --dest .
npx @kontourai/flow-agents kit activate --dest . --format json

Git installation never executes setup scripts or silently installs the engine. See the Governance Kit guide for the reviewed engine-setup and readiness gate sequence.

What You Get

• Executable repo standards — requirements for tests, docs, protected files, shared contracts, release checks, security scans, and team-specific expectations.
• Merge readiness — a per-change outcome that says whether the current change has enough fresh evidence to merge under the repo standards.
• Readiness coverage — the evidence state behind that outcome: satisfied, missing, stale, failing, advisory, or recheckable.
• Change boundaries — work areas, protected areas, and boundary crossings that add coordination, evidence, or authority requirements when shared code is touched.
• Change guidance — just-in-time instructions for developers and agents so repo knowledge does not disappear during long AI sessions.
• Protected standards — stronger authority requirements for changes that alter the repo standards, repo map, or verification authorities.
• Standards feedback — observed evidence about where the standards are helpful, noisy, stale, or missing coverage.
• Standards recommendations — suggested improvements to the repo standards based on evidence, with explicit accept/reject review.

Caught In The Wild…