App Schema Reference (Marketing HQ)
How the KB’s knowledge domains map to entities/tables in your custom app. The app holds the live, queryable records; the KB holds the durable understanding. Same concepts, different jobs.
Core entities and their KB counterparts
| App table | Holds (live data) | KB domain (durable knowledge) |
|---|---|---|
brands | brand records, status, owner | Brand_Architecture, 02 Brand Guidelines |
products / skus | live SKUs, stock, price, marketplace links | 03 Products & Catalogue |
channels | marketplace accounts, health scores | 04 Channels & Marketplaces |
campaigns | status, dates, budget, results | 06 Campaigns (briefs + post-mortems) |
tasks | assignments, deadlines, completion | 05 Playbooks (the how) + 08 (the who) |
kpis / metrics | daily/weekly numbers | KPI_Definitions (the definitions) |
people | roster, roles | 08 Team & People |
assets | creative files, links | 02/03 (asset libraries) |
Suggested relationships (matrix without explosion)
campaigns⇄brands(many-to-many viacampaign_brands)campaigns⇄channels(many-to-many viacampaign_channels)products⇄channels(a SKU listed on N marketplaces vialistings)tasks→people(owner) and →campaigns(parent)
This is exactly the brand × channel matrix from the org design — modeled as join tables instead of nested folders. Backed by Supabase, “show every active TikTok Shop campaign for startup brand X” becomes one query, not a folder dig.
Principle
The KB tells you what a good campaign brief contains. The app tells you the status of campaign #47. Don’t duplicate; link.