How can generated records encode policy applicability without ambiguous joins?

A structured release can separate `policy_versions`, `scope_rules`, `work_items` and `applicability_results`. Each policy version needs a stable identifier; each scope rule should link to that identifier rather than to a mutable document title. Work items can reference product, jurisdiction, channel and processing stage through controlled values.

A `scope_rules` table could contain `scope_rule_id`, `policy_version_id`, `dimension`, `operator`, `value` and `precedence`. Explicit precedence matters when a broad rule overlaps a narrower exclusion. The schema should also state whether absent information means unknown, unrestricted or invalid. Those meanings should not share an undocumented null value.

Parquet can carry typed tables for analytical use, while JSONL can carry individual task instances referencing the same identifiers. A schema version and declared timestamp convention help consumers interpret both representations consistently.

Validation can reject orphaned references, unsupported operators and overlapping scope rules without a declared resolution. An applicability result can record the matched rule identifiers and a reason code. This gives the buyer a reproducible path from input attributes to policy selection, while leaving natural-language interpretation available as a separate task.