Proposal: Parmana refund scenario as a reproducible test package, mapped to TRACE #286

Summary

Parmana is a server between an AI agent and the systems it acts on. It evaluates each proposed action against a
versioned policy, requires a signed human approval where the policy says so, releases the action only through a
gateway that holds the credentials, and signs a record of every action and every refusal.
This issue proposes one scenario as a reproducible test package, and asks how its decision and execution evidence
should map to TRACE before any integration is written.

Scope proposed

One scenario: a customer refund (paytm:refund) under the policy customer-refund 1.2.0, in three cases:
Case Expected Connector invocations
Valid approval: a signed manager approval for the order, up to the amount 200, APPROVED, signed Execution Trust Record 1 (mock result)
Refusal: every caller fact true, no approval 403 POLICY_DENIED, signed Refusal Record 0
Replay: the same approval sent again with a new request 403 POLICY_DENIED, signed Refusal Record 0

Pinned source and commands

Source: https://github.com/pavancharak/parmana at commit b4deee66fa8f0aad29a7ddc916f7fb33eef0ff50
Package README: https://github.com/pavancharak/parmana/blob/b4deee66fa8f0aad29a7ddc916f7fb33eef0ff50/docs/evaluation/agentrust-refund/README.md
Policy: https://github.com/pavancharak/parmana/blob/b4deee66fa8f0aad29a7ddc916f7fb33eef0ff50/policies/customer-refund/1.2.0/policy.json

git clone https://github.com/pavancharak/parmana.git
cd parmana
git checkout b4deee66fa8f0aad29a7ddc916f7fb33eef0ff50
npm ci
npm run build
npm run evaluate:agentrust-refund

Node.js 24. No network, database, keys or accounts: storage is in memory, the approver key is generated per run, and
the connector is a hermetic mock. The command writes evaluations/agentrust-refund/report.json with the commit,
whether the working tree was clean, the Node.js version and, for each case, the HTTP status, decision, reason,
connector invocation count and the signed record (id, hash, algorithm, policy content hash).
Existing run record: https://github.com/pavancharak/parmana/blob/main/evaluations/agentrust-refund/report.json (a run on a clean checkout of b4deee66; the record names that commit)

Limitations stated up front

Mock results only. The connector is MockPaytmConnectorServer. Nothing in the package confirms a refund at a downstream system; the report labels each connector result as a mock result.

Caller supplied facts. The policy treats refundEligible and fraudCheckPassed as declared by the caller,
not checked against an order or fraud system. They can only refuse a refund; the signed manager approval is what
authorizes one. The report keeps this limitation.
Enforcement versus evidence. The refusals are enforced by the server (policy, approval verification, single use). The signed records are evidence that can be verified afterwards, offline, with the public key; they do not enforce anything by themselves.

Proposed TRACE mapping (for discussion)
Against TRACE v0.2 (agentrust-trace 0.11.0, TrustRecord):
TRACE field From Parmana Status
policy.bundle_hash, policy.version, policy.enforcement_mode Policy content hash, customer-refund@1.2.0, enforce Available (approved requests; Refusal Records do not carry the hash today)
tool_transcript.call_count Connector invocations: 1, 0, 0 Available
tool_transcript.hash Hash over the canonical list of connector calls To define
origin third-party-control-plane, producer parmana, the record id Available
references The Parmana record id, resolver, record hash Available
iat Record creation time Available
runtime software-only; measurement to agree Partly
build_provenance SLSA level 0 for the server today; digest to agree Partly
appraisal none (no hardware evidence) To agree
subject, model, data_class Not visible to a governance layer Need guidance
cnf / signature Parmana signs its own canonical form, not the TRACE form Need guidance

Questions for a maintainer

Is one TRACE record per Parmana decision the right unit, including refusals with call_count: 0?
What should an adapter use for subject, model and data_class when the governance layer does not see them?
Should the TRACE record be signed by an adapter key that references the Parmana record, or should Parmana sign the TRACE form itself?
How should a mock connector result be marked so it is never read as a confirmed downstream action?
I will not start the integration until the scope is agreed here.

Permissions

The current licence is evaluation only. For this work I can grant written permission to you and the AgenTrust reviewers to run the evaluation and publish fixtures and results in agentrust-io/integrations. I will send that permission separately.