DEV PLAN / OVERVIEW

IEF Agentic System Development Plan

Strategic overview of the development direction, current production needs and the path toward stable digital production.

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.

Normalized metric coordinate illustrative position

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

Pmetric = 100 × Actual−Floor Ceiling−Floor

Normalize the direction of improvement before applying the formula so that a higher position always represents a better result.

Operating Principles

  1. Keep the Domain–Dimension hierarchy stable and add detail through an extensible library of Atomic Metrics.
  2. Use Work Cases to select applicable metrics and define business context; use R&D to design tests and produce validation evidence.
  3. 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.
  4. 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.
  5. Pair every reported score with its metric coverage, evidence confidence and Benchmark version so the result remains interpretable and comparable.
  6. 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.