> portal · assurance
Explore the normative control baseline, classify workload characteristics, plan assurance evidence, discover crosswalks, and onboard machine-readable conformance tooling — without overstating what repository artifacts prove.
Display this badge in your repository README to signal compliance with the AI Engineering Standard.
[](https://www.ai-standards.dev)<a href="https://www.ai-standards.dev" target="_blank" rel="noopener noreferrer"><img src="https://img.shields.io/badge/AIES-Compliant-6366f1?style=for-the-badge&logo=shield" alt="AIES Compliant" /></a>Every result below is parsed from the normative kernel and control documents. Requirement language and objective evidence are authoritative; portal filters do not decide applicability.
The organization MUST maintain an approved system boundary covering every component and dependency capable of affecting outputs or actions.
The organization MUST name one system owner and a control owner for every applicable control.
The system owner MUST classify all applicable workload profiles, autonomy level, and impact level before production use and after material change.
The SoA MUST include every control in the claimed AIES version and record its applicability disposition and rationale.
A not-applicable disposition MUST NOT be used solely because implementation is costly, difficult, outsourced, or incomplete.
Third-party components MUST remain inside the system boundary wherever their behavior can affect conformance.
A4 deployment MUST NOT enter production without documented executive authorization, independent risk assessment, bounded authority, and tested containment.
The system owner MUST maintain a risk register covering intended use, foreseeable misuse, affected parties, failure modes, likelihood, impact, safeguards, residual risk, and treatment owner.
Residual risks above the organization’s approved tolerance MUST NOT be accepted by the system owner alone.
The organization MUST define measurable acceptance criteria and evaluate the complete system against representative and adversarial cases before release.
Production model, prompt, policy, tool, and configuration versions MUST be uniquely identifiable and reproducible.
Material model or prompt changes MUST NOT bypass regression, safety, and security gates.
Data used for training, tuning, retrieval, evaluation, or inference MUST have documented provenance, permitted purpose, sensitivity, retention, and responsible owner.
Sensitive data MUST be minimized and protected in prompts, logs, memory, evaluation sets, and outputs according to its classification.
Identity and access controls MUST enforce least privilege for models, tools, data stores, administrative interfaces, and service accounts.
Untrusted input and model output MUST be treated as data rather than executable authority across trust boundaries.
Secrets MUST NOT be embedded in prompts, source artifacts, model context, logs, or generated output.
Production releases MUST use an approved, attributable, reversible change process with separation appropriate to impact.
The organization MUST monitor safety, security, quality, availability, cost, and policy-relevant events at frequencies justified by risk.
AI incidents MUST enter a documented response process that preserves evidence, limits harm, notifies accountable parties, and records corrective action.
Users MUST receive accurate notice when they interact with AI or when AI materially influences an outcome, except where lawfully exempted and documented.
Applicable controls MUST be supported by evidence meeting the quality rules in 03.
Assistant output MUST be constrained or reviewed where an unsupported claim could cause material harm.
The system MUST communicate material capability limits and uncertainty at the point where a user relies on output.
Safety and refusal behavior MUST be tested against domain-relevant harmful, ambiguous, multilingual, and adversarial requests.
Retrieval authorization MUST be enforced at query time using the requesting principal and source permissions.
Retrieved content MUST retain source identity, version or retrieval time, and trust metadata through generation.
The system MUST evaluate retrieval relevance, coverage, grounding, and resistance to content-based instruction injection before release.
Stale, revoked, or deleted source content MUST be removed from serving indexes within a documented risk-based service level.
Code execution MUST occur in an isolated environment with bounded network, filesystem, identity, compute, and time permissions.
Generated code MUST pass deterministic tests, static analysis, dependency, license, and secret checks appropriate to the repository before merge or deployment.
Security-sensitive or production-impacting code changes MUST receive independent human approval from an authorized reviewer.
Agent-selected dependencies MUST be resolved through approved registries and verified against integrity and vulnerability policy.
Every external action MUST pass deterministic authorization, schema validation, policy, and idempotency controls outside the model.
Consequential or irreversible actions MUST require informed human approval bound to the exact action payload before execution.
Reversible actions MUST have a tested compensation or rollback path before autonomous production execution.
Action limits MUST bound value, rate, scope, destination, and cumulative exposure independently of model instructions.
Delegation MUST NOT increase permissions, data access, or action authority beyond the initiating principal and approved workflow.
Every inter-agent message and action MUST be attributable to agent identity, version, parent task, and initiating principal.
Orchestration MUST enforce termination conditions for cycles, fan-out, cost, time, and repeated failure.
Conflicting agent outputs MUST be resolved by an explicit deterministic or human-governed policy before consequential action.
A high-impact system MUST complete an impact assessment covering affected groups, rights, safety, accessibility, discrimination, contestability, and cumulative effects before production use.
High-impact deployment MUST have independent pre-release assurance and an organization-approved reassessment interval derived from impact, change rate, incident history, applicable obligations, and claim period; that interval must be shorter than the approved interval for otherwise comparable lower-impact systems.
Affected persons MUST have an accessible path to explanation, correction, contest, and human review of material adverse outcomes.
High-impact performance MUST be evaluated for relevant subgroups, operating conditions, and foreseeable distribution shifts using domain-approved thresholds.
The operator MUST maintain and test an immediate safe-stop, fallback, or service-withdrawal mechanism.
High-impact evidence MUST be retained under an approved records schedule that accounts for applicable jurisdictional, regulatory, contractual, claim-period, appeal, incident, investigation, and litigation-hold needs and receives independent legal or records-management approval before disposal.
Tool access MUST use explicit allowlists, least-privilege credentials, argument constraints, and default-deny behavior.
Memory that can influence future actions MUST have provenance, access control, retention, integrity protection, and a deletion mechanism.
Operators MUST be able to suspend autonomous execution without model cooperation.
Autonomous decisions and actions MUST produce tamper-evident traces sufficient to reconstruct inputs, policy decisions, tool calls, approvals, outputs, and outcomes.
Each evidence item MUST identify source, custodian, collection time, covered period, system scope, control mapping, integrity mechanism, and retention date.
Operating-effectiveness evidence MUST represent the full assessment period and include failures and exceptions in the sampled population.
Evidence MUST NOT rely solely on a control owner’s uncorroborated assertion.
The organization MUST protect evidence against unauthorized alteration and verify retrievability throughout retention.
The SoA MUST identify system/version, boundary, profiles, autonomy, impact, AIES version, every control disposition, rationale, owner, evidence, exception, approval, and review date.
Each not-applicable decision MUST cite a factual boundary or applicability condition and receive system-owner approval.
Each exception MUST identify the unmet requirement, cause, exposure, affected assets/people, likelihood, impact, compensating controls, residual risk, remediation owner, due date, expiry, applicable maximum-duration policy, duration rationale, and approvers.
An exception MUST NOT remain valid beyond its expiry or after a material change without reassessment and new approval.
Compensating controls MUST be tested for the stated risk before exception approval.
Expired or rejected exceptions MUST cause the affected control to become nonconforming until remediated.
The organization MUST approve exception-duration maxima by residual-impact tier, make higher-impact maxima progressively shorter, and review the maxima when risk tolerance, applicable obligations, or claim periods change.
A conformance claim MUST state system boundary, environments, AIES version, assessor, assessment period, status, active exceptions, issue date, expiry date, and material-change limitation.
An AIES claim MUST NOT be described as certification, accreditation, regulatory approval, endorsement, or organization-wide assurance; any separately issued external certification must be clearly distinguished from the AIES claim and attributed to its actual scheme and issuing body.
The organization MUST suspend or correct a claim when a major nonconformity, expired exception, material scope change, or unreliable evidence invalidates its basis.
The standard maintainer MUST publish versioned release notes identifying control-level additions, changes, deprecations, retirements, migrations, effective dates, and the evidence-based rationale for each migration window.
A deprecated control MUST retain its ID and normative force until its published retirement date.
A retired control ID MUST NOT be reassigned to another requirement.
Affected claims MUST be reassessed when a requirement is withdrawn for urgent safety, security, or legal reasons.
The assessor MUST document scope, criteria, period, team competence, independence, limitations, methods, populations, samples, tests, evidence, findings, and conclusion.
The assessor MUST validate SoA completeness and challenge not-applicable rationales against system-boundary facts.
The assessor MUST test both control design and operating effectiveness unless the report explicitly provides a design-only conclusion whose approved expiry is bounded by the claim period and whose wording excludes operating effectiveness.
Sample selection MUST be reproducible and risk-based, derive size and census decisions from approved assurance and deviation criteria, include failures and overrides, apply stronger criteria to I3, and preserve the source population or immutable query.
I3 assessments MUST use an assessor independent of control ownership, implementation, operation, and delivery reporting lines.
A positive conclusion MUST NOT be issued when a major nonconformity remains open or a scope limitation prevents sufficient appropriate evidence.
Assessment reports MUST receive factual review and independent quality review before issuance.
Active claims MUST follow an organization-approved surveillance interval derived from impact, change rate, control frequency, incident history, applicable obligations, and claim period; I3 intervals must be shorter than otherwise comparable lower-impact intervals, and material change, major incident, invalid evidence, or withdrawal of relied-upon supplier assurance triggers immediate review.
Corrective actions MUST identify root cause, owner, due date, remediation, validation method, and closure evidence.
This informative worksheet identifies a candidate control set for SoA review. It does not classify a system, prove applicability, or produce a conformance result.
24 controls match the universal baseline or selected overlays. Conditional controls and legal or organization-specific requirements still require explicit review.
Do not describe this candidate set as an assessment or claim. Complete boundary analysis, applicability rationales, approvals, evidence, and catalog reconciliation in the SoA.
The evidence quality attributes, evidence classes, and SoA dispositions below come directly from the normative assurance source.
Record system/version, boundary, profiles, autonomy, impact, environments, period, and catalog version.
Create one decision for every one of the 78 controls in this generated catalog.
Map attributable, scoped, timely, complete, reproducible, and protected evidence references.
Record owners, exceptions, approvals, validation evidence, material-change triggers, and next review.
| Disposition | Meaning | Claim effect |
|---|---|---|
| Applicable — conforming | Requirement implemented and evidenced | Pass |
| Applicable — exception | Requirement not fully satisfied; active exception meets this document | Conditional pass; disclosed in claim |
| Applicable — nonconforming | Requirement not satisfied and no valid exception exists | Fail |
| Not applicable | Applicability condition is factually absent | Excluded with rationale; assessor validates |
Crosswalks are informative evidence-discovery aids. They do not establish equivalence, compliance, endorsement, certification, or external validation.
Give engineering teams an honest, evidence-oriented map from EU AI Act concepts to AIES artifacts — without claiming CE marking, notified-body approval, or legal classification.
Map AIES evidence artifacts to the management-system, AI risk-management, and AI system impact-assessment concerns in ISO/IEC 42001, ISO/IEC 23894, and ISO/IEC 42005.
Map AIES artifacts to NIST AI Risk Management Framework 1.0 functions and the NIST AI 600-1 Generative AI Profile.
Map AIES prevention, detection, and response artifacts to the OWASP Top 10 for LLM Applications 2025 and OWASP Top 10 for Agentic Applications 2026.
Define how AIES contracts record security and telemetry evidence for Model Context Protocol authorization, Agent2Agent interoperability, and OpenTelemetry Generative AI semantic conventions.
Map AIES artifacts to NIST SSDF SP 800-218, applicable NIST SP 800-53 Rev. 5 controls, SLSA, and OpenSSF practices.
These contracts and commands are implementation tooling. Running them can validate supplied artifacts; it does not create external evidence or a certification.
| Contract | Version | Required fields | Source |
|---|---|---|---|
| AIES Agent Definition v1 | 1.0.0 | 19 | schemas/agent-definition.v1.schema.json |
| AIES AI System Manifest v1 | 1.0.0 | 25 | schemas/ai-system-manifest.v1.schema.json |
| AIES Context Manifest v1 | 1.0.0 | 12 | schemas/context-manifest.v1.schema.json |
| AIES Control Catalog v1 | 1.0.0 | 8 | schemas/control-catalog.v1.schema.json |
| AIES Evaluation Result v1 | 1.0.0 | 19 | schemas/evaluation-result.v1.schema.json |
| AIES Evidence Bundle v1 | 1.0.0 | 14 | schemas/evidence-bundle.v1.schema.json |
| AIES Exception and Risk Acceptance v1 | 1.0.0 | 37 | schemas/exception.v1.schema.json |
| AIES AI Incident v1 | 1.0.0 | 19 | schemas/incident.v1.schema.json |
| AIES MCP Server Record v1 | 1.0.0 | 16 | schemas/mcp-server-record.v1.schema.json |
| AIES Model Record v1 | 1.0.0 | 16 | schemas/model-record.v1.schema.json |
| AIES Prompt Release v1 | 1.0.0 | 17 | schemas/prompt-release.v1.schema.json |
| AIES Risk Register v1 | 1.0.0 | 13 | schemas/risk-register.v1.schema.json |
| AIES Statement of Applicability v1 | 1.0.0 | 24 | schemas/statement-of-applicability.v1.schema.json |
| AIES Tool Contract v1 | 1.0.0 | 17 | schemas/tool-contract.v1.schema.json |
node tools/conformance/cli.mjs assess \
--manifest records/ai-system.json \
--soa records/statement-of-applicability.json \
--catalog records/control-catalog.json \
--evidence records/evidence-bundle.json \
--exception records/exception-DAT-010.json \
--as-of 2026-07-16T00:00:00.000Z \
--format jsonnode --test \
tools/conformance/test/conformance.test.mjs \
reference/test/harness.test.mjs \
eval/test/evaluation.test.mjsCLI output is a deterministic assessment of supplied artifacts, not external certification or regulatory approval.
Normative document versions and lifecycle vocabulary are derived from the published standard sources. No controls are presented as deprecated without a canonical source record.
Current requirement
Assess normally
Still valid; replacement or retirement announced
SoA identifies migration plan
No longer accepted in new claims
Preserve ID and historical evidence
Unsafe, invalid, or legally incompatible
Suspend affected claim and reassess
Governance status is derived from repository policy files and the canonical RFC directory. Absence of an RFC record is reported as absence, not approval or rejection.
This document defines how AIES decisions are proposed, reviewed, approved, and reversed.
This policy defines maintainer eligibility, responsibilities, access, inactivity, and removal.
This process governs high-impact AIES proposals before implementation.
This policy defines compatibility guarantees for AIES documents, URLs, generated artifacts, website behavior, and releases.
No RFC records are present in the canonical rfcs/ directory.
Canonical RFC records discovered: 0