Tracking issue. Once RFC #3533 ratifies and impl #3764 lands, fold the RFC's content into the normative spec at `docs/brand-protocol/brand-json.mdx` and delete the proposal file.
What to fold (move from RFC into brand-json.mdx)
The RFC carries content the spec page doesn't have today:
- Motivation paragraph (operational pain story — 'Converse can't update its own logo without editing Nike's file'). Useful framing for spec readers.
- Conformance section (validator invariants — brand_id cross-array uniqueness, mutual-assertion as canonical trust primitive, managed_by non-trust, standalone trumps third-party claim, strictest-of compliance, 180-day TTL). Belongs in the normative spec.
- Strictest-of compliance resolution rule for governance fields. Belongs alongside the field-resolution table.
- Prior art note (ads.txt / sellers.json). Worth keeping for context, possibly in a sidebar.
- AAO API ergonomic note (server-side family merge). Already non-normative; can stay as-is in spec page.
What to drop
- Open questions — once decided in the RFC review, no longer questions. Drop.
- Migration plan section — once both shapes coexist in production, the spec page just states the rule. The full plan was a discussion artifact.
- Status table — RFC-only artifact. Drop.
What to delete
- `docs/brand-protocol/proposals/distributed-brand-json-rfc.mdx` — the file
- The directory `docs/brand-protocol/proposals/` if no other RFC files moved in
Acceptance
References
Tracking issue. Once RFC #3533 ratifies and impl #3764 lands, fold the RFC's content into the normative spec at `docs/brand-protocol/brand-json.mdx` and delete the proposal file.
What to fold (move from RFC into brand-json.mdx)
The RFC carries content the spec page doesn't have today:
What to drop
What to delete
Acceptance
References