Skip to content

execution-substrates.md

Latest commit

 

History

History
184 lines (144 loc) · 8.21 KB

execution-substrates.md

File metadata and controls

184 lines (144 loc) · 8.21 KB

Execution Substrates and the Authority Layer

AWF is not an execution platform. AWF does not spawn agents, route subagents, generate code, run tests or capture tool-call telemetry. Those concerns belong to execution substrates. AWF is the authority layer above them.

This document explains the distinction, why it matters and how the three layers fit together.

The two questions

Execution and authority answer different questions. Conflating them collapses important structure.

Execution substrates answer: "Can the agent do the work?"

AWF answers: "Has the agent earned authority to do the work?"

A substrate can be perfectly capable of running a database migration. Capability does not imply authority. AWF's job is to decide whether the trust subject mapped to that substrate has accumulated enough D1 to D4 evidence on that task class to be authorized. If not, AWF either rejects the work, escalates for human approval or recommends a different substrate that has earned the authority.

These are different layers of the system. They run as separate code and produce different artifacts. Capability is observed at execution time. Authority is consulted at authorization time, which happens before execution begins.

The three-layer stack

┌─────────────────────────────────────────────────────────────┐
│  Authority layer: AWF / TrustPlane                          │
│  Decides who is allowed to do what, under which controls,   │
│  and records the decision in the audit log.                 │
└─────────────────────────────────────────────────────────────┘
                            ▲
                            │ authorizes
                            ▼
┌─────────────────────────────────────────────────────────────┐
│  Execution substrate layer                                  │
│  Maggy, Claude Code, Codex, Cursor, Devin, LangGraph.       │
│  Drives the work. Spawns agents, routes subagents, captures │
│  events. Answers "can this be done."                        │
└─────────────────────────────────────────────────────────────┘
                            ▲
                            │ executes via
                            ▼
┌─────────────────────────────────────────────────────────────┐
│  Runtime / model layer                                      │
│  Claude, GPT, Gemini, Qwen.                                 │
│  The underlying LLM that produces tokens.                   │
└─────────────────────────────────────────────────────────────┘

Each layer is independent. AWF is model-agnostic and substrate-agnostic. A substrate can swap its underlying model without AWF noticing. AWF authorizes the substrate, not the model.

What an execution substrate is

An execution substrate is any system that takes a task description and drives it to completion through one or more agents. The shape varies. Some are CLIs (Claude Code, Codex, Aider). Some are IDE integrations (Cursor, Continue). Some are end-to-end engineering platforms (Devin, Maggy). Some are agent runtime frameworks (LangGraph, AutoGen).

What they have in common:

  • They spawn the agents that produce the artifact.
  • They are the source of tool-call telemetry.
  • They define the local execution model: how subagents are dispatched, how state is tracked, how the session terminates.
  • They can be observed and authorized over by an external authority layer.

What they are not:

  • They are not the authority over their own agents at scale. Each substrate has its own internal policy surface (Claude Code's permission modes, Cursor's safety settings, Devin's approval rules). None of them produce a cross-substrate authorization decision keyed on what this trust subject has earned across all the substrates it has worked through.

That last gap is the one AWF fills.

What AWF is

AWF is the authority layer above substrates. For every task, it decides whether the candidate runtime has earned the right to do the work. The artifacts:

  • Task Risk Profile. A per-task score on five dimensions, summing to a composite that maps to a risk lane.
  • Trust Capability Profile. A persisted record per (trust_subject_id, task_class, runtime_provider) of earned authority, evidence strength and session count.
  • Runtime Authorization Decision. The per-task output. AUTHORIZED, SUPERVISED (authorized with controls) or BLOCKED, with an audit event recording why.

AWF does not generate the code. The substrate does. AWF decides whether the substrate is allowed to. The substrate then executes (or does not), and the result feeds back into the trust capability profile that gates the next decision.

The shape: authorize, execute, observe, update authority. Every loop moves the trust signal forward.

Why this layering matters

For buyers. Adopting Maggy, Cursor or Devin does not displace AWF. Those are the execution substrates AWF was designed to authorize over. A buyer who has standardised on Cursor for engineering work still needs an answer to "which trust subject is allowed to invoke Cursor on this task class and under which controls". AWF is the layer that answers it.

For builders. A new substrate enters the market every quarter. AWF absorbs that change rate through an adapter pattern. The substrate's events get translated into AWF's canonical audit event shape, the substrate's identity becomes a trust_subject_id and the substrate gets a row per task class in the trust capability profile. The authority layer does not need to know the substrate's internal model of agents.

For regulators. Per-event user_id carried on every audit event answers the question regulators actually ask: which human authorized the agent to do this? Substrates produce the events. The authority layer enforces that the events are correctly shaped, joined and retained.

Layer boundaries in practice

A few rules that keep the boundaries clean.

AWF does not call substrate-internal APIs to make decisions. The authority decision is made on AWF's own state: the trust_capability_profile table, the task_risk_profile for the request and policy config. The substrate's internal trust signals, if any, are not consulted at authorization time. They may feed in later via Process Intelligence (Sprint 4), but only as one input among many.

Substrates do not write to trust_scores directly. A substrate emits events. The Eval/Telemetry Service is the only writer to canonical trust tables. This rule is the same one AWF applies to its own internal components.

The runtime/model layer is not addressable. AWF does not produce authorizations against Claude or GPT directly. It produces authorizations against the substrate that runs the model. If a substrate switches its underlying model, the trust history travels with the substrate, not with the model.

Related

  • docs/architecture/three-layer-stack.md: a different three-layer lens, oriented around governance concerns (runtime governance, scheduled automation, behavioural accountability). Complementary to the authority-of-substrate stack described here.
  • docs/architecture/four-plane-model.md: the four-plane operating model AWF runs inside (workforce, autonomy, control, automation).
  • docs/task-risk-profile.md: the per-task input to authorization.
  • docs/d1-d4-scoring.md: the per-session evidence that updates trust tiers.
  • docs/competitive-landscape.md: where individual substrates sit relative to AWF.
  • AWF Sprint Plan v4.4.2, Strategic Refinement and Three-Layer Stack.