Skip to content
MirrorFirm

What schema fields link assessments, requests and resubmissions?

Assessment, request and resubmission records can share keys and carry enumerated gap codes, so a customer can trace a gap from detection through request to resolution.

The most useful design choice is a shared gap code. Each gap an assessment finds is a small object, and the same object is referenced downstream.

``` assessment.gaps[] = { gap_id: "GAP-7731", code: "missing | expired | partial | mismatch | not_required", rule_id: "RULE-0092", doc_id: "DOC-5510" | null } ```

A request lists `gap_ids` instead of repeating the text, along with `message`, `due_at` and `lapse_outcome`. A resubmission record carries `request_id`, `new_doc_ids` and `gaps_resolved`. The next assessment references the earlier one through `supersedes`.

**Delivery:**

- JSONL for nested records, one file per record family. - Parquet for flat analysis tables, with gaps exploded to one row each. - A `schema.json` and a `manifest.json` carrying release version, generation settings and record counts for that release.

**Evaluation hooks:**

- exact match on `code` and `rule_id` per gap - set comparison between predicted and reference `gap_ids` - a request check that every gap appears in the message and no extra item is asked for

Keep key formats consistent between releases. If you merge two releases for a customer, namespace the identifiers so they cannot collide.

All records are generated. Verify field population in a sample before describing the schema to customers.

Enumerated gap codes and stable keys make the dataset joinable and scoreable without free-text parsing on your customers' side.

Audience:
Licensed resellers
Content type:
Integration
Buyer question:
What can be generated

Content release: r-a220eb6e099b243b

More on Document sufficiency