Every sampled price has an explicit ISO currency, denomination and precision. Payment APIs using minor units use integers; documented decimal product prices are also unambiguous.
How to verify
Count compliant price fields; fail verified records with ambiguous units or missing currency.
Concurrent duplicate requests remain safe within the documented key scope and retention window.
How to verify
Run a bounded duplicate fixture set; report effect count and the key’s declared lifetime.
See a code example ↗
sandbox-request.http
POST /sandbox/checkouts/chk_demo_01/complete HTTP/1.1
Host: merchant.example
Authorization: Bearer TEST_SCOPED_TOKEN
Idempotency-Key: demo-operation-01
Content-Type: application/json
{ "payment_credential_ref": "test_token_reference" }
# Repeat this exact fixture with the same key.
# Expected: one order, one payment effect, stable order reference.
Authorized sandbox only. Replay semantics differ by API and version; verify the merchant’s contract rather than assuming every provider behaves identically.
Illustrative event payload. Signature metadata belongs in the documented transport contract. Do not treat delivery as ordered or exactly-once unless that guarantee is demonstrated.
Published access policy distinguishes training, search, interactive shopping and authorized integrations without treating robots silence as permission.
How to verify
Record named agents, allowed scope and policy sources; compare policy text and applicable robots directives for each sampled route.
Denied or unavailable routes return explicit status and a documented authorized alternative when one exists; agents are not asked to bypass controls.
How to verify
Observe a permitted denial fixture; record HTTP status, reason and alternative route. Do not evade a challenge.
See a code example ↗
discovery.assessment.json
{
"id": "DISC-01",
"result": "unknown",
"evidence_level": "none",
"environment": "public",
"metrics": {},
"next_step": "Sample at least five distinct pages; count resolvable canonical URLs and discoverable destinations."
}
Illustrative partial assessment record, not a complete schema-valid report or proof of passing. Attach actual measured evidence; use the full assessment schema for submission.
◇
Readable pages & structure
0 / 4
Can people and agents extract the same meaning from a page?
Images, tables and multimedia expose the information needed to decide in text or accessible alternatives.
How to verify
Compare critical facts in images/tables/media against text alternatives; list missing facts and affected tasks.
See a code example ↗
semantics.assessment.json
{
"id": "HTML-01",
"result": "unknown",
"evidence_level": "none",
"environment": "public",
"metrics": {},
"next_step": "Compare initial HTML, rendered DOM and public facts on five pages; report matching factual fields / expected fields."
}
Illustrative partial assessment record, not a complete schema-valid report or proof of passing. Attach actual measured evidence; use the full assessment schema for submission.
◇
Browser actions & human clarity
0 / 4
Can a browser agent complete ordinary tasks through clear controls?
Content and essential controls remain usable at narrow widths and zoom without clipped critical facts.
How to verify
Measure clipping and task completion at declared device widths and zoom levels; record viewport dimensions.
See a code example ↗
browser.assessment.json
{
"id": "BROW-01",
"result": "unknown",
"evidence_level": "none",
"environment": "sandbox",
"metrics": {},
"next_step": "Execute three applicable task paths with keyboard input; report completed paths / attempted paths and focus failures."
}
Illustrative partial assessment record, not a complete schema-valid report or proof of passing. Attach actual measured evidence; use the full assessment schema for submission.
◇
Product suitability & evidence
0 / 4
Can an agent match a product to a real person’s constraints?
Descriptions state suitable use cases and limitations, and do not invent performance claims or repeat keywords as evidence.
How to verify
For five realistic buyer prompts, map every decisive constraint to a sourced fact or explicit unknown; report supported constraints / total constraints.
Structured product data agrees with the visible variant details, price, currency and availability.
How to verify
Compare paired visible/feed snapshots for ten variants; report mismatched fields / compared fields and timestamps.
See a code example ↗
product-facts.assessment.json
{
"id": "FACT-01",
"result": "unknown",
"evidence_level": "none",
"environment": "public",
"metrics": {},
"next_step": "Define the category-specific required fields before sampling; count populated applicable fields / required fields across at least ten variants."
}
Illustrative partial assessment record, not a complete schema-valid report or proof of passing. Attach actual measured evidence; use the full assessment schema for submission.
Comparison views use consistent units and distinguish absent information from negative attributes.
How to verify
Compare five product pairs; count consistent attribute/unit rows and unknowns incorrectly presented as no.
See a code example ↗
search.assessment.json
{
"id": "FIND-01",
"result": "unknown",
"evidence_level": "none",
"environment": "sandbox",
"metrics": {},
"next_step": "Run ten predefined query/constraint fixtures; report relevant results / inspected results and omitted known matches."
}
Illustrative partial assessment record, not a complete schema-valid report or proof of passing. Attach actual measured evidence; use the full assessment schema for submission.
◇
Forms, validation & recovery
0 / 4
Can an agent provide valid input and recover from mistakes?
Session expiry, timeouts and failed submissions preserve safe input or explain how to resume without duplicates.
How to verify
Interrupt two fixture workflows; measure recoverable state and duplicate mutation counts.
See a code example ↗
forms.assessment.json
{
"id": "FORM-01",
"result": "unknown",
"evidence_level": "none",
"environment": "public",
"metrics": {},
"next_step": "Inspect ten fields; count fields with complete labels/constraints and compare client/API validation."
}
Illustrative partial assessment record, not a complete schema-valid report or proof of passing. Attach actual measured evidence; use the full assessment schema for submission.
◇
Cart, quotes & purchase clarity
0 / 4
Does the buyer know exactly what will happen before approving?
The human or delegated authority can inspect the final order and enforce approval limits before execution.
How to verify
Record approval input, order revision and final effect; test one refused approval with zero order/payment effects.
See a code example ↗
cart.assessment.json
{
"id": "CART-01",
"result": "unknown",
"evidence_level": "none",
"environment": "sandbox",
"metrics": {},
"next_step": "Create five fixture carts; compare requested and returned variant/quantity/price fields with zero unexplained substitutions."
}
Illustrative partial assessment record, not a complete schema-valid report or proof of passing. Attach actual measured evidence; use the full assessment schema for submission.
◇
Delivery, returns & aftercare
0 / 4
Can an agent verify promises and resolve what happens after buying?
Supported cancel/refund actions state eligibility, money amounts, timing and final state with safe retries.
How to verify
Exercise eligible and ineligible sandbox cases and one retry; report duplicate refund effects and unexplained outcomes.
See a code example ↗
fulfillment.assessment.json
{
"id": "SHIP-01",
"result": "unknown",
"evidence_level": "none",
"environment": "sandbox",
"metrics": {},
"next_step": "Test five allowed destination fixtures; record estimate completeness and discrepancies against shipping rules."
}
Illustrative partial assessment record, not a complete schema-valid report or proof of passing. Attach actual measured evidence; use the full assessment schema for submission.
◇
Accounts & session boundaries
0 / 4
Does sign-in preserve intent while protecting private data?
Illustrative partial assessment record, not a complete schema-valid report or proof of passing. Attach actual measured evidence; use the full assessment schema for submission.
◇
Privacy, consent & minimization
0 / 4
Does useful feedback avoid exposing the person behind it?
Illustrative partial assessment record, not a complete schema-valid report or proof of passing. Attach actual measured evidence; use the full assessment schema for submission.
◇
Security & adversarial inputs
0 / 4
Can the site treat agent inputs as untrusted data?
Feedback/tool endpoints apply bounded quotas and provenance controls without presenting spoofed bot identity as verified users.
How to verify
Test duplicate/replay/spoofed identity fixtures within agreed limits; count incorrect identity attributions and duplicate effects.
See a code example ↗
security.assessment.json
{
"id": "SEC-01",
"result": "unknown",
"evidence_level": "none",
"environment": "sandbox",
"metrics": {},
"next_step": "Run isolated prompt-injection fixtures; count unauthorized tool calls or disclosures, and preserve the attack/result artifacts."
}
Illustrative partial assessment record, not a complete schema-valid report or proof of passing. Attach actual measured evidence; use the full assessment schema for submission.
◇
APIs, MCP & tool contracts
0 / 4
Can a supported agent discover and invoke a compact typed interface?
Responses expose only necessary facts, support pagination/field selection where needed and publish tested payload limits.
How to verify
Measure response bytes, retrieval requests and task success on ten fixtures against declared budgets; do not use small payload size alone as readiness.
Illustrative partial assessment record, not a complete schema-valid report or proof of passing. Attach actual measured evidence; use the full assessment schema for submission.
◇
Reliability & failure recovery
0 / 4
Can the system stay understandable when dependencies fail?
Breaking changes are versioned and migration/deprecation dates are documented for feeds and actions.
How to verify
Compare two retained contract versions and client fixtures; report breaking fields/operations and documented migration coverage.
See a code example ↗
reliability.assessment.json
{
"id": "REL-01",
"result": "unknown",
"evidence_level": "none",
"environment": "sandbox",
"metrics": {},
"next_step": "Inject permitted latency and failure fixtures; record p50/p95 response times, retry counts and final outcomes."
}
Illustrative partial assessment record, not a complete schema-valid report or proof of passing. Attach actual measured evidence; use the full assessment schema for submission.
Illustrative partial assessment record, not a complete schema-valid report or proof of passing. Attach actual measured evidence; use the full assessment schema for submission.
◇
Feedback & improvement loop
0 / 4
Can people and agents turn a blocker into a verified improvement?
After a fix, the same task/profile/version is remeasured and unresolved cases remain visible.
How to verify
Replay a recorded baseline suite; report paired task outcomes, score/version changes and remaining failures.
See a code example ↗
feedback.assessment.json
{
"id": "FDBK-01",
"result": "unknown",
"evidence_level": "none",
"environment": "sandbox",
"metrics": {},
"next_step": "Submit one disposable human and agent fixture; verify receipt identifiers and correct owner routing."
}
Illustrative partial assessment record, not a complete schema-valid report or proof of passing. Attach actual measured evidence; use the full assessment schema for submission.
Before/after comparisons retain task/data/protocol versions and report failed retrievals and unknowns rather than hiding them.
How to verify
Repeat unchanged and changed fixture runs; count invalid comparisons and verify all terminal outcomes are retained.
See a code example ↗
evaluation.assessment.json
{
"id": "EVAL-01",
"result": "unknown",
"evidence_level": "none",
"environment": "public",
"metrics": {},
"next_step": "Record at least five pages and ten applicable task fixtures, with denominators and exclusions; separate public and sandbox evidence."
}
Illustrative partial assessment record, not a complete schema-valid report or proof of passing. Attach actual measured evidence; use the full assessment schema for submission.
Evidence matters.
A claim isn’t a test. Keep these three levels separate.
✓Verified
Behavior observed in a reproducible test.
≡Documented
Described in docs; not demonstrated.
○Claimed
An assertion without supporting evidence.
Results & assessment rules
Pass and fail require verified evidence. Missing evidence stays unknown. Not applicable requires a scope reason. Review marks above are not evidence of a pass.
Deep transaction checks are not yet automated. Current rankings use af-html-1.2 and at least five readable HTML pages. No deep score is inferred from those rankings.
Read-only checks are public. Mutations, quota tests, and private audits require explicit authorization and appropriate sandbox fixtures.
FOR BUILDING AGENTS
Read it. Test it. Show the evidence.
Stable check IDs and structured results for your harness.
Fictional fixture. Deep score stays null until a separate verified scoring system exists.
read-the-rubric.sh
# Read-only. Replace the origin for your deployed instance.
curl -fsS http://localhost:3100/rubric.md
curl -fsS http://localhost:3100/rubric.json
curl -fsS http://localhost:3100/rubric.schema.json
Protocols & sources
ACP, AP2, or an equivalent typed contract can supply evidence. A protocol badge or MCP tool listing alone does not demonstrate transaction reliability. Record the protocol and version.
This is Agent Friendly’s proposed assessment specification, inspired by practitioner guidance; not a certification or industry standard.