From Q&A to Runnable: Ontology & FDE Co-Build Enterprise AI's Semantic Runtime

Introduction: Why Enterprises with LLMs and Data Still Cannot Enter Core Financial Scenarios

Enterprises have accumulated vast systems, data warehouses, indicator platforms, and report assets through digitalization. Large language models (LLMs) provide a natural language entry point: users can ask about policies, reports, indicator definitions, and get analytical assistance. Superficially, enterprise intelligence seems only a matter of connecting LLMs to existing data and documents.

However, once entering core scenarios like finance, operations, risk control, and supply chain, problems surface rapidly. LLMs can explain an indicator name but may not know how it is calculated under the current enterprise caliber. RAG retrieves relevant policies but cannot execute deterministic rules. SQL agents generate queries but lack understanding of business semantics behind fields. Knowledge graphs show object relationships but cannot judge compliance, review needs, or trigger business actions.

The missing piece is not a stronger model but a runtime mechanism that connects business semantics, data facts, rule logic, and action execution. Without it, LLMs only "answer"; with it, AI can "judge, explain, audit, and execute."

This article argues two simultaneous answers are needed: Ontology answers "what the system runs on" — it is the semantic runtime layer that carries business objects, caliber rules, data mappings, and audit boundaries. FDE (Forward Deployed Engineer) answers "how this capability is built and governed on-site" — its value lies in translating on-site complexity into runnable, verifiable, governable semantic engineering. AI does not replace FDE; it frees FDE from low‑efficiency information sorting to focus on boundary judgment, rule confirmation, and controlled validation.

The case study uses PL BKD (Profit and Loss Booked) financial reports — a multi‑entity, multi‑version, multi‑caliber, complex‑formula report set. The difficulty lies not in display but in how indicators are defined, calculated, reconciled, explained, and reused.

Clarifying the Problem: Financial Reporting Is a Semantic Runtime Issue, Not a Display Issue

Traditional projects treat PL BKD as report automation: ingest Excel data, build pages, add query/filter/export, and sprinkle LLM explanations. But on-site, those Excel files are compressed business knowledge carriers: row/column structures hold management dimensions, account hierarchies hold financial classifications, cell formulas hold indicator dependencies, versions/periods hold management calibers, manual adjustments hold expert judgments, and report styles hold long‑formed usage habits.

In practice, the artifact is a 96‑sheet workbook. Each sheet may carry different entities, indicator calibers, dimension combinations, and formula logic. Manual page‑by‑page reading is inefficient and misses hidden formulas, cross‑sheet references, indicator aliases, and caliber differences.

Business users ask "why did this indicator change?", "where does this result come from?", "can this caliber be adjusted?"; systems see only cells, fields, codes, and values. A semantic gap exists: business speaks entities, accounts, indicators, revenue, cost, profit, forecast, actual, variance; systems store tables, fields, primary keys, versions, periods, org hierarchies, and amount fields.

Therefore, the essence of PL BKD is not "how to move Excel into a system" but "how to turn the financial semantics behind Excel into system‑runnable capabilities." Treating it as a report problem yields a new display page; treating it as a semantic runtime problem yields a reusable financial ontology, indicator rules, data mappings, validation mechanisms, and action loops.

This is why the field needs not messenger‑style analysts but FDEs who can make semantic judgments: which concepts become ontology objects, which formulas become rules, which mappings require business confirmation, which results are only candidates, which actions must enter human review.

Why RAG, Graph Retrieval, and SQL Agent Alone Are Insufficient

PL BKD is easily misjudged as a routine "LLM + data" problem. Examining each technical route reveals clear boundaries when used alone:

RAG suits document retrieval and text Q&A. It finds relevant passages from policies, manuals, indicator handbooks, and LLMs generate explanations. But PL BKD's key is not finding a passage but computing a trusted result from entity, period, version, account, formula, and warehouse fields. RAG provides evidence, not rule execution.

Graph retrieval suits object relationship queries. It tells which accounts an indicator links to, which org an entity belongs to, which sub‑indicators a formula depends on. Without rules, constraints, and actions, it only answers "there is a relationship", not "how to calculate", "is the result correct", "what to do on exception". Graphs make knowledge visible; ontology makes knowledge runnable.

SQL Agent suits natural‑language data fetching. It converts user questions to SQL, but lacks business caliber assurance. Similar field names ≠ semantic consistency; queryable data ≠ usable for current indicator; correct SQL result ≠ correct business result. In finance, a missing filter, version caliber, or account aggregation rule can deviate results from business facts.

Ontology does not replace these capabilities but organizes them. RAG provides document evidence, graph retrieval provides relationship paths, SQL Agent provides data queries, LLMs provide parsing and interaction, Agents provide action orchestration, while ontology provides unified business objects, relationships, rules, constraints, versions, and permission boundaries. Without ontology, these are point tools; with ontology, they collaborate around a single enterprise semantics.

The competitive landscape hinges on this: RAG alone stays at Q&A SQL Agent alone stalls at caliber; graphs alone stay at relationship display; report automation alone traps in repetitive development. The real moat is organizing semantics, rules, data, and actions into a sustainably evolvable runtime layer.

FDE Philosophy: Translating On‑site Complexity into Runnable Semantic Engineering

If ontology answers "what the system runs on", FDE answers "how this capability is built from the field." Per industry definition, FDEs are engineers embedded on‑site delivering runnable solutions under real business constraints — not messenger analysts, not page‑only implementation consultants, not pure backend modeling engineers. In this scenario, FDE's core work is semantic engineering: identifying objects, converging boundaries, confirming rules, validating mappings, and holding governance. Its value is not translating requirements into pages but translating field complexity into runnable, verifiable, governable semantic capabilities.

In finance, many rules exist not as structured docs but scattered in verbal explanations, meeting discussions, Excel formulas, historical handling habits, and expert experience. FDE's job is to turn this tacit knowledge into system‑executable semantic assets.

AI reshapes not FDE's judgment authority but FDE's work focus. Previously, FDEs spent hours replaying meetings, organizing minutes, reading sheets manually, hand‑crafting models. Now AI assists initial structuring; FDE focuses on judgment, confirmation, and governance. The method chain compresses to four steps:

Collection. AI interviews and AI meeting minutes continuously probe around entities, accounts, indicators, formulas, versions, periods, calibers, data sources, and acceptance samples, turning business expressions into candidate semantic materials. E.g., business repeatedly mentions "by entity", "accounts aggregate to indicators", "formula calculates", "caliber may adjust later". These structure quickly; FDE then judges: entities and indicators become core objects, account aggregation implies relationships and rules, formulas need extraction as logic rules, caliber adjustment implies rule versioning and governance mechanisms.

Exposure. Facing 96 sheets, manual reading struggles to fully identify entities, accounts, indicators, formulas, cross‑sheet dependencies. Table parsing extracts 3,000+ candidate objects and indicator formulas from the sheets. The goal is not "more is better" but to convert hidden Excel business knowledge into analyzable, filterable, reviewable semantic materials.

Convergence. 3,000+ candidates ≠ finished ontology. High‑quality ontology is not larger but has clear boundaries, stable objects, usable relationships, verifiable rules. FDE filters around business goals and acceptance questions: which objects directly support main reports? Which indicators participate in core calculations? Which formulas affect key results? Which fields are only attributes? What stays outside the scenario boundary? AI helps "discover many"; FDE decides "choose what".

Drafting & Governance. Within FDE‑confirmed boundaries, AI‑assisted ontology building auto‑generates object definitions, relationship candidates, logic rules, and data mapping drafts. FDE shifts from "hand‑crafting models" to "reviewing, correcting, governing models". For objects: focus on boundary review; for relationships: confirm support for business questions; for rules: confirm applicability scope, version, owner, exception handling; for mappings: verify field semantics, filter conditions, sample results.

Three judgment gates run throughout:

What enters ontology, what stays outside the scenario.

What AI can draft, what requires business owner confirmation.

What can auto‑run, what must enter human review.

Together these four steps form the FDE method: not using AI to replace field judgment, but using AI to amplify the efficiency and coverage of field judgment, turning semantic engineering from a craft workshop into replicable delivery.

Key Breakthrough: From Excel Formulas to Manageable Rules Connected to Data Warehouse Mappings

The PL BKD breakthrough is releasing Excel formulas from cells into manageable, reusable, auditable logic rules and connecting those rules to underlying data.

Traditionally, financial indicator calculation logic hides in Excel formulas. Business users can use them but systems cannot manage them; formulas produce results but hardly explain impact scope; reports can be copied but rules hardly reuse; when indicator calibers change, manual sheet/formula editing and re‑reconciliation are needed.

After structuring, formulas become dependencies between indicator objects. Which sub‑indicators compose an indicator, whether summation/subtraction/ratio, whether dependent on version/period/entity/org scope — all recorded. Rules further gain name, inputs, outputs, applicability scope, effective version, owner, evidence source, validation method.

Example: a simplified gross margin rule:

Rule: PL_BKD_GrossMargin_Calculation v1.2
Input: Revenue, Cost
Output: GrossMargin
Logic: GrossMargin = Revenue - Cost
Scope: Entity, Period, Version=Actual
Owner: Finance Dept
Evidence: PL BKD Excel sample 2026‑07
Validation: Compare with historical Excel sample; threshold ±0.5%

Validation cannot be a tautology like "gross margin + cost = revenue" — that merely rearranges the calculation and cannot detect real deviations. Effective validation must benchmark against external baselines: historical Excel samples, business‑given thresholds, or cross‑caliber results. FDE confirms rule scope, version, owner, and exception handling — not rewriting every formula.

Rules must connect to the data warehouse to be truly runnable. Ontology without data stays a knowledge model; data without ontology stays a field pile. Semantic mapping must establish not "field‑to‑field" but a complete chain: "Ontology Object — Business Attribute — Warehouse Field — Filter Condition — Transformation Logic — Validation Sample" .

Example: simplified revenue indicator mapping:

Mapping: Revenue_PL_BKD v1.3
Source System: Financial Detail Fact Table
Amount Field: amt
Period Filter: period = '2026-07'
Version Filter: version = 'Actual'
Entity Join: org_id → Entity-A
Currency Conversion: CNY → 10k CNY
Exclusion: Non‑operating adjustment accounts (list)
Validation Sample: 2026‑07 PL BKD Excel revenue = 1,280.50 10k CNY

For an indicator to auto‑fetch, at minimum: which system/table? which amount field? how to filter period/version? how to link org/entity? currency/unit conversion? exclusion accounts? can sample align with historical Excel? AI can recommend mapping paths, but FDE must perform three validations: field semantic consistency, filter completeness, sample alignment. Only after passing these does mapping enter runnable rules.

Rules solve "how to calculate"; mappings solve "where to fetch from". Together they turn objects and relationships from skeletons into calculable chains. Subsequent new indicators, caliber adjustments, or similar report migrations reuse existing entities, accounts, periods, orgs, and indicator mappings — the dividing line from "project delivery" to "capability accumulation".

Runtime Loop: How a Single Indicator Query Executes End‑to‑End

If stopped at object/rule/mapping definitions, ontology remains a design‑time asset, not a runtime layer. The real test of a "semantic runtime layer" is whether a business question can traverse the full unified semantics chain.

Example question: "What is Entity‑A's gross margin for July 2026?"

Step 1: Question Parsing. System grounds natural language to ontology objects: Indicator = GrossMargin, Entity = Entity‑A, Period = 2026‑07, Version = Actual, Scenario = PL BKD. If parsing uncertain, return clarification items instead of guessing.

Step 2: Rule Matching. System finds "PL_BKD_GrossMargin_Calculation" current effective version v1.2, confirms inputs Revenue, Cost, and constraints entity/period/version.

Step 3: Mapping Data Retrieval. System uses Revenue mapping v1.3 and Cost mapping v1.1 to extract details from financial detail fact table: filter by Entity‑A, 2026‑07, Actual; aggregate by account type; unify amount to 10k CNY; apply confirmed non‑operating adjustment account exclusion list.

Step 4: Rule Calculation. Execute "GrossMargin = Revenue - Cost". Result: Revenue 1,280.50, Cost 792.30, GrossMargin 488.20 (10k CNY). Retain intermediate results for traceable calculation chain.

Step 5: Validation & Explanation. System reconciles calculated result with 2026‑07 PL BKD Excel sample. Sample gross margin = 488.60, absolute diff 0.40, diff rate ~0.08% < business threshold 0.50% → validation passes. System returns gross margin amount with formula chain, data sources, filters, rule version, validation status.

Step 6: Exception Handling. If diff rate exceeds threshold, do not give "definite conclusion"; route to human review queue. FDE or business owner traces along object, rule, mapping, data chain to locate cause. System continues providing explanation but must not auto‑trigger downstream production actions.

A successful response must at least provide the following explanation information (entity, amounts desensitized):

This loop shows: LLM handles understanding and interaction; ontology constrains business semantics; rules ensure deterministic calculation; mappings connect factual data; Agent orchestrates calls; humans and governance mechanisms cover risks. "Runnable" means a business question can be parsed, calculated, explained, validated, and located upon failure — not merely moving Excel into a system.

Failure Governance: How Discrepancies Are Located and Turned into Governance Assets

High‑quality practice must show not only success paths but how failures are located. For a financial semantic runtime layer, the real danger is not discrepancies appearing but discrepancies being unexplainable, unattributable, un‑immortalized.

In PL BKD validation, system‑calculated revenue for an entity/period once mismatched the original Excel sample. First reaction often blames formula error or warehouse data inaccuracy. But tracing down the semantic chain revealed neither: gross margin/revenue calculation expressions held, underlying amount fields returned values. The discrepancy lay in caliber boundary — a category of accounts still tagged "revenue" in the warehouse, thus auto‑aggregated into revenue; but in PL BKD management caliber, those accounts belong to manually excluded non‑operating adjustments and should not count in current operating revenue. Excel relied on human memory to exclude; without explicit constraints in the system, the "business default" leaked.

Without ontology and mapping chains, such issues are vaguely labeled "data inaccurate" or "system miscalculation", ending in verbal explanations by veterans. In the semantic runtime layer, location converges to a specific point:

Indicator result triggers sample validation failure.

Trace back to revenue indicator, not rush to fix formula.

Check revenue mapping's account set and filter conditions.

Find discrepancy concentrated in a few special accounts.

Confirm with finance owner: these accounts should be excluded in PL BKD caliber.

Write exclusion condition into mapping, upgrade mapping version.

Retest passes; archive confirmer, applicable scenario, effective version together.

The key of this fix is not correcting a single number but turning a hidden business default into a versioned governance asset. Thereafter, similar indicators no longer rely on someone's ad‑hoc memory but execute confirmed caliber constraints. For FDE, professionalism lies not in "guaranteeing first‑time correctness" but in locating errors to a specific layer — object, rule, mapping, data, or permission — and immortalizing the fix as reusable capability.

This explains why failure cases belong in the method, not hidden in project retrospectives: success paths prove the system can calculate; failure loops prove the system can govern. Without the latter, the semantic runtime layer remains a seemingly complete definition set, not yet a production‑ready capability.

Validation Framework: Coverage, Accuracy, Explainability, and Reusability

A technical view must go beyond vision and specify verification. Combining PL BKD practice, at least four dimensions should provide evidence. The table below shows desensitized phased results to illustrate validation caliber and observable gains; entity names, amounts, and some process details are desensitized due to customer sensitivity.

1. Semantic Coverage. Not how many candidate objects, but whether converged core objects, rules, and mappings suffice to support main report operation. The "~3,200 → 186" funnel shows AI responsible for full exposure, FDE responsible for converging runnable scope to verifiable boundaries.

2. Calculation Accuracy. Baseline against historical Excel samples, compare system dynamic calculation results. Key is not "calculable" but when inconsistencies arise, can locate whether from formula parsing, data mapping, version caliber, period range, manual adjustment, or data quality, and retest passes after fix. The earlier revenue caliber exclusion account governance loop corresponds to a key deviation case in the table: first round failed, added exclusion condition, upgraded mapping version, retest passed.

3. Explainability & Traceability. System must output indicator result's formula chain, data sources, filter conditions, rule version, validation status. In finance, auto‑calculation without explanation chain is hard for business to accept; with explanation chain, business owners can trust and take over confirmation. MVP core indicator explanation chain completeness is prerequisite for business acceptance of auto‑calculation.

4. Reusability & Efficiency. Whether business understanding forms reviewable materials faster, modeling shifts from hand‑crafting to review/correction, new indicators/rule adjustments/similar report migrations reuse existing objects, relationships, mappings. The table shows gains mainly from "less repetitive sorting, more boundary confirmation" — not eliminating human judgment.

Note: above numbers are desensitized illustrations for validation method; formal release should replace with project‑measured calibers. Yet the validation logic is clear: without coverage, accuracy, explainability, and reusability evidence, one only proves "the path is right", not "it is done".

Boundaries and Extrapolation: What Goes into Production and What Replicates to Other Scenarios

Talking only auto‑fetch, dynamic calculation, AI reasoning without risk boundaries makes enterprise production entry hard, especially in finance.

Permission Boundaries. What users can ask, view, calculate must be constrained by entity, org, period, indicator permissions. Cannot bypass data permissions via LLM Q&A or Agent calls.

Audit Boundaries. Indicator results must trace to data sources, formula versions, rule configs, mapping relations, manual confirmation records. Suggested audit chain includes: operator, operation time, input parameters, data version, rule version, mapping version, output result, validation status, manual confirmation record, action execution record.

Misjudgment & Rollback Boundaries. AI parsing formulas, recommending mappings, generating explanations can err. Key indicators, key rules, high‑risk actions must enter human review, especially at first launch, caliber adjustment, warehouse structure changes. Trigger rollback or pause auto actions when: core validation fails; key indicator vs sample deviation exceeds business threshold; permission check fails; data source structure changes unconfirmed; rule version changes without business owner confirmation; Agent actions produce unexpected downstream effects.

Safer rollout is phased: Phase 1 read‑only validation, output calculation results and explanations only, no production actions; Phase 2 semi‑auto, anomalous results enter human review queue; Phase 3 open Agent actions only for stable rules, retaining audit and rollback mechanisms. These boundaries do not weaken intelligence but enable intelligence to enter core business systems.

For extrapolation, PL BKD provides not an isolated finance app but a replicable paradigm: real business problem as entry, FDE as field translation role, AI‑assisted collection/parsing to accelerate understanding, ontology as semantic base, rule logic as deterministic judgment, data platform as fact source, Agent as action orchestration. It can extend to budget forecasting, operational analysis, risk early warning, project management, supply chain, performance management — provided the scenario has complex indicators, cross‑system data, tacit rules, dynamic calculation, and explainability requirements.

Conversely, if a scenario only needs document Q&A, lacks stable calibers, lacks reconcilable samples, or business owners cannot confirm rule ownership, do not force‑fit the ontology solution. Semantic runtime layer and FDE method have applicability boundaries.

Data and Case Boundary Note: Customer entities, amount details, account codes, and some process info in this article are desensitized; validation results illustrate method effectiveness and magnitude, not for external disclosure as raw business data.

Conclusion: Enterprise AI Competition Is About Semantic Organization and On‑site Semantic Engineering Capabilities

PL BKD shows enterprise intelligence deep‑water zone is not just "let AI answer" but "let system understand, calculate, explain, audit, act". LLMs solve interaction and generation; data platforms solve fact supply; Agents solve action orchestration; ontology solves business semantics and rule runtime; FDE solves how this capability gets built, confirmed, and held on‑site.

Thus, ontology's value lies not in describing business more complexly but in transforming complex business into runnable system capabilities. FDE's value lies not in replacing business experts or modeling tools but in translating field complexity into runnable, verifiable, governable semantic engineering.

Future enterprise AI competition is not only whose LLM is stronger, but who can faster and more stably organize business semantics, data facts, rule logic, and action execution into a sustainably evolvable intelligent foundation.