01
SLA Contract
A signed JSON document per agent task. Defines the primary metric, guardrails, latency ceilings, test-set hash, and regulatory mapping. Cryptographically signed by both parties before traffic flows.
Open Agent SLA Specification
We published the standard before we built the product.
OASS is a vendor-neutral schema for expressing service-level agreements for production AI agent tasks — in a form that an engineer, an auditor, and a control plane can all agree on. It is the core artifact on which Attestum is built, and it is free for anyone to implement.
Why an open spec
Specifications outlive products.
The gap between "my agent is observable" and "my agent is governed" is structural. Observability describes; governance binds. Binding requires a shared vocabulary — a shape that a compliance auditor, an engineering team, and a control plane can all interpret the same way.
We published OASS first because the spec is the defensible artifact, not the proxy. If OASS is right, five vendors should implement it by 2027. Attestum is the first. The moat is adoption, not proprietary lock-in.
The spec is released under Creative Commons Attribution 4.0. You are free to implement it, extend it, fork it, or ignore it. We ask only that if you extend it, you propose the extension in public.
What's in v0.1
Three building blocks, one rollback procedure.
02
Audit Record
An immutable per-run record linking the contract in force, the model chosen, the tool calls made, the SLA evaluation, the rollback decision, and the regulatory evidence fields — in an append-only signature-chained log.
03
Rollback Procedure
A deterministic algorithm for reverting a regressing agent to the incumbent path — no human in the loop. Control planes MUST implement it for compliance. Humans re-arm via a signed event.
Regulatory mapping
Every field maps to a regulation your compliance team already knows.
The spec includes reference mappings to the major AI-governance frameworks in force today. The fields carry the evidence; your auditor reads the table.
| Framework | Coverage in v0.1 | Notes |
|---|---|---|
| EU AI Act (2024/1689) | Articles 9, 10, 13, 14, 15, 17, 21, 72 | Risk management, data governance, transparency, human oversight, robustness, QMS, post-market monitoring. |
| SOC 2 | Common Criteria CC7.1, CC7.2, CC7.3, CC8.1 | Change management, system monitoring, security-event evaluation, risk mitigation. |
| SR-11-7 | Model validation & ongoing monitoring | US Federal Reserve guidance for bank model risk management. Non-normative mapping. |
| MAS FEAT | Fairness, Ethics, Accountability, Transparency | Monetary Authority of Singapore. Signed SLAs + audit records satisfy accountability and transparency requirements. |
| NIST AI RMF | Coming in v0.2 | US National Institute of Standards and Technology. Community input welcome. |
How to contribute
We're looking for implementers, reviewers, and counter-arguments.
Open an issue
Especially valuable: missing regulatory mappings, missing audit fields your compliance team would ask about, rollback-procedure edge cases, ambiguities in the schema.
Implement it
If you implement OASS in another control plane, orchestrator, or
observability tool, open a PR against IMPLEMENTATIONS.md.
Implementation diversity is the goal.
Propose v0.2 additions
The open questions for v0.2 are listed in the spec itself. Proposals welcome as pull requests with a short rationale.
Disagree publicly
If OASS is wrong, we want to know now — before enterprises adopt the wrong schema. Substantive criticism gets a response within one business day.