How does a conditional approval fit into an agent evaluation harness?

A conditional approval fits into an evaluation harness as three linked pieces: state, tools and a grader.

**State.** A decision record with a status, a list of condition records, an evidence store and a downstream request that stays blocked until conditions clear. Each condition carries a condition_id, decision_id, owner_role, due_point, rule_text and a status such as open, submitted, satisfied, referred_back, waived or lapsed.

**Tools.** An agent could be given read actions such as get_decision, list_conditions and read_evidence, and write actions such as request_evidence, mark_condition_reviewed, escalate_to_approver and release_step. Keeping release_step as a separate action lets the grader see exactly when the agent tried to proceed.

**Grader.** It compares the final environment state with an expected state. Typical checks are whether release_step was called while any blocking condition was open, whether the evidence reviewed matched the condition it was linked to, and whether an escalation named the correct open item.

**Reset.** Each task starts from a snapshot, so a run that changes condition status can be replayed or compared across models without carry-over.

**Format.** Records can be held as JSONL with one object per line, keyed by decision_id, so the harness can load a single case without parsing the whole release.