Most tools treat everything as a row in a list. Nordite's ontology layer lets you define what your business entities actually are - their properties, their relationships to each other, and what operations are valid on them. Forecasts run against a knowledge graph of your business, not against anonymous dimension IDs.
Every dimension in Nordite can have a typed schema. Properties are not free-text strings - they have declared types (text, number, date, URL, boolean, enum, or a reference to another object type). Required fields are enforced at ingestion. Validation rules catch bad data before it reaches the model.
An agent asked to build a supply chain model doesn't start from a blank sheet. It reads the Product schema, sees that category is a required link to the Category dimension, and builds the module correctly the first time. No guesswork about what properties mean or whether values are trustworthy.
Links are first-class typed relationships between dimension items across different dimensions - not just parent/child within a single list. A Product links to a Category, a Supplier, and a Store. A Transaction links to a Product and a Customer. Cardinality is declared (one-to-one, one-to-many, many-to-many) and traversal is available in formulas and filters.
Relationships can also carry typed data of their own. A requires_material link holds a quantity and a unit. A serves_route link carries a contract rate and a lead time. These edge properties are declared once on the link type and validated on every instance - no loose columns, no ambiguous text fields.
Write a formula that reads Product.[sourced_from].lead_time_days or aggregates with SUM(Order.Amount ALONG [contains_product]). Filter a module to show only products where supplier.region = "EMEA" without pre-loading or joining anything. The engine traverses the graph in memory against live data - no ETL, no denormalisation, no wait.
Actions are named, typed operations that can be applied to objects. Each action declares its parameter schema, pre-conditions that must be true before it can run, and effects - what properties change, what links are created, what cells are written. Actions can require approval, trigger downstream computations, and leave a full audit trail automatically.
"Lock Period", "Approve Budget", "Reassign Supplier", "Flag for Review" become first-class operations with business logic built in - not ad-hoc API calls that bypass governance. Agents run actions the same way users do, through the same validated, audited path.
When the engine understands what your business entities are, a range of capabilities that would otherwise require custom integration become native.
Traverse link-type relationships directly inside formulas. Read a property from connected items with dot-bracket syntax — Product.[sourced_from].lead_time_days — or aggregate across all reachable items with SUM(Order.Amount ALONG [contains_product]). The engine resolves traversals in memory at evaluation time, no pre-joining required.
Define named subsets of entities using predicate expressions rather than manually curated lists. "Products where supplier.region = EMEA and category.margin > 30%" updates automatically as properties change.
Every operation on a business entity goes through a declared action with typed parameters, pre-condition checks, and an automatic audit log entry. No undocumented side-channel writes.
The frontend renders appropriate inputs for every property - date pickers for dates, dropdowns for enums, linked-object selectors for references. No more free-text fields that accept any value.
Agents read the ontology before building or modifying models. They understand what a Product is, what properties it has, what it links to, and which modules compute metrics for it. Module dimension bindings and line item attribute IDs give agents a named vocabulary to work with, not just anonymous IDs.
Trace how a change to a Supplier object propagates through Products, through Modules, and through dependent line items. The graph makes dependency chains explicit and auditable.
Tag any module as computing metrics for a specific dimension, then label each line item with an attribute ID. Formulas can resolve Product.[sourced_from].lead_time_days end-to-end: traverse the link, find the bound module, read the labelled line item. Agents see exactly what each module and metric means without extra context.
Any ontology action can include a trigger_workflow effect. Executing the action creates a timestamped record on the target workflow, giving planners a full history of which items triggered each workflow, when, and who initiated it.
Every relationship link records who created it and when. On feature branches, a dedicated API diffs exactly which links were added or removed compared to main - giving teams a clear, reviewable audit trail of structural data changes before merge.
AI agents can retrieve the complete structural schema for a project in a single MCP call - all dimensions, link types, property definitions, and available actions with no item data. Agents then traverse multi-hop relationships step by step, following named link types across dimensions to understand context before making changes.
Declare required link types and required properties on any dimension. A single API call validates every item in the project against those rules, returning a ranked list of violations by severity. Agents use this to baseline compliance before bulk operations and confirm the model is clean before merging a branch.
Organisations use Nordite's ontology layer in supply chain, finance, retail, sales operations, and inventory management. Here's what that looks like in practice.
A manufacturer defines Product, Supplier, Lane and Category as typed dimensions - each with its own icon, color, and property schema. Suppliers declare lead_time_days, regions, and capacity. Products link to their source supplier and category via typed relationships.
The routed_via link between Product and Lane carries edge properties: contract_rate (Number) and transit_days (Number). A procurement formula reads Product.[routed_via].contract_rate directly, and aggregates total lane cost with SUM(Volume ALONG [routed_via]). No lookup table, no VLOOKUP, no pre-joined column.
A "Products at Risk" subset - supplier.lead_time_days > 30 AND category.margin_target < 0.15 - auto-updates as supplier lead times change. An agent running a supply chain stress test understands the graph and surfaces impact by region, by product line, by supplier - with entity names and edge data, not anonymous IDs.
A financial planning team models Cost Center, Account, Department and Scenario dimensions. Cost Centers link to their parent Department and managing Manager. Properties include budget_limit, fiscal_year and variance_pct — all validated at input.
Actions govern the budget cycle: Approve Budget transitions items from Draft to Active and timestamps the approval. Lock Period freezes all items in a fiscal period atomically. Transfer Budget moves allocation between cost centers, validating that the source has sufficient remaining budget before executing.
Board-level dashboards surface "Departments with variance > 10%" via a dynamic subset that traverses Department → Cost Center. An agent asked about a budget overspend explains: "This originates in EMEA Sales, managed by Sarah Chen, under the Commercial department" — not "Row 847 exceeded Row 912."
A CPG retailer models SKU, Brand, Store and Season with full ontology. SKUs progress through lifecycle states — Draft → Active → End-of-Life → Discontinued — enforced by the dimension's state machine. Each transition is a governed action.
Launch SKU activates the item and sets a launch date. Mark End-of-Life moves it to Deprecated — automatically excluded from active demand planning modules. Discontinue retires it, severs store links, and archives history.
A store capacity planning formula reads SUM(LINKS(THIS.store.stocked_skus).projected_volume), traversing links in memory against live data. An agent tasked with "identify low-margin products for discontinuation" reads margin data, groups by brand via relationship traversal, and proposes actions as executable operations — not suggestions.
A sales operations team models Sales Rep, Territory, Account and Product Line as typed entities. Reps link to one territory. Accounts link to a territory and sell multiple product lines. Quotas are validated properties with minimums.
The Reassign Territory action changes a rep's territory link with full audit history. Set Quota validates that total assigned quota doesn't exceed territory target. Merge Accounts consolidates two accounts into one, preserving sales history and link audit trails.
Quota attainment dashboards traverse the graph: a formula reads SUM(aggregated_revenue) WHERE @sales_rep.territory.region = "EMEA". Dynamic subsets for "High-Value Unassigned Accounts" auto-update. AI assistants building territory plans propose balanced reassignments by traversing rep capacity and account value relationships.
A warehouse operator models Part, Warehouse, Vendor and Inventory Class dimensions. Parts link to their primary vendor and all warehouses where they're stocked. Vendors link to the warehouses they serve. The Inventory Class composite dimension auto-generates items for every Part × Warehouse pair.
Safety stock formulas traverse the graph: @part.primary_vendor.lead_time_days × @part.avg_daily_demand × 1.5, resolving the vendor relationship inline. Reorder alerts use a dynamic subset — on_hand < reorder_point AND primary_vendor.lead_time_days < 30 — that updates as inventory levels change.
The Change Primary Vendor action reassigns the vendor link and recalculates safety stock across all linked warehouses atomically. When a vendor disruption occurs, an agent can identify affected parts by traversing Vendor → Part → Warehouse, estimate inventory runway, and propose reorder actions — all within the governed ontology layer.
A manufacturer running Nordite defines their ontology once: Supplier has a region and lead_time_days. Product links to a Supplier and a Category. Category has a margin_target. Store has a capacity and a region.
With that in place, a formula in the procurement module can reference @product.supplier.lead_time_days directly. A board-level dashboard can filter to "Products at risk" using a dynamic object set: supplier.lead_time_days > 30 AND category.margin_target < 0.15. An agent running a supply chain stress test understands what each dimension item represents, traverses the graph to compute exposure, and surfaces the results with entity context - not anonymous IDs.
No ETL. No pre-joining. No separate data modelling tool. The ontology lives in the planning engine, versioned alongside the model, branched with scenarios, and governed with the same access controls as everything else.
Working with select organisations in pilot