Production AI Institute · Public recordRecord
AI agent readiness check

Check whether an AI agent is ready for production.

Generate a readiness report for an agentic system: answer the controls, add an optional public GitHub evidence scan, see the gaps, and publish a clearly scoped readiness badge.

Production safety methodologyEvidence gradePublic report URLREADME badge
Readiness report

Describe the agent and answer the checks

The report weights production safety controls, public evidence signals, and operational context. Repository scanning is limited to public GitHub file paths.

0/24 checks
Private repo modeFor private repositories, run this locally and paste the file-path manifest. PAI receives paths only, not source code, commits, secrets, or file contents.
Public report and badgePublic reports create a citeable URL and an embeddable badge. This is not a credential.
D1

Input boundary

Scope, allowed sources, abuse controls, and prompt injection boundaries.

Are the agent's allowed inputs, sources, and operating scope documented?Scope docs, API contracts, product policy, or operating instructions.
Are prompt injection, untrusted content, and boundary-crossing cases tested?Red-team cases, eval fixtures, attack tests, or review notes.
Are abuse controls such as rate limits, identity checks, or input filters in place?Rate limiting, auth checks, input filters, abuse monitoring, or gateway controls.
D2

Output validation

Contracts, schemas, refusals, confidence thresholds, and failure paths.

Are outputs validated against schemas, contracts, policies, or acceptance criteria before action?JSON schema, Zod, Pydantic, validators, policy checks, or acceptance tests.
Does the system have explicit refusal, fallback, or escalation paths when confidence is low?Refusal policy, fallback branch, confidence thresholds, escalation queue, or retries.
Are output failures measured and reviewed through evals or production checks?Eval dashboards, failed-output reviews, test reports, or incident tags.
D3

Data stewardship

Classification, minimisation, retention, redaction, and vendor data access.

Is sensitive data classified before it enters prompts, tools, logs, or model providers?Data classification matrix, prompt data policy, or provider access map.
Are minimisation, retention, and redaction rules documented and enforced?Retention config, redaction layer, logging policy, or deletion process.
Can the team explain what data each model, tool, and vendor can access?Vendor inventory, tool permission map, model data policy, or DPIA.
D4

Observability

Traces, evals, incidents, drift, operational review, and production metrics.

Are prompts, tool calls, model versions, traces, and key decisions observable?Tracing, structured logs, request IDs, model version capture, or tool call records.
Are incidents, drift, refusals, hallucinations, and unsafe actions tracked over time?Incident log, drift monitor, eval trend, refusal analytics, or safety dashboard.
Are readiness metrics reviewed on a regular operational cadence?Weekly review, release readiness check, governance forum, or lab report.
D5

Deployment control

Versioning, release gates, canaries, rollbacks, and reproducibility.

Are prompt, model, tool, and policy changes versioned and reviewable?Git history, prompt registry, policy versioning, release notes, or approval trail.
Are eval gates, canary releases, rollbacks, or staged deployments used before production changes?CI eval gates, staging environments, canary config, rollback runbook, or release checklist.
Can the team reproduce which agent version produced a given output or action?Trace IDs, version IDs, prompt hashes, deployment metadata, or audit records.
D6

Human oversight

Autonomy limits, approvals, escalations, overrides, and audit trails.

Are high-impact or irreversible actions gated by human review?Approval workflow, policy gate, review queue, sign-off logs, or role-based permissions.
Are autonomy levels, escalation rules, and manual override paths documented?Autonomy matrix, escalation policy, override procedure, or operator handbook.
Are human approvals and interventions logged for audit and learning?Approval logs, intervention records, audit trail, or post-action review.
D7

Security posture

Tool permissions, secrets, agent threat testing, and integration risk.

Are tool permissions, secrets, credentials, and external actions least-privilege by default?Scoped tokens, permission manifests, secret scanning, isolated tools, or RBAC.
Are agent-specific threats such as prompt injection, tool abuse, and data exfiltration tested?Threat model, red-team tests, security review, or adversarial evals.
Are dependency, provider, and integration risks reviewed before production release?Dependency review, provider risk register, integration review, or security checklist.
D8

Ecosystem resilience

Provider fallbacks, dependency inventory, portability, and degraded modes.

Can the system degrade gracefully if a model, provider, tool, or API fails?Fallback model, degraded mode, retry policy, circuit breaker, or incident playbook.
Is there a documented dependency inventory for models, vendors, datasets, and tools?Dependency inventory, vendor list, model card registry, or tool manifest.
Are portability, fallback, and exit paths considered for critical capabilities?Provider abstraction, fallback plan, exit plan, or compatible API layer.

The generated report separates self-reported controls from public evidence. It is a diagnostic report, not a certification or endorsement.

Run it over a repo

Paste any public GitHub repository into the form, or use private repo mode with a local `git ls-files` manifest. The scanner reads path evidence only: evals, schemas, tracing, runbooks, approval gates, security policy, and fallback paths.

Recently seen public agent projects

A lightweight discovery feed from public GitHub repositories tagged for AI agents. Load one, complete the checks, generate a PSF-aligned report, or view the public evidence benchmark PAI runs across recently active projects.

Share the benchmark

Teams do not need PAI approval to use the Index. They can run the report, fix gaps, publish evidence, and show how their agent maps to the standard.

View public benchmarkBuild PSF evidence packOpen control templates
Public methodology

Built to separate claims from evidence.

The methodology is deliberately conservative: equal PSF domain weighting, transparent answer values, explicit evidence grading, and a clear line between readiness signals and assurance claims.

Eight PSF domains

Input boundary, output validation, data stewardship, observability, deployment control, human oversight, security, and ecosystem resilience.

24 checks

Three focused checks per domain, scored as evidence exists, partial, not yet, or not applicable.

Repository signals

Public GitHub scans look for file-path evidence such as evals, schemas, runbooks, approvals, security policy, and fallbacks.

Not certification

The check generates a readiness report. It is not a PAI credential, endorsement, or safety guarantee.

Read methodologyPublic benchmarkEvidence packControl templatesRead the PSFResearch library
After the report

Use the score to choose the evidence path.

The readiness check is a credible starting point because it separates claims from evidence. The next step depends on whether the report surfaced deployment risk, a client opportunity, a proof package, or a team-wide rollout need.

Score exposed risk

Map the gaps to the controls they implicate.

When the Index shows gaps in a live system, the PSF names the controls that close them.

Read the PSF →

Follow the benchmark

See how public agent stacks score.

The public benchmark applies the same Index to well-known agent frameworks and publishes the results as records.

Open the benchmark →

Portfolio proof

Turn a report into a structured evidence pack.

Use the evidence pack when a team needs artifacts that survive procurement, audit, or internal review.

Build evidence pack →

Team rollout

Standardise readiness across multiple teams.

Adopt the PSF as the shared readiness vocabulary for policy, training, and operating cadence.

Read the PSF →
Public record

This record is maintained by PAI and free to cite. If something is wrong or missing, tell us. Corrections and source suggestions keep the record honest.

Follow policy changes ->Save a watch ->Submit a correction
Records are free to cite. citation guidance.
AI risk intelligence

Track what changed, read the weekly brief, and follow the public evidence record - the operator loop for production AI risk.

Live risk watch →AI risk brief →Save a watch →Public record →