← APRF overview

v0.10.0 · working-draft

How APRF works

Depth behind the overview: dual maturity model, lenses, evaluation rules, peer crosswalks, and stewardship. Working draft — not a ratified standard.

MaturityLensesEvaluationCrosswalksGovernance

Maturity & criticality

APRF separates two axes that older single ladders conflate: capability maturity (how disciplined the engineering system is) and criticality (blast radius). Required maturity is a function of tier—a small team shipping a high-blast-radius system must still climb the capability ladder.

Criticality tiers

Classify the system first. Then attain at least the required capability level.

  1. Tier 0

    Sandbox

    Requires L1 · Initial

    Non-customer experiments. Failures are contained to the builder’s environment.

    • Hackathon prototype
    • Local notebook agent
    • Throwaway prompt playground

  2. Tier 1

    Internal

    Requires L2 · Managed

    Employee-only or tightly gated internal use. Organizational impact only.

    • Internal knowledge assistant
    • Employee coding agent on non-prod systems

  3. Tier 2

    Production

    Requires L3 · Defined

    Customer- or partner-facing. Material product, privacy, or financial impact if it fails.

    • Customer support chatbot
    • SaaS RAG feature
    • MCP tools touching customer data

  4. Tier 3

    Mission Critical

    Requires L4 · Quantitatively Managed

    High blast radius: safety, regulated decisions, large financial movement, or critical infrastructure dependency.

    • Medical triage assistant
    • Autonomous trading or payments agent
    • Life-safety or critical-infrastructure copilots

Capability maturity

Pillar checks declare the capability level at which they become expected. Attainment for a level means all mandatory checks at that level (for the system's criticality) pass.

  1. Level 1

    Initial

    Ad-hoc practices. Works in demos; controls are informal or absent. Acceptable only for Tier 0 sandboxes.

    • No claim of production readiness
    • Changes may be undocumented console edits
    • Failures do not trigger organizational incident process
    • Spend and rate limits are owner-watched at best

  2. Level 2

    Managed

    Basic repeatable controls: auth, logging, spend caps, secret hygiene. Suitable baseline for Tier 1 (internal) systems.

    • Authenticated access for non-public surfaces
    • Request/cost logging exists
    • Hard spend or rate ceilings prevent runaway usage
    • Secrets are not hardcoded in production prompts or clients

  3. Level 3

    Defined

    Documented, enforced controls across critical domains. Mandatory checks for Tier 2 (customer production) are met.

    • Promotion path and rollback for prompts, models, and tools
    • Server-side authz, tool mediation, and eval gates on releases
    • Traces reconstruct model → tool → outcome paths
    • AI-specific incident playbooks and named owners exist

  4. Level 4

    Quantitatively Managed

    SLOs, audited evidence, formal governance, and measured quality/safety signals. Expected floor for many Tier 3 systems.

    • Published SLOs for latency, availability, and at least one quality/safety signal
    • Auditable evidence packs for critical controls
    • Change control and ownership across teams
    • Privacy/compliance obligations mapped to technical controls

  5. Level 5

    Optimizing

    Continuous improvement: automated gates, dual-control for irreversible actions, chaos/continuity drills, near-zero blast-radius ambiguity.

    • Dual-control (or equivalent) for irreversible high-impact actions
    • Continuous evaluation blocks unsafe releases automatically
    • Continuity and failure drills on a defined cadence with recorded results
    • Blast radius for every tool, agent, and data path is documented and enforced

Extension

Formal lenses

System-type overlays that add mandatory gates under existing pillars—no new top-level domains. Pair with Core Profile for RAG, agents, voice, or coding-agent systems. Counts below are gates beyond Core (lens lists may also reinforce checks already in Core).

RAG

+8 beyond Core · 14 listed

aprf-lens-rag

Retrieval-augmented generation: corpus ownership, context labeling, memory isolation, and retrieval-quality gates.

Applies to: RAG · Chatbots · AI Agents

  • Retrieval corpora need owners, versioning, and promotion controls (DG).
  • Retrieved content must be sized, labeled, and access-controlled in context (CTX).
  • Vector/memory stores inherit tenant isolation and retention (MEM).
  • Eval gates must cover retrieval quality and grounding regressions (EVL).

DG-M1 · DG-M2 · DG-M3 · CTX-M1 · CTX-M2 · CTX-M3 · MEM-M1 · MEM-M2 · MEM-M3 · PRI-M1 · EVL-M1 · EVL-M2 · SEC-M1 · OBS-M1

Agents

+6 beyond Core · 18 listed

aprf-lens-agents

Autonomous and tool-using agents: charters, step budgets, tool mediation, human gates, and kill switches.

Applies to: AI Agents · Multi-agent systems · MCP Servers · A2A Systems · Coding Agents · Autonomous systems

  • Every production agent needs a charter and hard step/time limits (AGN).
  • Tools fail closed with allowlists and schema validation (TOL).
  • High-impact actions require non-bypassable human approval (HUM).
  • Agent identities stay least-privilege; loops cannot burn unbounded spend (AUTHZ/COST).

AGN-M1 · AGN-M2 · AGN-M3 · AGN-M4 · TOL-M1 · TOL-M2 · TOL-M3 · TOL-M4 · HUM-M1 · HUM-M2 · HUM-M3 · AUTHZ-M1 · AUTHZ-M2 · AUTHN-M2 · COST-M3 · OBS-M1 · REL-M1 · REL-M3

Voice

+2 beyond Core · 16 listed

aprf-lens-voice

Voice and telephony AI: session identity, privacy of recordings, latency SLOs, safety, and escalation paths.

Applies to: Voice AI · Chatbots

  • Telephony sessions must authenticate before privileged tools (AUTHN).
  • Call audio and transcripts are sensitive personal data (PRI).
  • Latency and degraded mode matter more under real-time constraints (PERF/REL).
  • Safety refusals and human escalation must work on voice channels (SAF/HUM).

AUTHN-M1 · AUTHN-M2 · PRI-M1 · PRI-M3 · OBS-M1 · OBS-M3 · PERF-M1 · PERF-M2 · REL-M1 · REL-M2 · SAF-M1 · SAF-M2 · HUM-M1 · INC-M1 · COST-M1 · TOL-M1

Coding agents

+15 beyond Core

aprf-lens-coding

IDE and repo-connected coding agents: sandboxing, secret hygiene, tool allowlists, supply chain, and human gates for destructive changes.

Applies to: Coding Agents · AI Agents · MCP Servers

  • Coding agents need explicit charters, kill switches, and peer auth for multi-agent hops (AGN).
  • Shell/file tools require schema validation and fail-closed allowlists (TOL).
  • Repo and cloud credentials must stay out of prompts; model path stays bounded (SEC).
  • Dependency and model supply chain plus platform sandboxes reduce blast radius (SCI/DX/INF).

AGN-M1 · AGN-M3 · AGN-M4 · TOL-M4 · HUM-M2 · SEC-M2 · SEC-M4 · SCI-M1 · SCI-M3 · PRM-M3 · MOD-M2 · AUTHZ-M3 · DX-M1 · DX-M2 · INF-M2

Apply lenses in the reference assessment. Machine-readable: /aprf/spec/ → lenses[].

Evaluation methodology

APRF gated evaluation. Gates are binary. Recommended controls produce per-domain scores only. There is no single averaged “readiness percentage.”

Forbidden

  • A single averaged “readiness score” across all pillars
  • Trading a failed mandatory check against strong recommended scores
  • Conformance badges that omit open blockers or APRF version
  • Claiming Tier 3 / regulated readiness from Core Profile alone
  1. 01

    Classify criticality

    Assign Tier 0–3. This sets the required capability floor.

  2. 02

    Choose catalog, profile, and lenses

    Startups may assess Core Profile (Tier 2 minimum). Add formal lenses (RAG, Agents, Voice, Coding agents) when those system types apply. Full catalog for Tier 3 / enterprise / regulated.

  3. 03

    Collect evidence

    For each applicable check, produce the named artifact and evaluate the pass condition.

  4. 04

    Evaluate the gate

    All in-scope mandatory checks must pass or be formally marked notApplicable (N/A) with rationale. Failures and unanswered checks are blockers. Profile∪lens assessments only gate on the union of those check IDs. N/A is intended for agent, human-approval, tool-safety, and memory gates when those system types do not apply — not as a substitute for incomplete evidence.

  5. 05

    Compute capability attainment

    Per pillar: highest level L where all mandatory checks ≤ L pass. System attainment = minimum across pillars.

  6. 06

    Score recommended controls per domain

    Optional 0–100 domain scores from recommended checks, weighted by pillar severity. Never folded into the gate.

  7. 07

    Report

    Publish: APRF version, tier, profile (if any), lenses (if any), required capability, gate pass/fail, critical blockers, capability attained, per-domain recommended scores, evidence index.

Required capability by tier

  • Tier 0 · Sandboxrequires L1 · Initial
  • Tier 1 · Internalrequires L2 · Managed
  • Tier 2 · Productionrequires L3 · Defined
  • Tier 3 · Mission Criticalrequires L4 · Quantitatively Managed

Run the reference assessment and export a self-attestation: /aprf/assess/

Machine-readable spec (v0.10.0): /aprf/spec/

Compatibility

Crosswalks

Machine-readable maps from APRF pillars and checks to peer frameworks. Use them for gap analysis and evidence reuse.

Not certification

Crosswalks are informative alignment only. They do not constitute NIST, ISO/IEC, OWASP, AICPA, or other endorsement—and passing APRF does not imply SOC 2, ISO 42001, or similar certification.

NIST AI Risk Management Framework

1.0 (2023)
Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement.

ISO/IEC 42001

2023 (clause-level conceptual)
Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement. Not a substitute for a certified AI management system.

OWASP Top 10 for Large Language Model Applications

2025
Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement.

SOC 2 Trust Services Criteria

2017 (with 2022 revisions) — evidence reuse
Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement. Passing APRF does not imply SOC 2 compliance.

AWS Well-Architected Framework

WA Framework pillars + Generative AI Lens (conceptual)
Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement. Not an AWS Well-Architected Lens review or AWS certification.

SLSA (Supply-chain Levels for Software Artifacts)

v1.0 — conceptual levels / provenance
Peer source

Informative alignment only. Does not constitute certification, accreditation, or official endorsement. APRF alignment does not confer a SLSA level attestation.

Full JSON: /aprf/spec/ → crosswalks[]

Governance

Versioning, stewardship, extension, and certification rules for APRF as a working draft moving toward a ratifiable standard.

Version
0.10.0
working-draft · CHANGELOG + CI validators, Regulated Assess, WA/SLSA crosswalks, expanded N/A
Published 2026-07-25
Publisher
StackRail
working-draft-publisher
Phase: Working draft. Multi-stakeholder technical oversight (vendors, practitioners, OWASP/CNCF-adjacent participants) with public RFCs — not a single commercial owner.

Stewardship path

Evolve APRF into a ratifiable, vendor-neutral production-readiness standard for AI systems through open technical consensus—not through a single commercial owner.

  1. Working draft · current
  2. Interim advisory board
  3. Neutral working group
  4. Foundation / SDO home

Full charter, RFC stages, transfer triggers: /aprf/rfc/

RFC process

APRF Request for Comments. Minimum review 14 days. Template APRF-RFC-0000.

Working-draft phase: publisher decides after review window, with public rationale. Interim advisory+: majority of active advisors; ties escalate to published deadlock procedure.

Versioning

Pillar IDs (APRF-NN) and check IDs (e.g. AUTHN-M1) are immutable once published in a MINOR+. Deprecate; do not reuse.

  • MAJOR: breaking changes to domain IDs, check IDs, or gate semantics
  • MINOR: new domains, pillars, or checks; non-breaking field additions
  • PATCH: editorial clarifications to prose, artifacts, or pass conditions

Deprecation

Deprecated checks and pillars remain in the spec for at least one MINOR cycle (N−1), marked deprecated, with a replacement ID.

Support window: N-1 minor versions

Extension

Formal lenses (RAG, Agents, Voice, Coding agents) add mandatory checks under existing pillars. Claim lenses in assessments and attestations when those system types apply.

Organizations MAY add private checks with IDs prefixed x- (e.g. x-ACME-M1). Custom checks MUST NOT claim APRF conformance by themselves.

See Formal lenses.

Certification

  • Self-attestation

    Organization publishes assessment results + evidence index against a pinned APRF version. No third-party validation.

  • Third-party assessment

    Independent assessor verifies gate blockers and samples evidence. Intended for Tier 3 and regulated use.

Conformance statements MUST cite APRF version, criticality tier, attained capability level, profile (if any), and list any open blockers. No single percentage badge.

Compatibility

  • NIST AI RMF
  • ISO/IEC 42001
  • SOC 2 Trust Services Criteria (evidence reuse)
  • OWASP LLM Top 10
  • AWS Well-Architected (conceptual)
  • SLSA / supply-chain

Machine-readable maps for NIST AI RMF, ISO/IEC 42001, OWASP LLM Top 10, SOC 2, AWS Well-Architected, and SLSA ship in the APRF spec under crosswalks[]. Informative alignment only — not certification.

Browse mappings: Crosswalks

Full machine-readable document: GET /aprf/spec/