Skip to content
MirrorFirm

What schema and file layout would a sufficiency case release use?

A release can use relational tables in Parquet or nested JSONL, with stable identifiers that join policies, cases, documents, gaps and requests.

A release can be delivered in either shape, depending on your tooling.

**Relational layout (Parquet, one file per table)**

- `policies(policy_id, version, case_type, effective_from)` - `requirements(requirement_id, policy_id, clause_text, condition_expr)` - `cases(case_id, case_type, policy_id, status_initial, created_at)` - `documents(doc_id, case_id, doc_type, issued_date, signed, entity_ref, defect_label, content)` - `gold_decisions(case_id, decision, status_after)` - `gold_gaps(case_id, requirement_id, doc_id, reason_code)` - `messages(msg_id, case_id, direction, role, body, resolves_gap_ids)`

**Nested layout (JSONL)**

One line per case, with `documents`, `messages` and `gold` as nested fields. Gold fields can be placed in a separate file keyed by `case_id`, so the evaluation set can be shared without labels.

**Conventions to agree**

- Identifier styles such as `CASE-0412`, `DOC-8821`, `REQ-1175`, stable across tables. - Dates in ISO 8601. - A closed list of `reason_code` values, for example `missing`, `expired`, `wrong_entity`, `conflict`, `unsigned`. - A `split` column with train, dev and test values.

A schema description file can ship with the data. Scope field names and the reason-code list in a pilot so they match your harness.

A stable keyed schema lets engineers load, join and split the data with standard tooling and no custom parsing.

Audience:
Model labs
Content type:
Integration
Buyer question:
What can be generated

Content release: r-a220eb6e099b243b

More on Document sufficiency