The context layer that makes agents understand your operation
Products, lines, routings, materials and constraints captured as one semantic network — so the system doesn’t just store your data, it understands it and traces the impact of every change.
Layer 1 · Contour Ontology
Contour gives agents a working model of your business
What is a supply chain ontology?
Traditional systems describe your supply chain as tables and fields — item codes, warehouse IDs, line names. They store the data, but they don’t understand how any of it relates.
Contour (Convect Ontology Unified Representation) changes that. It captures your supply chain as a semantic network — the full contour of how your business actually runs:
- Entities
- Products, materials, lines, warehouses, customers, suppliers, work orders, BOMs…
- Relationships
- Product A is made from material B on line C, ships to customer D, subject to constraint E…
- Rules
- Changeovers need clean time, minimum batch sizes, equipment compatibility matrices…
- Constraints
- Capacity limits, material availability, due dates, routings, shelf life…
So when you tell the system “Line 3 is down for maintenance next week,” it doesn’t just update a date field. It works out which work orders are affected, which schedules must change, which deliveries are at risk and which lines could take over.
Supply chain ontology Click a node for details
Illustrative data · simplified slice of a food plant ontology
How it differs from a traditional data model
| Traditional data model | Supply chain ontology | |
|---|---|---|
| How it describes the business | Tables and fields (flat) | Entities, relationships and rules (a semantic network) |
| Impact of a change | People work out the ripple effects | Change propagation is inferred automatically |
| Adapting to new scenarios | Change code or table schemas | Add or edit entities and relationships |
| Industry differences | A separate system per industry | One engine, different ontology configurations |
| What AI can understand | Only structured inputs | Business meaning it can reason over |
What this means for you
Your experts stop re-teaching the system what a changeover rule or an approved substitute is — that knowledge lives in the model. Add a plant or a product line and the agents understand how it fits the moment it’s registered.
Approach
How the ontology gets built
Not a big-bang project — a model that starts with one use case and grows with the business.
- 1
Start from a use case
Begin with scheduling or another concrete use case, using master and transactional data you already have in Excel, ERP or MES.
- 2
Load an industry template
Reuse entities, relationships and rules we’ve built for equipment, electronics, food & beverage, CPG and more.
- 3
Capture your own rules
Turn your planners’ tribal knowledge — changeover rules, substitutes, priorities — into explicit constraints.
- 4
Validate and evolve
Replay past plans to validate the model. New plants and lines simply get registered in the ontology.
Positioning
A knowledge graph is not a supply chain ontology
Plenty of planning tools now talk about knowledge graphs and semantic layers. The difference: Convect’s ontology captures business rules and physical constraints — capacity, routings, material relationships — so it can drive decisions directly.
| Generic knowledge graph | Convect supply chain ontology | |
|---|---|---|
| Focus | How data is connected | Why the business runs the way it does |
| Contents | Entities and links | Entities and links + business rules + physical constraints |
| Where it sits | Data layer | Decision layer — translates directly into optimization models |
| Typical use | Search, link analysis | Impact tracing, constraint solving, root-cause diagnosis |
Industry templates
One engine, an ontology for every industry
Each industry template adds its own signature entities on top of the core model.
Industrial Equipment
- Project WBS
- Kitting network
- Milestone constraints
- Aftermarket capacity pool
Electronics Manufacturing
- Alternate parts graph
- ECO version control
- SMT feeder capability
- Routing constraints
Precision Machining
- Routing graph
- Machine capability matrix
- Tooling & fixtures
- Outside processing network
Food & Beverage
- Shelf-life chain
- Changeover & clean matrix
- Lot traceability graph
- Seasonal demand model
Consumer Goods (CPG)
- Channel & promotion calendar
- Multi-echelon network
- SKU lifecycle
- Freshness constraints
Frequently asked questions
How does the ontology relate to master data management (MDM)?+
MDM makes sure the data is right. The ontology makes the system understand what the data means. It sits on top of your existing master data and doesn’t replace ERP, MES or your MDM program.
How long does it take to build?+
Starting from a scheduling use case and an industry template, a first version usually takes a few weeks. It then grows with the business — it’s not a one-off modeling megaproject.
Our rules are unusual. Can the ontology express them?+
Yes. Rules and constraints are configurable. Adding a changeover rule or a substitution means adding a relationship in the model — not changing code or database tables.
How does the ontology relate to large language models?+
LLMs are good with language; the ontology provides a structure agents can reason over and trace. Agents use the ontology for business context, then call the optimizer for decisions — which keeps them from confidently making things up.
Give your agents real understanding of your plant
Book a technical session and we’ll show how the ontology gets built — using a scenario from your business.