Skip to main content

​
Task → Policy → Schema Model

​
Executive Summary

Parmana is built on a simple idea:
Once the task is known, the policy is known. Once the policy is known, the required evidence is known.
This allows authority verification to become deterministic. Instead of asking systems to decide what information might be relevant for a decision, Parmana derives required evidence directly from policy. 
Task
  ↓
Policy
  ↓
Schema
  ↓
Required Signals
  ↓
Verified Signals
  ↓
Evaluation
This model ensures that policies remain the source of truth and that authority decisions are based on verified facts rather than assumptions.

​
The Problem

Most systems treat authorization as an application concern. A request arrives. Developers decide:
  • What information to collect
  • What checks to perform
  • What rules to enforce
Over time these implementations drift. 
Request
  ↓
Custom Logic
  ↓
Decision
Different teams make different decisions. Different services enforce different rules. Eventually no one can confidently answer:
What evidence was required before this action was approved?

​
Why Tasks Matter

People do not think in terms of policies. People think in terms of business actions. Examples: 
Transfer Funds
Approve Claim
Issue Refund
Close Account
Create Vendor
Approve Payment
These are tasks. A task represents the action someone wants to perform. The customer chooses a task. Not a policy.

​
Organizations Define Authority

Organizations define authority through policies. Examples: 
Transfer Funds
        ↓
High Value Transfer Policy

Approve Claim
        ↓
Claims Approval Policy

Issue Refund
        ↓
Refund Authorization Policy
The organization decides which policy governs each task. This mapping becomes part of the organization’s authority model.

​
Task → Policy Mapping

The first step in Parmana is determining which policy applies. 
Customer Chooses Task
          ↓
Transfer Funds
          ↓
Task → Policy Mapping
          ↓
High Value Transfer Policy
This mapping can be configured by the organization. Policies can change without changing the task itself. For example: 
Transfer Funds
        ↓
Policy v1
later becomes: 
Transfer Funds
        ↓
Policy v2
without changing the customer experience.

​
Policies Define Schemas

A policy is the source of truth. Each policy defines a schema. The schema specifies the evidence required before evaluation. Example: 
{
  "policyId": "high-value-transfer",
  "requiredSignals": {
    "authenticated_user": {
      "type": "boolean"
    },
    "account_owner_verified": {
      "type": "boolean"
    },
    "available_balance": {
      "type": "number"
    },
    "destination_verified": {
      "type": "boolean"
    },
    "transfer_amount": {
      "type": "number"
    }
  }
}
The schema defines what must be known before a decision can be made.

​
Schemas Define Required Signals

Once the policy is known: 
Policy
   ↓
Schema
the required signals become deterministic. 
Schema
   ↓
Required Signals
No runtime guessing. No AI interpretation. No hidden business logic. The required evidence is explicitly defined.

​
Signals Must Be Verified

Signals are not decisions. Signals are facts. Examples: 
Account Exists
Balance Available
Customer Authenticated
Device Verified
Destination Verified
These facts must be verified by external systems. Examples: 
Banking System
Fraud Platform
Identity Provider
CRM
ERP
Claims System
Parmana does not verify signals. External systems verify signals.

​
Verified Signals

After verification: 
{
  "authenticated_user": true,
  "account_owner_verified": true,
  "available_balance": 5000,
  "destination_verified": true,
  "transfer_amount": 1000
}
These become verified signals. Verified signals are facts. Not opinions. Not recommendations. Not AI-generated assumptions.

​
Parmana Evaluates Policy

Parmana receives verified signals. 
Verified Signals
         ↓
Parmana
Parmana evaluates those facts against policy. 
Verified Signals
         ↓
Policy Evaluation
         ↓
Decision
Parmana does not trust AI output. Parmana evaluates verified facts.

​
Decision

Evaluation produces a decision. Example: 
{
  "action": "approve",
  "requires_override": false,
  "reason": "policy_requirements_satisfied"
}
Or: 
{
  "action": "reject",
  "requires_override": true,
  "reason": "policy_requirements_not_satisfied"
}
The decision is deterministic because the evidence was deterministic.

​
Attestation

Every decision can be signed. 
Decision
    ↓
Attestation
The attestation records:
  • Policy
  • Policy version
  • Decision
  • Evidence fingerprint
  • Provenance
  • Signature
This creates a verifiable authorization record.

​
Execution

Execution occurs outside Parmana. 
Decision
      ↓
External System
      ↓
Execution
Examples: 
Bank Transfer
Claim Approval
Refund
Vendor Creation
Account Closure
Parmana verifies authority. External systems perform execution.

​
Execution Integrity

After execution: 
Authorization
        ↓
Execution
        ↓
Confirmation
Parmana can verify that execution matched authorization. 
Authorized Action
        ↓
Executed Action
        ↓
Integrity Proof
This creates evidence that the approved action is the action that actually occurred.

​
Banking Example

A customer asks an AI assistant to transfer money. 
Customer
      ↓
AI Assistant
The AI captures the request. 
Transfer ₹10,000
The bank verifies facts. 
Customer Authenticated
Account Owner Verified
Balance Available
Destination Verified
The verified signals are sent to Parmana. 
Verified Signals
        ↓
Parmana
Parmana evaluates policy. 
Approve
The bank executes the transfer. 
Bank Executes Transfer
The bank confirms execution. 
Execution Integrity Proof
Result: 
AI Captured Request
Bank Verified Facts
Parmana Enforced Policy
Bank Executed Decision

​
Why This Model Matters

Without this model: 
Request
  ↓
Application Logic
  ↓
Decision
Required evidence is often unclear. Authority is difficult to audit. Policy enforcement varies between systems. With the Task → Policy → Schema Model: 
Task
  ↓
Policy
  ↓
Schema
  ↓
Required Signals
  ↓
Verified Signals
  ↓
Evaluation
The required evidence becomes deterministic.

​
Benefits

​
Consistency

Every evaluation uses the same required evidence.

​
Auditability

Organizations can prove which evidence was required.

​
Determinism

Policies define required facts explicitly.

​
Separation of Responsibilities

AI
  ↓
Captures Request

External Systems
  ↓
Verify Facts

Parmana
  ↓
Evaluates Policy

External Systems
  ↓
Execute Action
Each component has a clear responsibility.

​
Independent Verification

Because evidence requirements originate from policy, auditors can independently verify: 
Which policy applied?
Which evidence was required?
Which facts were verified?
What decision was made?

​
Core Insight

The Task → Policy → Schema Model makes authority verification deterministic. 
Task
  ↓
Policy
  ↓
Schema
  ↓
Required Signals
  ↓
Verified Signals
  ↓
Decision
Once the task is known, the policy is known. Once the policy is known, the schema is known. Once the schema is known, the required evidence is known. This is how Parmana transforms authority verification from application-specific logic into a verifiable system.