Stop Drawing Architecture: How FDE Turns Field Claims into Engineering Evidence

Introduction: The Trap of Premature Architecture

A client requests an AI agent that automatically identifies abnormal orders, analyzes impact, and suggests dispositions. Technical teams often immediately jump to solution design—integrating ERP, MES, WMS, TMS, using LLMs for contract understanding, and orchestrating workflows—producing architecture diagrams, interface lists, and schedules. However, the request hides critical unconfirmed questions: what defines an abnormal order, which delivery date is authoritative, how to resolve system record conflicts, who can adjust schedules and customer commitments, how far AI suggestions can go, and which actions require human approval. If these remain unanswered, a detailed architecture merely solidifies unverified assumptions into system design.

Core Principle: Field Discovery Is Not Requirements Gathering

FDE field discovery does not organize customer statements into requirements; it converts field claims into evidence with source, status, owner, verification path, and the ability to constrain downstream engineering decisions.

Unlike business research that asks "what problem is worth solving," FDE's evidence discipline further demands:

Where does this conclusion originate, and can we trace back to the original record?

Under what time, version, and business scope does it hold?

Do different roles or systems give conflicting answers?

Who has authority to confirm business facts, interpret rules, approve permissions, and accept risks?

What evidence is currently missing, and which engineering decision does the gap block?

If confirmation is not yet possible, do we narrow scope, arrange verification, escalate, or stop?

Physical presence ("stationed co-creation") shortens information distance but cannot replace evidence quality. Meeting count, duration, or response speed do not prove the team has found an engineerable problem.

Six Types of Field Information Mixed in One Statement

The most dangerous situation is not lack of information but different natures of information recorded in the same meeting minutes, all later treated as "confirmed requirements." The article proposes a six-category framework (author's method, not an industry standard):

Wish – Stakeholder's desired outcome, function, or solution. Record: proposer, goal, context, verification questions. Cannot directly become architecture or delivery commitment.

Fact – Already occurred or currently true, verifiable via records, materials, systems, or observed behavior. Record: source, time, version, provider, confirmation status. Cannot be established by meeting consensus or hierarchy alone.

Constraint – Business, data, permission, compliance, operational, or technical boundaries that must be respected in current scope. Record: basis, applicable scope, authorized confirmer, exceptions, review conditions. Cannot turn habitual practices into mandatory rules automatically.

Risk – Potential impact of an uncertain event. Record: trigger condition, likelihood, impact, owner, response and escalation path. Cannot just state "risk exists" without handling.

Unknown – Lack of evidence, conflicts, or no authorized confirmation, preventing a definite judgment. Record: blocked decision, verification method, owner, deadline, timeout handling. Cannot be answered by FDE, model, or developers on their own.

Non-do Item – Explicitly excluded, prohibited, or deferred objects, actions, or commitments for this phase. Record: exclusion basis, approver, applicable period, review conditions. Cannot hide in verbal agreements or outside the schedule.

These categories are not static document columns; they change state during evidence supplementation. For example, "system automatically adjusts order scheduling" starts as a wish; after confirming source systems, permissions, and approval requirements, part may become allowed scope, part may move to non-do items due to high risk. "ERP delivery date is the final commitment" is not a fact if only verbal; when contract, order, and extension approval conflict, it enters unknowns rather than letting the technical team pick the most convenient field.

Field Discovery Output: Not Just Interview Minutes

Interview minutes record "who said what" but cannot directly support architecture, development, and production gates. FDE must produce a continuously updatable, mutually traceable field discovery evidence package with five parts:

Field Task Map – Centers on a concrete task, capturing trigger and end, participating roles, systems and materials used, key judgments, normal and exceptional paths, and handoff points. Validity is tested by whether the team can take a normal and an abnormal case and trace them back to original records along the timeline.

Field Evidence Ledger & Domain Language Table – Every key item has an ID, type, source location, time and version, provider, confirmer, and current status. Same term with different meanings across departments/systems must not be silently merged; different names for the same business concept must be confirmed by respective business owners, not unified by experience after meetings.

Unknowns, Risks, and Non-do Items Ledger – Unknowns must state blocked decision, evidence owner, completion deadline, and timeout handling. Risks need trigger, impact, owner, response path. Non-do items require basis, approver, and re-review conditions. Otherwise "confirm later" becomes default confirmed under schedule pressure.

Permissions, Human-in-the-loop Points, and Validation Plan – System read access does not grant FDE or agent authority to interpret business facts; write access does not grant business authorization. Every key judgment and action must know who is responsible, who approves, and when human takeover is mandatory. For unconfirmed items, define samples, methods, pass/fail criteria, stop conditions, and validation window.

Downstream Traceability Links – Evidence must flow into subsequent engineering: facts, terms, and semantic conflicts into business model; data/transaction authority, system limits, non-do items into architecture decisions; capability unknowns into prototype validation; identity, permissions, handoff points into agent integration design; baselines, guardrails, stop conditions into production gates. The package's value lies in letting every later engineering decision answer: what it relies on, what remains unconfirmed, and who accepted the boundary.

Case Study: Abnormal Order Scenario Shows How Evidence Constrains Engineering

Using the series' synthetic "manufacturing enterprise uses AI to assist abnormal order handling" scenario (not a real client, no production results yet), the team conducted field walkthroughs and produced evidence fragments instead of immediately decomposing into interfaces and functions. The table below shows only type, content, and current handling; the actual ledger also records source, time, version, provider, confirmer, and handling deadline.

W-01 (Wish) : System automatically judges whether order can be delivered on time and gives disposition suggestions. → Continue confirming target role, usage node, allowed assistive actions.

F-01 (Fact) : In synthetic abnormal samples, contract, ERP order, and extension approval records show inconsistent delivery dates. → Retain each source and version; do not immediately select authoritative value.

C-01 (Constraint) : Changes to external customer commitments must be approved by designated business owner. → Enters human confirmation point and action permission boundary.

U-01 (Unknown) : When contract version, ERP date, and extension approval conflict, which determines current valid commitment is unconfirmed. → Business and source system owners to jointly confirm; blocks automatic conclusion until confirmed.

R-01 (Risk) : Using wrong date may cause false positives, false negatives, or unauthorized customer commitments. → Enters validation plan, risk guardrails, stop conditions.

N-01 (Non-do) : Phase 1 will not automatically modify ERP scheduling, procurement plans, or customer commitments. → Enters scope baseline and subsequent system boundaries.

This evidence set does not yet answer the target architecture, but it shifts the engineering starting point. Without evidence discipline, the team might default to ERP date as authoritative, develop cross-system aggregation and abnormal judgment, then discover during integration that contract version, extension approval, and customer commitment cannot be unified. Rework would span object definitions, judgment logic, permission boundaries, evaluation samples, and disposition flows. With the evidence package, the team retains conflicts, clarifies who can interpret current commitment; before confirmation, they can validate material extraction and conflict identification but cannot auto-generate final fulfillment conclusions, let alone modify scheduling or commitments. Unknowns become objects that control engineering scope—triggering evidence supplementation, scope reduction, temporary boundaries, or stopping. FDE's value is not giving quick answers but preventing unconfirmed answers from entering production systems.

When Can We Start Drawing Architecture Diagrams?

Field discovery cannot eliminate all unknowns. The real completion criterion is that remaining unknowns are explicitly managed and not disguised as certain facts. Before entering business modeling and architectural trade-offs, at minimum verify:

Is there a concrete task with defined start, end, and exclusion scope?

Are there normal and abnormal cases, not just a prescribed process?

Can key facts be traced back to data, documents, logs, records, or observed behavior?

Are conflicts between different roles and systems still visible?

Does every unknown have an owner, verification method, deadline, and timeout handling?

Are business facts, data authority, permission boundaries, and risk acceptance confirmed by respective authorized parties?

Are human-in-the-loop points, failure paths, and stop conditions recorded?

Have key evidences been mapped to subsequent business model, architecture decisions, or validation tasks?

Only templates without real content do not mean field discovery is done; only final conclusions without original sources, conflicts, and confirmation process cannot prove reliability. AI can help transcribe interviews, cluster materials, extract terms, find contradictions, and generate pending questions—these accelerate information processing. But source credibility, conflict resolution, and which unknowns block engineering still require FDE judgment and confirmation by authorized parties. An AI-generated structurally complete document does not equal complete field facts.

Endpoint of Field Discovery: Credible Engineering Inputs

FDE enters the field not to turn customer wishes into development tasks faster, but to clarify what can serve as engineering basis, what still needs verification, what must be decided by authorized parties, and what cannot enter this phase's scope. Only then does the team have the conditions to discuss the next step: how to transform confirmed field facts and domain language into a business source model traceable by both business experts and engineering teams. This will be covered in Part 03 of the series.

References

Don't Ask Users What Features They Want First: How Business Research Discovers Real AI Opportunities (https://mp.weixin.qq.com/s?__biz=MzcwNDM2MTg3NA==∣=2247484240&idx=1&sn=36561f6ff06a9efc7a0a840a3176f7a4&scene=21#wechat_redirect)

OpenAI launches the OpenAI Deployment Company

Beijing Municipal Measures on Accelerating Agent-Led Development