VERITAS separates implemented components, reproducible bounded proofs, measured benchmark outcomes, and customer-specific production validation. Each claim below is tied to its own source and scope; these are not interchangeable proof levels.

Choose your next step: Technical review · Architecture and current limits · Repeatable E2E · AgentDojo benchmark · Pilot evaluation criteria · Enterprise value brief.

For a customer-specific evaluation or potential paid PoC, propose a narrow effect boundary (such as a particular API mutation or approval-gated action), relevant identity/credential sources, a fail-closed bypass test, reviewer-visible receipts, and a reconciliation plan. Scope, fees, access and safety conditions require separate agreement; a PoC is not a production deployment. Contact · Commercial-use license.

Evidence discipline: A successful test run is evidence for its exact SHA, case population and assumptions. It is not evidence that every later commit, effect path, model, environment or customer deployment has been audited. The displayed 87% coverage is a 2026-03-24 CI snapshot, not current-head coverage (historical measurement).

VERITAS OS is a Decision Governance and Bind-Boundary Control Plane for AI agents.

Instead of passing model output directly to tools or external systems, VERITAS treats AI output as a Decision Candidate and routes it through explicit governance and execution boundaries before a real-world side effect can be committed.

The core distinction is simple:

Authorization at issuance ≠ permission at execution.

AI agents can increasingly prepare or initiate consequential actions:

• payments and financial operations
• IAM and permission changes
• production infrastructure changes
• compliance and risk decisions
• external API calls
• customer or operational workflow mutations

The difficult question is no longer only:

Can the model decide what to do?

It is also:

What must still be true before the organization allows that decision to become an external effect?

Between decision and execution, any of the following may change:

• the actor's authority
• the governing policy
• the target or scope
• a human approval's validity
• the execution credential
• the authorization's consumption state
• the external system's state
• the certainty about whether an earlier effect already occurred

VERITAS governs that gap.

flowchart LR
    A["AI / Agent"] --> B["Decision Candidate"]
    B --> C["Governance Evaluation"]
    C --> D["Authority · Policy · Approval · Evidence"]
    D --> E["Execution Authorization"]
    E --> F["Single-Use Consumption"]
    F --> G["Bind Boundary"]
    G --> H["External Effect"]
    H --> I["Receipt / Outcome"]
    I --> J["Read-Only Reconciliation"]
    J --> K["Reviewer Evidence"]

AI / Agent
   proposes
      ↓
VERITAS
   governs
      ↓
Bind Boundary
   permits or blocks
      ↓
External System
   produces an effect
      ↓
VERITAS
   records and reconciles evidence

VERITAS is built around explicit execution-governance invariants.

VERITAS contains a reproducible current-head Decision-to-Effect proof path that connects a governed decision to a controlled external effect and back to reviewer-facing evidence.

/v1/decide
    ↓
Canonical Decision Artifact
    ↓
Verified Promotion
    ↓
Native v2 Authorization
    ↓
Single-Use Consumption
    ↓
Current Governance Rechecks
    ↓
TLS POST
    ↓
PostgreSQL Persistence
    ↓
Read-Only Reconciliation
    ↓
BindReceipt / Outcome

The dedicated proof path uses:

• real TLS transport
• real PostgreSQL persistence
• durable authorization-consumption records
• current governance rechecks before dispatch
• deterministic decision / authorization / receipt lineage
• read-only reconciliation
• machine-readable proof artifacts
• exact tested commit identity in CI

The business decision, credentials, and external effect are controlled synthetic fixtures.

The normal scenario verifies that a governed action can move through:

Decision → Promotion → Authorization → Consumption → Revalidation → External Effect → Reconciliation → Receipt / Outcome

without bypassing the defined execution boundary.

The fault scenario covers a harder case:

External system commits the effect
              ↓
Caller loses the response
              ↓
        EFFECT_UNKNOWN
              ↓
        No blind retry
              ↓
     Read-only reconciliation
              ↓
      Original effect confirmed

The proof explicitly preserves the distinction between:

• no observed response, and
• proof that no external effect occurred.

While the effect is unresolved, VERITAS does not treat the missing response as permission to blindly issue a replacement business event.

• Reproducible Decision-to-Effect E2E Evidence
• Controlled Execution Proof Architecture Freeze
• Reconciliation-Capable Execution Profile Proof
• Runtime Proof CI Evidence

VERITAS deliberately separates implemented proof from production claims.

The controlled Decision-to-Effect proof does not by itself establish:

• production readiness in every customer environment
• real customer credentials
• real customer endpoints
• live bank integration
• live IAM / IdP / SaaS integration
• external UTC clock trust
• production SLA
• regulatory approval
• compliance certification
• completed third-party audit
• universal bind coverage of every effect-bearing route

The authoritative implementation boundary is maintained in:

Current Implementation Matrix

POST /v1/decide is the main structured decision path.

It produces governance and audit-facing lineage and provides the upstream decision context used by later execution-governance artifacts.

An AI decision is not, by itself, external execution permission.

VERITAS does not ask an LLM to govern itself.

flowchart TD
    A["LLM / Agent Proposal"] --> B["DecisionCandidate"]
    B --> C["Normalize"]
    C --> D["Validate"]
    D -->|"Incomplete / ambiguous"| E["Refusal / Human Review Evidence"]
    D -->|"Valid"| F["Execution Intent"]
    F --> G["Bind Adjudication"]

Incomplete or ambiguous model output is not automatically promoted into an executable intent.

See:

• LLM-to-Control-Plane Contract
• External Reviewer Quickstart

VERITAS represents execution lineage through explicit artifacts and transitions.

Decision
   ↓
Execution Intent
   ↓
Authorization
   ↓
Consumption
   ↓
Bind Adjudication
   ↓
External Effect
   ↓
BindReceipt
   ↓
Outcome

The Bind Boundary is the final governance point before a proposed action crosses into an external side effect.

See:

• Bind Boundary Governance Artifacts
• External Bind Integration Path

The repository explicitly documents bind governance for selected operator mutation paths including:

PUT  /v1/governance/policy
POST /v1/governance/policy-bundles/promote
PUT  /v1/compliance/config
POST /v1/system/halt
POST /v1/system/resume

This is an explicit documented subset.

VERITAS does not claim that every effect-bearing route is bind-governed unless that route is covered by the relevant bind-coverage documentation and tests.

VERITAS provides structured Authority Evidence handling for governance decisions.

Authority evidence can represent:

• identity
• scope grants
• scope limitations
• validity and expiry
• provenance
• deterministic evidence hashes

Missing, invalid, expired, stale, or indeterminate authority evidence can fail closed.

Current repository support includes deterministic local/offline ingestion and validation patterns. It does not imply completed live integration with every enterprise identity, banking, sanctions, or customer authority source.

See:

Authority Evidence Ingestion

Human approval is represented as a structured governance artifact rather than a simple Boolean.

Approval can be bound to:

• a specific action
• target
• scope
• decision context
• expiry
• verifier provenance

Secure / production postures require stronger verifier-derived provenance than local test compatibility state.

Human approval does not become an unlimited reusable execution capability.

See:

Human Approval Receipt

VERITAS supports durable single-use authorization-consumption semantics.

The intended invariant is:

one valid decision
        +
one valid approval
        ↓
one contextual authorization
        ↓
one valid consumption
        ↓
one governed effect attempt

A previously consumed authorization is not silently treated as fresh authority.

Outcome Receipt artifacts represent post-execution evidence for governed action attempts.

They can capture:

• observed outcome
• commit / block / rollback state
• postcondition status
• state fingerprints
• observed effects
• deterministic hashes

Outcome evidence records what was observed.

It does not grant new execution authority.

See:

Outcome Receipt

VERITAS includes reviewer-facing evidence-chain capabilities including:

• deterministic hashes
• evidence manifests
• validation reports
• Reviewer Evidence Packets
• trusted-public-key provenance workflows
• Ed25519 verification paths
• reproducible handoff artifacts

Integrity and trust are intentionally separated.

A matching hash can support integrity checking relative to an expected value; it does not automatically establish that the underlying authority source or public key should be trusted.

Start here:

• Reviewer Evidence Index
• Reviewer Evidence Assurance Overview
• Technical Proof Pack

Mission Control is the operator-facing governance surface.

It provides visibility into areas such as:

• decisions
• governance state
• audit evidence
• policy workflows
• bind artifacts
• risk state
• system posture

Frontend stack:

Mission Control is a governance and review surface. The UI itself is not the source of execution authority.

WebhookBindAdapter is the first reference adapter for external bind execution.

It demonstrates an integration pattern involving:

• governed action preparation
• target snapshot
• external HTTPS effect
• deterministic idempotency
• HMAC signing
• postcondition verification
• fail-closed behavior
• compensation semantics where supported
• bind receipts

See:

WebhookBindAdapter

This is a reference integration pattern, not production certification or proof of a completed customer deployment.

A minimal Python SDK reference is available at:

sdk/python/README.md

The SDK helps clients interact with VERITAS APIs and prepare integration payloads.

It does not bypass the execution boundary.

SDK request
    ≠
permission for external side effect

VERITAS includes a Regulated Action Governance Kernel covering concepts such as:

• Action Class Contract
• Authority Evidence
• Runtime Authority Validation
• Admissibility Predicate
• Human Approval
• Irreversible Commit Boundary
• reviewer-facing evidence

For selected regulated action paths, the kernel is designed to determine whether an execution intent should commit / block / escalate / refuse at the Bind Boundary.

See:

• Regulated Action Governance Kernel
• Authority Evidence vs Audit Log
• AML/KYC Regulated Action Path
• Regulated Action Governance Proof Pack
• Regulated Action Governance Quality Gate

The repository includes a deterministic fixture-backed AML/KYC governance PoC for reviewer and pilot workflows.

Start here:

• AML/KYC 1-Day PoC Quickstart
• One-Day PoC Evidence Pack
• One-Day PoC Operator Runbook
• One-Day PoC Reviewer Handoff Template

The AML/KYC customer risk escalation fixture is a deterministic engineering path for reviewing regulated-action governance behavior.

Audit Log vs Authority Evidence: an Audit Log records what happened. Authority Evidence records why an action was authorized and admissible at bind time. An Audit Log alone does not authorize commit.

VERITAS uses pluggable persistence for MemoryOS and TrustLog.

PostgreSQL is the formal production storage path documented by this repository.

Repository capabilities include:

• Alembic migrations
• PostgreSQL-backed MemoryOS
• PostgreSQL-backed TrustLog
• advisory-lock chain serialization
• JSONL → PostgreSQL migration tooling
• contention tests
• pool and health observability
• backup / restore / recovery drills

See:

• PostgreSQL Production Guide
• PostgreSQL Drill Runbook
• Database Migrations
• PostgreSQL Production Proof Map

Production guarantees still depend on the actual deployment infrastructure and operating controls.

VERITAS supports posture-aware behavior across environments including:

dev → staging → secure → prod

Higher-security postures can require stronger controls around:

• signing
• secret management
• approval provenance
• audit persistence
• replay behavior
• WORM storage
• trust evidence
• runtime configuration

See:

Security Hardening

• Python 3.11+
• Docker / Docker Compose for the recommended full-stack path
• Node.js 20+ for local frontend development
• an OpenAI API key for the default LLM configuration

git clone https://github.com/veritasfuji-japan/veritas_os.git
cd veritas_os
cp .env.example .env

Replace required CHANGE_ME values and configure the required application, API, database, and frontend authentication secrets.

Then:

docker compose up --build

Stop:

docker compose down

For Docker security configuration, see:

Docker Compose Security

Install:

pip install -e ".[dev]"
cp .env.example .env

Backend:

make dev

Frontend:

make dev-frontend

Both:

make dev-all

Open:

http://127.0.0.1:8000/docs

Authorize with the configured API credentials and call:

POST /v1/decide

Example:

{
  "query": "Should I check tomorrow's weather before going out?",
  "context": {
    "user_id": "test_user",
    "goals": ["health", "efficiency"],
    "constraints": ["time limit"],
    "affect_hint": "focused"
  }
}

/v1/decide produces a governed decision result.

It does not by itself authorize an external side effect.

pytest -q

Production-like validation:

make test-production

PostgreSQL smoke validation:

VERITAS_MEMORY_BACKEND=postgresql \
VERITAS_TRUSTLOG_BACKEND=postgresql \
pytest -m smoke veritas_os/tests/ -q

The repository contains workflows covering areas including:

• core CI
• CodeQL
• release gates
• security checks
• reviewer evidence validation
• reproducible Decision-to-Effect proof
• PostgreSQL-backed validation
• release evidence generation

A green workflow should be interpreted according to the scope of that workflow.

A passing focused proof is evidence for the proof contract it evaluates; it is not blanket certification of every deployment property.

See:

Operational Readiness Runbook

You do not need to read the entire repository to evaluate VERITAS.

1. README — product and execution-boundary model
2. Reviewer Entry Point — guided review path
3. Current Implementation Matrix — implemented vs partial vs roadmap
4. Decision-to-Effect E2E Evidence — controlled execution proof
5. Technical Proof Pack — reviewer checklist and proof assets

Continue with:

• Regulated Action Governance Kernel
• External Bind Integration Path
• External Bind PoC Evidence
• Reconciliation-Capable Execution Profile Proof
• External Audit Readiness
• Validation Evidence Map

For the detailed and maintained truth table, use:

Current Implementation Matrix

High-level summary:

VERITAS is not:

• an LLM asking itself whether it is safe
• a prompt-only guardrail
• a substitute for IAM
• a substitute for KMS / HSM infrastructure
• a substitute for organizational policy
• proof that every model output is correct
• proof that every external system is trustworthy
• legal advice
• regulatory approval
• automatic production certification

Its role is narrower:

Determine whether a proposed AI action is permitted to cross the execution boundary under the evidence and governance state available at that moment.

Traditional audit often answers:

What happened?

VERITAS is designed to make additional questions explicit before effect:

And after an attempted effect:

VERITAS has separate publications for system architecture and execution governance.

VERITAS OS: Auditable Decision OS for LLM Agents

DOI: 10.5281/zenodo.17838349

Japanese edition:

DOI: 10.5281/zenodo.17838456

VERITAS OS: From Authorization to Verified External Effect in AI Agent Execution Governance

• DOI: 10.5281/zenodo.22844531
• Zenodo Record 22844531

The execution-governance work focuses on:

• execution-time revalidation
• single-use authorization consumption
• explicit EFFECT_UNKNOWN semantics
• reconciliation-capability gating
• read-only reconciliation
• controlled reproducible evidence

The top-level README stays concise, while the following references remain part of the public review contract.

• Decision Semantics
• Required Evidence Taxonomy
• Intervention Actionability Map schema
• Intervention Actionability Map fixture

The Intervention Actionability Map artifacts are reviewer-facing evidence. They are not automatic enforcement, automatic blocking, automatic escalation, production decisioning, scoring, or certification.

• Builder: scripts/demo/build_reviewer_evidence_bundle.py
• Guide: Reviewer Evidence Bundle
• Validation workflow: .github/workflows/reviewer-evidence-packet-validation.yml
• CI artifact set: reviewer-evidence-packet-validation-artifacts
• Artifact manifest: reviewer-evidence-artifact-manifest.json
• Manifest verifier: scripts/demo/verify_reviewer_evidence_artifact_manifest.py

The checked-in illustrative provenance sample is under:

samples/evidence_bundle/key_provenance_review/

That sample chain includes:

• reviewer-handoff-review-result.json
• reviewer-review-result-validation.json
• reviewer-review-result-report-validation.json
• reviewer-handoff-package-validation.json
• reviewer-handoff-quickstart-command-validation.json

A reviewer result may record ACCEPT, REJECT, or NEEDS_FOLLOW_UP. These artifacts support review workflow and correlation; the trust source for a public key remains an out-of-band reviewer/operator trust channel.

• Performance Metrics
• Latest local performance metrics
• Latest local performance metrics JSON
• One-Day PoC Evidence Pack
• One-Day PoC Operator Runbook
• One-Day PoC Reviewer Handoff Template

These measurements are local/reviewer-facing engineering evidence. They are not a production SLA and are not a customer environment measurement unless explicitly stated.

VERITAS treats protected audit storage as secure-by-default. Where encryption is required, VERITAS_ENCRYPTION_KEY must be configured; missing required key material raises EncryptionKeyMissing rather than silently falling back to plaintext.

• External Security Remediation Summary
• Japanese External Security Remediation Summary
• Maintainer Handoff

Security evidence reduces known vulnerability risk; it does not establish vulnerability-free operation.

VERITAS provides governance and evidence infrastructure. It is not legal certification, not legal advice, not regulatory approval, and not third-party certification.

• Reviewer Entry Point
• Current Implementation Matrix
• Enterprise Value Brief
• Technical Proof Pack

• External Bind Integration Path
• WebhookBindAdapter
• External Bind PoC Evidence
• Reconciliation-Capable Execution Profile Proof

• Reviewer Evidence Index
• Reviewer Evidence Assurance Overview
• Evidence Bundle Reviewer Checklist
• Evidence Bundle Signature Verification
• Sample Evidence Bundle Verification Output
• Reviewer Key Provenance Walkthrough
• Reviewer Handoff Guide
• Reviewer Handoff Sample Quickstart
• External Audit Readiness

• Operational Readiness Runbook
• Security Hardening
• PostgreSQL Production Guide
• Provider Support Matrix

• One-Day PoC Reviewer Pack
• One-Day PoC Evidence Pack
• AML/KYC Quickstart

Near-term work is focused on strengthening the boundary between authorization and externally verified effect.

Priority areas include:

• broader bind coverage
• real external integration validation
• customer-specific authority-source integration
• credential-resolution hardening
• stronger external-reality authenticity
• clock-trust hardening
• reconciliation across additional effect classes
• production customer workflow validation
• independent external review
• continued benchmark and adversarial evaluation

Roadmap items are not represented as completed implementation.

This repository uses a directory-scoped multi-license model.

See:

• LICENSE
• NOTICE
• TRADEMARKS

See CONTRIBUTING.md.

Security issues should be reported according to SECURITY.md.

@software{veritas_os_2025,
  author = {Fujishita, Takeshi},
  title  = {VERITAS OS: Auditable Decision OS for LLM Agents},
  year   = {2025},
  doi    = {10.5281/zenodo.17838349},
  url    = {https://github.com/veritasfuji-japan/veritas_os}
}

Takeshi Fujishita

• GitHub Issues: https://github.com/veritasfuji-japan/veritas_os/issues
• Email: veritas.fuji@gmail.com
• LinkedIn: https://www.linkedin.com/in/takeshi-fujishita-279709392