Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.manthan.systems/llms.txt

Use this file to discover all available pages before exploring further.

This document is written for technical evaluators, investors, and engineering leaders conducting diligence on Parmana Systems. It covers the market problem, the technical architecture, the correctness properties, the competitive position, and the moat analysis. It is intended to be read alongside the source code, which is open and fully auditable.

​
Executive Summary

Parmana Systems builds governance infrastructure for AI agents and automated decision systems. Every decision produced by the Parmana runtime is cryptographically signed, deterministically reproducible, and independently verifiable by any party with the public key - with no access to the operator’s infrastructure required. The market problem is structural: AI systems are executing consequential decisions at scale - approving loans, escalating patients, modifying infrastructure, executing trades - and the current technology stack has no cryptographic governance layer. Orchestration frameworks control when decisions execute. Models recommend what to decide. But nothing in the standard AI stack produces tamper-evident, independently verifiable proof that a decision followed the rules that were claimed to govern it. Parmana solves this with a narrow, deep technical primitive: deterministic policy evaluation producing Ed25519-signed attestations over canonical payloads. The signing happens in the operator’s infrastructure. The verification requires only the attestation and the public key. No vendor dependency at verification time. No data leaves the operator’s boundary. The governance guarantee is in the cryptography, not in a service.

​
The Market Problem

​
The Governance Gap in AI Stacks

The current AI execution stack looks like this: 
User Input -> LLM / Model -> Orchestration (LangChain, etc.) -> Action
Logging and observability tools sit alongside this stack, recording what happened. But recording is not governing. A log entry does not prove that a decision followed the policy that was claimed to govern it. A log entry can be altered, selectively deleted, or retroactively generated. The governance layer is missing: 
User Input -> LLM / Model -> [GOVERNANCE LAYER] -> Action
                                  |
                          Signed Attestation
                          (verifiable by anyone)
This missing layer is not an edge case. It is the entire regulatory compliance story for AI systems. The EU AI Act (2024), NIST AI RMF, SR 11-7 (Federal Reserve model risk management), and emerging AI liability frameworks all require demonstrable proof that AI decisions follow documented rules - not claims of compliance, but cryptographic evidence of it.

​
Who Needs This Now

Financial services - Credit decisions, trading execution, fraud adjudication, and insurance underwriting are subject to model risk management requirements (SR 11-7, MAS TRM) that require validation evidence and audit trails. AI systems making these decisions are not exempt. The audit trail must be tamper-evident and independently verifiable. Healthcare - Clinical decision support systems making triage, escalation, or treatment recommendations are subject to HIPAA and emerging AI-specific regulations. Explainability and audit requirements are stringent. Legal and compliance functions - Contract review, regulatory filing, and compliance monitoring systems operated by law firms and compliance teams require defensible audit trails. Government and regulated infrastructure - Public sector AI systems, critical infrastructure operators, and defense contractors require air-gapped or self-hosted governance with no external dependencies. Any enterprise deploying consequential AI - The EU AI Act’s risk classification applies broadly. Companies operating high-risk AI systems without cryptographic governance are accumulating regulatory liability.

​
Market Timing

The EU AI Act enters enforcement for high-risk AI systems in 2025-2026. NIST AI RMF has been adopted as a baseline by major US agencies and is being adopted by their contractors. Insurance underwriters are beginning to require AI governance documentation for cyber liability policies. The regulatory forcing function is active and accelerating. The infrastructure layer does not exist at scale. The companies that build it now will define the standard.

​
The Technical Architecture

​
Core Primitive: The Execution Attestation

The fundamental output of the Parmana runtime is an ExecutionAttestation - a structured JSON record containing: 
interface ExecutionAttestation {
  executionId:           string;  // UUIDv4 - unique event identifier
  execution_fingerprint: string;  // SHA-256(canonicalize(signals)) - decision identity
  policyId:              string;  // which policy governed this decision
  policyVersion:         string;  // exact semver version
  signals:               Record<string, unknown>; // exact evaluated inputs
  decision: {
    action:              string;  // "approve" | "deny" | "escalate" | custom
    reason:              string;  // human-readable explanation
    requires_override:   boolean; // whether human override is required
    ruleId?:             string;  // which rule matched
  };
  approved_at:           string;  // ISO 8601 (metadata - not in signed payload)
  signature:             string;  // Ed25519 over canonical payload
  runtimeHash:           string;  // hash of runtime manifest
}
Every field serves a purpose. The execution_fingerprint is the semantic identity of the decision - a hash of the canonical signals. The executionId is the event identity - unique per execution event. The runtimeHash binds the decision to the exact runtime version. The signature is the cryptographic proof.

​
The Execution Pipeline

Signals
  |
  v
canonicalize(signals) -> execution_fingerprint
  |
  v
replayStore.reserve(fingerprint)    <- atomic - fails if already claimed
  |
  v
policyEvaluator.evaluate(signals, policy) -> decision
  |
  v
buildCanonicalPayload(fingerprint, policyRef, decision, runtimeHash)
  |
  v
signer.sign(canonicalPayload) -> signature
  |
  v
replayStore.confirm(fingerprint)
  |
  v
ExecutionAttestation
This pipeline enforces four properties:
  1. Determinism - canonical serialization ensures the same signals produce the same fingerprint and the same canonical payload, regardless of platform or time
  2. Tamper evidence - the signature covers the canonical payload; any modification invalidates it
  3. Exactly-once execution - two-phase atomic reservation prevents duplicate execution
  4. Fail-closed - unavailability of the replay store blocks execution rather than proceeding ungoverned

​
Key Correctness Properties

Determinism. The canonical form is specified exactly: sorted JSON keys (recursive), compact encoding (no whitespace), NFC Unicode normalization, CRLF-to-LF line ending normalization, UTF-8 encoding. The same signals produce the same bytes on Windows, Linux, and macOS. This is a correctness requirement, not a performance optimization - without it, verification would be platform-dependent. Tamper evidence. Ed25519 is used for signing. Ed25519 is deterministic: the same private key signing the same payload always produces the same signature. This determinism is a correctness requirement - it means the signature itself is reproducible, not just the payload. The signature covers the execution fingerprint, policy reference, decision, and runtime hash. It does not cover the executionId or approved_at - these are metadata fields that are excluded from the signed payload by design. Portability. Verification requires only the attestation and the public key. The verifyAttestation function reconstructs the canonical payload from the attestation fields and verifies the Ed25519 signature. No infrastructure access. No database query. No connection to the governance runtime. This can be executed offline, in any language that supports Ed25519. Replay safety. The two-phase commit - reserve(fingerprint) before evaluation, confirm(fingerprint) after signing - ensures exactly-once execution. The reserve operation must be atomic: two concurrent requests with the same fingerprint will result in exactly one succeeding. This atomicity requirement is enforced by the ReplayStore interface contract. The built-in RedisReplayStore uses SET key value NX (atomic conditional set). The DynamoReplayStore uses ConditionExpression: "attribute_not_exists(fingerprint)". If the replay store is unavailable, execution is blocked - fail-closed, not fail-open.

​
The Policy Model

A governance policy is a JSON file with a declared schema, signals schema, and ordered rules: 
{
  "policyId": "loan-approval",
  "version": "1.0.0",
  "signalsSchema": {
    "credit_score": { "type": "number", "minimum": 300, "maximum": 850 },
    "loan_amount":  { "type": "number", "minimum": 1000 }
  },
  "rules": [
    {
      "ruleId": "high-credit-auto-approve",
      "condition": { "credit_score": { "$gte": 750 } },
      "decision": { "action": "approve", "reason": "Credit score exceeds auto-approval threshold." }
    },
    {
      "ruleId": "catch-all-deny",
      "condition": {},
      "decision": { "action": "deny", "reason": "Does not meet approval criteria." }
    }
  ]
}
The policy compiler validates policies through an 8-phase pipeline: file existence, JSON validity, required fields, directory structure match, schema version, signals schema validity, rules validity, and catch-all presence. A policy without a catch-all is rejected - this enforces the fail-closed property at the policy level. Compiled policies are content-addressed bundles. The bundle hash is a SHA-256 hash of the canonical serialization of the policy content. The same policy content always produces the same bundle hash. Deploying a policy means deploying a specific bundle hash - the policy version in an attestation is a cryptographic commitment to exact policy content.

​
The BYOI Model

Parmana is a protocol, not a service. Three interfaces define the integration surface: 
interface Signer   { sign(payload: string): string | Promise<string>; }
interface Verifier { verify(payload: string, signature: string): boolean | Promise<boolean>; }
interface ReplayStore {
  reserve(fingerprint: string): Promise<void>;
  confirm(fingerprint: string): Promise<void>;
  hasExecuted(fingerprint: string): Promise<boolean>;
  markExecuted(fingerprint: string): Promise<void>;
}
Built-in implementations - LocalSigner, LocalVerifier, MemoryReplayStore, RedisReplayStore - cover development and common production cases. For enterprise deployments:
  • Signing keys: AWS KMS, HashiCorp Vault Transit, Azure Key Vault, Google Cloud KMS, HSM via custom Signer
  • Replay store: DynamoDB, PostgreSQL, custom via ReplayStore interface
  • Audit database: Any storage system - attestations are plain JSON
Nothing leaves the operator’s boundary. The SDK makes no outbound network calls. It runs in any Node.js environment, including air-gapped systems.

​
Competitive Analysis

​
vs. Open Policy Agent (OPA)

OPA is a policy engine: it evaluates a query against a policy and returns a decision. It does not produce cryptographic attestations. An OPA decision is correct at evaluation time, but there is no tamper-evident, independently verifiable proof that a specific decision was produced from specific inputs by a specific policy version. Post-facto verification is not possible without access to OPA logs. Parmana produces signed attestations that are self-contained and verifiable without infrastructure access. For compliance use cases requiring independent verification, OPA requires a custom attestation layer built on top - which is what Parmana provides as its core primitive. OPA and Parmana are complementary in some architectures: OPA for policy evaluation logic, Parmana for attestation and governance of the execution. But for customers who need the full governance stack, Parmana is the narrower, deeper, and more complete solution.

​
vs. LangChain / AutoGPT and Agent Frameworks

Orchestration frameworks control workflow - they do not produce governance. LangChain’s observability plugins record what happened; they do not produce cryptographic proof that it happened correctly. The decision is made by a model, routed by the orchestration layer, and logged - but none of that chain is tamper-evident or independently verifiable. Parmana sits at the execution boundary - between orchestration and action - and produces the governance attestation that the orchestration layer cannot. These are complementary layers, not competitors. A LangChain workflow can call executeFromSignals at the action boundary to produce a governed, attested decision before taking the action.

​
vs. SaaS Governance Platforms

SaaS governance platforms require decision data to leave the operator’s boundary. For regulated industries - financial services, healthcare, government - this is often a disqualifying requirement. Security review processes, data sovereignty requirements, and compliance frameworks make third-party dependencies on governance-critical paths unacceptable. Parmana is self-hosted. The SDK is deployed in the operator’s infrastructure. Keys never leave the operator’s key management system. Attestations are stored in the operator’s database. No SOC 2 review of a third-party vendor is required - Parmana is a library with the same security surface as any audited npm dependency.

​
vs. Custom Audit Logging

Custom audit logging is alterable, non-cryptographic, and infrastructure-dependent. An audit log entry can be modified by any party with database access. Verification of a log entry requires access to the database. Long-term verifiability depends on the logging infrastructure surviving. Parmana attestations are cryptographic, self-contained, and infrastructure-independent. The tamper-evidence is mathematical, not procedural. Verification requires only the attestation and the public key. Long-term verifiability depends only on Ed25519 remaining a supported algorithm - which it will, as a standardized IETF specification.

​
Moat Analysis

​
Technical Moat

Deterministic governance is a narrow, deep problem. Correct implementation requires:
  • Canonical serialization - a single, exact specification for key ordering, Unicode normalization, line ending normalization, and encoding. Any deviation makes cross-platform fingerprints non-reproducible.
  • Two-phase commit semantics - the reserve/confirm pattern with fail-closed behavior on store unavailability. Incorrect implementation creates replay vulnerabilities.
  • Ed25519 determinism - correct use of Ed25519 requires understanding that it is deterministic (unlike ECDSA, which requires a random nonce and is vulnerable to nonce reuse). This determinism is a correctness property, not a performance one.
  • Policy compiler correctness - the 8-phase validation pipeline enforces invariants that application developers would not independently derive (catch-all requirement, directory-policy ID match, signal schema enforcement).
  • Separation of executionId and execution_fingerprint - these are different concepts (event identity vs. decision identity) with different properties (random vs. deterministic). Conflating them is a common design error with security implications.
The public test infrastructure (9 test repos, 200+ tests) demonstrates the investment in correctness. Deterministic governance implementations that skip these invariants will have correctness bugs that only appear in adversarial conditions - exactly the conditions where governance matters most.

​
Market Moat

Regulatory compliance creates switching costs. Once an organization has adopted Parmana for a regulated use case - credit decisions, clinical support, model risk management - the attestation format becomes embedded in their compliance documentation, audit procedures, and regulatory submissions. Switching costs are high. Signed policy bundles create network effects. When an operator publishes a signed policy bundle (content-addressed, with a specific hash), counterparties can independently verify that their decisions were governed by that exact policy version. This creates a network incentive: the value of using the same attestation format as your counterparties is that verification is interoperable. As adoption grows, the network effect strengthens. Enterprise sales cycles create long relationships. Compliance infrastructure has long evaluation cycles, legal review requirements, and integration timelines. Once sold and integrated, the relationship is stable and defensible. Open source reduces friction, enterprise adds moat. The open-source SDK lowers adoption friction - security teams can audit the code, enterprises can evaluate without procurement processes, developers can prototype without purchasing. The moat is in the enterprise relationships, the compliance documentation, the SLA-backed support, and the managed policy infrastructure that regulated customers require.

​
Technical Risk Assessment

Key management risk. Mitigated by BYOI: the operator’s keys never leave their key management infrastructure. Key compromise is a risk the operator manages with their existing security controls (AWS KMS, HSM, etc.). Parmana does not introduce a new key management dependency. Replay store availability risk. Mitigated by fail-closed design: if the replay store is unavailable, execution is blocked. This is a risk to availability (decisions cannot be made during store outages), not a risk to correctness (double-execution is prevented). Operators should deploy highly available replay stores (Redis Cluster, DynamoDB) for production use. Policy correctness risk. Mitigated by the 8-phase policy compiler, which validates policy content before deployment. The catch-all requirement ensures no policy has undefined behavior. Signal schema enforcement ensures that invalid signals produce validation errors (VAL-series error codes) rather than incorrect decisions. Long-term cryptographic validity. Ed25519 is a post-quantum candidate algorithm (Bernstein et al., 2011) with no known practical attacks. NIST’s post-quantum standardization process has elevated lattice-based algorithms (CRYSTALS-Dilithium, FALCON) as long-term successors, but Ed25519 remains the appropriate choice for current deployment. The Parmana architecture allows key rotation and signing algorithm migration without loss of historical verifiability. Regulatory interpretation risk. Regulatory requirements for AI governance are evolving. The EU AI Act implementing acts, NIST AI RMF updates, and emerging sector-specific guidance may impose additional requirements. Parmana’s attestation format is designed to be extensible - additional fields can be added without invalidating existing signatures - and the policy model is flexible enough to accommodate new governance requirements as they emerge.

​
Team Signal

The correctness focus visible in the public artifacts is a team signal worth noting. The test infrastructure spans multiple repositories (9 at last count), covering integration tests, conformance tests, adoption scenario tests, and edge case regression tests. The test philosophy - no mocking of the governance pipeline, real in-process execution in all tests - reflects a deep understanding of where correctness bugs hide: in the interaction between layers, not in individual functions. The invariant registry (documented in the architecture) catalogs 28 correctness invariants that were identified, tested, and hardened before the v1.0 release. Governance infrastructure that passes these invariants in adversarial conditions is rare. Most implementations discover these bugs in production, under regulatory scrutiny. The governed release pipeline - the governance SDK is used to govern its own releases - is a form of dogfooding that directly tests the most important path: policy compilation, bundle signing, and attestation verification in a production-like environment.

​
Conclusion

Parmana Systems has built infrastructure-grade governance for AI decision systems: deterministic, signed, portable, and replay-protected. The technical implementation is correct at a depth that is rare in early-stage infrastructure software. The market need is active, driven by regulatory enforcement timelines that are measured in months, not years. The BYOI model removes the primary objection of regulated-industry buyers. The open-source SDK lowers adoption friction while the enterprise relationships and compliance moat create defensibility. This is a narrow problem solved deeply. The correct approach to infrastructure.

​
See Also