Repository navigation
Registry: list the brands a house has (house_domain filter on listBrands) #8747
Description
Problem
A buyer platform creating an advertiser for a house domain such as pg.com wants to offer the house's brands as choices: Tide, Gillette, Pampers and so on. The registry already knows many of these links. Each sub-brand's own record carries house_domain, so tide.com points at pg.com. But the public API cannot answer "which brands belong to this house?":
GET /api/brands/registry(listBrands) reads onlysearch,limit,offsetandsource. Ahouse_domainquery parameter is ignored.search=pg.commatches the house's own record, not its sub-brands, because search looks at the domain and the name.- The only way to get the list today is to page through the whole registry (about 12,800 records) and filter on the client.
The database layer already supports the filter: BrandDatabase.listDiscoveredBrands({ house_domain }). Nothing exposes it.
Evidence (live registry, 5 November 2026)
Records that name a house (house_domain) |
422 |
| Largest houses | unilever.com 27, pg.com 27, nestle.com 23, pepsico.com 22, generalmills.com 21 |
| Source of those records | 338 enriched, 60 hosted, 23 community, 1 brand_json |
Records with relationship_trust computed |
0 |
pg.com is a hosted record whose manifest lists no brands, so a client reading the house's own document finds nothing to offer.
Proposal
- Add a
house_domainfilter tolistBrands.GET /api/brands/registry?house_domain=pg.comreturns the records whosehouse_domainis that domain, with the existing per-record fields, includingrelationship_trustandclaimed_house_domain. Because the SDK buildsListBrandsOptionsfrom the OpenAPI document, clients getlistBrands({ house_domain })with no new SDK method.statsshould honour the filter, as it honourssearch. - Compute
relationship_trustfor the existing links. None of the 422 has a verdict yet. Until it does, a client cannot tell a house-confirmed link (inline,mutual) from an enrichment guess, and the registry's own guidance says to treat everything else as a claim.
What a client does with it
The intended use stays within the trust rules: a listed sub-brand is offered as a suggestion by its own domain only, never as authority from the house and never with a house brand_id. Choosing tide.com creates an advertiser on tide.com's own identity. The client labels a link as confirmed only when relationship_trust is inline or mutual.
Activity
feat(registry): filter the brand list by house_domain (#8748)
fix(registry): the house filter includes brands whose claim is unconf…
bokelley commentedon Nov 5, 2026
Part 1, the
house_domainfilter onlistBrands, shipped in #8748 and #8749. #8749 also matchesclaimed_house_domain, so brands whose claim is unconfirmed stay listed. Part 2, computingrelationship_trustfor these links, moves to #8755, which also covers where AAO-inferred links should live. Closing this one.bokelley commentedon Nov 6, 2026
Where this stands:
1. List a house's brands. #8748 added
?house_domain=toGET /api/brands/registry(merged). #8749 made it also match a brand's own unconfirmed claim inclaimed_house_domain(merged). #8764 (open) lists every brand the registry links to the house and labels each row withhouse_link:house_linkconfirmedhouse_declaredbrand_declaredinferred#8764 also returns the house's own record, so a picker can show "Brands of Procter & Gamble (verified)" without a second call.
2. Compute
relationship_trustfor the 422 existing links. Not doing this as a backfill: there's nothing to compute against. The resolver only returns a verdict for domains that serve a brand.json, and the brands linked topg.comdon't (tide.com, gillette.com and pampers.com return 404, dove.com 403). Most of the 422 links (338) come from enrichment. After #8764 they're listed and labelledinferred, which matches what they are.What changes P&G's list.
pg.com's hosted manifest is a flat brand manifest with no brand list. Once the owner publishes a portfolio (brand_refs[]or inlinebrands[], for example with Addie'sadd_to_brand_refs), its brands show ashouse_declared. That works even for brands that never publish a brand.json, because the list reads the house's own manifest. A brand becomesconfirmedonly when it publishes its own brand.json naming the house.Open question, not blocking: when a house lists a brand and the brand publishes a brand.json that doesn't name the house back, the crawler records
house_onlyand clears both house columns on the brand's row. #8764 doesn't depend on that row, but/api/brands/resolvefor the brand then doesn't say which house claimed it. Worth deciding whetherhouse_onlyshould record the claiming house.feat(registry): label how each brand belongs to a house
feat(registry): label how each brand belongs to a house (#8764)
bokelley commentedon Nov 6, 2026
Update to my comment above:
house_onlywhen the house's record lists the brand inbrand_refs[], andunverifiableotherwise. Neither verdict extends trust, so nothing about point 2 changes for clients.brand_declarednow means the brand published the claim itself, so anunverifiableverdict computed from stored records is still labelledinferred. An enrichment guess that names another house also can't stop a verified house from listing a brand. A test runs fix(registry): compute relationship_trust for brands that name a house without a brand.json #8766's computation before checking the labels.