Chapter 2 — EDDA: The General Framework
"Governance you build once and inherit is governance that holds. Governance you rebuild per project is governance that fails per project."
What EDDA is
Evidence-Driven Delegation Architecture (EDDA) is a vendor-neutral architectural model for governing delegated action across humans, services, AI agents, automation, and external tools. Its tagline states the scope compactly: identity, policy, evidence, approval, and audit for delegated action. It is not a product, not a model, and not a security tool. It is a framework — a coherent set of governance decisions, made once and made well, that any system delegating action can build on rather than reinvent.
The word "governance" carries weight here. It does not mean compliance paperwork or an approval committee. It means the architectural machinery that answers, for any action an intelligent actor takes: who is acting, under whose authority, permitted by what policy, grounded in what evidence, approved by whom, observable how, attributable to whom, and recoverable in what way. EDDA exists because every team building a serious intelligent system needs answers to those questions, and — left to themselves — every team answers them differently, incompletely, and usually too late. Volume I's Law VI named this exact failure: practices that depend on each project deciding correctly will be decided wrongly somewhere. EDDA is the platform-shaped response — it removes the governance decisions from each project by making them once, at the framework level.
The governance domains
EDDA organizes governance into domains, each owning one aspect of the guarantee. The domains are worth naming, because together they define what "governed" means in concrete architectural terms:
anonymously.
authority it was granted, not authority it assumed.
actor's discretion.
taken, preserved.
implication.
known state.
- Identity — every actor, human or machine, has an established identity. Nothing acts
- Delegation — authority is delegated explicitly and traceably; an actor acts under
- Policy — privileged decisions are evaluated against explicit policy, not left to the
- Evidence — consequential actions produce evidence: the grounds on which they were
- Approval — approvals are explicit and auditable; consent is a recorded fact, not an
- Audit — actions produce an authoritative record of what happened.
- Observability — the system's behavior is legible to those who operate it.
- Recovery — actions are recoverable where practical; the system can be returned to a
Read against Volume I, these domains are not arbitrary. They are the eight architectural laws projected onto the specific problem of governing an actor. Identity and delegation are the Control Plane's enforcement of truth-plane facts (Law I, Part VII). Policy is constraint made first-class and enforced (Law II). Evidence is Law V given a home. Approval and attribution are human accountability at the consequential seam. Audit is the immutable record (Law I) distinguished from mere telemetry (Law I, Part VI). Observability is the Observation Plane. Recovery is graceful degradation and deterministic restoration (Law VII). EDDA is, in a real sense, Volume I's laws reorganized as the operating requirements of a governed actor.
The eight laws of governed AI
EDDA states its own governing principles compactly — eight laws of governed AI. These are not the same as the eight architectural laws of this book, and the distinction matters: the architectural laws are how you build any trustworthy system; the governed-AI laws are what EDDA specifically requires of any intelligent actor within such a system. They are downstream of the architectural laws — a domain specialization of them.
EDDA's eight laws of governed AI:
1. Every intelligent actor has an identity. 2. Every action executes under delegated authority. 3. Every privileged decision is governed by policy. 4. Every consequential action produces evidence. 5. Every approval is explicit and auditable. 6. Every action is observable. 7. Every action must be attributable. 8. Every action must be recoverable where practical.
These are architectural laws, not implementation details — they constrain what must be true of any action, not how to make it true. A system that satisfies all eight has the property EDDA exists to confer: an intelligent actor whose every meaningful action is identified, authorized, policy-governed, evidence-backed, approved where required, observable, attributable, and recoverable. A system that violates any one of them has a class of ungovernable action — the exact gap Chapter 1 described.
Framework, not implementation: why profiles exist
The most important architectural decision in EDDA is that it is general, and meant to be specialized. EDDA does not say how to govern a specific kind of actor in a specific domain; it says what governance means, in domain-independent terms, and leaves the specialization to profiles.
A profile is EDDA adapted to a domain. It takes the general governance domains and the eight laws and renders them concrete for a particular use case: which identities exist, what the policy language expresses, what counts as evidence, which actions require approval and at what risk tier, how recovery works. The framework supplies the structure and the guarantees; the profile supplies the domain specifics.
This is Law VI (Platforms Exist To Remove Decisions) operating at two levels. EDDA removes the governance decisions from profile authors — a profile does not decide whether to require evidence or whether actions must be attributable; those are settled by EDDA. The profile, in turn, removes the application decisions from the teams that build on it — a team using a profile inherits a domain-specific, ready-made governance posture. Each layer concentrates a set of hard decisions so the layer above need not remake them. And critically, the framework's decisions remain governable and the profile's remain adaptable: EDDA can evolve its guarantees, a profile can adapt them to its domain, without either collapsing into the other.
This is also why the framework/profile distinction is not pedantry. If EDDA and its profiles were the same thing, you would have to choose between a framework so general it governs nothing concretely, and an implementation so specific it governs only one use case. The two-level structure escapes that trade: EDDA is general enough to apply to any intelligent system, and its profiles are specific enough to deploy. The generality and the specificity coexist because they live at different levels.
The profile that proves it
A framework's promises are only as good as a profile that holds up under pressure, and EDDA has one in a genuinely hard domain. AISDR — the AI Security Decision Record — is the EDDA security profile: EDDA specialized to controlled AI-assisted security operations. It takes every governance domain and every law above and makes them concrete for the problem of letting an AI participate in security decisions.
AISDR is the subject of the rest of this volume, and it is the validation of EDDA, because security is the domain where governance is most adversarial and most consequential (Chapter 1). A framework that produces a workable profile there — where inputs are hostile, actions are irreversible, and accountability is absolute — has demonstrated that its governance is real and not merely aspirational. The chapters that follow examine AISDR domain by domain. Throughout, remember the relationship: what AISDR does in security, EDDA could do in any domain, because AISDR's governance is not its own invention. It is EDDA, applied.
Further reference. The formal EDDA specification — governance-domain definitions, RFCs, ADRs, schemas, and the reference architecture — lives in reference/edda-framework/. It predates this narrative and uses some legacy terms (notably Control Fabric for what the book calls the Control Plane); the reference README carries a term-by-term crosswalk.
The next chapter begins where every governed action begins: with identity, policy, and the control plane that gates everything.