FDE: Converting Field Evidence into Runnable Business Models

Business Source Model Is Not Another Requirements Document

The article opens with a concrete scenario: a business expert states that after a delay approval, the new date determines whether an order is overdue. Ontology engineers, developers, and agent engineers each ask different questions — whether the approval is an object, event, or process; which system and field holds the new date; whether the model can adopt the date directly or must call a tool. These questions operate at different levels, and without a shared, confirmed business model, discussions collapse into classes, attributes, interfaces, and prompts. The result may be a running system that no one can explain in business terms.

The previous article (FDE 02) categorized field claims into wishes, facts, constraints, risks, unknowns, and non‑items, producing a field evidence pack. The next step is not to hand these pieces to separate technical teams for ad‑hoc interpretation, but to form a business source model that business experts can confirm, engineering teams can jointly reference, and downstream artifacts can continuously trace.

FDE's modeling responsibility is not to define business for experts, nor to choose standards for ontology engineers, but to drive field evidence into a business model baseline that has an owner, version, confirmation boundary, and traceability to engineering implementation and testing.

The term "business source model" is an author‑defined concept (not an industry standard). It means a structured expression of business objects, relations, events, processes, states, rules, evidence, roles, and behaviors within a clear task boundary, with each item recording its source, owner, confirmation status, version, and open issues. "Runnable" does not mean the model executes transactions; it means the model can be controllably transformed into engineering artifacts, constrain implementation and testing, and continuously receive runtime feedback.

The business source model is not the customer's transactional or data authority. It cannot replace ERP, contract, approval, IAM, or other source systems, nor does publishing it as a baseline grant authority to modify business state. It provides a confirmed semantic baseline; which system holds authoritative data, which interface executes transactions, and how to integrate and roll back are decided later in architecture.

The model is also not: a renamed meeting minutes/glossary/database schema; a direct RDF/OWL/UML/BPMN model; a static blueprint where FDE fills unconfirmed rules or freezes all change.

Its validity is judged not by diagram completeness but by whether business experts confirm its meaning, engineering teams can build consistent implementations, and test failures can be traced back to specific model elements and field evidence.

FDE Does Not Define Business, But Personally Builds Engineering Connections

Assigning a single "business‑and‑technical" person to draw the model seems efficient but concentrates fact‑providing, rule‑interpreting, formalizing, implementation‑deciding, and risk‑accepting responsibilities. When disputes arise, the team cannot tell whether the error is in business understanding, formalization, or implementation.

The article proposes splitting responsibilities as follows:

Business Expert — confirms real cases, term meanings, rule bases, exceptions, business outcomes, and human judgments. Not responsible for choosing RDF, OWL, database, or agent implementation.

Business Model Baseline Owner — owns model scope, cross‑role consensus, business capability and domain boundaries, baseline release and change acceptance. Cannot be a nominal role that avoids semantic conflicts and cross‑department disputes.

FDE — maps evidence to model candidates, organizes walkthroughs, preserves conflicts and unknowns, establishes traceability from model to engineering artifacts. Cannot confirm business facts, approve permissions, or accept business risks on behalf of authorized parties.

Ontology Engineer — handles semantic formalization, model constraints, transformation rules, identification and versioning strategies. Cannot assume business meaning is confirmed just because technical expression is complete.

Development, Data, and Test Teams — implement data mappings, rules, actions, test verification, and feed back runtime deviations. Cannot use existing fields, interface capabilities, or test convenience to reverse‑define business semantics.

The "Business Model Baseline Owner" may be a business architect, domain lead, business analyst, or other authorized person. FDE and vendor solution architects do not become owners by default. The business analyst from article 01 may be the same person, but the former focuses on requirements and process analysis, while the latter owns model scope, cross‑domain consistency, and baseline confirmation.

One person can wear multiple hats in a small team, but responsibilities must not disappear. Business fact confirmation, permission approval, risk acceptance, and technical verification cannot be considered done just because "everyone attended the review."

FDE is not merely a facilitator of co‑creation workshops. It must personally map evidence to model candidates, maintain the baseline and traceability matrix, check downstream implementation deviations, and push authorized parties to complete business confirmation.

Five Actions from Field Evidence to Model Baseline

Converging field evidence into a business model is not a one‑shot translation from natural language to diagram, but a controlled convergence process.

Bind every model candidate to field evidence. Objects, states, and rules must trace to specific contract versions, approval records, system logs, policy clauses, normal or exceptional cases. Expert experience judgments must record the judge, applicability conditions, and exceptions — not be upgraded to universal rules.

Express in business language first, then choose technical representation. The team should first clarify "what object under what conditions changes how due to which process" before deciding whether it enters ontology, rule engine, workflow, code, or action contract. Technical teams may propose representations, but cannot let a standard's ease of expression retroactively trim business facts.

Conflicts must not be silently merged. If two departments understand "delivery date" differently, they cannot be merged for a unified field. If contract, order, and delay approval give different dates, developers cannot pick the most stable interface. Conflicts are kept as open items in the model, recording impact, owner, verification method, and deadline. Scope may be narrowed for the current baseline if needed.

Release a model baseline, not final truth. A baseline must include model version, applicable task and scope, confirmers, open items, change log, and effective time. Confirmed means "usable as a shared engineering version under current evidence, scope, and time," not "forever correct."

Simultaneously establish downstream traceability. Every key model element must indicate affected data mappings, rules, processes, actions, agent tools, and tests. Downstream deviations must generate change or deviation records; silent semantic modifications are forbidden.

Therefore, a deliverable business model baseline includes not only the model diagram but also the model body, terminology and evidence index, confirmation and open items, downstream traceability matrix, and version and change records.

Converging Business Semantics Through an Abnormal Order Scenario

Continuing the synthetic case: field evidence shows contract version, ERP order, and delay approval dates may conflict; external customer commitment changes require approval by a designated business owner; the first phase does not automatically modify ERP scheduling or customer commitments.

If the team jumps straight to technical implementation, they would likely create a single delivery_date field with a priority rule (e.g., prefer ERP or latest approval). The business model instead separates distinct concepts:

Order — the business object being fulfilled and tracked.

Contract Version and Delay Approval — evidences used to confirm fulfillment commitment, not automatically equal to the current effective commitment.

Fulfillment Commitment — records applicable order, validity period, basis, and confirmation status.

Fulfillment Risk Task — records a risk judgment with its evidence, rule version, and human confirmation result.

Confirm Current Fulfillment Commitment — the business process that resolves conflicts; cannot be replaced by a field priority rule.

In the current baseline, "Fulfillment Commitment" can have states "Pending Confirmation", "Valid", "Superseded". When multiple bases conflict, the model keeps the commitment as "Pending Confirmation" and triggers confirmation by the authorized business party. Before confirmation, the system can extract materials, compare dates, and identify conflicts, but must not produce a final fulfillment conclusion.

This step does not decide data storage or transaction authority; it freezes the business semantics that all engineering teams must honor: multiple dates are not copies of the same field, approval records are not inherently valid commitments, and unknown states cannot be silently filled by model or code.

The following simplified traceability matrix illustrates responsibility interfaces (numbers and content illustrate the method, not a real client model):

Model Element: Fulfillment Commitment with identity, validity period, basis. Field Evidence: F‑01 date conflict, contract and approval materials. Downstream Artifacts: Ontology concepts, data mappings, data constraints. Minimum Verification: Same order multi‑version and conflict samples not silently merged.

Model Element: Fulfillment Commitment states (Pending Confirmation, Valid, Superseded). Field Evidence: U‑01 unknowns and business confirmation results. Downstream Artifacts: State model, process or object runtime constraints. Minimum Verification: Illegal state transitions and missing confirmation records cannot enter Valid state.

Model Element: Multiple bases conflict → must not auto‑select final commitment. Field Evidence: U‑01, C‑01. Downstream Artifacts: Rule model, decision service, exception handling. Minimum Verification: Conflict samples only enter human confirmation or controlled blocking.

Model Element: Generate handling suggestions. Field Evidence: W‑01, C‑01. Downstream Artifacts: Action contracts, agent tool descriptions, human confirmation points. Minimum Verification: Tool calls retain evidence and cannot overstep to change customer commitments.

Model Element: Phase 1 does not modify scheduling and customer commitments. Field Evidence: N‑01. Downstream Artifacts: Tool whitelist, permission policies, interface scope, No‑Go tests. Minimum Verification: Agent lacks relevant write tools or write authorization.

Model Element: Conclusions must return source and rule version. Field Evidence: F‑01, R‑01. Downstream Artifacts: Evidence structure, audit logs, evaluation samples. Minimum Verification: Every conclusion traceable to material location and rule version.

This table is not a one‑time design of all technical artifacts; it establishes responsibility interfaces: business experts confirm semantics, ontology engineers and developers formalize and implement, test teams verify consistency, and FDE maintains the closed loop among evidence, model, artifacts, and tests.

The diagram above gives an overview from business basis to engineering artifacts. Inside the business model, the six concepts relate as follows:

Model Must Enter Engineering, Not Stay on Diagrams

The business source model can be transformed into various technical artifacts as needed: concepts and relations into RDF or OWL; constraints on RDF data via SHACL; processes mapped to BPMN or existing workflow engines; interfaces and data structures constrained by OpenAPI and JSON Schema contracts. The project need not adopt all standards, but must have explicit transformation relations and consistency validation.

At least four traceability categories must be preserved between model and engineering artifacts:

Source Traceability: Which field evidence and business confirmation each model element originates from.

Transformation Traceability: Which ontology, data, rules, processes, and contracts each model element generates or constrains.

Verification Traceability: Which normal, abnormal, conflict, and over‑permission samples verified each element.

Runtime Traceability: Which model version is affected by production deviations, human takeovers, and rule exceptions.

Traceability cannot be mere document links. Model elements, engineering artifacts, and tests must have stable identifiers and versions; otherwise it is impossible to prove that model updates have entered the running system.

When Can a Business Model Baseline Be Released?

The model need not cover the entire domain on first release, but must fully support the current task boundary. Before release, at least the following must be confirmed:

Model scope, baseline owner, confirmers, and applicable time are explicit.

Key objects, relations, states, rules, and behaviors are backed by normal, abnormal, or conflict cases.

Same‑name‑different‑meaning, different‑name‑same‑meaning, and cross‑system conflicts are not silently merged.

Boundaries between business rules, expert judgments, AI judgments, and human confirmations are distinguishable.

Unknowns, non‑items, and permission boundaries remain visible with handling paths.

Key model elements trace to field evidence, downstream artifacts, and verification samples.

Version, effective conditions, change entry points, and re‑verification scope are recorded.

If a model has only objects and relations without states, evidence, actions, and responsibility boundaries, it cannot support a runnable system. If it has a complete diagram but lacks owner, version, and test traceability, it remains a modeling document.

AI can help extract candidate terms, compare material versions, generate model drafts, discover conflicts, complete traceability links, and generate test samples. But AI cannot decide which business interpretation is valid, cannot merge conflicting concepts on behalf of authorized parties, and cannot approve permissions, accept risks, or release the business model baseline.

FDE may use AI to accelerate modeling, yet remains responsible for ensuring evidence is retained, conflicts are exposed, confirmation responsibilities are clear, and the model truly enters engineering.

The Endpoint of the Business Model: Input to Architectural Decisions

The business source model turns field knowledge into a semantic baseline that engineering teams can jointly reference, but it does not decide which system owns fulfillment commitment data, how cross‑system information synchronizes, or which capabilities go into the product platform, configuration extensions, or manual handling.

These are not questions the business model should decide unilaterally; they are the next step — system boundary and architectural trade‑offs that must be made based on field evidence and the model baseline.

This will be the topic of article 04 in this series.

References

Ontology Modeling Connecting Business and Technology: Standards Are Not Business Entry Points but Compilation Targets (https://mp.weixin.qq.com/s?__biz=MzcwNDM2MTg3NA==&mid=2247484439&idx=1&sn=a325781c1b801710755976cf58bb09f3&scene=21#wechat_redirect)

W3C: Shapes Constraint Language (SHACL)

OMG: Business Process Model and Notation 2.0.2

OpenAPI Specification 3.1.1

JSON Schema Draft 2020‑12