# Deep Agentic Rubric

Version: dar-0.2
Status: assessment specification; deep checks are not automated by the current rankings.

A broad, evidence-based website assessment covering human clarity, agent discovery, factual retrieval, safe actions and merchant transaction engineering.

## Current ranking boundary

Rankings use af-html-1.2 and public HTML from at least five readable pages. Deep assessments are separate; no deep score is inferred from those rankings.

## Evidence levels

- **verified**: Observed in a reproducible read-only check or an explicitly authorized sandbox test.
- **documented**: Specific behavior described in current technical documentation; execution has not been demonstrated.
- **claimed**: Merchant assertion without sufficient technical or behavioral evidence.
- **none**: No usable evidence has been collected.

## Assessment rules

- Only verified evidence can produce a pass or fail. Documented or claimed evidence remains unknown until tested.
- Missing evidence is unknown, not failure. A reproduced contract violation is failure.
- Not applicable requires a written scope reason; an unsupported capability is not automatically exempt.
- Record observed_at, environment, source URL, method, and artifacts. Reassess evidence after contract changes.
- Deep assessments do not replace the current HTML ranking. No new weighted score is published by this specification.
- Use read-only public discovery by default. Mutating, quota, and webhook tests require an authorized sandbox and disposable fixtures. Never place live orders or intentionally exhaust a production quota.

## 1. Structured catalog

Can an agent read current products, prices, and availability without interpreting a screen?

### CAT-01: Parseable products

Pass condition: A structured feed or API returns stable product and variant IDs, explicit availability enums, and machine-readable attributes.

Verification: Validate the declared JSON/XML schema on a recorded sample; report valid records / sampled records.

Required access: public_read

### CAT-02: Unambiguous prices

Pass condition: 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.

Verification: Count compliant price fields; fail verified records with ambiguous units or missing currency.

Required access: public_read

### CAT-03: Cache & freshness contract

Pass condition: The response exposes an ETag or equivalent revision marker and documentation states a freshness interval.

Verification: Record response headers, revision, and declared interval. Documentation alone does not establish freshness.

Required access: public_read

### CAT-04: Feed matches checkout

Pass condition: For identical variants and quantities, feed price/stock and sandbox checkout agree within the declared reconciliation window.

Verification: Compare timestamped feed and checkout snapshots; record mismatches / compared variants and maximum observed lag.

Required access: sandbox

Example (illustrative):

```json
{
  "revision": "catalog-42",
  "updated_at": "2026-10-10T18:00:00Z",
  "products": [{
    "id": "lamp_01",
    "variant_id": "warm_white",
    "availability": "in_stock",
    "price": { "amount": 12900, "currency": "USD" },
    "attributes": { "color_temperature_kelvin": 2700 }
  }]
}
```

Illustrative merchant contract. This is not an ACP feed schema. The refresh interval belongs in the published API contract.

## 2. Headless checkout

Can software complete the transaction through explicit, observable state transitions?

### CHK-01: Complete API flow

Pass condition: A documented headless flow can create/update a checkout, attach a delegated payment credential, and complete an authorized sandbox order.

Verification: Execute one authorized fixture per supported flow; report completed flows / attempted flows.

Required access: sandbox

### CHK-02: Explicit state & totals

Pass condition: Every tested mutation returns checkout/order identifiers, current state, currency, and authoritative item, tax, shipping, and total amounts.

Verification: Validate responses against the merchant schema; record missing or inconsistent fields.

Required access: sandbox

### CHK-03: Invalid transitions fail clearly

Pass condition: An unpaid or otherwise invalid completion returns the documented conflict error, typically 409, without an order or charge.

Verification: Test the invalid fixture in a sandbox; inspect both HTTP response and resulting order/payment state.

Required access: sandbox

### CHK-04: Discoverable contract

Pass condition: The API has a versioned OpenAPI specification or equivalent typed contract, including errors and supported transitions.

Verification: Fetch and validate the contract; report resolvable operations and schema errors. A spec does not prove the flow runs.

Required access: public_read

Example (illustrative):

```http
HTTP/1.1 409 Conflict
Content-Type: application/json

{
  "error": {
    "code": "payment_required",
    "message": "Attach an authorized payment credential first."
  },
  "checkout_id": "chk_demo_01",
  "state": "awaiting_payment",
  "total": { "amount": 12900, "currency": "USD" }
}
```

Example error contract, not a live API response. An HTTP status alone cannot prove that no side effect occurred.

## 3. Scoped authorization

Does the merchant act only within authority the buyer actually delegated?

### AUTH-01: No raw payment secrets

Pass condition: The agent-facing payment flow accepts a delegated token or mandate, with no requirement for raw card numbers or account secrets.

Verification: Inspect the contract and authorized test trace with redacted credential values.

Required access: sandbox

### AUTH-02: Scope is enforced

Pass condition: The authorization binds allowed merchant/action, maximum amount, currency, and expiry or equivalent restrictions.

Verification: Test in-scope and out-of-scope fixtures; count unauthorized actions accepted.

Required access: sandbox

### AUTH-03: Fail closed

Pass condition: Expired, invalid, revoked, or unverifiable authorization is rejected before any charge or order side effect.

Verification: Replay each negative fixture and inspect the authoritative order/payment state.

Required access: sandbox

### AUTH-04: Credentials stay redacted

Pass condition: Observed agent and merchant trace artifacts contain references or redacted tokens, without raw payment secrets.

Verification: Review a scoped, redacted test trace. Full production log coverage remains unknown without an authorized audit.

Required access: authorized_audit

Example (illustrative):

```json
{
  "credential_ref": "test_token_reference",
  "scope": {
    "merchant": "merchant.example",
    "action": "complete_checkout",
    "max_amount": 15000,
    "currency": "USD",
    "expires_at": "2026-10-10T18:30:00Z"
  },
  "expected_out_of_scope_result": "rejected_without_side_effect"
}
```

Test fixture description, not a valid signed credential. Validation and payment processing belong to the merchant’s supported protocol and provider.

## 4. Safe retries

Does one logical operation produce one effect, even when an agent retries?

### IDEM-01: Mutation coverage

Pass condition: Every non-idempotent mutation documents and enforces an idempotency mechanism.

Verification: Inventory the mutation operations, then test each documented mechanism in a sandbox.

Required access: sandbox

### IDEM-02: Replay has one effect

Pass condition: Repeating the same operation and payload with the same key produces one logical effect and a consistent replay result.

Verification: Send the identical sandbox fixture twice; compare order/charge counts and response identifiers.

Required access: sandbox

### IDEM-03: Key collisions are rejected

Pass condition: Reusing a key with a materially different payload returns a documented error without executing the new operation.

Verification: Change quantity or amount in a sandbox replay; inspect the resulting state.

Required access: sandbox

### IDEM-04: Concurrency & lifetime

Pass condition: Concurrent duplicate requests remain safe within the documented key scope and retention window.

Verification: Run a bounded duplicate fixture set; report effect count and the key’s declared lifetime.

Required access: sandbox

Example (illustrative):

```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.

## 5. Reliable status events

Can an agent learn what happened without repeatedly guessing the order state?

### EVT-01: Signature validation

Pass condition: The contract documents a signature scheme; valid fixtures are accepted and tampered fixtures are rejected.

Verification: Verify known-good and modified event fixtures using the documented verifier.

Required access: sandbox

### EVT-02: Stable event identity

Pass condition: Events have stable IDs and a documented delivery guarantee; repeated deliveries are deduplicated without losing updates.

Verification: Deliver the same sandbox event twice and measure processed effects.

Required access: sandbox

### EVT-03: Recoverable delivery

Pass condition: The contract documents retry/backoff and supports authorized replay, event retrieval, or equivalent gap recovery.

Verification: Miss a sandbox event, recover it using the supported mechanism, and verify the resulting state.

Required access: sandbox

### EVT-04: State-to-event consistency

Pass condition: Order state changes and emitted events reconcile without unexplained missing transitions.

Verification: Compare a scoped state/event audit. An outbox assertion alone is not behavioral verification.

Required access: authorized_audit

Example (illustrative):

```json
{
  "event_id": "evt_demo_01",
  "type": "order.confirmed",
  "occurred_at": "2026-10-10T18:05:00Z",
  "order_id": "ord_demo_01",
  "checkout_id": "chk_demo_01",
  "state": "confirmed"
}
```

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.

## 6. Attribution & limits

Can the business trace agent actions, protect capacity, and reconcile disputes?

### OPS-01: Agent attribution

Pass condition: Recorded test requests and orders resolve to an authenticated agent/client identity, not only a spoofable User-Agent string.

Verification: Follow a test request ID from client to order record; report linked requests / sampled requests.

Required access: authorized_audit

### OPS-02: Per-agent quotas

Pass condition: Quotas are defined per authenticated agent or equivalent principal, and one agent’s fixture does not consume another’s allocation.

Verification: Use a small, explicitly authorized sandbox quota and compare two isolated principals.

Required access: sandbox

### OPS-03: Usable rate-limit response

Pass condition: A throttled sandbox request returns 429 plus a parseable Retry-After value or the explicitly documented equivalent backoff contract.

Verification: Inspect a sandbox response; do not intentionally exhaust a live merchant quota.

Required access: sandbox

### OPS-04: Auditable authorization chain

Pass condition: A sampled order links to the authorizing token/mandate reference, checkout, agent identity, and payment result without exposing secret material.

Verification: Inspect a scoped redacted audit artifact and reconcile its identifiers.

Required access: authorized_audit

Example (illustrative):

```http
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30

{
  "error": { "code": "agent_quota_exceeded" },
  "request_id": "req_demo_01",
  "retry_after_seconds": 30
}
```

Illustrative response. Respect the declared retry interval; quota tests belong in a sandbox with agreed limits.

## 7. Discovery & access

Can an agent find the right public pages and understand access rules?

### DISC-01: Canonical discovery

Pass condition: Each sampled public page has a stable canonical URL and important pages are linked from navigation or a sitemap.

Verification: Sample at least five distinct pages; count resolvable canonical URLs and discoverable destinations.

Required access: public_read

### DISC-02: Agent policy clarity

Pass condition: Published access policy distinguishes training, search, interactive shopping and authorized integrations without treating robots silence as permission.

Verification: Record named agents, allowed scope and policy sources; compare policy text and applicable robots directives for each sampled route.

Required access: public_read

### DISC-03: Discoverable machine contract

Pass condition: Supported feeds, APIs or connectors are linked from accessible developer documentation with versions and authentication requirements.

Verification: Fetch every advertised contract; report reachable contracts / advertised contracts and unresolved references.

Required access: public_read

### DISC-04: Honest blocked states

Pass condition: Denied or unavailable routes return explicit status and a documented authorized alternative when one exists; agents are not asked to bypass controls.

Verification: Observe a permitted denial fixture; record HTTP status, reason and alternative route. Do not evade a challenge.

Required access: sandbox

Example (illustrative):

```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.

## 8. Readable pages & structure

Can people and agents extract the same meaning from a page?

### HTML-01: Meaningful initial content

Pass condition: Public pages expose meaningful readable content in initial HTML or a documented accessible equivalent.

Verification: Compare initial HTML, rendered DOM and public facts on five pages; report matching factual fields / expected fields.

Required access: public_read

### HTML-02: Headings and landmarks

Pass condition: Sampled pages have descriptive titles, ordered headings and named main/navigation regions.

Verification: Count pages with usable titles and landmarks; record missing or misleading headings in DOM artifacts.

Required access: public_read

### HTML-03: Names, roles and states

Pass condition: Interactive controls expose accurate accessible names, roles and current states consistent with visible labels.

Verification: Inspect at least ten controls across pages; count correctly named controls / sampled controls and state mismatches.

Required access: public_read

### HTML-04: Equivalent nonvisual information

Pass condition: Images, tables and multimedia expose the information needed to decide in text or accessible alternatives.

Verification: Compare critical facts in images/tables/media against text alternatives; list missing facts and affected tasks.

Required access: public_read

Example (illustrative):

```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.

## 9. Browser actions & human clarity

Can a browser agent complete ordinary tasks through clear controls?

### BROW-01: Keyboard-operable task paths

Pass condition: Key tasks can be navigated with keyboard input and visible focus without traps.

Verification: Execute three applicable task paths with keyboard input; report completed paths / attempted paths and focus failures.

Required access: sandbox

### BROW-02: Stable action targets

Pass condition: Controls remain identifiable across layout changes and do not require brittle screen coordinates.

Verification: Repeat task selection at desktop/mobile widths; record semantic locator success rate and ambiguous matches.

Required access: sandbox

### BROW-03: Observable loading and completion

Pass condition: Loading, empty, error and success states are distinguishable in the DOM and do not hide failed actions.

Verification: Exercise each state fixture; count correctly exposed states / attempted states and capture DOM evidence.

Required access: sandbox

### BROW-04: Responsive clarity

Pass condition: Content and essential controls remain usable at narrow widths and zoom without clipped critical facts.

Verification: Measure clipping and task completion at declared device widths and zoom levels; record viewport dimensions.

Required access: public_read

Example (illustrative):

```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.

## 10. Product suitability & evidence

Can an agent match a product to a real person’s constraints?

### FACT-01: Decision-relevant specifications

Pass condition: Sampled variants expose dimensions, materials, weight, compatibility and other applicable facts with explicit units.

Verification: Define the category-specific required fields before sampling; count populated applicable fields / required fields across at least ten variants.

Required access: public_read

### FACT-02: Use cases and limitations

Pass condition: Descriptions state suitable use cases and limitations, and do not invent performance claims or repeat keywords as evidence.

Verification: For five realistic buyer prompts, map every decisive constraint to a sourced fact or explicit unknown; report supported constraints / total constraints.

Required access: public_read

### FACT-03: Traceable claims

Pass condition: Certifications, ingredients, safety or performance claims link to current evidence for the exact variant and claim scope.

Verification: Sample claimed attributes; count traceable claim-to-variant evidence links and expired or unsupported claims.

Required access: public_read

### FACT-04: Visible and structured facts agree

Pass condition: Structured product data agrees with the visible variant details, price, currency and availability.

Verification: Compare paired visible/feed snapshots for ten variants; report mismatched fields / compared fields and timestamps.

Required access: public_read

Example (illustrative):

```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.

## 11. Search, filters & comparisons

Can agents find and compare the right options?

### FIND-01: Constraint-based retrieval

Pass condition: Search and filters support applicable buyer constraints with stable product identifiers and explicit unknown fields.

Verification: Run ten predefined query/constraint fixtures; report relevant results / inspected results and omitted known matches.

Required access: sandbox

### FIND-02: Pagination and completeness

Pass condition: Search/catalog responses document pagination, ordering and limits without silently dropping products.

Verification: Traverse a bounded fixture catalog; compare unique returned IDs with known expected IDs and duplicate count.

Required access: sandbox

### FIND-03: Meaningful empty results

Pass condition: No-result states distinguish no matches, invalid filters and unavailable search.

Verification: Exercise three fixtures; record correct distinctions / fixtures and suggested safe next steps.

Required access: sandbox

### FIND-04: Comparable attributes

Pass condition: Comparison views use consistent units and distinguish absent information from negative attributes.

Verification: Compare five product pairs; count consistent attribute/unit rows and unknowns incorrectly presented as no.

Required access: public_read

Example (illustrative):

```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.

## 12. Forms, validation & recovery

Can an agent provide valid input and recover from mistakes?

### FORM-01: Explicit input contracts

Pass condition: Fields have labels, expected formats, required state and associated instructions.

Verification: Inspect ten fields; count fields with complete labels/constraints and compare client/API validation.

Required access: public_read

### FORM-02: Actionable validation errors

Pass condition: Invalid values produce field-associated errors with stable machine codes where APIs are offered.

Verification: Submit bounded invalid fixtures in a sandbox; report actionable errors / invalid inputs and preserved valid fields.

Required access: sandbox

### FORM-03: No surprise mutations

Pass condition: Selection and navigation do not trigger purchases, subscriptions or destructive changes without an explicit final action.

Verification: Record side-effect counts during navigation/input fixtures; require zero unexpected mutations.

Required access: sandbox

### FORM-04: Recoverable interruptions

Pass condition: Session expiry, timeouts and failed submissions preserve safe input or explain how to resume without duplicates.

Verification: Interrupt two fixture workflows; measure recoverable state and duplicate mutation counts.

Required access: sandbox

Example (illustrative):

```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.

## 13. Cart, quotes & purchase clarity

Does the buyer know exactly what will happen before approving?

### CART-01: Variant and quantity identity

Pass condition: Cart lines identify exact variants, quantities, unit prices and item availability.

Verification: Create five fixture carts; compare requested and returned variant/quantity/price fields with zero unexplained substitutions.

Required access: sandbox

### CART-02: Complete preapproval total

Pass condition: Shipping, tax, fees, discounts and recurring commitments are disclosed before authorization with explicit currency.

Verification: Compare displayed and authoritative totals for fixture destinations; report unexplained amount differences.

Required access: sandbox

### CART-03: Quote validity and changes

Pass condition: Quotes state expiry or revision, and material changes require renewed buyer approval rather than silent replacement.

Verification: Change price/stock after a fixture quote; verify expiry/change detection and zero unauthorized completions.

Required access: sandbox

### CART-04: Reviewable final action

Pass condition: The human or delegated authority can inspect the final order and enforce approval limits before execution.

Verification: Record approval input, order revision and final effect; test one refused approval with zero order/payment effects.

Required access: sandbox

Example (illustrative):

```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.

## 14. Delivery, returns & aftercare

Can an agent verify promises and resolve what happens after buying?

### SHIP-01: Destination-specific delivery

Pass condition: Delivery estimates identify destination scope, order cutoff, business-day rules and unavailable regions.

Verification: Test five allowed destination fixtures; record estimate completeness and discrepancies against shipping rules.

Required access: sandbox

### SHIP-02: Return and warranty facts

Pass condition: Return windows, exclusions, costs and warranty scope are public and linked to relevant products.

Verification: Sample five products; count applicable return/warranty answers with explicit sources and exclusions.

Required access: public_read

### SHIP-03: Order status and support

Pass condition: Authorized clients can retrieve state, shipment references and a documented support/escalation route.

Verification: Follow three sandbox order states; report retrievable transitions / expected transitions and support-route availability.

Required access: sandbox

### SHIP-04: Cancellation and refunds

Pass condition: Supported cancel/refund actions state eligibility, money amounts, timing and final state with safe retries.

Verification: Exercise eligible and ineligible sandbox cases and one retry; report duplicate refund effects and unexplained outcomes.

Required access: sandbox

Example (illustrative):

```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.

## 15. Accounts & session boundaries

Does sign-in preserve intent while protecting private data?

### ACCT-01: Intent survives sign-in

Pass condition: Authentication returns the user to the requested safe action or page without losing pending non-sensitive input.

Verification: Test sign-in, confirmation and recovery callbacks on approved origins; report preserved intents / fixture journeys.

Required access: sandbox

### ACCT-02: Session expiry is explicit

Pass condition: Expired sessions stop private actions and offer reauthentication without exposing private results.

Verification: Expire one fixture token; measure private reads/writes rejected and successful recovery after sign-in.

Required access: sandbox

### ACCT-03: Cross-account isolation

Pass condition: Private records and actions are authorized by server/database policy for the current principal.

Verification: Use two disposable principals; require zero unauthorized reads or mutations across each private resource type.

Required access: sandbox

### ACCT-04: Ownership is proven

Pass condition: Claims to manage a domain or organization require verifiable ownership rather than a URL or client-supplied flag.

Verification: Test valid, invalid and replayed ownership proofs; record unauthorized claims accepted and proof expiry rules.

Required access: sandbox

Example (illustrative):

```json
{
  "id": "ACCT-01",
  "result": "unknown",
  "evidence_level": "none",
  "environment": "sandbox",
  "metrics": {},
  "next_step": "Test sign-in, confirmation and recovery callbacks on approved origins; report preserved intents / fixture journeys."
}
```

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.

## 16. Privacy, consent & minimization

Does useful feedback avoid exposing the person behind it?

### PRIV-01: Minimal buyer disclosure

Pass condition: Agent requests and feedback disclose only necessary permitted constraints, avoiding raw personal histories and credentials.

Verification: Review a consented redacted sample; count unnecessary sensitive fields / sampled fields and document purpose.

Required access: authorized_audit

### PRIV-02: Consent and revocation

Pass condition: Sharing and delegated actions follow explicit consent scope with revocation and expiry enforcement.

Verification: Test consent grant, withdrawal and expired fixture permissions; require zero out-of-scope disclosures.

Required access: sandbox

### PRIV-03: Retention and deletion

Pass condition: Stored feedback and agent traces have documented retention and authorized deletion/export behavior.

Verification: Inspect retention configuration and exercise a disposable export/delete fixture; record retained identifiers and completion time.

Required access: authorized_audit

### PRIV-04: Safe public aggregation

Pass condition: Public metrics distinguish simulations, submissions and independent users and avoid small-cohort identifying detail.

Verification: Reconcile public aggregates to a scoped redacted fixture dataset; count provenance errors and disclosed identifying fields.

Required access: authorized_audit

Example (illustrative):

```json
{
  "id": "PRIV-01",
  "result": "unknown",
  "evidence_level": "none",
  "environment": "sandbox",
  "metrics": {},
  "next_step": "Review a consented redacted sample; count unnecessary sensitive fields / sampled fields and document purpose."
}
```

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.

## 17. Security & adversarial inputs

Can the site treat agent inputs as untrusted data?

### SEC-01: Untrusted text stays data

Pass condition: Retrieved pages and submitted feedback cannot redefine agent/system authority or trigger actions without authorization.

Verification: Run isolated prompt-injection fixtures; count unauthorized tool calls or disclosures, and preserve the attack/result artifacts.

Required access: sandbox

### SEC-02: Server-side input boundaries

Pass condition: URLs, identifiers, amounts and callbacks are validated server-side; private/internal network targets are denied.

Verification: Run bounded invalid-input and SSRF fixtures against an authorized isolated service; count accepted prohibited targets.

Required access: sandbox

### SEC-03: Credential and transport hygiene

Pass condition: Secrets remain server-side, scoped and redacted; HTTPS and supported authentication protect private actions.

Verification: Inspect a scoped configuration and redacted traces; count exposed secrets and unauthenticated private operations.

Required access: authorized_audit

### SEC-04: Abuse controls without blanket claims

Pass condition: Feedback/tool endpoints apply bounded quotas and provenance controls without presenting spoofed bot identity as verified users.

Verification: Test duplicate/replay/spoofed identity fixtures within agreed limits; count incorrect identity attributions and duplicate effects.

Required access: sandbox

Example (illustrative):

```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.

## 18. APIs, MCP & tool contracts

Can a supported agent discover and invoke a compact typed interface?

### TOOL-01: Typed tool interfaces

Pass condition: Supported tools have accurate names, descriptions, schemas, errors and documented input/output limits.

Verification: Validate advertised schemas and ten representative fixtures; report valid contracts / advertised contracts.

Required access: public_read

### TOOL-02: Read and write boundaries

Pass condition: Tools clearly distinguish read-only, reversible and consequential actions; real authorization governs execution.

Verification: Inventory tools and execute allowed/denied sandbox fixtures; count mislabeled effects and permission violations.

Required access: sandbox

### TOOL-03: Connector identity and authorization

Pass condition: MCP/API clients use the supported authorization flow with appropriate audience/scope checks rather than passing unrelated tokens through.

Verification: Inspect the current protocol contract and test isolated wrong-audience/scope fixtures; require zero unauthorized accepted requests.

Required access: sandbox

### TOOL-04: Bounded response cost

Pass condition: Responses expose only necessary facts, support pagination/field selection where needed and publish tested payload limits.

Verification: Measure response bytes, retrieval requests and task success on ten fixtures against declared budgets; do not use small payload size alone as readiness.

Required access: sandbox

Example (illustrative):

```json
{
  "id": "TOOL-01",
  "result": "unknown",
  "evidence_level": "none",
  "environment": "public",
  "metrics": {},
  "next_step": "Validate advertised schemas and ten representative fixtures; report valid contracts / advertised contracts."
}
```

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.

## 19. Reliability & failure recovery

Can the system stay understandable when dependencies fail?

### REL-01: Timeout and retry contracts

Pass condition: Clients receive bounded timeouts, retryable/nonretryable error classes and backoff guidance.

Verification: Inject permitted latency and failure fixtures; record p50/p95 response times, retry counts and final outcomes.

Required access: sandbox

### REL-02: Durable background work

Pass condition: Long-running jobs survive worker restarts and expose stable job IDs, state and terminal failures.

Verification: Restart an isolated worker mid-job; compare job/effect counts and observable status before/after restart.

Required access: sandbox

### REL-03: Reconciliation after uncertainty

Pass condition: Ambiguous client timeouts can be resolved through authoritative status without reissuing a new logical purchase.

Verification: Drop one sandbox completion response; query authoritative state and require one logical effect after recovery.

Required access: sandbox

### REL-04: Contract compatibility

Pass condition: Breaking changes are versioned and migration/deprecation dates are documented for feeds and actions.

Verification: Compare two retained contract versions and client fixtures; report breaking fields/operations and documented migration coverage.

Required access: public_read

Example (illustrative):

```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.

## 20. Locale, time & money

Do facts keep the same meaning across regions?

### LOC-01: Explicit units and dates

Pass condition: Dates/times state timezone and relevant calendar rules; dimensions and quantities state units.

Verification: Sample twenty applicable values; count unambiguous unit/timezone values / sampled values.

Required access: public_read

### LOC-02: Regional prices and eligibility

Pass condition: Currency, geography, taxes, inventory and eligibility are tied to the buyer-selected region.

Verification: Compare five region fixtures; record mismatched currency/availability and unannounced regional fallbacks.

Required access: sandbox

### LOC-03: Language parity

Pass condition: Supported languages preserve decisive product/policy facts and recognizable action semantics.

Verification: Compare the same five pages in two supported locales; report decisive fact mismatches / compared facts.

Required access: public_read

### LOC-04: Accessible localization

Pass condition: Language metadata, right-to-left layouts where supported and translated control names remain usable.

Verification: Inspect supported locale DOMs and keyboard flows; count correctly declared languages and missing translated control names.

Required access: public_read

Example (illustrative):

```json
{
  "id": "LOC-01",
  "result": "unknown",
  "evidence_level": "none",
  "environment": "public",
  "metrics": {},
  "next_step": "Sample twenty applicable values; count unambiguous unit/timezone values / sampled values."
}
```

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.

## 21. Feedback & improvement loop

Can people and agents turn a blocker into a verified improvement?

### FDBK-01: Simple feedback entry

Pass condition: Public pages provide a usable human feedback route and a documented structured agent endpoint when supported.

Verification: Submit one disposable human and agent fixture; verify receipt identifiers and correct owner routing.

Required access: sandbox

### FDBK-02: Evidence and provenance

Pass condition: Feedback records page/context, blocker, source kind and evidence without inventing a customer or purchase outcome.

Verification: Validate ten redacted fixtures against the feedback schema; count incomplete provenance and unsupported outcome claims.

Required access: authorized_audit

### FDBK-03: Useful verified responses

Pass condition: Owners can publish sourced answers and agents can retrieve revisions with timestamps without seeing private feedback.

Verification: Create an authorized answer fixture, retrieve it publicly and test unauthorized edits; report stale revisions and leakage.

Required access: sandbox

### FDBK-04: Comparable follow-up

Pass condition: After a fix, the same task/profile/version is remeasured and unresolved cases remain visible.

Verification: Replay a recorded baseline suite; report paired task outcomes, score/version changes and remaining failures.

Required access: sandbox

Example (illustrative):

```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.

## 22. Harness, evidence & regression

Can another builder reproduce the assessment?

### EVAL-01: Representative task set

Pass condition: The assessment declares persona constraints, task scope, pages/variants and sample selection before testing.

Verification: Record at least five pages and ten applicable task fixtures, with denominators and exclusions; separate public and sandbox evidence.

Required access: public_read

### EVAL-02: Reproducible artifacts

Pass condition: Each result links timestamped inputs, expected/observed outcomes, environment, versions and redacted artifacts.

Verification: Validate all reported checks; count results with complete replay metadata / reported results.

Required access: authorized_audit

### EVAL-03: Measured task outcomes

Pass condition: Success rate, retries, latency and cost use defined units and do not treat documentation coverage as executed success.

Verification: Replay the fixed suite; report successes / attempts, p50/p95 latency and request/token cost with environment and sample size.

Required access: sandbox

### EVAL-04: Regression and comparison controls

Pass condition: Before/after comparisons retain task/data/protocol versions and report failed retrievals and unknowns rather than hiding them.

Verification: Repeat unchanged and changed fixture runs; count invalid comparisons and verify all terminal outcomes are retained.

Required access: sandbox

Example (illustrative):

```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.

## Agent workflow

1. Read /rubric.json and /agent-guide.md; record the rubric version and intended site profile.
2. Inventory applicable pages, feeds, actions and data boundaries. Choose representative task fixtures before making changes.
3. Assess public-read checks first; attach observations and record unknowns where evidence is unavailable.
4. Implement small fixes with sourced facts and explicit contracts; keep the human interface clear.
5. Run mutations only in an explicitly authorized sandbox with disposable data. Do not execute live purchases or bypass access controls.
6. Validate the assessment against /rubric.schema.json; keep baseline and follow-up artifacts under the same task/profile/version.
7. Report verified pass/fail counts, unknowns, scope exclusions and measured task outcomes; do not invent a deep score.

## Site profiles

- **commerce**: Full commerce scope, including catalog, checkout and aftercare.
- **content**: Publications and information sites; transaction checks need an explicit applicability decision.
- **service**: Booking, subscription and SaaS sites; adapt catalog and fulfillment tests to plans, slots and service policies.

## Assessment format

Validate against /rubric.schema.json. Example is fictional:

```json
{
  "rubric_version": "dar-0.2",
  "merchant": "merchant.example",
  "assessed_at": "2026-10-10T18:05:00Z",
  "deep_score": null,
  "checks": [
    {
      "id": "IDEM-02",
      "result": "pass",
      "evidence_level": "verified",
      "observed_at": "2026-10-10T18:05:00Z",
      "environment": "sandbox",
      "method": "Two identical authorized requests with the same key",
      "source_url": "https://merchant.example/docs/idempotency",
      "artifacts": [
        "redacted-request-pair.json",
        "order-effect-count.json"
      ],
      "metrics": {
        "requests": 2,
        "orders_created": 1,
        "payment_effects": 1
      }
    },
    {
      "id": "EVT-04",
      "result": "unknown",
      "evidence_level": "claimed",
      "observed_at": "2026-10-10T18:05:00Z",
      "environment": "documentation",
      "method": "Merchant statement; no audit artifact",
      "source_url": "https://merchant.example/docs/events",
      "artifacts": [],
      "metrics": {}
    }
  ]
}
```

## Protocol neutrality

ACP, AP2, another typed contract, or equivalent behavior can satisfy a capability. Protocol badges and MCP tool listings alone do not prove transaction readiness. Record protocol versions. No live purchase, payment, quota exhaustion, or private audit is authorized by this specification.

## Sources

- [Pratik Dhanave — Building an Agent-Ready Merchant](https://pratikdhanave.com/blog/posts/agentic-commerce-agent-ready-merchant.html) — Practitioner framing; not an industry standard.
- [Stripe — Agentic Commerce Protocol](https://docs.stripe.com/agentic-commerce/protocols/acp) — Primary protocol overview and specification links.
- [Stripe — Idempotent requests](https://docs.stripe.com/api/idempotent_requests) — Provider-specific replay semantics; not a universal contract.
- [Stripe — Webhooks](https://docs.stripe.com/webhooks) — Primary event delivery and signature documentation.
- [AP2 — Agent Payments Protocol](https://ap2-protocol.org/) — Alternative authorization/mandate protocol.
- [W3C — WCAG quick reference](https://www.w3.org/WAI/WCAG22/quickref/) — Accessibility guidance; this assessment is not WCAG certification.
- [Google — Product structured data](https://developers.google.com/search/docs/appearance/structured-data/product) — Product discovery implementation guidance; not proof of agent checkout.
- [MCP — Security best practices](https://modelcontextprotocol.io/specification/latest/basic/security_best_practices) — Protocol-specific security guidance; record the tested protocol version.

The original six commerce capabilities follow the practitioner essay; additional website dimensions are Agent Friendly assessment proposals. Pass conditions and evidence rules are Agent Friendly proposals, not an industry standard.