How ontologies and filtering work
The problem: “relevant to the niche” is not a vibe — it has to be a computable property, or discovery drifts and brand safety becomes luck. The platform’s answer: make the niche an explicit, derived ontology, and make every filter a separate gate with one owner.
Layer 1 — the ontology is derived, not hand-typed
Section titled “Layer 1 — the ontology is derived, not hand-typed”Each contract’s niche ontology is derived from its brand description (the same source that feeds brand voice) plus the contract’s own structural pages — About and Services, not articles. Empty inputs fail loud: a contract that cannot say what it is about cannot collect. The result is a tiered term structure: core concepts, actions, ecosystem entities, user intents.
Layer 2 — per-candidate taxonomy, then comparison
Section titled “Layer 2 — per-candidate taxonomy, then comparison”During discovery every surviving candidate gets its own small LLM-built taxonomy in the same shape — and scoring compares taxonomies, not keywords: term overlap across tiers plus a domain affinity bonus, blended into the candidate’s overall rank. “Is this about our niche?” becomes a structured comparison instead of substring luck.
Layer 3 — filters with one owner each
Section titled “Layer 3 — filters with one owner each”Filtering is deliberately not one big function. Each gate owns a concern (the same charter philosophy as the writing framework):
| Gate | Owns | Verdict |
|---|---|---|
| URL dedup | ”have we seen this exact source” | delete |
| Per-domain cap | funnel diversity | cap |
| LLM screener | cheap topicality pass/fail | drop |
| Ontology comparison | niche fit, structured | score |
| Topic dedup | semantic novelty vs committed topics | defer (reversible) |
| Export policy | rank floor + capped bands | never seeded |
Layer 4 — brand defense as declarations plus signals
Section titled “Layer 4 — brand defense as declarations plus signals”The ontology says what the contract is about; brand-defense declarations say what it must not promote. Competitor lists live in the brand description as explicit sections — maintained by an automated candidate miner (signals: donor gravity, corpus frequency) with an owner-approved lifecycle, so the lists cannot silently rot. Downstream, a battery of deterministic signals watches the rendered result: donor on a competitor domain, competitor name in the title, recommendation-verbs near a competitor, third-party promotion even for brands never declared (a list-independent rule: promote only your own), buyers-guide shapes, outbound links. A brand-safety hit doesn’t lower the quality number — it flips the verdict (reject/rework), a deliberate separation of “how good is the text” from “may this ship”.
The trade-offs, honestly
Section titled “The trade-offs, honestly”Filtering by declared ontology means the ontology’s quality is the ceiling — a vague brand description yields vague collection, which is why derivation fails loud instead of falling back to defaults. Competitor filtering is intentionally absent at the discovery stage (a competitor URL can be a legitimate research source); defense is enforced where intent is visible — in what gets written and published.
See it in two minutes
Section titled “See it in two minutes”Any candidate row carries its ontology comparison and rank; any published article carries its brand-safety signal battery — both readable through the API.
Specs: SPEC-082 (ontology derivation + comparison), SPEC-111 (competitor registry lifecycle), SPEC-118 (topic dedup), quality signal battery S1–S8.