How does an approval-authority workflow map onto an existing evaluation harness?

Most harnesses already separate three things: the task input, the tools or state the agent can touch, and the grader. Approval authority maps onto each without much change.

**Task input.** A task record carries a request ID, the requester role, the amount or risk fields and the acting agent's assigned role. The agent receives these as the prompt context, plus access to policy text.

**Environment state.** Tables hold the authority matrix, active delegations with start and end dates, request history and routing events. Tool actions might include `get_authority`, `get_request`, `approve`, `decline`, `escalate` and `request_info`. Each write action appends an event to a log.

**Grader inputs.** The grader reads the final request state, the event log and a gold record that lists the permitted outcomes. Several outcomes can be valid, such as escalate to either of two eligible approvers.

**Typical files:**

- `authority.jsonl` for roles, limits and effective dates - `requests.jsonl` for items to be decided - `gold.jsonl` for permitted outcomes and rationale tags

**Reset.** Each task starts from a snapshot of the tables and discards the event log afterwards, so runs stay independent.

Because the data is generated, schemas can be shaped to your harness. Scope the field names and the format in a pilot, and inspect the sample for grounding and any disclosure risk before wider use.