ABDS / AUSF

What ABDS / AUSF is

ABDS/AUSF is EPICORTEK’s conformance framework for specifying, verifying, and governing AI agents.

AUSF — Agent User Story Framework defines the intent layer: who the agent acts for, what it is allowed to do, what is forbidden, when it must escalate, and what success or failure means.

ABDS — Agentic Behavioral Design Specification defines the specification layer: it transforms the AUSF story into engineering-grade documentation covering agent intent, behavior, verification, execution model, telemetry, budget, and safety.

Together, AUSF provides the structured story. ABDS generates the artifacts that engineers, operators, auditors, and safety reviewers need to build, deploy, and govern the agent.

Three adoption levels

ABDS/AUSF defines three conformance levels. Each level is additive: upgrading from Level 1 to Level 2 adds sections; it does not require rewriting existing documentation.

---

Level 1 — Lite

For: prototypes, internal tools, demos, and low-risk single agents.

AUSF input: Boundary Card — a concise declaration of the agent’s purpose, permitted scope, forbidden actions, and escalation conditions.

ABDS output: three core specification documents:

Document	Purpose
AIS — Agent Intent Specification	Documents what the agent is intended to do and why
ABS — Agent Behavior Specification	Documents how the agent should behave within its permitted scope
AVS — Agent Verification Specification	Documents how the agent’s behavior can be tested and verified

Level 1 is the minimum baseline. It is sufficient for prototypes and demos where risk is low and scope is tightly bounded.

---

Level 2 — Standard

For: production agents, real data, customer-facing systems, cost exposure, multi-agent systems, and hybrid (human + AI) systems.

AUSF input: Production Contract — a structured agreement defining production-scope permissions, delegation boundaries, cost exposure limits, and escalation requirements.

ABDS output: all Level 1 artifacts, plus:

Additional document	Purpose
Governance specification	Defines accountability, audit obligations, and policy bounds
Budget specification	Documents cost exposure limits and enforcement mechanisms
Model resilience specification	Defines acceptable model failure modes and fallback behavior
Behavioral test specification	Defines the behavioral test suite required before production deployment
Runtime specification (where applicable)	Documents execution model, concurrency, and latency expectations
Telemetry specification (where applicable)	Documents what signals the agent emits and how they are collected

Level 2 is the standard requirement for any agent that handles real data, affects real users, or exposes the operator to cost or reputational risk.

---

Level 3 — Full

For: regulated systems, safety-critical deployments, and any agent whose decisions or actions directly affect humans.

AUSF input: Delegation Contract — a formal delegation record specifying the chain of authority, the delegator’s obligations, the agent’s safety constraints, and the conditions under which human oversight is mandatory.

ABDS output: all Level 2 artifacts, plus:

Additional document	Purpose
Ethics and bias guardrails specification	Documents how the agent avoids or detects harmful bias in its outputs
Human handoff specification	Defines when and how the agent transfers control to a human
Evaluator specification	Documents the evaluation criteria and the party responsible for sign-off
Formal verification specification	Documents what formal verification has been applied and to what scope
Safety framework	Defines the safety model, failure containment, and incident response
Safety certificate	A signed attestation that the Level 3 requirements have been met

Level 3 is required for any agent in a regulated industry, any agent that makes decisions affecting individual welfare, and any safety-critical deployment.

---

The additive upgrade principle

A system that starts at Level 1 can be upgraded to Level 2 or Level 3 without discarding its existing documentation. Each level adds specification sections. The Boundary Card becomes a Production Contract; the Production Contract becomes a Delegation Contract.

This design is intentional: it allows teams to begin with a lightweight Lite specification for prototypes and progressively formalize their documentation as the agent matures toward production and regulated deployment.

Relationship to AgIS

AgIS operates at the Identity & Verification layer — it verifies who an agent is and whether its requests are authentic.

ABDS/AUSF operates at the Context Governance layer — it specifies what the agent is permitted to do, under what conditions, and with what governance obligations.

An agent governed by an ABDS Level 2 or Level 3 specification would typically also be verified by AgIS at the identity and request layer. The two frameworks are complementary: ABDS/AUSF defines intent and governance; AgIS verifies identity and authenticity.

Current status

Artifact	Status	Notes
Level model (Lite / Standard / Full)	Direction defined	Framework structure is specified
AUSF Boundary Card structure	Direction defined	Formal schema in progress
AUSF Production Contract structure	Direction defined	Formal schema in progress
AUSF Delegation Contract structure	Direction defined	Formal schema in progress
ABDS AIS / ABS / AVS specification	Direction defined	Formal specification in progress
ABDS Level 2 document set	Direction defined	Formal specification in progress
ABDS Level 3 document set	Direction defined	Formal specification in progress
ABDS/AgIS integration	Conceptual	Formal specification not yet started
Reference tooling	Not started	No implementation exists
Standardization	Not started	No submission planned at this stage

What exists today

• Framework level model and adoption structure (Lite / Standard / Full)
• AUSF and ABDS conceptual model and purpose definitions
• ABDS document type inventory for each level
• Defined relationship to AgIS and the EPICORTEK trust infrastructure stack
• Internal working notes for AUSF input types and ABDS output categories

What is not claimed

• ABDS/AUSF is not a deployed product
• ABDS/AUSF is not a runtime system or SaaS platform
• ABDS/AUSF is not an approved standard
• ABDS/AUSF does not formally prove the reasoning quality of LLM outputs
• No reference implementation or tooling exists at this time
• The Safety Certificate described in Level 3 is a framework artifact — it is not issued by a regulatory body

Which edition do you need?

Answer these questions in order. Stop at the first YES.

Question	If YES
Agent affects decisions about real people?	Use Level 3 — Full
System is regulated (EU AI Act, HIPAA, financial compliance)?	Use Level 3 — Full
Agent handles real customer data or PII?	Use Level 2 — Standard
Agent can incur cost > $10/run or calls paid APIs?	Use Level 2 — Standard
Agent connects to any production system?	Use Level 2 — Standard
None of the above (prototype, internal demo, low-risk tool)	Use Level 1 — Lite

Default rule: when in doubt, start Lite. Every Level 1 document is a valid subset of Level 2 and Level 3. You never rewrite — you only add sections.

Who reads what

Role	Start here	Core sections
Product Manager	AUSF story (Boundary Card or Production Contract)	Intent Layer, Goal Contract, Permission Map
Software Architect	Level 1 — Lite, then expand	All sections are primary reference
Engineer / Developer	ABS (Behavior Specification) + AVS (Verification)	Capability Contracts, Anomaly Signatures
QA / Test Engineer	AVS (Verification Specification)	Evaluation Rubric, Behavioral Test Suite
Security Engineer	Permission Map, Ethics & Bias Guardrails	AIS Sections 3.3, 3.8, 3.9
Executive	Section 0 overview only	System Classification, Level model

AUSF is always written first. ABDS documents are generated from the AUSF story.

AUSF input formats

Each ABDS level has a corresponding AUSF story format as its upstream input.

Level 1 — Boundary Card (5 fields)

The minimum viable AUSF story. Written before any technical specification begins.

AGENT: <name and role — one sentence>
ACTING_ON_BEHALF_OF: <human principal accountable for this agent>
OPERATIONAL_GOAL: <measurable outcome — must be testable by an automated check>
PERMITTED: <exhaustive list of what the agent may do>
FORBIDDEN: <exhaustive list of what the agent must never do>

Test: Can an engineer write an automated check for the OPERATIONAL_GOAL? If not, rewrite it.

Level 2 — Production Contract (7 sections)

Extends the Boundary Card with production requirements.

Adds: DATA_HANDLING · COST_EXPOSURE · ESCALATION_CONDITIONS · AUDIT_REQUIREMENTS · DELEGATION_SCOPE

Level 3 — Delegation Contract (10 sections)

Extends the Production Contract with regulated-system requirements.

Adds: ETHICS_CONSTRAINTS · HUMAN_HANDOFF_CONDITIONS · FORMAL_SAFETY_REQUIREMENTS · EVALUATOR_OBLIGATIONS · ACCOUNTABILITY_CHAIN

Worked example — Level 1 Lite

Step 1: Write the AUSF Boundary Card

AGENT: Invoice Processing Agent — reads invoices from the inbox,
       extracts line items, and submits them to the accounting system.
ACTING_ON_BEHALF_OF: Finance Manager (accountable for all submissions)
OPERATIONAL_GOAL: Process 95% of invoices within 4 hours of receipt
                  with < 0.5% error rate on extracted amounts.
PERMITTED:
  - Read emails in the invoices@company.com inbox
  - Extract text and structured data from PDF and image attachments
  - Submit validated line items to the accounting API
  - Flag ambiguous invoices for human review
FORBIDDEN:
  - Approve or pay any invoice
  - Modify any submitted record after submission
  - Access any email folder other than invoices@company.com
  - Contact vendors directly

Step 2: ABDS generates three documents

From this Boundary Card, ABDS-Lite produces:

AIS — Agent Intent Specification Documents what the agent must achieve and its absolute boundaries. Includes the identity block, goal contract, permission map, failure contract, and operational constraints.

ABS — Agent Behavior Specification Documents how the agent behaves: its tools, when to use each one, and test scenarios covering success and edge cases.

AVS — Agent Verification Specification Documents how correct behavior is proved: the evaluation rubric, anomaly signatures, and mandatory test checks.

Total time to first Level 1 specification: approximately 30 minutes.

Formal foundations (Level 3)

Level 3 specifications include formal mathematical definitions for regulated and safety-critical deployments.

The core agent representation is defined as a tuple:

Ω = (S, A, T, G, E, π, M)

Where S is the state space, A is the capability space, T is the transition model, G is the goal set, E is the evidence function, π is the policy, and M is the memory model.

For multi-agent systems: Σ = (Ω₁ … Ωₙ, C) where C is the coordination protocol.

The capability space is partitioned: A_permitted and A_forbidden are mutually exclusive by definition — their intersection is the empty set.

A safety invariant φ must hold in every reachable state of the system.

These formal definitions map directly to ABDS Level 3 specification artifacts. They are grounded in Markov Decision Process theory and are verifiable against the produced documentation.