FDE Capability Framework: Deriving 12 Competencies from Real Deliverables, Not Buzzwords

The article opens by referencing the previous installment, which assigned nine responsibilities across a frontline squad while stressing that authorization, independent verification, and risk acceptance cannot disappear even when one person wears multiple hats. The immediate question becomes: what kind of person can actually carry the FDE role?

Typical answers list adjectives — understands business, knows technology, communicates well, handles pressure, owns outcomes, preferably knows LLMs, data, cloud, and project management. The author argues such trait-based descriptions are unusable for verification. Claiming "strong business understanding" does not prove one can preserve unknowns from conflicting on-site accounts; claiming "strong architecture skill" does not show one can articulate authoritative systems, failure paths, and rollback boundaries; claiming "strong delivery skill" does not clarify whether the function is merely built or the customer can independently assume responsibility.

FDE capabilities must not be forward-derived from abstract qualities but reverse-engineered from the artifacts, decisions, and results that real projects must produce.

The piece continues with a synthetic case — a manufacturing enterprise using AI to assist with abnormal orders — used only to illustrate the verification method, not as a real customer or a claim that anyone has passed this validation.

Doing Tasks ≠ Bearing Responsibility

An engineer can use AI to quickly generate interview summaries, model sketches, architecture diagrams, code, tests, and runbooks. This proves execution cost has dropped, not that the engineer possesses the corresponding FDE capability. Behind every artifact lie at least four questions: Are input facts trustworthy? Who judges key boundaries? Who confirms conclusions? Has the artifact actually entered downstream verification and production?

Take an Architecture Decision Record (ADR). Producing a well-formatted ADR only shows template familiarity. Real architectural trade-off capability is evidenced by whether it cites confirmed on-site facts and business models, compares alternatives, exposes irreversible risks, documents failure signals, rollback and review conditions, and records risk acceptance by an authorized party.

Similarly, chairing a client meeting ≠ on-site discovery capability; drawing an ontology model ≠ completed business modeling collaboration; writing an Agent tool ≠ establishing identity, data, action, and audit accountability chains; delivering training ≠ completed customer handover.

Therefore, FDE capability checks should not target "which tasks were done" but:

What real inputs and constraints were faced;

What verifiable artifacts were produced;

What decisions were made or driven;

How artifacts entered implementation, production, handover, or product feedback;

Which responsibilities were explicitly not assumed beyond authority.

The last point is critical: FDE maturity comes not from "can do everything" but from both performing key engineering work and knowing which decisions must be delegated to business, security, quality, source-system, or management authorities.

Twelve Capabilities Reverse-Engineered from the First Ten Articles

Articles 01–10 established an artifact chain from on-site problems to production learning. Article 11 asks: to stably produce these artifacts, what capabilities are needed, and what should verification examine?

The capability matrix below is the author's framework, not an industry standard, hiring certification, or job-level system. Projects may merge roles or adjust artifact carriers, but cannot cancel fact confirmation, independent verification, authorization, and risk acceptance responsibilities due to organizational differences.

The third column retains only the core judgments FDE cannot transfer to tools or others. Transcription, model drafts, code, tests, and docs can be accelerated, but acceleration ≠ responsibility fulfilled.

Capability Matrix

Role & Responsibility Boundaries — Primary Artifacts: Role comparison, applicability conditions, responsibility ceilings. Non-Transferable Core Verification: Can the person explain who is responsible for what outcomes and identify at least one responsibility FDE must not assume?

On-Site Discovery — Primary Artifacts: On-site discovery evidence pack. Non-Transferable Core Verification: Can they distinguish facts, wishes, constraints, risks, unknowns, and non-actions, and trace back to original evidence?

Business Modeling Collaboration — Primary Artifacts: Business source model, downstream traceability. Non-Transferable Core Verification: Can objects, processes, states, rules, evidence, roles, and actions be confirmed by business and traced to engineering artifacts?

Architectural Trade-offs — Primary Artifacts: Boundary diagrams, ADRs, interfaces & failure contracts. Non-Transferable Core Verification: Can they explain authority, integration paths, alternatives, failure signals, rollback, and review conditions based on on-site constraints?

Engineering Slice & Delivery — Primary Artifacts: Controlled runnable loop, keep/discard/risk lists, iteration gates. Non-Transferable Core Verification: Can they cut a minimum repeatable verifiable loop from full requirements and prevent demo assets from silently entering production?

Agent Integration & Security — Primary Artifacts: Production access boundary diagrams, security responsibility artifacts. Non-Transferable Core Verification: Can they reconstruct identity delegation, data egress, least privilege, action confirmation, audit linkage, final verification, and exception takeover?

Value Proof & Production Gates — Primary Artifacts: Six-dimensional scorecard, four hard gates. Non-Transferable Core Verification: Can they separate "can it enter production" from "is it worth continuing", giving metrics scope, data source, window, owner, guardrails, and exit conditions?

Exit & Responsibility Handover — Primary Artifacts: Handover modes, handover gates, responsibility tracks, run artifacts. Non-Transferable Core Verification: When the original FDE does not operate, can the agreed handover party perform changes, troubleshooting, recovery, and upgrades within their responsibility?

Product Feedback & Knowledge Reuse — Primary Artifacts: Feedback classification, productization judgment, three 沉淀载体. Non-Transferable Core Verification: Can they distinguish customer facts, desensitized experience, and formal product assets, and guard reuse rights and cross-customer information boundaries?

Frontline Squad Collaboration — Primary Artifacts: Nine responsibilities & five-column responsibility matrix. Non-Transferable Core Verification: When one person wears multiple hats, can they retain independent parties for high-risk decisions, production verification, security authorization, and residual risk acceptance?

Judgment Under Incomplete Information — Primary Artifacts: Unknowns, temporary boundaries, verification paths, stop conditions. Non-Transferable Core Verification: When evidence is insufficient, can they shrink the reversible scope and escalate instead of inventing a definitive answer?

Customer Expectation & Conflict Handling — Primary Artifacts: Change records, impact analysis, decision & re-verification records. Non-Transferable Core Verification: Facing scope, quality, time, and responsibility conflicts, can they drive decisions with facts and options rather than masking risk with relationship coordination?

The first ten follow the series mainline; the last two are cross-cutting capabilities. They resemble "judgment" and "communication" but still cannot be proven by self-assessment. A decision where an unknown was not arbitrarily filled, and a conflict record containing all parties' goals, facts, options, impacts, decision-maker, and re-verification method, are the checkable evidence.

The article references three earlier pieces for detailed methods on value proof/production gates, exit/handover, and product feedback/reuse.

The matrix does not imply a single FDE must produce all artifacts alone. Business experts confirm semantics, product owners decide roadmap, quality leads set independent verification baselines, security and source-system owners authorize, executives or authorized parties accept business and residual risk. FDE capability shows in personally establishing critical engineering links and driving these responsibilities to close on the same evidence chain — not putting one's name in every box.

Checking One Capability Requires At Least Four Evidence Types

Looking only at final documents mistakes template quality for project capability; looking only at project results masks process gaps with a lucky success. Each capability needs four evidence types:

Input Evidence — Must Answer: What on-site facts, constraints, versions, and unknowns were known at the time? What remained unconfirmed?

Artifact Evidence — Must Answer: What structured artifacts were produced, where is the current version, which roles actually used them?

Decision Evidence — Must Answer: What was chosen, what excluded, on what basis, who confirmed or accepted risk?

Result Evidence — Must Answer: How did artifacts enter implementation, verification, operation, handover, or product feedback? What happened after failure?

For example, someone claiming to have led an abnormal-order Agent can be asked to walk through a randomly selected key decision, not a rehearsed demo. Follow-up questions include:

When contract date, order date, and planned date appeared simultaneously, which became the fulfillment commitment and how were conflicts preserved?

Why did phase one only generate risk tasks instead of letting the Agent auto-modify schedules?

Who approved data usage and write-back actions?

When the tool returns success but source-system state is unknown, how does the system stop retries and enter reconciliation?

After FDE departure, who performs the first config change, alert handling, and rollback?

Which experiences go to the customer archive, which are desensitized into the FDE knowledge base, and which never enter the product?

If answers stop at "we built a model, results were good, customer was happy," verifiable capability evidence is missing. Conversely, even if a project stops, showing the facts, assumptions, boundaries, gates, stop decision, and asset disposition at the time can still prove certain FDE capabilities.

Project success does not automatically prove all capabilities; project failure does not automatically negate all. The key is whether evidence can be re-walked along "input → artifact → decision → result."

E0–E3 Are Evidence Maturity Levels for Single Capabilities, Not Job Grades

To avoid conflating "did it once" with "can stably handle in complex scenarios," each capability gets an evidence maturity marker:

E0 Unverified — Condition: Knows concepts, tools, or templates but has no real artifact/result evidence. Cannot Conclude: Training, certificates, or simulations ≠ project capability.

E1 Guided Completion — Condition: Completes artifacts under explicit scope, frozen inputs, and review support. Cannot Conclude: Cannot assume cross-boundary or high-risk scenarios.

E2 Independent Loop — Condition: Independently gathers evidence, produces artifacts, handles feedback, and completes verification in low-to-medium risk real scenarios. Cannot Conclude: Does not automatically generalize to other industries, scales, or risk levels.

E3 Complex Scenario Validated — Condition: Handles conflicting constraints, failure recovery, organizational collaboration, and responsibility handover in high-complexity/high-risk scenarios with verifiable evidence. Cannot Conclude: Only valid for the verified capability dimensions and applicability scope; ≠ "full-stack FDE".

These levels remain the author's verification method, not a universal certification. E3 is not self-assessed by tenure but requires authorized real-project evidence and review by responsible parties.

Crucially, levels must be recorded per capability. One may be E3 on architectural trade-offs but E1 on customer handover; may know Agent security mechanisms but never independently resolved customer business-semantic conflicts. Averaging twelve capabilities into a single score hides true gaps.

Security authorization, production verification, source-system transaction boundaries, and responsibility handover especially cannot be compensated by averages. A blocking gap in any dimension means the person or squad cannot independently own the full loop in the current project. The correct response: shrink responsibility scope, add the missing role, or retain supervision and approval mechanisms until real verification exists.

Comprehensive Check ≠ Testing Twelve Items Separately

The difficulty of FDE work lies not in single artifacts but in their continuity. On-site facts not entering business model, model not constraining architecture, architecture decisions not reaching code and tests, production metrics not tracing back to versions, handover materials inconsistent with actual operation — even if each document looks perfect alone, the loop is broken.

A comprehensive check selects an authorized real project slice and traces the chain:

On-site facts → Business source model → Architecture decisions → Controlled runnable loop → Agent integration & production gates → Customer handover or stop → Product feedback

The reviewer can randomly inject a change — source-system field meaning change, model version upgrade, permission tightening, tool timeout, or customer scope expansion — and ask how it impacts downstream artifacts. A person with true loop capability not only shows the final architecture but points out which baselines break, which gates must re-run, which owners must re-confirm, and how to contract or stop when continuation is impossible.

For non-public client projects, evidence can be desensitized; public articles must not leak contracts, data, system details, or internal owners. But "not public" ≠ "cannot be inspected internally." If even authorized internal reviewers cannot see inputs, decisions, and results — only personal summaries — the capability cannot be marked verified.

AI Compresses Execution Cost, Cannot Replace Authorization

AI already accelerates interview transcription, material clustering, candidate model extraction, architecture sketches, code and test generation, run analysis, knowledge-base organization, and feedback classification. This will only get faster.

But Article 11's capability standard must not lower. After using AI, at minimum one must retain input sources, candidate options, human modifications, verification results, and final decision records. Otherwise the team only proves the tool generated content, not that on-site facts were correctly understood, engineering boundaries judged, and risks accepted by authorized parties.

Judging whether AI replaces an FDE capability cannot rely on task completion count; one must still ask:

Who confirms on-site records are true and usable;

Who decides how semantic conflicts are handled and which unknowns cannot be filled;

Who chooses system boundaries and owns failure consequences;

Who approves data usage, permissions, and high-risk actions;

Who confirms production evidence, completes responsibility handover, and decides continued investment.

These questions have not disappeared; therefore capability has not wholesale transferred to AI. AI can draft a responsibility matrix but cannot make absent responsible parties appear; can propose rollback plans but cannot prove the real environment has rehearsed them; can generate product commonality candidates but cannot authorize reuse on behalf of the customer nor commit long-term support for the product team.

The article defers long-term AI impact on role structures to Article 13, keeping one boundary here:

Tools can accelerate artifact formation, but fact judgment, engineering trade-offs, authorization, verification, and responsibility handover must still be borne by identifiable humans.

The Capability Matrix Exposes Gaps

This matrix is not to select a twelve-item "super FDE" nor to add twelve question sets to HR interviews.

First, it aids project staffing. Facing a high-risk Agent scenario, the team can check who provides already-verified capabilities for on-site discovery, business modeling, Agent security, production gates, and customer handover, and which dimensions still need business, security, quality, or platform teams to fill.

Second, it supports personal capability inventory. The result is not "I have eight years of experience" but which dimensions have E2/E3 evidence, which only E0/E1, and which evidence has expired due to industry, version, or responsibility-scope changes.

Third, it enables project retrospectives. The question is not just who erred, but which capability dimension was missing from the responsibility matrix, which artifact was not produced, which evidence was not reviewed, which decision lacked an authorized owner. Improvements then land on next project's staffing, supervision mechanisms, and verification scenarios — not another "improve communication" platitude.

FDE capability cannot be answered with a string of pleasant qualities. Truly verifiable capability is the continuous production of on-site evidence, business models, architecture decisions, controlled loops, security responsibility chains, production evidence, handover materials, and product feedback under real constraints, with the ability to explain the basis, owner, applicability boundary, and failure handling for every decision.

Capability is not "what I know" but "within what scope, with what evidence, can I prove I can stably assume what responsibility."

Article 11 defined capabilities and their verification. The next article will address: what foundations do traditional development, industry delivery, AI engineering, and knowledge engineering backgrounds already have, where are their gaps, and through what real project slices should they be filled and verified.