Skip to main content
One of the first questions organizations ask when building autonomous systems is:
What information should we collect from the customer?
At first glance, this appears straightforward. A customer wants to transfer money. The system needs information. The system asks questions. The process seems simple. But this question hides a deeper problem. Who decides which questions should be asked? And more importantly:
Why are those questions being asked in the first place?
The answer reveals an important distinction between information and evidence. As autonomous systems become capable of executing actions, that distinction becomes critical.

​
The Temptation To Start With Inputs

Most systems begin by defining inputs. For example:
  • Transfer amount
  • Beneficiary name
  • Beneficiary account
  • Source account
The system collects these inputs and sends them through a workflow. This approach feels natural because inputs are visible. Customers provide them. Forms collect them. APIs transmit them. But inputs are not the thing we actually care about. What we care about is whether an action should be executed. The information required to make that decision is evidence. Not inputs.

​
Inputs Are Claims

Consider a beneficiary transfer. A customer provides:
  • Beneficiary name
  • Beneficiary account
These are inputs. They are claims. They are not verified facts. The customer cannot provide:
beneficiary_verified = true
Only the banking system can determine that. Likewise, a customer cannot provide:
identity_verified = true
or
available_balance = true
or
fraud_score = 12
These are not inputs. These are verified facts. This distinction is fundamental. Claims enter the system. Facts are established by the system. Policy enforcement should operate on facts. Not claims.

​
Signals Versus Verified Signals

Signals are claims entering the system. Examples:
  • beneficiary_account
  • beneficiary_name
  • transfer_amount
Signals are not trusted facts. They represent information provided by customers, applications, APIs, or AI systems. Verified signals are facts produced by trusted systems. Examples:
  • beneficiary_verified
  • identity_verified
  • available_balance
  • fraud_score
Verification transforms claims into facts. Policy enforcement operates on verified signals, not raw signals. Verified signals are facts produced by trusted systems. Examples:
  • beneficiary_verified
  • identity_verified
  • available_balance
  • fraud_score
The role of verification is to transform signals into verified signals. The role of policy enforcement is to evaluate verified signals. These are different responsibilities. Confusing them creates ambiguity. Separating them creates trust.

​
The Mistake Of Putting Inputs In Policies

A common idea is:
Why not define customer inputs directly inside the policy?
At first, this seems reasonable. A policy requires beneficiary verification. Why not specify exactly which customer information is required? The problem is that verification is organization-specific. Consider the verified signal:
beneficiary_verified
Different organizations may establish this fact differently. Bank A may require:
  • beneficiary account
Bank B may require:
  • beneficiary account
  • beneficiary name
Bank C may require:
  • beneficiary account
  • beneficiary name
  • OTP confirmation
All three ultimately produce the same verified fact:
beneficiary_verified = true
The policy should not care how the fact was established. The policy should care only that the fact exists. This leads to a critical principle:
Policies should define evidence, not inputs.

​
Policies Define Evidence

A policy should answer one question:
What verified facts must exist before this action can be evaluated?
For example:
  • identity_verified
  • beneficiary_verified
  • available_balance
  • fraud_score
  • transfer_amount
These are evidence requirements. Not user interface requirements. Not workflow requirements. Not implementation requirements. The policy does not dictate how those facts are obtained. The policy dictates that those facts must exist. This distinction makes policies portable across organizations, systems, and customer experiences.

​
The Task → Policy → Schema Model

Organizations do not think in policies. Customers certainly do not think in policies. They think in tasks. Examples include:
  • Transfer Money
  • Add Beneficiary
  • Issue Refund
  • Approve Vendor Payment
A customer chooses a task. The organization maps that task to a policy. The policy defines a schema. The schema defines required verified signals. The resulting architecture becomes: 
Customer Chooses Task
          ↓
Task
          ↓
Task → Policy Mapping
          ↓
Policy
          ↓
Policy Schema
          ↓
Required Verified Signals
          ↓
Signal Verification
          ↓
Verified Signals
          ↓
Policy Evaluation
          ↓
Decision
          ↓
Execution
This structure creates deterministic enforcement. 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.

​
The Trust Boundary

This architecture creates a clear separation of responsibilities. Customer Provides information. AI Collects information and assists interaction. Operational Systems Verify information and establish facts. Parmana Evaluates verified facts against policy. Execution Systems Execute approved actions. This separation is important because it prevents policy enforcement from depending on AI reasoning. AI can help gather information. AI can assist workflows. AI can improve user experiences. But AI does not determine truth. Verification determines truth. And policy enforcement operates on verified truth.

​
Evidence Is The Stable Interface

Customer experiences change. AI systems change. Verification systems change. Organizations change workflows. Policies should not. A policy should define the evidence required for evaluation. How that evidence is collected is an implementation detail. How that evidence is verified is an operational concern. Policy enforcement begins only when verified facts exist. This separation allows policies to remain stable while systems evolve around them.

​
Why This Matters

The future will contain increasingly autonomous systems. The challenge is not merely collecting information. The challenge is establishing evidence. Inputs are claims. Verified signals are facts. Policies define the facts required for evaluation. Verification establishes those facts. Policy enforcement determines whether execution is allowed. As autonomous systems become more capable, organizations will need a reliable mechanism to ensure actions remain subject to human-defined rules. That mechanism cannot depend on user interfaces. It cannot depend on workflows. It cannot depend on AI reasoning. It must depend on evidence. Because autonomous systems should be governed by facts, not forms. And policies should define evidence, not inputs.