How do conditions map onto record types and links in an environment?

A sketch of the core record types, key fields and foreign keys needed to represent an approval, its conditions, evidence and the actions those conditions gate.

A minimal model uses five record types linked by identifiers.

- **approval**: `approval_id`, `subject_id`, `granted_by_role`, `granted_at`, `status`, `policy_ref` - **condition**: `condition_id`, `approval_id`, `kind`, `owner_role`, `due_at`, `evidence_spec`, `status`, `waivable` - **evidence**: `evidence_id`, `condition_id`, `submitted_by_role`, `submitted_at`, `doc_type`, `valid_from`, `valid_to` - **gated_action**: `action_id`, `approval_id`, `blocked_by` (list of `condition_id`), `status` - **audit_event**: `event_id`, `actor_role`, `target_id`, `verb`, `at`, `reason`

A release would typically ship these as JSONL, one file per record type, or as Parquet tables for larger sets. Each line of the condition file might look like this:

`{"condition_id":"COND-2187-A","approval_id":"APPR-2187","kind":"valuation","status":"open","waivable":true}`

Two design points matter. First, keep `status` transitions explicit, such as `open`, `awaiting_evidence`, `satisfied`, `waived`, `expired`, so your environment can validate them. Second, derive gate checks from the links rather than storing a separate flag, so state cannot drift.

The records are generated. Agree field names and enumerations with MirrorFirm in a sample so they fit your environment's own schema.

Starting from a small, linked schema lets you check gating logic early and extend it with domain fields later.

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

Content release: r-a220eb6e099b243b

How do conditions map onto record types and links in an environment?

Related questions