The Execution Authority Boundary Contract (EABC) defines an implementation-independent contract between systems that authorize actions and systems that execute them.
EABC specifies the minimum architectural properties, evidence requirements, and execution semantics required to establish trustworthy execution-authority boundaries.
The goal is to enable interoperability between autonomous system architectures without requiring a shared implementation.
Autonomous systems are increasingly moving from generating information to taking actions that create externally observable effects.
Modern architectures often separate:
- decision-making;
- governance evaluation;
- authorization;
- execution;
- external state transitions.
However:
- authorization does not necessarily prove execution;
- execution does not necessarily prove legitimate authority;
- implementation-specific evidence makes independent verification difficult.
EABC defines the missing contract between authorization and execution.
EABC defines:
- execution authority properties;
- evidence requirements;
- execution lifecycle semantics;
- failure semantics;
- conformance requirements;
- implementation profile structure.
EABC defines the boundary contract, not a specific implementation.
EABC does not prescribe:
- a specific autonomous agent architecture;
- a governance framework;
- a policy language;
- a runtime implementation;
- a hardware platform;
- a communication protocol.
Different architectures may satisfy the same contract through different mechanisms.
EABC focuses on the transition between authorized intent and externally committed effect.
Authorization Domain
│
▼
Execution Authority Boundary
│
▼
Execution Domain
│
▼
External State Change
The boundary exists to ensure:
- authority is explicit;
- execution is mediated;
- evidence is preserved;
- outcomes are independently verifiable.
Execution authority must remain independent from the entity whose actions are being governed.
Externally committed actions must pass through the execution-authority boundary.
Trust should be established through verifiable evidence rather than implementation assumptions.
Authorization, execution attempt, and committed effect must remain distinguishable.
EABC standardizes properties and evidence, not mechanisms.
/
├── docs/
│ └── Core EABC specification
│
├── profiles/
│ └── Implementation mappings
│
└── examples/
└── Illustrative execution flows
The normative specification is available in:
Core documents:
| Document | Purpose |
|---|---|
| Introduction | Scope and motivation |
| Execution Authority Properties | Required architectural guarantees |
| Evidence Model | Verification requirements |
| Failure and Execution Semantics | Lifecycle semantics |
| Conformance | Compatibility requirements |
EABC is designed to support multiple independent implementations.
Implementation profiles describe how a concrete architecture maps to the EABC contract.
Current profile:
- EGA/SIF v1
See:
Examples demonstrate how execution-authority boundaries operate in practical scenarios.
See:
EABC is currently an initial draft specification.
Current work focuses on:
- refining execution authority properties;
- improving evidence models;
- defining interoperability patterns;
- documenting implementation profiles.
Feedback and contributions are welcome.
Areas of interest include:
- execution authority properties;
- evidence requirements;
- lifecycle semantics;
- implementation profiles;
- interoperability scenarios.
The objective is to establish an open contract that multiple independent architectures can satisfy.
The EABC specification, documentation, profiles, and examples in this repository are licensed under the Apache License, Version 2.0.
See LICENSE for the full terms.
Copyright © 2026 Equinibrium.
This repository license does not grant rights to trademarks, trade names, or other intellectual property that may be separately protected. Patent rights are governed by Section 3 of the Apache License, Version 2.0; this NOTICE grants no additional patent license beyond the rights expressly provided by the applicable license.