Brel’s entity-graph concept is a method for relating nodes—companies, products, models, people, and Knowledge guides—with typed edges that carry evidence and confidence. It is a way to navigate an AI ecosystem without pretending the map is complete or live-scraped. This page owns that method: why an entity graph helps, node types, edge types, evidence and confidence, sync with Knowledge articles, failure modes such as stale edges, reader uses, and the boundary to the knowledge-graphs technical guide. It does not fabricate a full live graph dump, and it is not a how-to for unauthorized scraping or data harvesting.
Conceptual neighbors: AI industry for stack structure, AI products for product surfaces, AI models for model entities, AI research labs for lab nodes, and knowledge graphs for the general KG engineering discipline this concept specializes.
Why an entity graph—company nodes follow AI company method
Flat lists hide structure. Readers meeting only ranked logos or isolated articles miss that a product wraps a model, that a lab spun out a company, or that a guide explains a capability family many products claim. An entity graph makes those relationships explicit—and, when honest, makes missing relationships visible as gaps rather than as silent absences.
Graphs also fight category errors. Linking a buyer to a product node with a clear surface type is more useful than linking them to a vague “AI innovator” label. Graphs support multi-hop questions: which guides explain the failure modes of the product class this company sells?
Operationally, a graph concept supports editorial consistency. If two articles disagree about whether something is a model or a product, the graph forces a typing decision. Typing decisions are cheaper than perpetual prose conflict.
The graph is not a surveillance product and not a promise of omniscience. Its value is disciplined partial knowledge: better questions, clearer ownership, fewer invented completeness claims.
Finally, graphs age. The point of a method page is to teach update and distrust habits so the visualization never becomes more trusted than its evidence ledger.
Discovery without structure floods readers with peers that are not peers. A graph that encodes layer and product-surface typing supports “same class” browsing without asserting a ranked order. That is the opposite of top-list thinking: neighborhood by type, not podium by hype.
Graphs also help internal authors. When writing a Knowledge update, authors can query which entity classes are implicated and update edges in the same batch as prose. Coupled updates reduce the classic failure where articles mention a sunset product that the graph still treats as current.
Humility remains mandatory. Partial graphs tempt people to overfit stories from visible nodes. Train readers—and executives—to ask what is missing on purpose, what is missing for lack of evidence, and what is missing because it is out of editorial scope.
Node types
Node types should be few, stable, and mutually intelligible:
Company. A commercial or legal entity that sells or operates AI-relevant offerings. Company nodes are about accountability and contracting identity—not about every employee.
Product. A sellable or operable surface: API, application, suite, platform feature, or infra offering. Align typing with AI products. One company may have many product nodes.
Model. A trained artifact or model family offered or referenced as a distinct capability unit. Align with AI models. Do not create a node for every ephemeral checkpoint name without evidence of public identity.
Person. A public role-bearing individual when relevant to founding, research leadership, or public accountability—not a dossier. Prefer sparse, high-signal person nodes over social-graph sprawl.
Lab / research organization. Distinct from company when the public identity is research-first; see AI research labs. Some organizations need both lab and company nodes with a typed link.
Knowledge guide. A Brel Knowledge article node representing durable literacy, not an entity in the world. Guide nodes enable “explained-by” edges.
Optional: sector / capability tags. Use sparingly as classification nodes; overbuilt taxonomies become a second confusing product.
Typing rules: one primary type per node; dual identities only via edges; refuse “misc” as a junk drawer. When unsure, leave untyped rather than mis-typed.
Capability or topic nodes can exist when they represent stable Knowledge ownership—such as a guide topic—not every buzzword. If a topic lacks a guide, prefer omitting the node until ownership exists. Empty topic nodes become graves for slogans.
Region nodes are optional and dangerous if they invite invented landscape statistics. If used, keep them as navigation aids linked to landscape guides with qualitative scope—not as containers for fabricated market shares.
Deduplicate aggressively. One product sold under two marketing names still needs one product node with aliases. Duplicate nodes break degree counts and create contradictory edges.
Edge types
Edges should be verbs with constraints, not decorative lines:
Sells / offers. Company → product.
Provides / hosts / wraps. Product → model (or company → model when direct).
Depends-on. Product or company → infra provider or model provider. Critical for lock-in analysis.
Affiliated-with / spun-out-of. Company ↔ lab.
Founded / leads (public). Person → company or lab, only with public evidence.
Explains / governs-topic. Knowledge guide → capability or entity class (not every firm).
Competes-in (weak). Prefer shared category membership over hard-coded rivalry edges that editorialize.
Invested-in (cautious). Only with evidenced funding literacy; omit amounts if unverified; never invent.
Edge properties: directed or undirected declared; time window; evidence class; confidence; review date. An edge without properties is a rumor with a line.
Do not mint edges from unauthorized scraping plays. Public docs, primary disclosures, and editorial verification are the legitimate inputs. Method pages that teach theft or ToS-violating collection are out of scope and out of bounds.
| Edge type | Typical ends | Requires | Common misuse |
|---|---|---|---|
| Offers | Company → product | Product identity evidence | Logo as product |
| Wraps / hosts | Product → model | Docs or clear claim | Assuming all apps train models |
| Depends-on | Product → provider | Architecture evidence | Inferring from ads |
| Explains | Guide → topic class | Editorial ownership | Linking every guide to every firm |
| Affiliated | Lab ↔ company | Primary disclosure | Equating papers with products |
Qualify edges with role notes when needed: “reseller,” “technology alliance,” “cloud marketplace listing.” Role notes prevent treating a listing as a deep integration. The verb stays stable; the qualifier carries nuance.
Avoid sentiment edges (“is exciting,” “is untrustworthy”). Those belong in dated reviews with methods, if anywhere. The entity graph should remain boring enough to audit.
Bidirectional display is a UI concern; storage should keep canonical direction to prevent double counting. Undirected edges are appropriate for some affiliations; declare them rather than implying symmetry that does not exist in contracts.
Evidence and confidence
Every edge and non-obvious node attribute needs an evidence class: primary disclosure, product behavior observation, regulator filing, reputable secondary pointer, or unverified claim. Confidence can be qualitative (high/medium/low) tied to evidence class and freshness—not fake numeric precision.
High confidence example: a product docs page stating which model API is called. Low confidence example: a slide implying partnership without a primary page. Unverified claims may be stored internally as hypotheses; they should not present as fact edges in reader UI.
Confidence decays with time for volatile relations (pricing dependence, model menus) and decays slowly for stable legal identity. Decay is a feature: it schedules review.
Contradictions: keep competing edges with flags rather than deleting history silently. Readers and editors benefit from seeing that the graph once claimed X and later claimed Y.
Never “complete” the graph by generative guesswork. A sparse honest graph outperforms a dense hallucinated one—especially when the hallucination invents companies, rankings, or stats.
Attach pointers to evidence, not pasted secrets. A link to a public docs URL plus retrieval date is enough for many edges. Internal notes may hold richer verification state without exposing non-public material on public pages.
Confidence should not be a vibes emoji. Tie high confidence to primary, recent, specific evidence; medium to credible secondary with partial primary; low to thin or aged signals. When confidence is low, UI should default to hiding or labeling rather than drawing thick authoritative lines.
Batch imports need quarantine. New edges enter as unverified until sampled review. Automating layout is fine; automating truth is not.
Sync with Knowledge articles
Knowledge articles and the entity graph should stay synchronized in ownership, not duplicated in content. Guides own explanations; entities own instances; edges own relationships.
Sync patterns: when AI industry revises layer language, check that product and company typing still maps. When AI products taxonomy changes, migrate product node types. When AI models guidance clarifies model-versus-product boundaries, audit wraps/hosts edges.
Guide nodes should link outward to classes of entities, not maintain shadow directories inside HTML. Long Knowledge lists of firms go stale and fight the graph’s job.
Editorial workflow: content changes that affect relationships should include a graph checklist—new product launched, model retired, lab commercialization, acquisition—so prose and edges move together.
Do not require the graph to cite every sentence of every guide. Require that conflicting claims between guide and graph trigger a ticket. Consistency is a process, not a one-time import.
Create a lightweight ownership matrix: which editorial role updates company nodes, which updates guide explains-edges, which approves depends-on edges for prominent products. Unowned graphs rot.
When a guide is substantially rebuilt, run a graph diff checklist: removed claims, renamed concepts, new boundaries. Especially watch Class C boundaries so entity typing does not smuggle ranking pages back in through the side door.
Guide nodes should use stable slugs as identifiers. Title changes should not break explains-edges. Identity is the slug; titles are labels.
Failure modes (stale edges)
Stale edges are the primary failure mode. A “depends-on” link that survives a provider migration misleads architecture reviews. A “offers” edge that survives product sunset frustrates buyers. An “affiliated” edge that survives a spin-out separation confuses accountability.
Other failure modes: type drift (product labeled as company); edge overload (everything “related”); vanity density (maximizing link count); ranking edges dressed as objective order; and scraped blobs without licenses or permission—both legally and epistemically toxic.
Operational mitigations: review dates on edges; volatility classes; bulk “needs review” queues; prohibiting undated competitive rank edges; and human acceptance for high-impact depends-on links.
Reader-facing mitigations: show as-of dates; show confidence; allow “unknown”; and never imply the visible neighborhood is the entire market.
When staleness is discovered, prefer correcting with a dated supersession note over quiet deletion that erases audit trail—especially for edges that influenced published articles.
Stale person edges are a quieter failure: leaders depart, but “founded” remains historically true while “leads” becomes false. Use time-bounded roles. Historical edges are valuable if labeled historical.
Mirror sites and outdated press kits can re-seed false edges after you corrected them. Prefer canonical domains and dated captures. If a correction war repeats, raise the evidence bar rather than editing forever on rumor cadence.
Performance failure modes matter too: giant visualizations that imply completeness. Prefer progressive disclosure—neighborhood views with explicit “more may exist”—over hairball charts that look omniscient.
Reader uses
Readers can use an entity graph to: orient (“what does this company actually sell?”); traverse (“which guide explains this product class?”); compare structurally (“same surface type, different model posture”); and spot concentration (“many products depend on one model provider”).
Readers should not use the graph to: crown winners; infer secret relationships; replace vendor evaluation; or treat missing nodes as proof a firm is unimportant. Absence is often editorial prioritization or evidence insufficiency.
Practical reading habit: for any path of length greater than two, re-check evidence at each hop. Multi-hop stories compound error. Prefer short evidenced paths for decisions.
Pair graph exploration with AI industry literacy so hops respect stack layers, and with product taxonomy so comparisons stay fair.
Writers can use the graph to avoid contradictory descriptors across articles. If the graph says a firm is primarily an API vendor, Knowledge prose should not casually call it a chip company without an edge and evidence.
Buyers can use neighborhoods to assemble bakeoff candidates of the same product class, then leave the graph and enter evaluate-AI-vendor workflows. The graph proposes; evaluation disposes.
Educators can use short paths—guide → capability → example product class—without turning lessons into vendor endorsements. Example nodes should be illustrative and dated, not ranked.
Boundary to knowledge-graphs guide
Use knowledge graphs when the question is the general technology of graph data models, ontologies, embeddings-plus-graphs, and engineering patterns for KG systems. Use this page when the question is Brel’s AI ecosystem entity-graph concept—editorial method for companies, products, models, people, labs, and guides.
This page does not teach unauthorized data collection. It does not publish a fabricated complete graph. It does not replace AI products, AI models, or AI research labs ownership.
A useful entity graph is a humble instrument: typed nodes, evidenced edges, visible uncertainty, scheduled review, and tight sync with Knowledge. Build for navigation and accountability—not for the illusion that the AI world has been fully captured in a picture. When the picture and the evidence disagree, believe the evidence and fix the picture.
Implementation note for future builders: storage format can be a graph DB, a relational edge table, or even carefully governed content relationships—so long as evidence, confidence, and review dates travel with edges. Technology choice is secondary to epistemic hygiene.
If visualization is offered to readers, default views should be small neighborhoods with legends for edge types and confidence. Exportable machine graphs, if any, must respect licensing and not imply completeness. A downloadable hallucination is still a hallucination.