Context
The current fabrication development workflow still relies heavily on manual verification, repeated instructions, and manual correction. Many recurring errors require continuous human attention, communication, and rework to control. When deliverables fail to meet standards, additional resource and energy is required to resolve the issues, putting both delivery quality and project timelines at risk.
Although modeling capacity can be increased relatively inexpensively by adding more production resources, the associated quality risks do not scale down automatically. As production volume increases, the number of items requiring manual verification also increases, while risk control remains heavily dependent on the attention of the fabrication managements. As a result, quality control cannot scale at the same rate as production, creating a bottleneck in both manpower and attention and ultimately affecting the consistency and reliability of downstream production delivery.
The goal of the IEF Agentic System is to develop a more effective digital information production and quality control process that can grow with production needs. As production capacity increases, QC capacity should be able to increase accordingly. When short-term staffing gaps occur, technology-assisted automation can support certain production and verification tasks. The system will start by addressing specific issues in the existing 3D and 2D production workflows, and gradually develop into an integrated and scalable digital production and quality control process.
Strategic Themes
01 / Asset Management
Manage and version reusable digital production resources, including cross-project 3D models, extrusion profiles, drawing templates, standard modeling workflows, as well as part naming conventions and related maintenance practices.
02 / QC Framework
Formalize and standardize the digital information QC process while providing transparent, automated support tools to define QC baselines and standardized assessment methods for specific deliverables, including but not limited to 3D model clash detection, compliance with part naming rules, hole size and alignment checks, iPart table validation, iProperty alignment, unfold pattern pre-export inspections, and drawing integrity checks.
03 / Agentic Production
Integrate existing DeliverablesHandler capabilities and develop an agent-based modeling and drafting system using iLogic, MCP, and AI orchestration. The goal is to define data exchange protocols and establish a stable and reliable cross-software design information workflow. Development will follow an operational structure of input materials –> preparation methods –> recipes, aiming to develop workflows that remain closely integrated with human operations while allowing selected processes to operate with partial autonomy.
Operating Model
Fab Team observations enter through the Opportunity Register. An Opportunity may be formalized as a Work Case, investigated through R&D, or move between the two as questions and evidence develop. Work Cases return an actionable response to the Fab Team. The Benchmark evaluates both the evidence produced through R&D and the production scope and outcomes defined by Work Cases.
%%{init: {"flowchart": {"nodeSpacing": 38, "rankSpacing": 68, "padding": 12, "curve": "basis"}}}%%
flowchart LR
FAB["<span class='operating-record'><b>FAB TEAM</b><small>Problem / improvement input<br/>Implementation / feedback</small></span>"]:::operatingExternal
OPP["<span class='operating-record'><b>OPPORTUNITY REGISTER</b></span>"]:::operatingCore
subgraph PROJECTS[" "]
direction TB
RD["<span class='operating-record'><b>R&D</b><small>Test / evidence</small></span>"]:::operatingCore
WC["<span class='operating-record'><b>WORK CASE</b><small>Production scope / outcome</small></span>"]:::operatingCore
end
BM["<span class='operating-record'><b>BENCHMARK</b><small>Assessment</small></span>"]:::operatingExternal
FAB -->|intake| OPP
OPP -->|investigate| RD
OPP -->|formalize| WC
RD <-->|questions / evidence| WC
WC -->|production response| FAB
RD -->|evaluate| BM
WC -->|evaluate| BM
Benchmark
The Benchmark provides a stable evaluation structure for known production challenges and development directions. It separates the technical strength of the tools from their business value. Opportunities preserve the originating need, while Work Cases and R&D select relevant metrics, define realistic scenarios and produce evidence over time.
Architecture
The Benchmark owns a three-level hierarchy. Domains define the major evaluation perspectives, Dimensions organize each perspective, and Atomic Metrics provide the measurable units. The diagram shows the governing structure rather than every record-level mapping: each Work Case and R&D record selects the metrics relevant to its scope, Opportunities can inform either record type, and Cases and R&D may support one another.
%%{init: {"flowchart": {"nodeSpacing": 9, "rankSpacing": 24, "padding": 4, "curve": "monotoneX"}}}%%
flowchart LR
subgraph DOM[" "]
direction TB
DOMH["DOMAIN"]:::columnTitle
TC["<span class='domain-node'>Technical Capability</span>"]:::domain
BV["<span class='domain-node'>Business Value</span>"]:::domain
end
subgraph DIM[" "]
direction TB
DIMH["DIMENSION"]:::columnTitle
D01["<span class='dimension-node'>Functional Capability</span>"]:::dimension
D02["<span class='dimension-node'>Reliability & Robustness</span>"]:::dimension
D03["<span class='dimension-node'>Verifiability & Control</span>"]:::dimension
D04["<span class='dimension-node'>Operability & Integration</span>"]:::dimension
D05["<span class='dimension-node'>Scalability & Evolvability</span>"]:::dimension
D06["<span class='dimension-node'>Delivery & Capacity</span>"]:::dimension
D07["<span class='dimension-node'>Cost & Resource Economics</span>"]:::dimension
D08["<span class='dimension-node'>Quality & Risk Economics</span>"]:::dimension
D09["<span class='dimension-node'>Organizational Leverage</span>"]:::dimension
D10["<span class='dimension-node'>Lifecycle Investment & Burden</span>"]:::dimension
end
subgraph MET[" "]
direction TB
METH["ATOMIC METRICS"]:::columnTitle
M01["<span class='metric-set'><i></i><i></i><i></i></span>"]:::metricBundle
M02["<span class='metric-set'><i></i><i></i><i></i></span>"]:::metricBundle
M03["<span class='metric-set'><i></i><i></i><i></i></span>"]:::metricBundle
M04["<span class='metric-set'><i></i><i></i><i></i></span>"]:::metricBundle
M05["<span class='metric-set'><i></i><i></i><i></i></span>"]:::metricBundle
M06["<span class='metric-set'><i></i><i></i><i></i></span>"]:::metricBundle
M07["<span class='metric-set'><i></i><i></i><i></i></span>"]:::metricBundle
M08["<span class='metric-set'><i></i><i></i><i></i></span>"]:::metricBundle
M09["<span class='metric-set'><i></i><i></i><i></i></span>"]:::metricBundle
M10["<span class='metric-set'><i></i><i></i><i></i></span>"]:::metricBundle
end
subgraph MAP[" "]
direction TB
MAPH[" "]:::columnTitle
COLLECTOR["<span class='metric-collector' aria-label='All Atomic Metrics'></span>"]:::metricCollector
end
subgraph DEV[" "]
direction TB
DEVH["DEVELOPMENT RECORDS"]:::columnTitle
CASES["<span class='record-group'><b>WORK CASES</b><small>CASE-1001 · · · CASE-1005</small></span>"]:::developmentGroup
RNDS["<span class='record-group'><b>R&D</b><small>RND-1001 · · · RND-1005</small></span>"]:::developmentGroup
end
subgraph OPR[" "]
direction TB
OPRH["OPPORTUNITY REGISTER"]:::columnTitle
OPP["<span class='record-group'><b>OPPORTUNITIES</b><small>OPP-1001 · · · OPP-1005</small></span>"]:::opportunityGroup
end
DOMH ~~~ DIMH ~~~ METH ~~~ MAPH ~~~ DEVH ~~~ OPRH
TC --- D01
TC --- D02
TC --- D03
TC --- D04
TC --- D05
BV --- D06
BV --- D07
BV --- D08
BV --- D09
BV --- D10
D01 --- M01
D02 --- M02
D03 --- M03
D04 --- M04
D05 --- M05
D06 --- M06
D07 --- M07
D08 --- M08
D09 --- M09
D10 --- M10
M01 -.- COLLECTOR
M02 -.- COLLECTOR
M03 -.- COLLECTOR
M04 -.- COLLECTOR
M05 -.- COLLECTOR
M06 -.- COLLECTOR
M07 -.- COLLECTOR
M08 -.- COLLECTOR
M09 -.- COLLECTOR
M10 -.- COLLECTOR
COLLECTOR -.- CASES
COLLECTOR -.- RNDS
%% CASES --- RNDS is rendered after layout as a non-constraining Bezier curve.
CASES <--> OPP
RNDS <--> OPP
Domain Definitions
01 / Technical Capability
Technical Capability measures the strength and maturity of the tools themselves. It answers whether the system can perform its intended work reliably, remain under appropriate human control and continue to evolve.
| Dimension | Assessment scope |
|---|---|
| Functional Capability | Intended task coverage, performance and defined capability boundaries |
| Reliability & Robustness | Repeatability, stability and recovery under normal, changing and exceptional conditions |
| Verifiability & Control | Traceability, auditability, result verification and appropriate human supervision |
| Operability & Integration | Fit with real users, production workflows and connected software environments |
| Scalability & Evolvability | Reuse, maintainability, extensibility and operation at increasing scope or volume |
02 / Business Value
Business Value evaluates the expected benefit and burden of applying the system within a defined business scope. It is a planning assessment, not a realized-value study; measured production value requires a separate validation framework.
| Dimension | Assessment scope |
|---|---|
| Delivery & Capacity | Potential effect on delivery speed, throughput and usable production capacity |
| Cost & Resource Economics | Potential effect on labor, materials, software and other resource consumption |
| Quality & Risk Economics | Potential effect on rework, defects, delivery failures and expected risk exposure |
| Organizational Leverage | Potential effect on coordination, knowledge reuse, staffing flexibility and organizational scale |
| Lifecycle Investment & Burden | Development, deployment, training, operation, maintenance and change costs |
The planning-stage net value is evaluated as the combined delivery, resource, quality, risk and organizational benefit, less the full lifecycle burden. Time and other operational gains should remain visible in their original units and should only be converted to monetary value when the conversion basis is credible.
Metric Model
Coordinate System
Each Atomic Metric is placed on its own normalized assessment axis. Floor and Ceiling define the credible bounds; Baseline, Target and Actual are metric-specific positions within those bounds.
The plotted positions are illustrative. Each Atomic Metric defines its own bounds and places Baseline, Target and Actual from explicit assumptions or measured evidence.
Normalization
Normalize the direction of improvement before applying the formula so that a higher position always represents a better result.
Operating Principles
- Keep the Domain–Dimension hierarchy stable and add detail through an extensible library of Atomic Metrics.
- Use Work Cases to select applicable metrics and define business context; use R&D to design tests and produce validation evidence.
- Assign every Atomic Metric to one Dimension, one direction of improvement and one explicit Floor-to-Ceiling range. Treat non-applicable metrics as
N/A, not zero. - Aggregate Atomic Metrics into Dimension scores, then into separate Technical Capability and Business Value Domain profiles. Do not collapse both Domains into one overall score.
- Pair every reported score with its metric coverage, evidence confidence and Benchmark version so the result remains interpretable and comparable.
- Version the stable framework, the evolving metric library and each Benchmark run separately. Never overwrite a historical result when definitions, weights or test conditions change.