APRF · v0.10.0 · working-draft

AI Production Readiness Framework

The vendor-neutral specification for AI production readiness—whether an AI application can safely operate in production.

Eight domains, measurable checks, gated profiles, and a dual maturity/criticality model. Distinct from broad AI readiness: APRF measures production gates, not strategy workshops. Working draft published by StackRail (working draft publisher); normative stewardship is intended to transfer to a neutral working group.

SpecificationDocumentsParticipate (RFCs)Self-attest (quiz)

Purpose

Give practitioners a clear, measurable answer on AI production readiness—whether an AI application is ready for production operation—not whether a demo worked, a checklist was ticked, or a single control domain looks green. The AI Production Readiness Framework (APRF) ships today as a public working draft.

Terminology

AI readiness
Organizational and program preparedness to adopt AI (people, process, governance, data). Broader than production gates for one system.
AI production readiness
Whether a specific AI application can safely operate in production under real users, attackers, and cost—measured with pass/fail controls.
AI Production Readiness Framework (APRF)
The vendor-neutral working-draft specification that defines domains, checks, profiles, and conformance rules for AI production readiness.

What APRF specifies

A taxonomy of engineering domains and pillars; checks with artifacts and pass conditions; profiles that gate production by criticality; and rules for versioning, extension, and conformance claims.

What APRF is not

  • Not only “Is this secure?”
  • Not only “Is this compliant?”
  • Not only “Does it work?”

Non-goals

  • Replacing NIST AI RMF, ISO/IEC 42001, SOC 2, or OWASP as peer frameworks.
  • Granting certification authority to the working-draft publisher by default.
  • Locking the taxonomy behind proprietary tooling or paywalled normative text.

Related work

APRF does not replace NIST AI RMF, ISO/IEC 42001, OWASP, SOC 2, or similar peer frameworks. Machine-readable crosswalks support gap analysis and evidence reuse; they are informative alignment only—not certification or endorsement.

View crosswalks · Spec crosswalks[]

Documents

Normative and informative artifacts for APRF v0.10.0. Framework SemVer and JSON Schema path versions are independent—cite both when validating.

Normative repository
github.com/stackrail-io/APRF
License intent
Normative text and machine-readable catalogs remain freely available under a permissive documentation license; intended to transfer with stewardship.
Changelog
v0.10.0 · CHANGELOG + CI validators, Regulated Assess, WA/SLSA crosswalks, expanded N/A · published 2026-07-25
ID stability
Pillar IDs (APRF-NN) and check IDs (e.g. AUTHN-M1) are immutable once published in a MINOR+. Deprecate; do not reuse. Deprecation support: N-1 minor versions.

Applicability

Vendor-neutral and system-agnostic by design. The same pillars and gate semantics apply whether you call a hosted model API or run weights yourself, and whether you ship a single assistant or a multi-agent system—subject to formal lenses when a system type adds mandatory checks under existing pillars.

  • ProvidersAny model provider or runtime. Conformance is claimed against checks and profiles, not against a vendor list.
  • SystemsAny production AI application class. Lenses (e.g. RAG, agents, voice, coding agents) extend mandatory gates without inventing parallel taxonomies.
  • ExtensionsOrganizations MAY add private checks with IDs prefixed x-. Custom checks MUST NOT claim APRF conformance by themselves.

Domains

Top-level taxonomy. Open the catalog for full pillar specifications, checks, and evidence.

8 domains · 27 pillars · catalog at /aprf/

  1. 01

    Security

    7 pillars

    Adversarial resistance, identity, authorization, secrets, tool mediation, supply chain, and hardened runtime for AI systems.

    Adversarial Security · Authentication · Authorization · Secrets · Tool Safety · Supply Chain Integrity · Infrastructure

  2. 02

    Safety & Responsible AI

    2 pillars

    Harm prevention, content safety, fairness, and transparency—NIST trustworthiness characteristics distinct from adversarial security.

    Safety & Responsible AI · Explainability & Transparency

  3. 03

    Data

    3 pillars

    Privacy, corpus and index governance, data quality, and memory integrity across AI pipelines.

    Data Privacy · Data Governance & Quality · Memory Management

  4. 04

    Model & Prompt Lifecycle

    4 pillars

    Model selection and versioning, prompt and context as production artifacts, and continuous evaluation gates.

    Model Governance · Prompt Engineering · Context Engineering · Evaluation

  5. 05

    Agents & Autonomy

    2 pillars

    Agent charters, autonomy limits, A2A trust, and human oversight for high-impact actions.

    Agent Governance · Human Approval

  6. 06

    Reliability & Operations

    5 pillars

    Observability, performance SLOs, graceful degradation and continuity, change management with rollback, and incident readiness.

    Observability · Performance & SLO Engineering · Reliability & Continuity · Change Management & Release · Incident Readiness

  7. 07

    Cost

    1 pillar

    Spend bounds, attribution, caching, routing, and denial-of-wallet controls for AI workloads.

    Cost Optimization

  8. 08

    Governance & Compliance

    2 pillars

    Organizational AI policy, ownership, risk acceptance, and auditable evidence of controls—without equating compliance with readiness.

    Organizational Governance · Compliance

  9. XC

    Cross-cutting concerns

    1 pillar

    Concerns that apply across every domain. They are not peer domains; they enable safe delivery of all other pillars.

    Platform Engineering

Full specifications (purpose, checks, evidence): Domain & pillar catalog.

aprf-profile-core · normative gate set

Core (Tier 2 Production)

Minimum mandatory gates for customer- or partner-facing AI. Pass this gate before claiming production readiness. Tier 3 and regulated systems must still assess the Regulated profile or full catalog.

Target criticality
Tier 2 · Production
Target capability
L3 · Defined
Gate checks
40 mandatory

Not sufficient for Tier 3

Passing Core means a customer-facing system cleared the production minimum. Mission-critical and regulated systems must use the Regulated (Tier 3) profile (aprf-profile-regulated)—Core plus Tier-3-only mandatories—or assess the full catalog at capability Level 4+.

Why these gates

  • Identity and authorization before any customer traffic (AUTHN/AUTHZ).
  • Secrets and injection/tool mediation to prevent common AI incidents (SEC/TOL).
  • Safety policy + eval gates so quality/harm regressions cannot silently ship (SAF/EVL).
  • Pinned prompts/models with promotion evidence (PRM/MOD).
  • Observability, timeouts, degraded mode, and tested rollback (OBS/REL/CHG).
  • Spend ceilings to prevent denial-of-wallet (COST).
  • Named owners so gates have stewards (ORG-M2).

Check list

40 gates · 8 domains · expand a domain to read requirements

Full pillar catalog
01Security13 gates · 7 pillars
APRF-01Adversarial Security2 checks
  • SEC-M1

    Untrusted input shall never authorize privileged actions without server-side policy

  • SEC-M3

    Abuse, jailbreak, and injection testing shall gate customer-facing releases

APRF-10Authentication2 checks
  • AUTHN-M1

    Customer-facing AI APIs shall reject unauthenticated callers

  • AUTHN-M2

    Service-to-service and MCP connections shall use strong machine identity

APRF-11Authorization2 checks
  • AUTHZ-M1

    Authorization shall be enforced server-side for AI features, tools, and retrieval

  • AUTHZ-M2

    Multi-tenant isolation shall be tested for AI data and memory paths

APRF-12Secrets2 checks
  • SEC2-M1

    Production secrets shall live in a secrets manager and not in prompts, repos, or prod notebooks

  • SEC2-M2

    Logging and tracing pipelines shall redact secret-like patterns

APRF-05Tool Safety3 checks
  • TOL-M1

    Every tool invocation shall be authorized server-side independent of model output

  • TOL-M2

    Tools shall be allowlisted per agent/workload; unknown tools shall not be inventable at runtime

  • TOL-M3

    High-impact tools shall require additional gates (approval, dual control, or policy engine)

APRF-24Supply Chain Integrity1 check
  • SCI-M2

    MCP servers and high-impact tools shall be inventoried, version-pinned, and reviewed before production use

APRF-20Infrastructure1 check
  • INF-M1

    AI data stores and control planes shall not be publicly exposed without authenticated edge controls

02Safety & Responsible AI3 gates · 1 pillar
APRF-25Safety & Responsible AI3 checks
  • SAF-M1

    A documented harm taxonomy and refusal/escalation policy shall exist for the product domain

  • SAF-M2

    Automated safety evaluation gates shall run on relevant releases

  • SAF-M3

    Users shall be disclosed when interacting with AI where required by policy or law

03Data3 gates · 2 pillars
APRF-18Data Privacy2 checks
  • PRI-M1

    Data flowing to models shall be classified; sensitive classes shall have documented handling rules

  • PRI-M3

    Users or tenants shall have deletion/export paths covering AI memory and logs where required

APRF-04Memory Management1 check
  • MEM-M1

    Memory shall be isolated by tenant (and user where required) with tested boundaries

04Model & Prompt Lifecycle5 gates · 3 pillars
APRF-07Model Governance1 check
  • MOD-M1

    Production shall use pinned model identifiers; aliases like “latest” are forbidden on critical paths

APRF-02Prompt Engineering2 checks
  • PRM-M1

    Every production prompt shall have an immutable version identifier and owner

  • PRM-M2

    Prompt changes shall go through review and be tied to evaluation results before release

APRF-08Evaluation2 checks
  • EVL-M1

    Critical customer journeys shall have automated offline eval suites on every relevant change

  • EVL-M2

    Release gates shall enforce numeric minimum thresholds for quality and safety metrics

05Agents & Autonomy3 gates · 2 pillars
APRF-06Agent Governance1 check
  • AGN-M2

    Hard limits shall exist on steps, wall-clock time, and recursive agent spawning

APRF-17Human Approval2 checks
  • HUM-M1

    High-impact action classes shall be inventoried and gated by human approval in production

  • HUM-M3

    Approval shall not be bypassable via alternate agent or API paths

06Reliability & Operations10 gates · 5 pillars
APRF-09Observability2 checks
  • OBS-M1

    Distributed traces shall link user request → model calls → tools → outcome

  • OBS-M2

    Token usage and cost shall be attributable per request/feature/tenant

APRF-28Performance & SLO Engineering1 check
  • PERF-M1

    Critical AI user journeys shall have documented latency and availability SLOs

APRF-14Reliability & Continuity2 checks
  • REL-M1

    All model and tool calls shall have timeouts and bounded retries

  • REL-M2

    Critical user journeys shall define a degraded mode when AI is unavailable

APRF-15Change Management & Release3 checks
  • DEP-M1

    A promotion path shall exist from non-prod to prod for prompts, models, and tools

  • CHG-M1

    Prior production versions of prompts and model pins shall be retained and restorable

  • CHG-M3

    Rollback shall be tested in a drill or real event on a defined cadence

APRF-21Incident Readiness2 checks
  • INC-M1

    AI-specific incident playbooks shall exist for abuse, leakage, bad actions, and provider outage

  • INC-M2

    On-call shall be able to execute containment: pause agents, disable tools, roll back prompts/models

07Cost2 gates · 1 pillar
APRF-13Cost Optimization2 checks
  • COST-M1

    Production AI workloads shall have hard spend or rate limits

  • COST-M3

    Retry and loop policies shall prevent unbounded cost amplification

08Governance & Compliance1 gate · 1 pillar
APRF-29Organizational Governance1 check
  • ORG-M2

    Each production AI system shall have named owners for critical APRF domains

Machine-readable profile: Spec profiles[] · Sample attestations: /aprf/samples/ · Optional self-attestation quiz (not evidence-backed conformance): /aprf/assess/.

Conformance claims

What “implements APRF” or “APRF-ready” must mean. Vague percentage badges are not conformance.

Required citation

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

  • self-attestation

    Self-attestation

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

  • third-party

    Third-party assessment

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

Reference self-attestation tool

Core or Regulated profile quiz with optional lenses: one question per gate, on-screen gate result, client download of full aprf-self-attestation JSON, optional save (POST /api/aprf/submit) that emails a branded summary with a private /aprf/results/{token} link to refetch the attestation. AGN/HUM/TOL/MEM gates offer formal N/A. Unanswered checks count as failed.

Path: /aprf/assess/ · Export: aprf-self-attestation · Levels: self-attest vs third-party.

Commercial products that implement APRF (including StackRail) are separate from this normative draft. Product features do not redefine gate semantics.

Stewardship

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

Current phase
Working draft
StackRail publishes the draft, hosts the machine-readable spec, and accepts RFCs. Normative intent is public; stewardship is not yet transferred.
Working-draft publisher
StackRail
Role: working draft publisher. Not a permanent normative owner.

Path

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

Interim advisory (recruiting)

StackRail is recruiting an interim advisory board (≥3 independent organizations) before MAJOR/MINOR releases require advisory consensus. Volunteer via the interim contact; a seat does not grant commercial preference or veto over peer RFCs.

Target: 5 seats · ≥3 independent organizations.

  • Independent security / AppSec practitioner
  • AI platform or model vendor (non-publisher)
  • Production AI operator (practitioner)
  • Standards / SDO-adjacent participant (e.g. OWASP/CNCF)
  • Researcher or academic

Transfer triggers

  • At least three independent organizations actively reviewing RFCs for two consecutive MINOR cycles.
  • Published interim charter signed by advisory participants.
  • Public RFC backlog with decisions recorded for ≥90 days.
  • Willingness of a neutral host (foundation, consortium, or multi-party WG) to accept stewardship.

Full charter, RFC stages, and decision log: /aprf/rfc/ · Machine-readable: Spec stewardship · Normative repo: github.com/stackrail-io/APRF.

FAQ

Short answers for the terms and claims this working draft uses.

What is the AI Production Readiness Framework?
The AI Production Readiness Framework (APRF) is a vendor-neutral working-draft specification for AI production readiness: eight domains, measurable checks, gated profiles, and a dual maturity/criticality model—not a vanity readiness percentage.
What is AI production readiness?
AI production readiness means a specific AI application can safely operate in production under real users, attackers, and cost—measured with pass/fail engineering controls, not demos or strategy workshops.
What is AI readiness?
AI readiness is broader organizational and program preparedness to adopt AI (people, process, governance, data). It is not the same as AI production readiness for a single system. APRF focuses on production gates.
Who publishes APRF?
StackRail is the working-draft publisher. Normative stewardship is intended to transfer to a neutral multi-stakeholder working group via a public RFC process. APRF does not replace NIST AI RMF, ISO/IEC 42001, OWASP, or similar peer frameworks.
Is an APRF assessment a certification?
No. The reference /aprf/assess/ tool is a self-attestation quiz against a pinned APRF version—not evidence-backed third-party certification and not proof of NIST, ISO, or SOC 2 compliance. Conformance claims must cite version, tier, capability, profile, and open blockers.
Where is the machine-readable APRF specification?
The canonical machine-readable spec is at /aprf/spec/. Definitions of AI readiness and AI production readiness: /guides/ai-readiness/ and /guides/ai-production-readiness/. Human depth: /aprf/how/.