AnantVerify
Technical Overview

Build assurance into the decision path

An engineering overview of AnantVerify contracts, evidence, DTT, APIs, runtime enforcement and replay.

One fabric, several places

One decision fabric in several places. Cloud, data center, edge and air-gapped change where it runs, not what it is.
Core Concepts

Normalized proposal

One assurance interface for heterogeneous engines.

AnantVerify normalizes proposals so rules, ML models, agents and external services can enter the same assurance path. The envelope can carry the proposed value, probability distribution, confidence, uncertainty, abstention state, engine identity and provenance.

State contract

Declare what must be known.

A State Contract identifies required fields, freshness constraints, conflict handling and provenance requirements. State can be SUFFICIENT, INCOMPLETE, STALE, CONFLICTED, UNCERTAIN or UNKNOWN.

Decision contract

Constrain the legal action vocabulary.

A Decision Contract defines legal decisions and relevant semantics for a task. It provides a stable interface between proposal engines and assurance.

Evidence and resolution

Keep authority explicit.

Evidence remains provenance-bearing. Resolution Policy is customer-owned, versioned and auditable. Unresolved material conflict can fail closed.

DTT and evaluation

Combine conventional evaluation with property-based assurance.

Registered evaluations can cover deterministic correctness, semantic quality, agent behavior, RAG, safety and stochastic consistency. DTT adds explicit state transformations and transformation contracts.

Runtime verdict

Return a control decision, not only a score.

The assurance result includes verdict, reasons, state/evidence status, relevant test/coverage context and artifact versions.

API Example

One request, one verdict

POST /v1/assurance/assess

{
  "state_ref": "state://payments/txn-88213@v14",
  "proposal": {
    "task": "payment_authorization",
    "action": "PAY",
    "source": "agent:payments-copilot"
  },
  "decision_task": "supplier_payment_authorization"
}

200 OK

{
  "verdict": "ESCALATE",
  "state_status": "SUFFICIENT",
  "evidence_status": "CONFLICTED",
  "reasons": [
    "Current policy requires HOLD while proposal recommends PAY"
  ]
}

Illustrative example for orientation—confirm exact contracts against current API documentation.

Core Types
ProposalEnvelope
StateStatus
AssuranceVerdict
DecisionPack
Integration
State providers
Proposal sources
Evidence sources
Execution gateway
Replay

Version everything required to reproduce the determination

A historical verdict should be replayable using the state, evidence and governing artifacts effective at the time.