Follow-up from PR #4540 (brand verification RFC).
The gap
When a brand's verification agent returns `disputed` or `not_ours` in response to a leaf's `house_domain` claim, the spec is clear that agent wins. What it doesn't say: how should a consumer's UI render that to a user?
Examples:
- DSP inventory-shopping UI encounters a parent-rejected brand. Hide? Warn? Surface the brand's stated reason?
- Portfolio explorer navigating leaf→parent — what does the user see when the parent rejects?
- Creative-clearance UI shows a brand-rejected trademark — workflow continues how?
- Rejected leaf publisher — does the leaf get any UI surface to know it's been rejected? Today: no protocol path. Should there be one?
What this tracks
Non-normative consumer-side guidance for rendering and recovering from the disputed-claim state. Includes:
- Brand-side rendering recommendations
- Leaf-publisher recovery paths (update or remove `house_domain`)
- Audit-trail / appeal-process guidance
- Legal-exposure considerations (broadcasting a brand's rejection has defamation risk)
When to land
Lower priority than #4542 (bulk) and the Tier-2 implementer guide. The spec ships without this; UIs improvise reasonably until the doc exists.
Related
Follow-up from PR #4540 (brand verification RFC).
The gap
When a brand's verification agent returns `disputed` or `not_ours` in response to a leaf's `house_domain` claim, the spec is clear that agent wins. What it doesn't say: how should a consumer's UI render that to a user?
Examples:
What this tracks
Non-normative consumer-side guidance for rendering and recovering from the disputed-claim state. Includes:
When to land
Lower priority than #4542 (bulk) and the Tier-2 implementer guide. The spec ships without this; UIs improvise reasonably until the doc exists.
Related