3.1: policy_id attribution on feature_requirements and creative feature results

[bokelley]

Problem

In 3.0 we unified on policy-entry.json as the shape for all policies (registry-published and buyer-authored), and established policy_id as the universal cross-surface pointer (governance findings, validation feature verdicts, etc.).

What's missing: when a buyer adds a property filter or creative constraint because of a policy, there's no way to tag the filter with its authorizing policy. The mechanism and the policy are decoupled — which means audit trails can't answer "why does this property list exclude children's programming?" without human interpretation.

Proposal

Add optional policy_id: string to the schemas that define mechanism-level constraints:

1. static/schemas/source/core/feature-requirement.json — feature predicates used by property list filters today (and other surfaces in the future)
2. static/schemas/source/creative/creative-feature-result.json — creative feature measurements
3. Any audience-filter schemas where buyers author targeting constraints

Example:
```json
{
"feature_requirements": [
{
"feature_id": "audience_children_composition",
"max_value": 15,
"policy_id": "uk_hfss"
}
]
}
```

Why bottom-up tagging (not top-down in policy-entry)

Considered an alternative: add `implementation_hints.property_filters[]` to policy-entry so policies declare their mechanisms. Rejected because:

• Audit trail is natural bottom-up. Looking at a filter and asking "why is this here?" — answer lives on the filter itself, not in a remote policy declaration.
• Policies stay thin. PolicyEntry doesn't need to know about every tool that might implement it.
• Extends the pattern we already committed to in 3.0. `policy_id` is the universal pointer across findings, validation verdicts, validation features. Adding it to mechanism-level constraints is consistent.

Use cases enabled

• Audit: "Why is this property list filtering out children's audiences?" → `policy_id: uk_hfss`, look it up in registry.
• Compliance reporting: group filters and constraints by authorizing policy.
• Governance agents: when emitting findings, populate `policy_id` on the finding from the underlying filter's `policy_id`.
• Policy lifecycle: when `uk_hfss` sunsets (via `sunset_date`), identify all constraints that cite it and notify buyers to remove them.

Non-breaking

Purely additive. Optional field. 3.0 clients populate nothing; 3.1 clients populate when applicable. No schema surgery on existing fields.

Related

• 3.0 GA establishes: `policy_id` as universal pointer; `policy-entry.json` as unified policy shape (Schema↔storyboard shape mismatch: content_standards.policy (array vs prose string) #2284 + the fresh-builder test bundle)
• Depends on: `policy-entry.json` registry being populated enough that `policy_id` references have something to resolve to

Scope for 3.1

• Add optional `policy_id` to `core/feature-requirement.json`
• Add optional `policy_id` to `creative/creative-feature-result.json`
• Identify audience-filter surfaces that need the same addition
• Update docs to describe the attribution pattern
• Consider: governance findings populate `policy_id` from underlying filter `policy_id` when traceable

[bokelley]

Update: the policy_id field is now reserved in 3.0 on both core/feature-requirement.json and creative/creative-feature-result.json — present in the schema with semantics deferred to 3.1. This makes the 3.1 attribution work truly non-breaking for strict validators.

3.1 scope narrows to:

• Formalize the semantic contract (when producers SHOULD populate policy_id)
• Add policy_id to any audience filter schemas that weren't caught
• Define findings → source filter traceability (i.e., governance findings populating their own policy_id from the underlying filter's policy_id when traceable)
• Docs on the attribution pattern

Field is already reserved pre-GA, so 3.0 consumers validating strictly against the 3.0 schema accept 3.1-authored data without issue.