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.

Fail-closed governance means execution is denied whenever governance guarantees cannot be deterministically established. The system never silently degrades, retries with partial state, or continues past unverified conditions. Uncertainty is always an explicit rejection with a structured error code. This is not a safety feature layered on top of governance. It is the foundational design principle from which all other governance guarantees derive their meaning.

​
What triggers a fail-closed rejection

The runtime rejects execution across all of these conditions - without exception, without retry, without fallback:
ConditionStageError
Signal not declared in schemaSignal validationVAL-003
Required signal missingSignal validationVAL-004
Signal has wrong typeSignal validationVAL-006 - VAL-012
No policy rule matchedPolicy evaluationSYS-006
Replay detectedReplay enforcementINV-013
Invalid token signatureToken verification-
Runtime version unsupportedToken verification-
Required capability missingToken verification-
Schema version unsupportedToken verification-
Bundle hash mismatchBundle verification-
Redis unavailableReplay enforcementAll executions rejected
Pending override not foundOverride resolution-
Every rejection is deterministic: the same invalid input always produces the same error code through the same path.

​
The execution sequence enforces fail-closed at every stage

The pipeline is sequential and cannot be short-circuited: 
validateSignalsStrict()   ← fail if signals invalid
      ↓
reserve(fingerprint)      ← fail if Redis unavailable
      ↓
evaluatePolicy()          ← fail if no rule matches
      ↓
issueToken()              ← bind decision + versions
      ↓
signToken()               ← Ed25519 over canonical payload
      ↓
confirm(fingerprint)      ← fail if signature/version/capability invalid
      ↓
signAttestation()         ← only runs if everything above passed
Execution authority exists only after every stage passes. There is no shortcut, no partial execution, no optimistic path.

​
Failures are reproducible

Failure in Parmana is not an error state - it is a governed outcome. Every rejection carries a structured error code derived deterministically from the condition: 
class InvariantViolation extends Error {
  readonly report: ViolationReport;
  // Format: "[{code}@{boundary}] {reason}"
  // e.g.:  "[INV-013@replay] Replay detected: fp-abc already consumed"
}
This structure means failures are auditable, aggregatable, and independently reproducible - exactly like successful executions. A compliance auditor can review not just approvals but rejections, and verify that each rejection was correct for the given inputs.

​
The policy must be fail-closed too

The governance runtime fails closed at the policy level as well. If no rule in the policy matches the provided signals, execution is rejected with SYS-006. There is no implicit default-approve path, no fall-through to a permissive catch: 
{
  "rules": [
    { "id": "reject-low-score", "condition": { "signal": "credit_score", "less_than": 500 }, ... },
    { "id": "approve-standard", "condition": { "signal": "credit_score", "greater_than": 700 }, ... },
    { "id": "catch-all", "condition": { "all": [] }, ... }
  ]
}
The catch-all rule ("all": []) is required precisely because of fail-closed semantics - it makes the policy author’s intent for the unmatched case explicit. The compiler warns when it is missing (POL-021).

​
Redis availability is a hard dependency

In production, Redis is not optional. When Redis is unavailable, every execution request is rejected. This is intentional. Allowing executions without replay protection would break the single-use guarantee - the same signals could produce multiple attestations, duplicating approvals, payments, or escalations. There is no degraded mode that preserves partial correctness. Replay protection requires Redis, or execution does not happen. This is a system design choice with operational implications: Redis must be treated as a first-class dependency with the same uptime requirements as the governance server itself.

​
Override flows are also fail-closed

Human override does not weaken fail-closed semantics. When resolveOverride() runs, the same verification pipeline executes against the original token:
  • The original signature is re-verified
  • The runtime version is re-checked
  • The capability set is re-checked
  • The replay slot is claimed atomically
The human approver does not bypass any check. The approver enables the completion of an execution whose admissibility was already established - they do not modify the decision or inject new signals.

​
Why silent degradation is more dangerous than rejection

In payment processing, healthcare, and regulated systems, silent degradation has worse consequences than explicit rejection:
  • A duplicate payment approval that passes through because Redis was briefly unavailable causes real financial harm
  • A governance check that silently succeeds with invalid signals produces an attestation that falsely claims governance was enforced
  • An unverified decision recorded in the audit log as if it were verified destroys audit integrity
Explicit rejection is always recoverable - the caller knows the decision was not made and can retry, escalate, or alert. Silent degradation may not be detected until an audit, a regulatory review, or a real-world consequence surfaces the gap.

​
Distributed systems semantics

Fail-closed semantics apply uniformly across distributed deployments:
  • Concurrent requests for the same fingerprint result in exactly one succeeding via SET NX; all others are rejected with INV-013
  • Network partitions that isolate the governance server from Redis cause all executions to fail, not degrade silently
  • Unknown runtime versions are rejected across all nodes - no node silently accepts an execution from an unrecognized runtime version
Distributed uncertainty never becomes implicit execution authority.

​
See also