v1.1.7 · Open Governance Infrastructure

Govern AI systems with evidence, policy and operational control.

KAVACH is an open governance and control plane for AI agents, workflows and decisions. It provides evaluation, policy enforcement, execution control, auditability and deterministic governance across REST APIs and MCP tools.

REST APIsMCP ToolsVersioned GovernanceAuditable DecisionsSelf-Hosted

Architecture

Layered Control Plane for AI Governance

KAVACH separates experience, control, governance, execution and persistence into explicit planes with unidirectional data flow.

KAVACH Enterprise Architecture

Lifecycle

How KAVACH works

A deterministic loop from observation to immutable audit.

01

Observe

Capture execution, evidence, model, prompt and policy context.

02

Evaluate

Run quality, safety, compliance and governance checks.

03

Decide

Produce deterministic governance decisions with reasoning and evidence.

04

Audit

Store immutable execution and decision history for replay and investigation.

KAVACH Architecture Flows

Principles

Engineering Principles

KAVACH is built to be operated in production. These constraints shape every interface.

01

Control Plane Ownership

Kavach owns governance state and decisions. It tracks assets, results, comparisons, rankings and recommendations — but never the live AI runtime or deployment system.

02

Explicit Contracts

Every boundary is visible in code. Repository interfaces, provider interfaces and framework-neutral APIs are all explicit contracts. Hidden cross-system contracts are avoided.

03

Immutable Artifacts

Governed records are immutable where possible. Mutable control flows create new records or versions instead of mutating historical facts.

04

Version Everything

Prompts, models, datasets and experiment-facing artifacts are versioned. Versioning is required for reproducibility, comparison, auditability and replay.

05

Replayability

If a governance decision cannot be reconstructed later, it is weak evidence. Replayability affects storage, versioning, immutability and API design.

06

Storage Independence

The platform does not depend on SQLite as a core architectural choice. Repository contracts preserve the ability to add PostgreSQL, Snowflake or other stores.

07

Provider Independence

Evaluation logic remains behind provider interfaces. TruLens is the current implementation, but the architecture should not require provider-specific knowledge.

08

Failure Isolation

Failures stop at the narrowest useful boundary. A provider failure should not silently mutate registry state. A transport adapter should not rerun ranking logic.

Interfaces

Evaluate Governance Decisions

The same governance operation is available over REST and as an auditable MCP tool. Every call is correlated and recorded.

POST /api/v1/decisions/evaluate

{
  "subject_type": "agent_execution",
  "subject_id": "execution-2048",
  "policy_id": "production-ai-policy",
  "evidence_ids": [
    "eval-result-981",
    "audit-event-477"
  ]
}

// 200 OK
{
  "decision_id": "decision-991",
  "outcome": "APPROVED",
  "policy_version": "3.2.0",
  "reason": "All mandatory controls satisfied"
}

Releases

Shipping Governance, Incrementally

Govern the system before the system governs production.