Skip to content
MirrorFirm

What might the JSONL schema for schedules, instalment lines and requests look like?

Sketches field-level structure and keys for three linked JSONL files, plus a manifest, so engineers can judge fit with their own harness.

A release could ship as line-delimited JSON, one file per entity, with stable identifiers for joins. Parquet versions of the same tables can be requested for larger runs.

**schedules.jsonl**

- `schedule_id`, `agreement_id`, `version`, `supersedes` (nullable), `status`, `created_at`, `created_by_role`.

**instalments.jsonl**

- `line_id`, `schedule_id`, `seq`, `due_date`, `amount`, `components` (object: principal, interest, fees, or quantity), `status`, `rounding_adjustment`.

**events.jsonl**

- `event_id`, `line_id`, `type` (payment, reversal, dishonour, delivery, short-delivery), `amount`, `occurred_at`, `reason_code`.

**requests.jsonl**

- `request_id`, `agreement_id`, `channel`, `text`, `received_at`, `requested_action`.

**policies.jsonl**

- `policy_id`, `version`, `effective_from`, `rule` (structured), `approval_role`.

**tasks.jsonl**

- `task_id`, `request_id`, `as_at`, `starting_snapshot_ref`, `expected_end_state`, `policy_refs`, `allowed_outcomes` (such as `commit`, `refuse`, `escalate`).

A `manifest.json` should list file hashes, the generation parameters, the schema version and a seed. Money is best held as integer cents to avoid float drift, and all dates as ISO 8601 with an explicit time zone.

The field names above are a starting proposal. Exact names, nesting and any extra keys are things to agree during pilot scoping so that the files fit your harness.

A concrete key-and-link layout helps engineers judge quickly whether a release can load into an existing evaluation harness.

Audience:
Evaluation teams
Content type:
Integration
Buyer question:
What can be generated

Content release: r-a220eb6e099b243b

More on Repayment scheduling