How does intake appear as linked records a model can learn from?

Intake becomes learnable when each step leaves a typed trace. A useful structure links five record types by identifier:

- **submission**: `submission_id` (`SUB-7741`), channel, `received_at`, `raw_text`, `attachment_ids`. - **case**: `case_id` (`CASE-0412`), `submission_id`, `applicant_ref`, category, status, `queue_id`. - **check_result**: `case_id`, `rule_id`, outcome (`pass`, `fail`, `unclear`), `evidence_span`. - **action**: `case_id`, `actor_role`, `action_type` (`request_info`, `merge`, `route`, `reject`, `escalate`), timestamp, note. - **policy_rule**: `rule_id`, text, `applies_to`, `effective_from`, `exception_path`.

Links run from submission to case, from case to checks and actions, and from checks to rules. A model can be trained to predict the next action given the case history, or to produce check results given the raw submission and the policy.

JSONL suits nested case histories, one object per case. Parquet suits flat tables joined by identifier. Keep timestamps in ISO 8601 and statuses as a closed enumeration so that transitions can be validated.

A buyer can ask for a schema file with the sample so field meanings, allowed values and nullable fields are stated rather than guessed. All records are generated; check that identifiers and free text carry no trace of real people or organisations.