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.

Modern systems increasingly automate execution. Orchestration systems - Temporal, Airflow, Step Functions, agent frameworks - coordinate workflow steps, schedule tasks, manage retries, and route execution. These are valuable capabilities. But orchestration is not governance. The distinction matters because conflating them leaves consequential actions without the enforcement guarantees that regulated, auditable, or high-stakes environments require.

​
The core difference

OrchestrationGovernance
Coordinates when execution happensConstrains whether execution is permitted
Schedules workflowsDetermines admissibility
Manages retriesPrevents replay
Routes tasks between systemsEnforces policy
Tracks workflow stateVerifies execution lineage
Optimizes operational automationEnforces trust at the execution boundary
Orchestration systems answer: what should happen next? Governance systems answer: is this execution permitted?

​
Why orchestration alone is insufficient

Orchestration systems are designed for operational reliability - ensuring workflows complete, retrying failures, and routing tasks efficiently. They are not designed for governance: Retries can duplicate consequential actions. An orchestration system that retries a payment approval step may trigger a second payment. Without replay protection, there is no mechanism to detect that the same governance decision has already been executed. Parmana’s two-phase replay commit makes the second attempt raise INV-013 - regardless of which node, which retry, or which orchestration framework submitted it. Workflow state can drift. Orchestration systems track operational state. Governance tracks admissibility. These can diverge: a workflow may be in a “completed” state while the underlying governance decision was never actually enforced. Runtime trust is implicit. Orchestration assumes execution happens correctly - it records that a step was triggered, not that governance was enforced before it ran. There is no cryptographic proof that the governance check actually executed. Provenance is weak. Workflow logs record what happened operationally. Governance lineage records what was admissible: the policy version, the exact signals evaluated, the runtime version that produced the decision, and a signature that proves it. These are fundamentally different records. Verification is absent. No orchestration system produces an artifact that a third party can verify independently - without access to the system - to confirm that governance was enforced.

​
The governance layer sits at the execution boundary

Governance is not a replacement for orchestration. It is the enforcement check that runs before any consequential step executes: 
Agent / Workflow Engine
          │
          ▼
Proposed Action
          │
          ▼
executeFromSignals()        ← Is this admissible under policy?
          │
          ├── approve  →  proceed with signed attestation
          ├── reject   →  execution blocked
          └── manual_review →  pending_override, await human
          │
          ▼
Operational System
(payment processor, infrastructure, database, external API)
The orchestration system controls the workflow. The governance runtime controls whether each consequential step in that workflow is permitted to proceed.

​
AI agent systems

AI agents that execute tools - calling APIs, modifying files, deploying infrastructure, approving requests - need governance as much as they need orchestration. The agent decides what to do. Governance determines whether it is allowed to do it. Without governance, an autonomous agent has execution capability with no admissibility boundaries. It can take consequential actions that are difficult or impossible to undo, without any verifiable record that those actions were permitted under explicit policy. With governance, every consequential action the agent takes:
  • Is evaluated against explicit policy rules
  • Produces a signed, tamper-evident attestation
  • Is replay-protected against duplicate execution
  • Can be independently verified by any party with the public key
  • Is linked to the exact policy version that governed it
This is what makes AI agents deployable in production environments where consequences matter.

​
Governance and orchestration are complementary

Parmana is not a competitor to Temporal, Airflow, or any agent framework. It is a governance layer that sits at the execution boundary within those systems. An orchestrated workflow calls executeFromSignals before proceeding with a consequential step. The governance runtime enforces the policy and issues a signed attestation. The workflow continues - or pauses for human approval - based on the outcome. 
// Inside an orchestration workflow
const attestation = await executeFromSignals(
  { policyId: "payment-approval", policyVersion: "1.0.0", signals: { amount, verified } },
  signer, verifier, replayStore
);

if (attestation.decision.action === "approve") {
  // Proceed with the payment
  await paymentProcessor.execute(attestation.executionId, amount);
} else if (attestation.execution_state === "pending_override") {
  // Pause workflow - await human approval
  await workflow.waitForOverride(attestation.executionId);
}
The orchestration framework handles how the workflow executes. Governance handles whether each consequential step is permitted.

​
What governance adds that orchestration cannot

RequirementOrchestrationGovernance
Deterministic admissibility❌✅
Cryptographic proof❌✅
Replay protection❌✅
Independent verification❌✅
Immutable lineage❌✅
Policy version binding❌✅
Fail-closed uncertainty❌✅

​
For enterprise and compliance teams

In regulated industries, the distinction between orchestration and governance is precisely what regulators care about: “Did the system execute the action?” - Orchestration can answer this. “Was the action admissible under the policy in effect at the time, and can you prove it?” - Only governance can answer this. A workflow log that shows a payment step was triggered is operational evidence. A signed Parmana attestation that shows the payment was admissible under policy version 1.0.3, evaluated against credit_score: 720 and loan_amount: 15000, signed by a runtime with a specific hash, and replay-protected - that is compliance evidence.

​
See also