Model records and relationships separately
Give an organization or product a stable identity record. Attach category, capability, geography and role as relationships with their own source and review state. A page route then selects a useful view for a buyer task. If a label changes, the entity remains the same; if a relationship is disproved, its evidence changes without erasing the entity. That distinction prevents a market map from becoming a collection of disconnected cards.
- Define stable entity IDs and separate display names from identity.
- Connect each entity to a category and to evidence for the asserted relationship.
- Add buyer tasks and routes that expose a meaningful slice of the graph.
Entity-category-demand graph with example
| Decision field | Record or rule |
|---|---|
| Entity | organization or product with its own source-backed identity. |
| Relationship | category, capability, geography or role with evidence. |
| Route | a page that answers one buyer task using those records. |
- 01Entity
- 02Relationship
- 03Route
Test the graph against a real route
Search1001 links product profiles to category, capability, engine and integration pages. The useful observation is that one product can be reached through several buyer questions without copying its core identity into multiple records. Draw a sample graph with one product, two relevant relationships and their sources. If a proposed category has no distinguishable question or evidence, it should not become a new route merely because the database can store it.
To carry this decision forward, write the inclusion boundary; distinguish an ecosystem view; compare the selected alternatives.
One product, several buyer routes
Take a product with a stable identity and two documented capabilities. Store the product once, then create separately sourced relationships to the relevant categories. A buyer arriving through a capability route sees the product because that relationship exists; a named-entity visitor sees the profile because the identity record exists. If one capability is withdrawn, update that edge and the route that uses it without deleting the whole profile. This simple case demonstrates why the Market is a maintained graph. Search1001's public route structure offers a visible example, while the proposed schema remains an original decision model for the article.
A practical schema needs provenance at the relationship level. A product profile can truthfully exist while a claimed category membership is outdated; tying both to one publication date would conceal the error. For each edge, keep the evidence URL, captured statement, review state and last meaningful check. The public route should explain why that edge helps the buyer, and a correction should target all views using it. This is the bridge between a diagram in an article and an operable Market database.
Do not build empty relationship types
A map schema is only as good as its boundary and data. Avoid creating empty relationship types because the template happens to support them.
References and source notes
Original 1000&1 methodology reviewed and approved by the author. Public claims and historical measurements are bounded by the linked sources and dates.