Ecosystem
One technical system, multiple runtime components, one verification chain.
ERDL is not an isolated library — it's a technical system from semantic specification to runtime framework. Each repo has a distinct role, pinned together by one deterministic verification chain.
Repo navigation
MCP: one when/then is all it takes
Stop reminding your agent to behave — teach it. Prompt rules don't work: LLMs forget, reinterpret, rationalize. ERDL as an MCP server: the agent doesn't try to follow rules — the engine enforces them before every tool call.
$ npx -y @openoba-ai/erdl-mcp30 rules · 5 tools · zero config · unlimited custom rules · free forever.
Relationship with Microsoft ACS
ACS (Agent Control Specification, Microsoft AGT) gets the orchestration contract right — a stateless, deterministic, fail-closed policy-decision runtime that standardizes "where to intercept, how to execute". But it is an orchestration contract, not a policy language: it deliberately outsources "the semantics of the rule itself" to Rego / Cedar.
ERDL fills exactly that layer — the policy language itself: a decision model + frozen semantics + three projection surfaces, so the rule's semantics are isomorphic to the policy sentence. Need "a standard, portable policy intercept for an existing agent"? ACS already suffices. Need "rule semantics that are stable, verifiable, and readable"? That's where ERDL comes in.
Delegated authority (A2A / multi-agent)
When agents delegate decisions to one another, cross-implementation trust can't rest on bilateral endorsements. OpenOBA's delegated-authority governance rests on four runtime-authority invariants (from A2A Discussion #2031):