What does a JSONL schema for approval requests and decisions look like?

A release can ship each entity type as its own JSONL file, with Parquet equivalents for large tables. Keys are stable strings so files join cleanly.

A request line might look like this:

`{"request_id":"REQ-3301","domain":"procurement","amount":42500,"currency":"AUD","risk_class":"medium","requester_id":"P-118","status":"pending","created_at":"2026-03-02T09:14:00+11:00"}`

A matching decision line:

`{"decision_id":"DEC-7720","request_id":"REQ-3301","actor_id":"P-204","action":"escalate","rule_id":"AUTH-0088","delegation_id":null,"timestamp":"2026-03-02T10:40:00+11:00","valid":true}`

Recommended links:

- `decision.request_id` references `request.request_id`. - `decision.rule_id` references the `authority_rule` that applied. - `decision.delegation_id` is null unless acting authority was used. - `role_assignment` rows carry validity windows, so authority can be resolved at any timestamp.

Practical notes:

- Store money as integer minor units or decimal strings, never floats, and state the currency on every row. - Use ISO 8601 timestamps with offsets. - Keep the `valid` label in a separate file from the observable data if the agent should not see it during an episode. - Include a schema file, such as JSON Schema, per entity and a manifest listing file hashes and the generation seed.

Field names are negotiable. Ask for a sample that matches your environment's existing keys, and check that joins resolve with no orphan identifiers.