IDEF0.

                         CONTROL
                            │
                            ▼
INPUT ───────────────▶ ┌───────────────┐ ───────────────▶ OUTPUT
                       │               │
                       │   FUNCTION    │
                       │      A1       │
                       │               │
                       └───────────────┘
                            ▲
                            │
                        MECHANISM

LEFT   = INPUT
TOP    = CONTROL
RIGHT  = OUTPUT
BOTTOM = MECHANISM

MODEL HEADER

Purpose:
  clarify functional architecture
  of the production AI system.

Viewpoint:
  system architect.

System boundary:
  from authenticated task intake
  to verified output/action.

Outside:
  external model providers,
  customer systems,
  human users,
  legal/regulatory environment.

                         CONTROLS
         product policy · security · governance
                budgets · task contracts
                            │
                            ▼
USER REQUEST ───────▶ ┌───────────────────────────┐ ───────▶ VERIFIED OUTCOME
SOURCE DATA ────────▶ │ A-0                       │ ───────▶ ARTIFACT / ACTION
EVENT / TRIGGER ────▶ │ EXECUTE AI PRODUCT TASK   │ ───────▶ TRACE / FEEDBACK
                      └───────────────────────────┘
                            ▲
                            │
                         MECHANISMS
           AI runtime · models · tools · knowledge
        production fabric · people · external systems

PARENT BOX A3:

Inputs:
  task query
  source refs

Controls:
  access policy
  research strategy

Outputs:
  evidence set
  tool results

Mechanisms:
  R06 Knowledge Engine
  R07 Tool Engine


CHILD DIAGRAM A3:

A31 retrieve sources
A32 call external tools
A33 normalize evidence
A34 attach provenance

Boundary arrows of A3
must be explainable on A31–A34.

Do not invent:
  new external payment system
  new unrestricted data source
inside child diagram
without updating parent context.

                     ┌──────────────┐
source metadata ────▶│ A21 classify │
      │              └──────────────┘
      │
      ├─────────────▶┌──────────────┐
      │              │ A22 route     │
      │              └──────────────┘
      │
      └─────────────▶┌──────────────┐
                     │ A23 log/audit │
                     └──────────────┘

Branch:
  one arrow concept splits into uses.

Join:
  multiple compatible flows can merge
  only when the resulting arrow meaning remains clear.

A-0 EXECUTE AI TASK

Possible top decomposition:

A1 FORMULATE TASK
  mechanisms:
    R02

A2 CONTROL EXECUTION
  mechanisms:
    R01
    R03

A3 BUILD OPERATING CONTEXT
  mechanisms:
    R04
    R05

A4 ACQUIRE KNOWLEDGE / PERFORM ACTION
  mechanisms:
    R06
    R07

A5 GENERATE / ROUTE MODEL WORK
  mechanisms:
    R09
    models / gateway

A6 VERIFY & COMMIT RESULT
  mechanisms:
    R08
    policies / HITL / tools

A7 LEARN FROM OUTCOME
  mechanisms:
    R10
    eval / feedback systems

Notice:
  function map ≠ module list.
  One function may use several mechanisms.
  One mechanism may support several functions.

                             CONTROLS
          data governance · model policy · budgets
            capability requirements · latency SLO
                                │
                                ▼
model request ─────────▶ ┌───────────────────────────┐ ─────────▶ selected target
task metadata ─────────▶ │ SELECT MODEL TARGET       │ ─────────▶ routing rationale
runtime health ─────────▶ │ A51                       │ ─────────▶ fallback candidates
                         └───────────────────────────┘
                                ▲
                                │
                             MECHANISMS
                    R09 Model Router
                    №65 Model Gateway
                    health registry
                    quota service

                             CONTROLS
      access policy · retrieval strategy · top-k budget
           freshness rules · evidence requirements
                                │
                                ▼
query ─────────────────▶ ┌──────────────────────────────┐ ───────▶ evidence refs
source/index state ─────▶│ PROVIDE RELEVANT EVIDENCE    │ ───────▶ retrieval metadata
                         │ A41                           │ ───────▶ insufficiency signal
                         └──────────────────────────────┘
                                ▲
                                │
                             MECHANISMS
                     R06 Knowledge Engine
                     vector DB / HNSW
                     source store
                     reranker

At high-level runtime model:

data governance policy
  = CONTROL
  directing other functions.

Inside governance subsystem:

A1 CLASSIFY DATA
A2 DETERMINE ALLOWED PURPOSE
A3 DETERMINE PROVIDER / REGION ELIGIBILITY
A4 APPLY RETENTION / DELETION RULES

Now governance itself
is decomposed into FUNCTIONS.

This is not contradiction.

IDEF0 semantics depend on
the system boundary and viewpoint.

A1 classify request ──mechanism──▶ Human Reviewer
A2 approve action  ───mechanism──▶ Human Reviewer
A3 review failure  ───mechanism──▶ Human Reviewer
A4 approve release ───mechanism──▶ Human Reviewer

IDEF0 reveals:
  one mechanism supports many critical functions.

TOC asks:
  is this shared mechanism
  the current system constraint?

Then:
  exploit / subordinate / elevate
  around that resource.

IDEF0 WORKSHEET
=========================================================

MODEL PURPOSE
Why are we modeling this system?
→

VIEWPOINT
Whose perspective?
→

SYSTEM BOUNDARY
Inside:
→
Outside:
→

A-0 TOP FUNCTION
Verb + object:
→

INPUTS
What does the function transform?
1.
2.
3.

CONTROLS
What constrains/directs it?
1.
2.
3.

OUTPUTS
What does it produce?
1.
2.
3.

MECHANISMS
Who/what performs it?
1.
2.
3.

---------------------------------------------------------

A0 DECOMPOSITION

A1:
Function:
Inputs:
Controls:
Outputs:
Mechanisms:

A2:
Function:
Inputs:
Controls:
Outputs:
Mechanisms:

A3:
Function:
Inputs:
Controls:
Outputs:
Mechanisms:

A4:
Function:
Inputs:
Controls:
Outputs:
Mechanisms:

---------------------------------------------------------

BOUNDARY CHECK

Parent input represented?
[ ] yes [ ] tunneled [ ] gap

Parent control represented?
[ ] yes [ ] tunneled [ ] gap

Parent output produced?
[ ] yes [ ] tunneled [ ] gap

Parent mechanism represented?
[ ] yes [ ] tunneled [ ] gap

---------------------------------------------------------

ARCHITECTURE FINDINGS

Missing owner/mechanism:
→

Missing control:
→

Dead output:
→

Duplicated function:
→

Ambiguous arrow:
→

Candidate typed contract:
→

Need deeper decomposition?
→ yes / no

Need BPMN for sequence?
→ yes / no

You are assisting with IDEF0 functional modeling.

Rules:
1. Ask/derive the model PURPOSE and VIEWPOINT first.
2. Define the system boundary.
3. Create one A-0 function using a verb + object phrase.
4. Classify every external arrow as:
   INPUT, CONTROL, OUTPUT or MECHANISM.
5. Use these semantics:
   INPUT = transformed/processed object;
   CONTROL = rule/constraint/objective directing function;
   OUTPUT = result produced by function;
   MECHANISM = resource/component/person performing function.
6. Do not model components/departments as functions
   unless rewritten as activities.
7. Decompose a parent function into a small coherent set
   of child functions.
8. Preserve parent-child boundary consistency.
9. Do not assume box position implies exact chronology.
10. If chronological flow matters, recommend a separate BPMN model.
11. Mark missing controls, mechanisms or outputs as gaps;
    do not invent them.
12. Maintain a glossary for important arrow concepts.
13. For every diagram identify:
    - missing responsibilities;
    - duplicated functions;
    - dead outputs;
    - overloaded/shared mechanisms;
    - candidate contract boundaries.
14. Stop decomposition when additional detail
    no longer serves the declared purpose.

START
  ↓
DEFINE MODEL PURPOSE
  architecture?
  automation?
  ownership?
  controls?
  constraint discovery?
  ↓
DEFINE VIEWPOINT
  architect
  operations
  product
  governance
  user
  ↓
DEFINE SYSTEM BOUNDARY
  ↓
CREATE A-0

                CONTROL
                   ↓
INPUT ───────▶ [ FUNCTION ] ───────▶ OUTPUT
                   ↑
               MECHANISM

────────────────────────────────────────

ASK:

INPUT
  what is transformed?

CONTROL
  what constrains/directs execution?

OUTPUT
  what exists because function ran?

MECHANISM
  who/what performs or enables it?

────────────────────────────────────────

DECOMPOSE:

A-0
  ↓
A0 diagram

A1 function
A2 function
A3 function
A4 function
A5 function

then:

A3
  ↓
A31
A32
A33
...

ONLY AS DEEP
AS MODEL PURPOSE REQUIRES.

────────────────────────────────────────

BALANCE:

parent external ICOM
must remain explainable
on child diagram

unless explicitly tunneled.

────────────────────────────────────────

IN AI ARCHITECTURE:

FUNCTION:
  provide relevant evidence

INPUT:
  query / source state

CONTROL:
  access policy
  retrieval strategy
  freshness requirements

OUTPUT:
  evidence refs
  insufficiency signal

MECHANISM:
  R06
  vector DB
  source store
  reranker

HNSW IS A MECHANISM,
NOT THE BUSINESS FUNCTION.

────────────────────────────────────────

FUNCTION:
  select model target

INPUT:
  request
  health/capability state

CONTROL:
  governance
  budgets
  latency SLO
  model policy

OUTPUT:
  selected route
  fallback candidates

MECHANISM:
  R09
  Model Gateway

────────────────────────────────────────

USE WITH:

TOC
  to find overloaded/shared mechanisms
  and system constraints

KT
  to diagnose deviations in a function

TRIZ
  to redesign conflicting functions
  or trim mechanisms

BPMN
  to specify exact sequence,
  waits, events and branching

STRUCTURED CONTRACTS
  to formalize critical arrows

────────────────────────────────────────

THE CENTRAL QUESTION IS NOT:

“WHAT SERVICES DO WE HAVE?”

IT IS:

“WHAT FUNCTIONS MUST THE SYSTEM PERFORM,
WHAT DO THEY TRANSFORM,
WHAT CONTROLS THEM,
WHAT DO THEY PRODUCE,
AND WHAT ACTUALLY MAKES THEM HAPPEN?”

THAT SHIFT
FROM COMPONENTS
TO FUNCTIONS
IS THE PRACTICAL VALUE
OF IDEF0.