Business validation

• Authority. May this kind of action be decided here at all?
• Business validity. Is this exact action valid for this exact business object, according to the system that owns the facts?

​

The flow

1. The agent proposes an action and facts.
2. The facts must describe the action being executed (boundSignals).
3. Authority. The policy in force must be the approved, current one, and the capability must be decided under its bound policy. At the API, the caller’s key must allow the capability. Under a policy with requireAuthorityGrant, the caller must also hold a grant in force for the action, and the request must be within its limits. If authority is not established the request is refused, and no business system is asked.
4. Business validation. For each fact the policy declares a source for, Parmana asks that source about the business object it reads from the request, never using the agent’s value. If the agent proposed a value, it must equal the source’s.
5. The policy is evaluated on the values the sources established.
6. The signed human approval is checked (Human approval), then the action is authorized and released, and a signed record is written.

​

Naming the source of a fact

"signalSources": {
  "refundEligible": {
    "source": "orders-system",
    "claim": "refund.eligible",
    "subject": "parameters.orderId",
    "maxAgeSeconds": 60
  }
}

• source: the business system to ask, as registered through maker checker. Any system that answers the protocol can be one: an ERP, an order system, a CRM, a ledger.
• claim: what to ask it.
• subject: where the business object is in the request, target or a parameters path.
• maxAgeSeconds: how old the answer may be, from 1 to 86400, default 300.

​

Trusted Signal

{
  "signalKey": "refundEligible",
  "source": "orders-system",
  "sourceIdentity": "https://orders.example.com/parmana/signals",
  "claim": "refund.eligible",
  "subject": "123",
  "observedValue": true,
  "observedAt": "2026-10-10T12:00:00.000Z",
  "validUntil": "2026-10-10T12:01:00.000Z",
  "action": "refund",
  "businessTransactionId": "…",
  "integrityProof": {
    "algorithm": "sha256",
    "digest": "…",
    "sourceProof": "…",
    "sourceKeyId": "orders-2026-10",
    "sourceProofVerified": true
  },
  "verificationStatus": "VERIFIED"
}

​

Statuses

• AUTHORIZED means the action may be decided: the action type, and, under a policy that requires a grant, this request within the caller’s grant. It does not mean this action is valid or was executed.
• NOT_AUTHORIZED: the capability is decided under the wrong policy, or, under a policy that requires a grant, the caller holds none in force or the request is outside its limits.
• AUTHORITY_EXPIRED: the caller’s grant has passed its validUntil.
• AUTHORITY_UNCLEAR: the policy in force could not be established as the approved one, or the caller’s grants could not be read.
• INVALID: the agent proposed a value the source contradicts, or proposed facts that do not describe the action.
• MISSING_DATA: the request names no business object, the source has no such fact, or it answered with the wrong type.
• CONFLICTING_DATA: the source holds contradictory facts.
• SOURCE_UNAVAILABLE: the source is not registered or was revoked, failed, took longer than 10 seconds (or its registered timeout), or gave an answer Parmana cannot trust: incomplete, not echoing the query, or not signed by its registered key.
• VALIDATION_EXPIRED: the answer is older than maxAgeSeconds, or past the source’s own validUntil.
• NOT_EVALUATED: validation did not run, because authority was not established or the policy declares no sources. It is never VALID.

​

In the record

"assessment": {
  "authority": { "status": "AUTHORIZED", "reason": "…" },
  "businessValidation": {
    "status": "INVALID",
    "reason": "refundEligible: the request proposed true, but source \"orders-system\" reports false for 123.",
    "signals": [ … ]
  },
  "execution": { "status": "NOT_EXECUTED", "reason": "Not executed: business validation failed." }
}

​

Limits today

• Not deployed yet. Registering sources and asking them is in the repository and tested, but no real business system has been connected. No shipped policy declares a source.
• Checked once. An answer is checked when the request is decided, not again when the action is released (phase 4).
• Grants are opt in, per policy. A policy without requireAuthorityGrant keeps today’s authority checks. No shipped policy requires a grant yet. Grant limits are per request, not per day.
• Refund eligibility has no source yet. refundEligible and fraudCheckPassed in customer-refund are still declared by the caller and can only refuse (see Limitations).