RAG or a business ontology? Count the lookups before you choose

Your engineers keep checking the same fact across two systems that disagree, with part numbers buried in free-text notes and one supplier spelled three ways. Whether AI should retrieve that answer or model it comes down to two numbers you can estimate this week: how often the lookup happens, and how long each one takes.

The short answer

Retrieval-augmented generation (RAG) is the quicker start. You embed your records, retrieve the closest matches, and a language model suggests an answer for a person to check.

A business ontology is a shared model of the things your business works with, such as components, qualifications, manufacturers and customers, and the rules that connect them. Mapped over existing databases as a virtual knowledge graph, it answers exact questions while the data stays in the source systems.

RAG costs less to set up. The ontology costs less per lookup. Volume decides which one wins.

What a mapped ontology gives you on repeated lookups

• Exact matches become queries, not reviews. Rule-based matches return automatically; people review only what needs judgement.
• Your current software keeps running. Where the database behind your ERP or PLM is reachable through a supported connection, the mapping reads it without changing records.
• The next automation starts further ahead. A second workflow or agent reuses the agreed definitions and adds mappings only for new data or rules.

FAIS builds that layer: a foundational ontology over the systems you already run. Your team defines 'approved part' or 'same manufacturer' once, and the automations built on top read it.

Before and after in one deployed case

In a paper submitted to arXiv on 20 March 2026, researchers from Politecnico di Milano, Quantia Consulting and Thales Alenia Space describe a tool that tells satellite-board designers whether an electronic component is already qualified.

Before, designers searched two databases by hand: a PLM database with tens of thousands of entries and a manually maintained qualification catalogue with thousands. Part numbers sat in free-text notes; manufacturer names came in several variants.

After, both databases are mapped into a virtual knowledge graph with Ontop. Queries return direct and by-similarity matches automatically; vector search proposes 'alternative' qualifications for a designer to review. An on-premise GPT-OSS-120B model generated 50 normalisation rules from 466 manufacturer names, and experts refined 9 of them in a single 2-hour workshop. An Ontop lens applies the rules at query time, so the original names stay untouched.

The model also extracted part numbers, each checked against the PLM database; people handled the exceptions, mainly the roughly 2% of qualifications whose part number was missing from the text. Validation took a few hours of expert time, against an estimated several weeks by hand. At submission, about 50 users had access and evaluation was continuing.

Where the effort lines cross

The authors estimated setup and per-component effort, excluding hardware and energy: manual review needs no setup and about 40 person-minutes per component; RAG about 10 person-days of setup and 15 minutes each; the knowledge graph about 60 person-days and 5 minutes each. Manual review wins only up to about 200 components. Against manual review, the knowledge graph saves over 70% of effort beyond 5,000 components and over 80% at 10,000.

The paper does not state where RAG and the knowledge graph cross, so we computed it, assuming an 8-hour person-day the paper does not define: (60 − 10) person-days × 480 minutes ÷ (15 − 5) minutes ≈ 2,400 components. The same assumption reproduces the paper's 200-component figure.

RAG was competitive on exact matches: on 675 components its GPT variant agreed with the deployed pipeline at an F1 of 92.07% on direct matches, falling to 61.88% on alternatives. The authors expect better models to push the break-even towards higher volumes, so treat 2,400 as a snapshot.

How to count your own lookup

This is one aerospace company with a simple two-entity ontology: apply the method, not the result. Pick one repeated cross-system check and write down:

• how many times a year it happens;
• how many minutes it takes today, including chasing colleagues;
• what a wrong answer costs;
• what share of cases follow exact rules.

Consider a Taiwan contract manufacturer whose engineers check each new customer bill of materials, line by line, against the ERP item master and that customer's approved-parts list. With a mapped model, exact matches return as a query and the engineer reviews only the lines that differ.

Multiply the count by the minutes. If the total is small or the rules are unclear, start with retrieval; the authors found RAG valuable for fast proofs of concept. If the count runs into thousands and most answers follow rules, the ontology's higher setup is likely to pay back through cheaper lookups.

How FAIS would build it

We map only the sources one question needs and agree the authoritative fields and matching rules with the people who maintain the data. A model proposes cleaning rules; those experts review them. Uncertain matches go to a named reviewer. The model built for the first lookup becomes the base for the next workflow.

Takeaway: write the yearly count and minutes per check next to the lookup. Those two numbers tell you what to build first.