Skip to content
MirrorFirm

How does an escalation workflow appear as data an evaluation harness can read?

A harness typically reads linked policy, case, exposure, event and expected-outcome tables joined by typed identifiers and delivered as JSONL or Parquet.

A harness usually needs linked views of the same case: the policy, the case, the exposure links, the event history and the expected outcome.

- **authority_matrix**: `role_id`, `product_type`, `risk_grade`, `max_exposure`, `next_role_id`, `policy_ref`. - **case**: `case_id`, `applicant_id`, `requested_amount`, `status`, `owner_role_id`, `opened_at`. - **exposure_link**: `case_id`, `related_facility_id`, `relationship_type`, `outstanding_amount`. - **case_event**: `event_id`, `case_id`, `event_type` (`REVIEWED`, `REFERRED`, `RETURNED`, `APPROVED`, `DECLINED`), `actor_role_id`, `rationale_text`, `evidence_ids`, `occurred_at`. - **expected_outcome**: `case_id`, `acceptable_actions`, `required_trigger_ref`, `required_evidence_ids`, `final_status`.

Each table can be delivered as JSONL, one object per line, with identifiers such as `APP-2187` or `CASE-0412` acting as join keys. Parquet suits larger tables that are queried in bulk.

A harness reads the case and policy, lets the agent act through tool calls, then compares the resulting `case_event` rows and final `status` against `expected_outcome`. Keeping the expected outcome in a separate file lets a team withhold it from the agent context and from training splits.

Field names above are a typical shape, not a fixed format; agree the exact schema in a pilot.

Keeping expected outcomes in a separate table lets a team grade runs from the event log while withholding answers from the agent and training splits.

Audience:
Evaluation teams
Content type:
Integration
Buyer question:
What it is and why it matters

Content release: r-a220eb6e099b243b

More on Credit escalation