LTL & transportation
NMFC classification, tariffs and rating, PODs, OS&D, linehaul and terminal operations, accessorials.
MEANING OF DATA
Ontology, three layers deep.
Everyone in enterprise AI now agrees you need an ontology. The disagreement is about who builds it, how long that takes, and what happens when the business changes its mind. Here is our answer.
A model that doesn't know what your columns mean isn't reasoning about your business. It's pattern-matching against someone else's.
Why three layers, and not one
The single-ontology approach fails in a predictable way. Build it top-down and it takes eighteen months and describes a company that no longer exists. Infer it bottom-up from the data and it faithfully reproduces every naming accident of the last twenty years. Hand it to the business and it becomes a governance committee.
Splitting it into three layers works because the layers have genuinely different owners and genuinely different rates of change. Domain canon changes slowly and is the same for everyone in your industry. Derived structure changes whenever your systems do. Your business rules change whenever you decide they should, and they win.
Resolution runs bottom-up: Layer 3 overrides Layer 2, which overrides Layer 1. Every answer records which layer supplied which definition, so a disagreement about a number becomes a five-minute conversation about a rule rather than a two-week investigation.
RESOLUTION ORDER
L3 customer rule
↑ overrides
L2 derived from data
↑ overrides
L1 domain canon
LAYER 1
Canon, what the industry means
An ever-growing library of ontologies for vertical industries and horizontal business functions, curated by our domain leads and hardened on live engagements. When we build an LTL freight ontology for one carrier, the general shape of it, not their data, not their rules, makes the next carrier faster.
This is the layer that means you don't start at zero. It arrives with entities, relationships, standard identifiers and regulatory concepts.
Ever-growing · shared shape, never shared data
VERTICAL
VERTICAL
Packaging & converting
Substrates, print and converting operations, plant hierarchy, quality defect taxonomy, spec-to-order.
VERTICAL
CPG & food
Brand and category hierarchy, trade promotion, retail syndicated measures, consumer sentiment, SKU lifecycle.
VERTICAL
Commercial real estate
Portfolio, lease and property structures, work orders, valuation and appraisal, client billing.
HORIZONTAL
Order-to-cash
Invoice, dispute, dunning, credit, cash application, revenue recognition events.
HORIZONTAL
HR & workforce
Job architecture, skills, leave and absence law, cases, onboarding, attrition signal.
HORIZONTAL
Procurement
Supplier master, spend taxonomy, contract clauses and obligations, risk and disruption.
HORIZONTAL
Legal & compliance
Contract types, obligations, jurisdictional variants, policy and control mapping.
LAYER 2
Derived, what your data says
Point the platform at a source and it produces a data portrait: what the tables are, what the columns really contain, which keys actually join, where the duplicates are, how fresh it is, and which fields quietly stopped being populated in 2019.
This layer is generated, not authored, and it regenerates on a schedule. It is what lets us map a forty-year-old AS400 schema to the canon in days instead of quarters, and what tells you honestly when a question can't be answered from the data you have.
Crucially, it is inspectable. Every inference the platform made about your data is shown to your team, with the evidence, and can be corrected, at which point it becomes Layer 3.
Regenerated on schedule · always inspectable
platform.flexday.ai / data portrait / AS400.SHPMT
COLUMNINFERRED MEANING
PRO_NBRshipment.identifier · 99.98% unique
DLVY_DTshipment.delivered_at · 4 formats
CLS_CDnmfc.class · 18 distinct, 2 invalid
STAT_FLGambiguous · needs SME review
BILL_HLDjoins BILLTRUST.HOLD on PRO_NBR
RSV_CD_2unpopulated since 2019 · excluded
Promote to Layer 3Assign SMERe-profile
LAYER 3
Customer, what you actually mean
Two companies in the same industry, with the same systems, will disagree about when a shipment counts as late, what makes an account at-risk, and which exceptions a human must see. Those disagreements are not data quality problems. They are your business.
Layer 3 is where your SMEs put them: local vocabulary, thresholds, exception rules, approved answers, corrections to anything the other two layers got wrong. It is authored in plain language, versioned, attributed to the person who wrote it, and it takes precedence over everything else.
It is also the layer that never leaves your tenancy. Nothing in Layer 3 informs another customer's canon, and nothing in it trains a shared model. Your edge stays yours.
How isolation works →EXAMPLE · AUTHORED BY AN SME
“Ready to bill”
A shipment is ready to bill when delivery is confirmed, the POD image is legible, no OS&D exception is open, and any accessorial has a matching authorization. Weight discrepancies under 2% do not block billing.
EXAMPLE · AUTHORED BY AN SME
“At-risk account”
Not the standard definition. For us it means two consecutive months of declining tender volume and an open service failure older than 14 days. Volume decline alone is seasonal and we ignore it.
EXAMPLE · CORRECTION TO LAYER 2
STAT_FLG
Values 3 and 7 both mean delivered. 7 is a legacy code from the 2011 acquisition and appears only in the eastern terminals. Treat both as delivered.
IN PRACTICE
What this buys you, concretely.
SPEED
Weeks, not quarters
Canon plus derived means the first useful ontology exists in the first workshop, not after a modeling program.
ACCURACY
Fewer confident wrong answers
Ambiguity is detected and escalated instead of guessed. The system knows what it doesn't know.
TRUST
Disputes end at the definition
Every number traces to a definition, a layer and an author. Disputes resolve at the rule, not in a spreadsheet.
REUSE
The second solution is already one step ahead
Ontology work is an asset, not a project cost. Solution two inherits everything solution one established.
ONTOLOGY SPECIFICATIONFLEXDAY.AI
- LAYERS
- L1 canon (Flexday-curated, industry & function) · L2 derived (generated from your sources) · L3 customer (SME-authored, overrides all)
- AUTHORING
- Plain-language rule authoring, versioned with attribution; bulk import from glossaries, data dictionaries and existing models
- FORMATS
- OWL 2 / Turtle import and export; JSON-LD; mapping to dbt, Databricks Unity Catalog and Snowflake semantic definitions
- PROFILING
- Automatic schema, semantic, cardinality, quality, freshness and join inference with evidence shown for every conclusion
- RESOLUTION
- L3 > L2 > L1, with the deciding layer recorded on every answer
- ISOLATION
- L3 never leaves the customer tenancy and never contributes to shared canon or model training
Your first ontology takes weeks, not quarters.
Bring a domain and two SMEs. We'll show you what Layer 1 already knows about it.