Validation status: This is a synthesis framework, not an empirically validated causal model. Its primary value is to make AI system design more legible: first by characterising the problem, then by connecting that profile to architecture and post-build diagnosis. The validation section separates grounded components from novel and speculative claims.

Audience: This framework is most useful for teams building AI systems whose outputs must be reliable, reviewable, or defensible. In low-consequence domains, parts of the machinery will be unnecessary. That is a feature of the framework, not a reason to apply all of it everywhere.

1. Core Thesis

AI implementation is not primarily a software problem. It is an epistemic engineering problem: a problem of defining what must be known, finding evidence that bears on it, producing a warranted conclusion, and preserving enough of that path to evaluate the result.

The difficulty of an AI system can be characterised along four dimensions: Synthesis Depth, Epistemic Friction, Intent Variance, and Consequence Asymmetry. Their interaction predicts where a system will struggle, what architecture it requires, how much inspection it owes its operators, and whether AI belongs in the load-bearing part of the process at all.

The theory comes first. The operational machinery follows: a five-stage pipeline, explicit node and edge choices, attestation surfaces, and a diagnostic protocol for tracing visible failures back to their primary cause.

2. Problem Characterisation

The central move is to characterise the problem before choosing the model or architecture. A model can perform impressively while the system around it is solving the wrong problem, reading the wrong evidence, or operating at a level of consequence its controls cannot support.

Why the Prompt Is Not the Task

AI systems are usually evaluated as if a task were one move: a prompt enters, an answer leaves, and the quality of that answer tells us whether the system works. Production tasks rarely have that shape.

Consider the question: Can we terminate this vendor agreement without penalty? The visible request is one sentence, but answering it requires several dependent operations:

  1. Interpret what “penalty” means in this context.
  2. Identify which agreements, amendments, and statements of work govern the relationship.
  3. Retrieve the relevant clauses from those documents.
  4. Reconcile clauses that modify or override one another.
  5. Distinguish termination fees from minimum-spend commitments and other liabilities.
  6. Produce an answer with the caveats and evidence needed for someone to act.

The user experiences one question. The system faces a chain. Each operation depends on the output of the one before it, and each dependency is a place where uncertainty can enter or an earlier mistake can compound.

This is why model capability and system reliability are different things. A model may be excellent at extracting a clause, comparing two passages, or drafting a legal memo when each operation is tested independently. The production system must perform the right operations, in the right order, over the right evidence, while preserving enough context for the final answer to remain warranted. Local competence does not guarantee reliable composition.

A note on hops: A reasoning hop is a meaningful dependency between an available fact or intermediate conclusion and the next conclusion—not a token count, chain-of-thought sentence, or model call. Length is not depth: a long summary can be shallow, while a short question can require several linked inferences.

Synthesis Depth captures this structure, but depth alone is not enough. The same chain behaves differently when its evidence is clean or contradictory, when the user’s goal is precise or open-ended, and when a mistake is harmless or irreversible. Those differences produce the other three dimensions.

The Four Dimensions

A problem profile has four dimensions. No single dimension decides whether AI is appropriate. The shape created by their interaction does.

1. Synthesis Depth — how many reasoning hops separate the input from the answer.

Level Profile Architectural Implication
D1 Single-step lookup or classification Single Node sufficient
D3 Multi-step retrieval and combination Pipeline required; intermediate validation possible
D5 Multi-source synthesis with inferential chaining Multi-stage with explicit checkpoints; faithfulness becomes hard
D∞ Open-ended exploration with unbounded hop count Agentic architecture required; inspectability degrades sharply

2. Epistemic Friction — how clean the source data is.

Level Profile Architectural Implication
F-Low Structured sources Standard retrieval techniques work
F-Mid Semi-structured Normalisation and chunking strategy become load-bearing
F-High Entropic Heavy preprocessing; representation choice critical; failure rates climb

3. Intent Variance — how many valid answers a single input can have.

Level Profile Architectural Implication
V-Convergent One correct answer Automatable end-to-end
V-Bounded Several valid answers; constraints distinguish them Requires explicit user-preference capture
V-Divergent Many valid answers; quality is contextual Human-in-the-loop required at intent stage

4. Consequence Asymmetry — what failure costs relative to success.

Level Profile Architectural Implication
C-Symmetric Recoverable mistakes Iteration tolerated; lighter verification
C-Asymmetric Failure costs more than success benefits, but recoverable Verification required; explicit uncertainty
C-Catastrophic Irreversible, public, regulated, or safety-critical Determinism preferred; AI may be inappropriate

The Profile

Write the profile as a four-tuple: (D, F, V, C).

  • Customer-support ticket routing: (D1, F-Low, V-Convergent, C-Symmetric). A comfortable automation case.
  • Contract termination analysis: (D3, F-Mid, V-Bounded, C-Asymmetric). Buildable with source controls, intermediate evidence, and review.
  • Flight-readiness support: (D5, F-Mid, V-Bounded, C-Catastrophic). Requires decomposition, blocking verification, and retained human authority.
  • Open-ended investment research: (D∞, F-High, V-Divergent, C-Asymmetric). Useful for exploration, but dangerous as an autonomous decision-maker.

The tuple is not a score. It is a compact description of where engineering pressure will accumulate. Two systems can use the same model and require entirely different controls because their problem profiles differ.

3. Interaction Effects and Loss Propagation

The four dimensions matter because they interact.

  • Friction × Depth multiplies evidence risk. Messy evidence is manageable in a one-step lookup. Across a long reasoning chain, every uncertain extraction becomes another place for the final conclusion to drift.
  • Variance × Consequence determines how much intent can remain implicit. Open-ended interpretation is useful when mistakes are cheap. When outcomes are consequential, acceptable intent must be narrowed, confirmed, or handed back to a person.
  • Depth × Consequence determines how much intermediate state must be exposed. Deep reasoning with cheap failure can remain integrated. Deep reasoning with expensive failure needs checkpoints, evidence contracts, and verifiers.
  • Friction × Variance expands the search space. When both the evidence and the goal are ambiguous, the system must infer what matters while also deciding where to look. That combination frequently turns an apparently simple task into an agentic one.

These interactions explain why model capability alone is a poor guide to system viability. A benchmark measures whether a model can make a move. A problem profile describes the conditions under which many moves must compose into a dependable outcome.

How Loss Propagates

Every stage of an AI system reduces, selects, or transforms information. Some loss is necessary: retrieval excludes documents, synthesis suppresses alternatives, and an output format hides detail so someone can act. The engineering question is not whether loss exists. It is whether the system loses the right things, whether that loss is visible, and whether an early mistake is allowed to propagate.

An upstream failure often appears as a downstream symptom. If intent is framed incorrectly, the system may select the wrong sources. If source selection is incomplete, retrieval can be precise and still miss decisive evidence. Synthesis can then be faithful to an incomplete evidence set and produce a plausible but wrong answer. Tightening the final output schema will not repair the original failure.

flowchart LR
    A["Primary failure<br/>intent or source boundary is wrong"]
    B["Stage II<br/>wrong source universe"]
    C["Stage III<br/>incomplete evidence"]
    D["Stage IV<br/>unsupported conclusion"]
    E["Observed symptom<br/>plausible but wrong output"]
    F["Correct fix<br/>repair the upstream boundary"]

    A --> B
    B -->|"unchecked handoff"| C
    C -->|"evidence gap hidden"| D
    D --> E
    A -.-> F

    classDef failure fill:#FCA5A5,stroke:#B91C1C,color:#111111;
    classDef stage fill:#D8B4FE,stroke:#6B21A8,color:#111111;
    classDef symptom fill:#FFE08A,stroke:#8A6400,color:#111111;
    classDef fix fill:#A7F3D0,stroke:#047857,color:#111111;

    class A failure;
    class B,C,D stage;
    class E symptom;
    class F fix;

This directionality is the bridge from the four-dimensional theory to the post-build machinery. The dimensions forecast where loss is likely to arise. FCTAF locates the stage where it arose, the edge through which it propagated, and the control that should have caught it.

4. The Capability / Inspectability Tradeoff

AI systems gain capability by integrating more context, longer reasoning, dynamic tool use, and adaptive loops. The same integration makes their internal path harder to inspect. Decomposing the work into explicit stages, contracts, and checks improves inspectability, but adds latency, cost, and coordination overhead—and can reduce capability.

flowchart LR
    A["Capability end<br/>integrated reasoning<br/>dynamic tool use<br/>fewer boundaries"]
    B["Inspectability end<br/>decomposed stages<br/>explicit contracts<br/>more attestation"]

    A <-->|"architecture chooses a position"| B

    classDef cap fill:#FCA5A5,stroke:#B91C1C,color:#111111;
    classDef ins fill:#A7F3D0,stroke:#047857,color:#111111;

    class A cap;
    class B ins;

There is no universally correct position. Depth and friction create pressure toward capability because the system must search, integrate, and adapt. Consequence creates pressure toward inspectability because the path to an answer must be checked and defended. Variance determines where human judgement belongs because the system may need a person to define what a good answer means before it can optimize for one.

The tradeoff is therefore an architectural consequence of the problem profile, not a preference for simpler or more sophisticated systems. The aim is not maximum inspectability. It is enough inspectability for the consequences the system is allowed to create.

5. FCTAF: The Five-Stage Operating Model

The four dimensions describe the problem. FCTAF describes the system built to address it. It decomposes the work into five stages so that a team can locate failures, expose intermediate state, and decide where verification belongs.

flowchart LR
    S1["I. Intent Framing<br/>Define goal and constraints<br/>Metric: Legibility"]
    S2["II. Source Mapping<br/>Select knowledge universe<br/>Metric: Identifiability"]
    S3["III. Information Retrieval<br/>Extract relevant evidence<br/>Metric: Completeness"]
    S4["IV. Logical Synthesis<br/>Reason over evidence<br/>Metric: Faithfulness"]
    S5["V. Transduction<br/>Shape result for use<br/>Metric: Conformance"]
    O["Actionable output<br/>ready for its consumer"]

    S1 -->|"clarified intent"| S2
    S2 -->|"source plan"| S3
    S3 -->|"evidence objects"| S4
    S4 -->|"cited conclusion"| S5
    S5 --> O

    classDef stage fill:#D8B4FE,stroke:#6B21A8,color:#111111;
    classDef output fill:#A7F3D0,stroke:#047857,color:#111111;

    class S1,S2,S3,S4,S5 stage;
    class O output;

Stage Table

Stage Objective Primary Failure Common Symptom
I. Intent Framing Define the goal, scope, and constraints Scope underspecification A polished answer to the wrong question
II. Source Mapping Select the relevant knowledge sources and tools Source-universe mis-selection Missing evidence that retrieval never had access to
III. Information Retrieval Extract the relevant evidence Incomplete or irrelevant evidence Sound reasoning over the wrong evidence set
IV. Logical Synthesis Reach a conclusion supported by the evidence Unsupported inference A plausible but ungrounded conclusion
V. Transduction Put the conclusion into an actionable form Output-contract violation A correct result the consumer cannot use

Stages as Governance Contracts

In capability-end systems, stages are descriptive — they label operations the system performs, but the operations may collapse into a single agentic loop with no inspectable intermediate state. The framework remains useful as a forensic decomposition: failures can be attributed post hoc to stage-level causes even when the system did not expose stage-level structure.

In inspectability-end systems, stages are prescriptive — they are the contract the system must expose for human and institutional oversight. The stages are not what the system does internally; they are what the system owes its operators in terms of inspectability. Each stage transition becomes an attestation surface (see Section 6). The stages are imposed by the requirements, not given by the architecture.

This is the framework’s central insight about agentic systems: the boundary between interface stages (I and V, externally observable) and internal stages (II–IV, model-resident) is not a fact about AI; it is a design choice. A system in an inspectability-end domain that internalises Stages II–IV inside an agentic loop has chosen to make them unobservable. A system that exposes them as inspectable artefacts has chosen to make them observable. The choice is dictated by the domain’s consequence profile, not by the technology.

The Externalisation Cost

Externalising an internal stage is not free. It costs latency (each attestation surface adds delay), capability (decomposition often reduces what the system can do compared with end-to-end integration), design complexity (each surface is a new contract to maintain), and operational overhead (each blocking attestation is a potential point of failure for the system as a whole).

The framework does not advocate maximum externalisation. It advocates deliberate externalisation — making the position on the capability/inspectability curve a conscious choice driven by the suitability assessment, with the costs accepted explicitly. A team that externalises every stage in a low-stakes context is over-engineering. A team that internalises every stage in a catastrophic-consequence context is building a system that cannot be defended.

6. Nodes, Edges, and Attestation

FCTAF stages are performed by Nodes connected through Edges. Attestation surfaces sit at the transitions where evidence, approval, or accountability must survive. These three choices turn a conceptual pipeline into an inspectable operating system.

Node Types

The coarse partition is AI / Code / Human. For triage and design, a finer partition of AI Nodes is necessary:

AI Node Subtype Purpose Failure Profile
Classifier Assign input to a label from a closed set Confident wrong labels at distribution edges
Retriever Surface evidence from a corpus Misses documents the schema cannot represent
Synthesiser Combine evidence into an answer Confabulates over evidence gaps
Agent Plan and execute multi-step actions with tools Compounds errors across steps; hard to diagnose
Verifier Check another node’s output against a contract Rubber-stamps when contracts are weak

Architectural shape decisions should specify Node subtype, not just “AI Node.” A problem that fits a Classifier may be misjudged as fitting a Synthesiser, with very different reliability and verification implications. The Agent subtype is the most capability-end choice and the most expensive to wrap in attestation; choose it deliberately.

Edge Types

Edges between stages enforce contracts on what passes between them.

Edge Type Contract When to Use
Deterministic Output of upstream stage must conform to a fixed schema High-consequence transitions; verifier insertion points; where catastrophic consequences demand a hard boundary
Dynamic Output is free-form; downstream stage must interpret Where ambiguity is irreducible and adds value; inappropriate where an ambiguous handoff could produce catastrophic consequences
Feedback Downstream stage can request upstream re-execution Agentic loops; iterative refinement

In inspectability-end systems, Edge selection is the primary mechanism by which a team converts an opaque agentic system into an auditable one. Default to Deterministic Edges and accept Dynamic Edges only where the suitability assessment justifies them.

Attestation Surfaces

In governance-contract systems, every stage transition is potentially an attestation surface — a point where the upstream output must be inspected and approved (by a human, an automated verifier, or a logged audit) before propagating to the downstream stage.

The framework recognises three attestation types, ordered by strength:

Attestation Type Mechanism Latency Reliability When to Use
Logged-Audit Output is recorded for retrospective inspection; non-blocking None Reconstructive only — cannot prevent failure, only investigate it Low-consequence systems; sampling and retrospective review
Automated-Verifier A deterministic checker validates upstream output against a contract; blocks on failure Low Reliable for what the contract specifies; misses what it doesn’t Asymmetric-consequence systems; high-volume transitions where human review is impractical
Human-Attested A person reviews and signs off; blocks on failure High Highest — but slow and rate-limited Catastrophic-consequence systems; irreversible transitions; where accountability requires named human responsibility

High-consequence systems often layer them: a blocking automated verifier at every transition, plus a non-blocking logged audit of every input/output, plus sampled human review of consequential transitions. The combination provides defence-in-depth without the latency cost of human-attesting everything.

Agentic Architectures

Agentic systems expand synthesis depth by planning, using tools, and revising their own intermediate work. That increases capability, but it also creates more states, more dynamic handoffs, and more opportunities for an early mistake to compound.

  • At D∞ with C-Symmetric, a capability-end agent may be reasonable because errors are recoverable.
  • At C-Asymmetric, expose plans, tool calls, evidence, and intermediate outputs. Wrap the agent in logging and verification rather than treating it as a black box.
  • At C-Catastrophic, prefer a shallower and more decomposed architecture. If an agent is still necessary, consequential branches require blocking verification and explicit human authority.

The question is not whether an agent can perform the task. It is whether the organization can inspect, constrain, and stand behind the path by which it acts.

7. Diagnostic Protocol

Once a system is built, diagnose it from the observed symptom back toward the earliest unsupported transition.

  1. Locate the symptomatic stage. At which FCTAF stage does the failure become visible?
  2. Separate symptom from cause. Could the incoming evidence or decision from the previous stage already have been wrong?
  3. Check observability. Is the failed operation exposed as an inspectable artefact? If not, tracing or intermediate-output capture is the next engineering task.
  4. Inspect the node assignment. Is the node type appropriate for the stage and for the problem’s depth, friction, and variance?
  5. Inspect the incoming edge. Did a dynamic handoff allow malformed or incomplete information to pass? Could a deterministic contract have rejected it?
  6. Inspect attestation. Was a checkpoint required by the consequence profile? Did it not exist, fail to run, or validate too weak a contract?
  7. Check the original problem profile. Has the system been asked to handle deeper synthesis, messier evidence, wider intent, or greater consequences than it was designed for?

When the Failure Is Model-Internal

Sometimes intent, source selection, retrieval, and output contracts are all sound, but the model still produces an unsupported conclusion. Treat this as a Stage IV model-internal failure. The remedies are local to synthesis: stronger grounding, a verifier node, a more capable model, narrower scope, or a deterministic alternative for the relevant operation. Do not redesign upstream stages without evidence that they contributed to the failure.

Consider a system answering: “Can we terminate the Acme vendor agreement without penalty?”

Step 1: Characterise the Problem

Profile: (D3, F-Mid, V-Bounded, C-Asymmetric).

  • D3: the answer requires gathering clauses from the master agreement, amendments, and statements of work, then combining them.
  • F-Mid: the contracts are PDFs with mixed scanning quality and inconsistent clause numbering.
  • V-Bounded: “without penalty” has several valid interpretations; the user’s intent must disambiguate them.
  • C-Asymmetric: a wrong answer creates legal and financial exposure, but human review can catch it before action.

The profile predicts pressure at three places: intent framing, evidence completeness, and synthesis faithfulness.

Step 2: Choose an Architectural Position

The system belongs near the inspectability side of the tradeoff. Stages II, III, and IV should produce inspectable artefacts. The handoffs from source selection to retrieval and from retrieval to synthesis should enforce explicit contracts. The capability gained from a fully autonomous agent does not justify hiding the evidence path.

Step 3: Build the Operating Model

  • Stage I: Human and AI clarify whether the question concerns convenience, breach, fees, minimum-spend commitments, or another termination condition.
  • Stage II: A retriever selects the master agreement, amendments, and statement-of-work register. The chosen source universe is logged.
  • Stage III: Hybrid retrieval produces evidence objects. An automated check confirms that every active agreement type was searched.
  • Stage IV: A synthesiser produces the conclusion; a verifier checks every material claim against the evidence.
  • Stage V: A deterministic output contract requires citations, uncertainty, a risk rating, and recommended next steps.

Step 4: Diagnose a Failure

Suppose the system concludes: “You can terminate without penalty.”

The visible error is at Stage IV, but the primary failure occurred earlier. Stage II omitted the statement-of-work register. Stage III therefore never retrieved a minimum-spend clause in SOW #4. Stage IV reasoned over an incomplete evidence set and produced an uncaveated conclusion. Stage V then presented it without the risk information needed by the consumer.

flowchart TD
    S2["Stage II<br/>SOW register omitted"]
    S3["Stage III<br/>minimum-spend clause missed"]
    S4["Stage IV<br/>terminate without penalty"]
    S5["Stage V<br/>no liability caveat"]
    O["Observed risk<br/>incomplete legal advice"]
    C["Correct answer<br/>no MSA fee, possible SOW liability"]

    S2 -->|"source universe incomplete"| S3
    S3 -->|"evidence gap"| S4
    S4 -->|"uncaveated conclusion"| S5
    S5 --> O
    S3 -.->|"if SOW #4 is retrieved"| C

    classDef stage fill:#D8B4FE,stroke:#6B21A8,color:#111111;
    classDef failure fill:#FCA5A5,stroke:#B91C1C,color:#111111;
    classDef correction fill:#A7F3D0,stroke:#047857,color:#111111;

    class S2,S3,S4,S5 stage;
    class O failure;
    class C correction;

The fix is not a better final prompt. It is a source-completeness contract at the Stage II→III edge, followed by a verifier that refuses to synthesize when required agreement types are absent. The four-dimensional profile predicts where controls are needed; the post-build machinery identifies which control failed.

9. Validation Boundaries

This framework combines established ideas with new synthesis. Those claims should not be treated as equally mature.

Claim Status Notes
Five-stage task decomposition Grounded with novel boundaries Consistent with cognitive-task analysis and levels-of-automation literature
Synthesis Depth Grounded Multi-step reasoning difficulty is well documented; the D∞ category is a framework convention
Epistemic Friction Theoretically grounded Draws from information-foraging and information-retrieval practice
Intent Variance Theoretically grounded Draws from HCI and task-design practice
Consequence Asymmetry Novel synthesis Central to deciding how much verification an AI system requires
Interaction effects Speculative Plausible and operationally useful, but not yet empirically calibrated
Capability / Inspectability tradeoff Novel synthesis Supported by engineering experience, not yet a formally validated curve
Node and edge taxonomies Partially grounded Draw from workflow, control, and safety-engineering patterns
Attestation surfaces Partially grounded Established mechanisms applied here as a unified AI-system design concept
Loss-propagation model Theoretically grounded The direction of propagation is plausible; production studies are needed
Stage I–II failures dominate production Speculative A useful hypothesis, not an established empirical result

The framework would become stronger through retrospective classification of failed AI projects, controlled comparisons of alternative node and edge assignments, empirical calibration of the four interaction effects, and translation into established assurance-case methods. Until then, it should be used as a disciplined way to ask questions—not as a scoring system that manufactures certainty.

10. How to Use the Framework

The theory and the machinery serve different moments in a system’s life.

Before Building

  1. Write the four-dimensional profile. Do this before selecting a model or architecture.
  2. Identify the dominant interactions. Mark where ambiguity, evidence quality, reasoning depth, and consequence amplify one another.
  3. Choose a suitability verdict.
    • Yes: the task is bounded, evidence is tractable, and mistakes are recoverable.
    • Yes, with conditions: AI is useful only with named controls, human decisions, or scope boundaries.
    • No, or not yet: the system cannot make the task dependable at an acceptable cost. Improve the data, narrow the task, automate deterministically, or retain a human process.
  4. Choose a position on the capability/inspectability tradeoff. Decide which stages may remain integrated and which must produce inspectable artefacts.
  5. Forecast tension. Depth points toward synthesis risk; friction toward retrieval risk; variance toward intent risk; consequence increases the required strength of every control.

Locating the Practical Phase Shift

The “phase shift” is not an extra theoretical dimension. It is a practical decision about the form of trust the system requires.

Use three questions:

  1. Must individual decisions be defensible, or is aggregate performance enough?
  2. Will a failure face adversarial reconstruction by a regulator, court, customer, investigator, or internal review body?
  3. Can the decision be reversed before harm occurs?

Strong “individual, adversarial, irreversible” answers move the architecture toward inspectability: explicit stages, retained evidence, deterministic contracts, and blocking attestation. Weak answers permit more integration and output-level monitoring.

A small warning about drift: systems tend to move toward capability after launch because integration improves speed and demos better. Revisit the target position when models, workflows, or consequences change. This is an architecture-review check, not a separate pillar of the theory.

While Building

Translate the profile into FCTAF:

  • Assign a Node type to every stage.
  • Define what each Edge is allowed to carry.
  • Make high-consequence transitions deterministic where possible.
  • Add attestation surfaces where an unchecked error would be expensive.
  • Preserve enough intermediate state to distinguish a primary failure from its downstream symptom.

After Deployment

When a failure occurs, begin with the diagnostic protocol. Repair the earliest unsupported transition, not merely the stage where the error became visible. Then compare the incident with the original four-dimensional profile. If the live system is handling a harder problem than the one that was characterised, update the profile and reconsider the architecture.

That is the complete loop: characterise the problem, choose the tradeoff, build the operating model, observe the system, and revise the earliest assumption that no longer holds.