DEV Community: Tim Poschel

Why SREL Matters for Agent Governance

Tim Poschel — Mon, 10 Aug 2026 15:02:20 +0000

Most conversations about AI agents focus on capability: what the agent can do, which tools it calls, how it reasons. Far less attention is paid to a harder question — how do we make the risk of that agent machine-readable and comparable?

This is where SREL becomes complementary to capability languages like ACEL.

Capability vs Risk: Two Missing Standards

Concern	What we need	Current state
What the agent is allowed / designed to do	Declarative capability contract	Emerging (ACEL, Agent Spec, etc.)
How risky that agent is in context	Structured, comparable risk output	Almost entirely free-form (PDFs, slides, spreadsheets)

ACEL answers the first question cleanly: five aspects + autonomy modal + oversight rules, expressed as a versioned contract.

SREL answers the second: a normative grammar so that risk assessments become data instead of documents.

Without the second half, governance stays manual and non-scalable.

The Gap SREL Closes

Today a model risk or agent risk assessment usually ends up as:

A long PDF
A spreadsheet with colored cells
A slide deck for a review committee

None of these can be:

Ingested by a monitoring system
Diffed across versions
Compared across vendors
Automatically escalated when a threshold is crossed
Linked structurally to the controls that are supposed to mitigate them

SREL turns the assessment into a conformant document with required sections, typed values, and semantic invariants. Downstream systems can consume it the same way they consume OpenAPI or SBOM files.

Geometric Structure, Not Just Another Schema

SREL is not “yet another YAML schema for risk.”

It is built on a geometric substrate:

9 dyadic groups × 6 compositional periods = 54 named risk primitives
Each primitive sits at a fixed coordinate
Scores live on an n-simplex decomposition
A meta-condition veto (KILL, SAF, HITL, AUT, TRU, MAN) can collapse the entire composite to zero if structural prerequisites fail

This gives the language two useful properties:

Comparability — two assessments of different systems can be placed in the same coordinate space.
Control linkage — the Controls Exchange profile places controls at the same coordinates as the risks they address. No external mapping table required.

That last point is rare. Most control frameworks (OSCAL, etc.) and risk frameworks live in separate conceptual spaces. SREL deliberately co-locates them.

How This Complements Declarative Agents

Imagine an agent defined in ACEL:

agent research_assistant {
  autonomy: SUPERVISED
  ...
  oversight high_stakes {
    trigger: UNCERTAINTY_ABOVE 0.3
    action: ASK_APPROVAL
  }
}

That contract tells us what the agent is and how it should be governed at runtime.

A corresponding SREL document can tell us how risky the current deployment of that agent is, under real conditions, with a machine-checkable composite score and a clear record of which primitives are driving the risk.

The two artifacts answer different questions:

ACEL → “What is this agent supposed to be and how is it constrained?”
SREL → “Given the current context, how risky is it actually behaving / performing?”

Together they form a more complete governance loop:

Declare capability and oversight (ACEL)
Assess risk in a structured, comparable form (SREL)
Feed the risk output back into monitoring, policy, or human review
Update the capability contract or the runtime thresholds when needed

Practical Implications

If you are building:

Agent platforms → You can emit SREL documents as part of continuous evaluation
Model risk management → You finally have an interchange format instead of proprietary report formats
Monitoring / observability → You can alert on structured bands (WATCH → DRIFT → ELEVATED → CRITICAL) instead of parsing prose
Controls / compliance → You can place controls at the same coordinates as the risks they mitigate

The language is deliberately open (CC0 for the specification text) and designed for downstream consumption rather than for any single vendor’s scoring engine.

Closing Thought

Capability languages make agents describable.

Risk languages make agents governable at scale.

SREL is an attempt to give the industry the second half of that equation in a form that machines can actually use.

If ACEL (or similar contracts) becomes the way we declare what an agent is, SREL is a strong candidate for how we exchange what its residual risk looks like.

Further reading

SREL specification & grammar: github.com/srel-spec/srel
Website: srel.net
Related capability language: github.com/srel-spec/acel

Declarative AI Agents: Spec Once, Generate Everywhere with ACEL

Tim Poschel — Mon, 10 Aug 2026 13:32:00 +0000

Most agent frameworks still force you to write imperative code: wire tools, manage memory, hard-code oversight logic, and re-implement the same patterns for every new runtime. The result is brittle agents that are hard to review, version, audit, or port.

A cleaner path is emerging: treat the agent as a declarative contract.

What is ACEL?

ACEL (Agent Capability Expression Language) is a small, focused language for defining AI agents. It is built on the Rectified Pentachoron Framework (RPF) and models an agent as exactly five aspects plus a global autonomy modal:

Aspect	Role	Neglect pathology
telos	The objective pursued	Aimless reactivity
world_model	Present apprehension of environment state	Ungrounded action (hallucination)
memory	State retained across time	Amnesia
deliberation	Mapping situation → action	Thrashing / myopia
actuation	Effecting change on the environment	Paralysis

Autonomy is not a sixth aspect. It is a modal that qualifies every aspect (supervised perception, supervised deliberation, etc.). Oversight rules sit alongside it as first-class triggers (uncertainty thresholds, irreversible actions, cost limits, etc.).

A minimal example looks like this:

agent research_assistant {
  autonomy: SUPERVISED

  telos {
    goal: ACHIEVE "comprehensive_report" AND MAINTAIN "factual_accuracy"
    priority: HIGH
  }

  world_model {
    grounding: REQUIRED
    percept web_search { type: RETRIEVE protocol: MCP freshness: 1h }
  }

  memory {
    type: HYBRID
    store short_term { capacity: 10000 ttl: 1h retrieval: RECENCY }
    store long_term  { capacity: 1000000 retrieval: RELEVANCE }
  }

  deliberation {
    mode: HYBRID
    plan   { strategy: HIERARCHICAL depth: 4 replan_on_failure: true }
    decide { strategy: MONTE_CARLO_TREE_SEARCH risk: 0.4 explore: 0.2 }
    reflect { trigger: ON_ERROR over: long_term }
  }

  actuation {
    effect document_store { type: MODIFY protocol: REST permissions: READ, WRITE }
  }

  oversight high_stakes {
    trigger: UNCERTAINTY_ABOVE 0.3
    action: ASK_APPROVAL
    escalate_to: lead
  }
}

The language enforces clean separations (raw data percepts are read-only; effects are write; reflection must bind to a declared memory store) and produces a conformance report against the five-aspect basis. The .acel file becomes the single source of truth — versionable, reviewable, and enforceable in CI.

From Spec to Artifacts: acel-generator

Writing the contract is only half the story. acel-generator (OpenAPI-Generator-style tooling for ACEL) turns that contract into concrete artifacts.

Pipeline:

.acel  →  parse + validate + framework conformance  →  intermediate representation (IR)  →  generators  →  artifacts

Current built-in generators include:

langgraph — LangGraph / LangChain-shaped Python package (agent, memory, tools, oversight)
markdown — Agent card (AGENT.md) + Mermaid architecture diagram
ossa — OSSA-style agent contract YAML
pytest — Basic invariant test suite
a2a — Agent2Agent Agent Card (.well-known/agent-card.json) for discovery and delegation
mcp — MCP tool manifest (mcp.json) with percepts as read tools and effects as write tools (plus destructiveHint annotations)

Governance details that current interoperability protocols do not express (autonomy level, oversight, grounding, retention shape) are emitted under namespaced extensions so the gap stays visible rather than being papered over.

Design principles of the generator:

The spec is the contract — generators map declared aspects; they invent no semantics.
Fail closed on validation.
Autonomy and oversight are first-class in every runtime generator.
Memory generators respect durability, resolution, and recording decisions.
Extensible via plugins and Jinja templates.

Why this matters

Governance as code — The same file that describes the agent also drives CI gates and runtime policy.
Interoperability without loss of intent — A2A skills and MCP tools are generated from the same percept/effect split.
Portability — One contract, multiple scaffolds (LangGraph today; others tomorrow).
Auditability — Every generated artifact can be traced back to a versioned, validated ACEL document.

ACEL is deliberately not a runtime. It is the contract that binds the layers you already run (agent loop, control plane, gateway, tools/MCP, memory). Author-time validation shifts left; runtime enforcement compiles autonomy and oversight into gateway rules.

Getting started

Language & validation: https://github.com/srel-spec/acel
Generator: https://github.com/srel-spec/acel-generator

Both are MIT-licensed (with a narrow patent non-assertion on the language itself). The projects are early (alpha), but the conceptual clarity is already strong.

If you are tired of re-implementing the same agent skeleton for every framework, try writing the contract once and generating the rest. Declarative agents are not just cleaner code — they are a practical step toward agents that are governable, auditable, and portable by design.