Skip to content
MirrorFirm

What record types and links does an agent meet in a conditional approval process?

The workflow usually spans decision, condition, evidence and downstream work item records, tied together by identifiers that let an agent decide whether a step may run.

In most businesses the workflow spreads across three record types, and an agent's tools usually touch all of them.

- **Decision record:** an identifier such as APP-2187, a decision status, decision date, approver role, expiry date and a version number. - **Condition records:** one row per condition, linked to the decision by `decision_id`, with `condition_type`, `owner_role`, `due_date`, `state` and `waiver_reason` when relevant. - **Evidence records:** documents, notes or system events linked by `condition_id`, with `received_at`, `source_channel` and a review outcome.

A fourth set, downstream work items such as a settlement task or dispatch order, carries a `gated_by` reference back to the decision. That link is what lets an agent decide whether a step may run.

A release can supply these as JSONL files, one per record type, with foreign keys stable across files so joins work in any pipeline. Parquet is a reasonable choice when volumes are large and columns are queried analytically.

Agent tools typically map to a small set of actions: `get_decision`, `list_conditions`, `attach_evidence`, `request_review`, `advance_work_item`. The last should reject calls when open conditions remain, so the environment itself tests restraint.

Treat the field names above as a starting pattern. Scope the exact schema against your own systems in a pilot, and check that generated fields behave plausibly against your process before building on them.

Knowing the record shapes and links up front lets you map your own systems to a generated release and check the joins your agent depends on.

Audience:
Agent developers
Content type:
Integration
Buyer question:
What it is and why it matters

Content release: r-a220eb6e099b243b

More on Approval conditions