Skip to content
MirrorFirm

How does intake map onto environment entities, links and state transitions?

Intake can be modelled as six linked entity types with a declared status transition table and tool actions that mirror those transitions, exportable as JSONL or Parquet.

A useful way to map intake into an environment is as six linked entity types, each exportable as its own JSONL file.

- **case**: case_id (for example APP-2187), request_type, status, channel, received_at, owner_id, queue_id - **party**: party_id, role, identifiers, contact fields, linked_case_ids - **document**: document_id, case_id, doc_type, page_count, received_at, quality_flag - **task**: task_id, case_id, task_type, due_at, state - **policy_rule**: rule_id, request_type, required_fields, required_documents, routing_condition, exception_text - **audit_event**: event_id, case_id, actor, action, before, after, at

Foreign keys such as case_id and party_id make the links explicit, so a grader can join tables without parsing text. Status values come from a declared transition table, for instance RECEIVED to PENDING_INFO to READY_TO_ROUTE to ROUTED, with each allowed transition listed in the schema.

Tool actions can mirror the transitions: get_case, list_documents, request_information, link_party, set_status, route_case, add_note. Each returns structured JSON and rejects transitions the table does not allow, which gives the agent clear error signals.

Parquet suits larger analytical exports of the same tables, while JSONL suits environment loaders that stream one record per line. Scope the exact schema in a pilot rather than assuming it.

Explicit keys and a transition table let an environment enforce consistency and give graders structured data instead of text to parse.

Audience:
Environment builders
Content type:
Integration
Buyer question:
What it is and why it matters

Content release: r-a220eb6e099b243b

More on Application intake