In ordinary technical conversation, a cause is usually the event that pushes another event into happening. A stale index causes an old document to be retrieved. A malformed request causes a parser to fail. Modern interventionist accounts sharpen this idea by asking what would change if we altered one variable while controlling others. That is indispensable for AI engineering.

Aristotle’s term aitia is wider. It names what is responsible for an adequate explanation. In Physics II.3, the same artefact can be explained by the material from which it is made, the form that makes the material this kind of thing, the source or process that brings it about, and the end for the sake of which it is produced.¹ These are conventionally called material, formal, efficient and final causes. They are not four stages in a pipeline. They are four answers to four different questions.

For an AI system, a first pass looks like this. Its material cause is whatever is being organised at the chosen grain: chips, numerical arrays, model artefacts, retrieved records, sensors, queues or human work. Its formal cause is the organisation that makes those materials this particular system: architecture, topology, prompts, memory boundaries, tool schemas, thresholds and authority rules. Its efficient cause is the process that produced and continues to maintain it: data collection, training, fine-tuning, integration, release, operation and repair. Its final cause is the end that selected the arrangement and supplies its standard of success: summarise notes, rank cases, reduce waiting time, preserve safety, sell subscriptions or automate a decision.

This mapping is useful only if we resist two temptations. The first is to assign every component a permanent label. The same checkpoint can be material for an application engineer, formal organisation for an inference researcher, and an effect of a training process for an auditor. The causal role depends on the question. The second temptation is to treat “final cause” as proof that the machine has an inner purpose. An end can organise production without being represented, desired or experienced by the artefact.

flowchart TD
  A["The Friday discharge incident"] --> B["The same checkpoint, two<br/>different systems"]
  B --> C["What is made, what makes it<br/>one, what brings it about,<br/>what it is for"]
  C --> D["Potential becomes actual<br/>inside a configured system"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#D95545,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Matter changes with the grain of the question

A processor engineer asks why latency spiked and points to memory bandwidth, numerical precision and thermal throttling. A model engineer asks why a representation shifted and points to parameter tensors, tokenisation and activations. An application engineer asks why a wrong record entered the prompt and points to an index, a document parser and an access-control filter. An operations lead asks why the recommendation became an action and points to queues, interfaces, people and credentials.

Which of these is the material cause? Potentially all of them, but not at once. Matter is the substrate that receives organisation relative to the chosen system boundary. At one grain, the checkpoint is the form imposed on numerical storage. At a wider grain, that same checkpoint is one material component organised by an agent runtime. At a wider grain still, the runtime is a component in a clinical workflow.

This relativity is not a licence for vagueness. It is a demand to declare the boundary. Without that declaration, teams slide between “the model”, “the assistant”, “the product” and “the organisation” as though they were interchangeable. The slide hides both responsibility and intervention points.

Form is organisation, not visual shape

In a simple artefact, form can look like geometry. In a machine-learning system, form is closer to organised constraint. It includes architecture, data flow, state transitions, control boundaries and the relations that make components operate as one system. Two deployments can contain the same checkpoint, documents and tools yet differ formally because one routes every action through a typed approval contract while the other lets generated text become an API call.

Formal cause therefore answers more than “which neural network architecture?” The transformer may be the relevant form when we ask how information is transformed within a model. It is not the whole form when we ask how a recommendation becomes an effect. At that grain, the relevant form includes identity, permitted context, proposal, authority, typed action, evidence receipt, readback and recovery.

Efficient cause includes the reproducible art of making

The efficient cause is often reduced to “who built it”. Aristotle’s own artefact examples are subtler. In the production of a statue, the relevant source of change can be the craft or organised knowledge of bronze-casting, rather than only the individual artisan.⁵ For AI, this points us towards the reproducible process: how data were collected, filtered and labelled; which objective and optimiser were used; how the checkpoint was adapted; which evaluations governed selection; how the service was integrated; and how updates are approved.

This history can matter in two distinct ways. It can leave behavioural traces, as when a training population produces systematic blind spots. It can also change what claims and uses are permissible even when current behaviour appears identical. Model cards, datasheets and end-to-end audit frameworks exist partly because performance alone does not expose intended use, provenance or lifecycle decisions.⁷⁸⁹

Final cause is the end that organises selection

Final cause is the most useful and most easily abused category. It does not mean that a model secretly wants an outcome. It asks what the system is for, which end explains why this data, architecture, threshold, interface and workflow were selected rather than alternatives. In engineered systems, ends can operate through designers, procurement criteria, objective functions, operating metrics, institutional incentives and user appropriation.

A single “intended use” field is rarely enough. The declared purpose may be clinical assistance. The optimisation target may be acceptance rate. The authorised action may be automatic discharge. The local incentive may be shorter queue time. Users may appropriate the tool as a substitute for review. These ends can point in different directions.

AI discourse is saturated with capability claims: the model can plan, use tools, write code, persuade, diagnose or act autonomously. Some of these claims are well supported within specified tests. The problem begins when a conditional result is turned into an unqualified power.

Aristotle’s distinction between potentiality and actuality helps because it forces us to ask what makes a capacity real. In Metaphysics IX, he explains the distinction through examples such as being capable of building and actually building, or possessing sight and exercising it.² The relation is analogical, not a single modern variable called “activation”. A potentiality is tied to a kind of actuality and to conditions under which it can be realised.

For AI, a capability claim should therefore be indexed to enabling conditions. A language model may generate a plausible tool-call string. It does not thereby have the actuality of changing a bank account. That actuality requires a tool implementation, a credential, an authority grant, a valid world state, an action contract, an execution path and a verified effect.

The De Anima boundary

Potentiality and actuality become especially tempting when readers encounter De Anima II.1. Aristotle describes soul as the first actuality of a natural organised body that has life potentially within it.³ The comparison with an axe and its power to cut can make it seem natural to call software the soul of hardware.

That move should be resisted. Aristotle is explaining living natural bodies, not supplying a generic slogan that every functional organisation is a soul. In Physics II.1, natural things are distinguished by an internal principle of change and rest, whereas artefacts depend on craft and external maintenance.¹ Whether artefacts count as substances in Aristotle’s ontology remains contested in scholarship. None of this warrants declaring a model architecture to be the soul of a machine.

The disciplined comparison is narrower. Source structure: matter organised by a form, with potentialities made actual through characteristic operations. Target structure: a configured AI system whose components support conditional capacities. Preserved relation: organisation constrains which operations the substrate can realise. Break point: Aristotle’s definition concerns natural living bodies and their immanent life-functions. Design insight: capability claims must state the body of enabling conditions. The comparison generates an audit question, not an ontological equivalence.

A causal profile and an intervention signature

We can now compress the argument into a practical object. For any consequential claim, record a causal explanation profile:

For each role, construct a matched counterfactual that changes it while preserving the others as far as engineering permits. Measure at least two deltas: a behavioural delta and a governance delta. The first captures changes in outputs, errors, latency or effects. The second captures changes in authority, provenance, reversibility, warranted use or accountability. A zero behavioural delta does not imply a zero governance delta, as the history-erasure case showed.

stateDiagram-v2
  [*] --> Claim
  state "Change authority, preserve the<br/>output" as Claim
  state "Do not answer a system<br/>question with a token<br/>explanation" as Test
  state "Why the model attracts<br/>explanations that belong to<br/>the system" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

The four causes become useful only when they alter engineering practice. A label-filled diagram is not an explanation. The operational contribution of this paper is a four-cause intervention audit: a small protocol that turns each explanatory role into a counterfactual test and a decision receipt.

The audit protocol

1. State the exact why-question. “Why did the model say this?” and “Why did the system execute this?” are different investigations.
2. Draw the candidate boundary. Include every component whose change could alter the property under decision. Mark external dependencies explicitly.
3. Write one evidence-backed statement for each cause. Name substrate, organisation, production history and operative end. Record missing evidence rather than filling it with inference.
4. Design one matched intervention per cause. Replace substrate, rewire form, vary production history or change the evaluation end while preserving the other roles as far as possible.
5. Measure behavioural and governance deltas. Outputs, latency and error are not enough. Check authority, reversibility, provenance, permitted use and recovery.
6. Repair the dominant sensitivity, then test interactions. One-at-a-time tests locate handles. Pairwise tests reveal thresholds and feedback that make small changes consequential.

Choose the unit of repair, rather than only the unit of measurement

Modern evaluation often begins with a measurable unit because measurement needs repeatability. A benchmark fixes a checkpoint, input format and scoring rule. This is good experimental practice. Trouble begins when the measured unit is assumed to be the repair unit. A benchmark can tell us that a checkpoint fails a task. It cannot by itself tell us whether a deployed incident should be repaired in the checkpoint, the context pipeline, the action boundary, the operating objective or several of them.

The audit therefore records two boundaries. The measurement boundary contains what the test directly manipulates and observes. The decision boundary contains what must remain trustworthy for the real consequence to be acceptable. When the two differ, transfer becomes an argument rather than an assumption.

For example, an evaluation may measure whether a model cites a supplied document. The decision boundary also includes whether the document was entitled for this user, valid at the cutoff, complete enough for the decision and correctly linked to the executed action. The model can pass its measured task while the governed system fails. Conversely, a model can appear weak in isolation yet be acceptable inside a form that abstains, retrieves independently and requires human authority.

This distinction changes review design. Teams should not ask only, “Did performance improve?” They should ask, “Did the repaired component lie on the causal path to the governed outcome, and did readback confirm the effect?”

The synthetic intervention lab

The Python programme below creates a small maintenance world, trains a logistic classifier and then changes one causal role at a time. It uses only the standard library. The dataset is synthetic and deterministic under a fixed seed.

What it tests: whether behaviour and expected decision loss remain invariant when matter, form, efficient history or final purpose changes. Assumptions: each deployment can be represented by a small set of parameters; one-at-a-time changes are approximately isolable; the cost function faithfully represents the chosen purpose. Positive result: a changed metric identifies a sensitivity that a model-only account would miss. Negative result: invariance supports irrelevance only within the tested range. It cannot establish: real-world safety, metaphysical truth, consciousness or the adequacy of the cost model.

#!/usr/bin/env python3
"""Synthetic one-cause-at-a-time audit for an AI maintenance classifier.

No third-party packages are required. The simulation is illustrative, not evidence
about any real deployment.
"""
from __future__ import annotations

from dataclasses import dataclass, replace
from math import exp
from random import Random
from typing import Iterable, Sequence


@dataclass(frozen=True)
class Deployment:
    # Material role: sensor precision and observation delay.
    sensor_step: float = 0.01
    stale_steps: int = 0
    # Formal role: decision boundary and action contract.
    threshold: float = 0.62
    authority: str = "advise"  # "advise" or "shutdown"
    # Efficient role: training population and optimisation history.
    training_shift: float = 0.0
    training_label_flip: float = 0.0
    # Final role: which consequence the system is selected to minimise.
    purpose: str = "queue"  # "queue" or "avoid-catastrophe"


@dataclass(frozen=True)
class Metrics:
    accuracy: float
    recall: float
    false_positive_rate: float
    expected_loss: float
    actions: int


def sigmoid(z: float) -> float:
    if z >= 0:
        return 1.0 / (1.0 + exp(-z))
    ez = exp(z)
    return ez / (1.0 + ez)


def make_events(
    n: int, seed: int, shift: float = 0.0, label_flip: float = 0.0
) -> list[tuple[float, float, int]]:
    """Create synthetic vibration, temperature and true-failure triples."""
    rng = Random(seed)
    events: list[tuple[float, float, int]] = []
    for _ in range(n):
        vibration = rng.gauss(0.0 + shift, 1.0)
        temperature = rng.gauss(0.0 + 0.4 * shift, 1.0)
        latent = 1.25 * vibration + 0.95 * temperature - 0.35
        probability = sigmoid(latent)
        failure = 1 if rng.random() < probability else 0
        if rng.random() < label_flip:
            failure = 1 - failure
        events.append((vibration, temperature, failure))
    return events


def train(events: Sequence[tuple[float, float, int]], steps: int = 350, lr: float = 0.08) -> tuple[float, float, float]:
    """Fit a tiny logistic classifier using batch gradient descent."""
    w_vib = 0.0
    w_temp = 0.0
    bias = 0.0
    n = float(len(events))
    for _ in range(steps):
        g_vib = g_temp = g_bias = 0.0
        for vibration, temperature, target in events:
            pred = sigmoid(w_vib * vibration + w_temp * temperature + bias)
            err = pred - target
            g_vib += err * vibration
            g_temp += err * temperature
            g_bias += err
        w_vib -= lr * g_vib / n
        w_temp -= lr * g_temp / n
        bias -= lr * g_bias / n
    return w_vib, w_temp, bias


def quantise(value: float, step: float) -> float:
    return round(value / step) * step


def evaluate(deployment: Deployment, n: int = 1200, seed: int = 41) -> Metrics:
    # Efficient cause intervention: change the training population.
    train_events = make_events(
        900, seed=seed, shift=deployment.training_shift,
        label_flip=deployment.training_label_flip
    )
    weights = train(train_events)

    # The evaluation world is held constant across deployments.
    events = make_events(n, seed=seed + 1, shift=0.15)
    if deployment.stale_steps:
        delayed = [(0.0, 0.0, events[0][2])] * deployment.stale_steps + events[:-deployment.stale_steps]
    else:
        delayed = events

    tp = tn = fp = fn = actions = 0
    loss = 0.0
    for current, observed in zip(events, delayed):
        _, _, truth = current
        vibration = quantise(observed[0], deployment.sensor_step)
        temperature = quantise(observed[1], deployment.sensor_step)
        score = sigmoid(weights[0] * vibration + weights[1] * temperature + weights[2])
        predicted = 1 if score >= deployment.threshold else 0
        actions += predicted

        if predicted and truth:
            tp += 1
        elif predicted and not truth:
            fp += 1
        elif not predicted and truth:
            fn += 1
        else:
            tn += 1

        # Final cause intervention: the same confusion event has different cost.
        false_positive = int(predicted == 1 and truth == 0)
        false_negative = int(predicted == 0 and truth == 1)
        if deployment.purpose == "queue":
            loss += 1.0 * false_positive + 3.0 * false_negative
        elif deployment.purpose == "avoid-catastrophe":
            loss += 4.0 * false_positive + 18.0 * false_negative
        else:
            raise ValueError(f"Unknown purpose: {deployment.purpose}")

        # Formal authority changes the consequence of a positive prediction.
        if deployment.authority == "shutdown" and predicted and not truth:
            loss += 6.0

    accuracy = (tp + tn) / n
    recall = tp / (tp + fn) if tp + fn else 0.0
    fpr = fp / (fp + tn) if fp + tn else 0.0
    return Metrics(accuracy, recall, fpr, loss / n, actions)


def variants() -> Iterable[tuple[str, Deployment]]:
    baseline = Deployment()
    yield "baseline", baseline
    yield "material: coarse, delayed sensors", replace(baseline, sensor_step=0.50, stale_steps=2)
    yield "formal: lower threshold, shutdown authority", replace(baseline, threshold=0.48, authority="shutdown")
    yield "efficient: corrupted training labels", replace(baseline, training_label_flip=0.28)
    yield "final: catastrophe-avoidance purpose", replace(baseline, purpose="avoid-catastrophe")


def main() -> None:
    print("variant,accuracy,recall,false_positive_rate,expected_loss,actions")
    for name, deployment in variants():
        m = evaluate(deployment)
        print(
            f"{name},{m.accuracy:.3f},{m.recall:.3f},"
            f"{m.false_positive_rate:.3f},{m.expected_loss:.3f},{m.actions}"
        )


if __name__ == "__main__":
    main()

How to read a negative intervention

Suppose replacing the substrate changes nothing, rewiring authority changes nothing, replaying a different training lineage changes nothing and changing the utility function changes nothing. The tempting conclusion is that the system is causally understood. That conclusion is too strong.

A negative result is local to the intervention range, outcome measure and boundary. The substrate replacement may not have crossed a precision-sensitive region. The formal change may have left a hidden route intact. The training replay may share the same contaminated source. The final-cause test may use two cost functions that rank every observed case identically. Negative tests lower particular explanations; they do not certify universal invariance.

The audit receipt should therefore state the tested contrast and its resolution. “No material sensitivity detected” is incomplete. “No change in action rate or expected loss when sensor precision moved from 0.01 to 0.05 under threshold 0.62” is useful. It tells the next investigator where the evidence stops.

The strongest alternative explanation

A serious objection is that none of this requires Aristotle. Systems engineering already distinguishes hardware, software, data, process, people and purpose. Sociotechnical analysis already studies institutions and incentives. Lifecycle governance already asks about intended use, testing and monitoring. NIST’s AI Risk Management Framework explicitly addresses design, development, use and evaluation of AI products, services and systems.¹⁰ Foundation-model research likewise places models in wider ecosystems of data, adaptation and applications.¹¹

The objection is partly correct. The four causes are not a replacement vocabulary for mature engineering disciplines. Their value is more specific. They connect four explanatory failures that teams often separate: mistaking a component for the system, mistaking behaviour for organisation, mistaking present performance for production warrant, and mistaking a metric for the end. They also force each category into a counterfactual test.

The framework would be weakened if ordinary lifecycle checklists produced the same diagnostic accuracy and repair quality with less ambiguity. It would be strengthened if four-cause profiles predicted incident recurrence, evidence-transfer failures or release defects that model-centric reviews missed. This is an open research hypothesis, not an established empirical result.