Knov.ai

OARS Specification

Open Agent Readiness Standard v1.0

Published by: Knov.ai

Version: 1.0

Status: Published 5-28-2026

Schema: https://knov.ai/schema/oars-manifest.json

Human documentation: https://knov.ai/standard

---

Overview

OARS (Open Agent Readiness Standard) defines what it means for a website or business entity to be ready for interaction with AI agents, autonomous systems, and language models acting on behalf of users.

The standard covers five cumulative levels — from basic discoverability through full machine-operability. Each level builds on the previous. A business cannot be certified at Level 3 without satisfying all requirements of Levels 1 and 2.

OARS does not prescribe how requirements are implemented. It defines what successful implementation looks like and how compliance is verified. Multiple technical approaches may satisfy any given requirement.

---

The Five Levels

LevelNameCore Question
1DiscoverableCan agents find and identify this entity?
2ReadableCan agents comprehend what this entity knows and offers?
3InteractableCan agents take defined actions with this entity?
4TransactableCan agents complete commercial transactions on behalf of users?
5OperableDoes AI operate workflows inside this entity's business?

---

Certification Policies

Cumulative Compliance

Each level assumes full compliance with all preceding levels. Level 3 certification requires that Levels 1 and 2 requirements are fully satisfied and verified.

Recertification Cadence

  • Levels 1–2: Annual recertification required
  • Levels 3–5: Annual recertification with quarterly automated monitoring between cycles

Regression Policy

Knov.ai's automated monitoring checks certified entities quarterly. If a regression is detected (previously passing requirements now failing), the entity enters a 30-day cure period with notification. If not resolved within 30 days, certification drops to the highest level the entity currently fully satisfies.

Partial Compliance Designation

Entities that pass all automated checks for a level and have submitted for human review but have an outstanding requirement within 90 days of a known deadline receive a "Level X Pending" designation. This designation does not appear in the verified directory but does not block progress.

Appeals Process

Entities who believe they were incorrectly assessed may submit an appeal with supporting evidence. A second Knov.ai reviewer assesses independently. Binding decision issued within 14 business days.

---

Level 1: Discoverable

Definition

AI agents can find, navigate, and identify this entity. They know the entity exists, what it fundamentally is, and how to reach it. Discoverability is the foundation — without it, all higher levels are unreachable by agents.

Requirements

Crawl and Navigation

  • robots.txt present, valid, and includes explicit directives for major AI agents. Required user-agents: GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, anthropic-ai, GoogleBot-Extended. Directives may allow or disallow — both are valid. Absence of explicit directives is a failure.
  • sitemap.xml present and valid XML at /sitemap.xml or declared in robots.txt
  • Canonical URLs declared on all primary pages via <link rel="canonical"> or HTTP header
  • Site renders meaningful content without JavaScript execution. Primary content pages must return substantive text content when fetched without a JavaScript engine.

Identity and Structured Data

  • Schema.org structured data present on homepage as JSON-LD. Required type: Organization, LocalBusiness, Person, MedicalBusiness, or other appropriate Schema.org type. Required fields: @type, name, description, url. At minimum one sameAs link pointing to a verifiable third-party profile (LinkedIn, Google Business Profile, licensed professional registry, etc.).
  • llms.txt present at domain root (/llms.txt). Must contain substantive content — minimum 200 words describing what the entity is, what it does, and how to navigate its content. Placeholder or empty files do not pass.
  • Content-Signal directives present in HTTP response headers declaring AI crawl permissions (ai-search, ai-input, ai-train). Values may be allow or disallow — explicit declaration required.
  • Link headers (RFC 8288) present on homepage pointing agents to key resources (sitemap, llms.txt, structured data).

Accuracy

  • All declared identity information is accurate and verifiable
  • Identity information is consistent across homepage, about page, and contact page

---

Verification

Automated Checks (all must pass)

  • [ ] robots.txt fetchable and parseable, contains directives for all six named AI agents
  • [ ] sitemap.xml fetchable and valid XML
  • [ ] Homepage JSON-LD present and validates against Schema.org for declared type
  • [ ] Required Schema.org fields present: @type, name, description, url, sameAs (minimum one)
  • [ ] /llms.txt fetchable, returns text/plain, contains minimum 200 words
  • [ ] Content-Signal headers present in homepage HTTP response
  • [ ] Homepage returns >500 characters of meaningful text content with JavaScript disabled
  • [ ] Canonical URL declared on homepage

Human Review (Knov reviewer)

  • Reviews Schema.org identity data for accuracy against publicly verifiable information
  • Reviews llms.txt for quality — does it meaningfully help an agent understand this entity?
  • Checks consistency of identity information across homepage, about, and contact pages
  • Confirms no misleading or contradictory identity claims

Successful Verification

An AI agent navigating to the domain can unambiguously identify the entity — its name, type, what it does, and who it serves — within a single interaction using only the structured data and llms.txt as sources. A Knov reviewer demonstrates this by prompting a live LLM with only the domain and confirming it returns accurate, complete identity information derived from the site's structured data.

---

Level 2: Readable

Definition

Agents can read, comprehend, and accurately extract meaningful information from the entity. Not just basic identity — the entity's full capabilities, offerings, knowledge, and context are accessible and correctly understood by AI systems.

Requirements

Content Accessibility

  • Semantic HTML throughout primary pages — logical heading hierarchy (H1→H2→H3), meaningful alt text on all images, proper form labels, descriptive button text
  • Clean, valid accessibility tree. Primary pages must pass accessibility tree validation with no critical structural failures. Agents use the same accessibility tree as screen readers.
  • Markdown content negotiation supported. Either: (a) server responds to Accept: text/markdown requests with markdown content, or (b) markdown equivalents available at [page-path]/index.md for all primary content pages.
  • All primary content pages render substantive content without JavaScript dependency.

Structured Knowledge

  • Schema.org expanded beyond Organization identity to cover primary offerings. Every service or product offered must have structured data with minimum fields: name, description, provider, and pricing signal (exact price, price range, or "priceSpecification": {"description": "contact for pricing"} — no silent omissions).
  • Acceptable Schema.org types for offerings: Service, Product, HealthcareService, LegalService, FinancialProduct, Course, or domain-appropriate type.
  • FAQPage schema implemented where FAQ content exists.
  • knowsAbout property populated in the Organization schema listing the entity's authoritative topics (minimum 5 entries).
  • HowTo or SpecialAnnouncement schema used where applicable to capture procedural or time-sensitive knowledge.

Knowledge Declaration File

A dedicated knowledge declaration file present at a standard location (see Open Question in README on final filename — current candidate: /oars.json or /.well-known/oars.json). This file is distinct from llms.txt (which is a content navigation aid) and from AGENTS.md (which is a coding agent convention). The knowledge declaration file serves as the machine-readable entity profile for the OARS standard.

Minimum content of the knowledge declaration file:

  • Entity identity (name, domain, type, description)
  • Audience declaration (who this entity serves, who it does not serve)
  • Knowledge topics and areas of authority
  • Primary offerings with structured descriptions
  • Engagement information (how to begin working with this entity)
  • OARS compliance declaration (current self-declared level, Knov.ai verification ID if verified)
  • Freshness metadata (last updated date, next review date)

See /schema/oars-manifest.schema.json for the full JSON Schema definition of this file.

Accuracy and Consistency

  • NAP consistency for local businesses: Name, Address, Phone identical across all pages and matching third-party profiles
  • No contradictory information between structured data and page content
  • Pricing signals honest and consistently declared — no unexplained gaps between structured data and page content

---

Verification

Automated Checks (all must pass)

  • [ ] Semantic HTML: no critical heading hierarchy failures, all images have alt attributes, all forms have labels
  • [ ] Accessibility tree: no critical structural failures
  • [ ] Markdown endpoint or content negotiation functional for minimum 80% of primary pages
  • [ ] All primary pages return >500 characters content with JavaScript disabled
  • [ ] Schema.org structured data present on minimum 80% of primary offering pages
  • [ ] knowsAbout property present with minimum 5 entries
  • [ ] Knowledge declaration file present and validates against OARS manifest schema
  • [ ] Knowledge declaration file freshness.lastVerified within 365 days

Human Review (Knov reviewer)

  • Structured data accuracy review: reviewer verifies that Schema.org data accurately reflects actual offerings, pricing, and identity
  • Knowledge file quality review: does the knowledge declaration file give an AI agent a complete, accurate picture of what this entity offers and knows?
  • Agent simulation test: reviewer uses a live LLM to research the entity using only the site as a source, then verifies the LLM's understanding matches reality
  • Contradiction scan: checks for inconsistencies between structured data and page content
  • Pricing signal review: confirms all pricing information is honestly and completely declared

Successful Verification

A Knov reviewer demonstrates that prompting a live LLM to "research [entity] and describe their offerings, pricing, who they serve, and what they're expert in" — using only the site as a source — returns accurate, complete, and useful information with no significant gaps, errors, or contradictions. The site is genuinely comprehensible to an agent, not just technically crawlable.

---

Level 3: Interactable

Definition

Agents can take defined actions with the entity — not just read about it. At least one agent-callable capability is exposed, documented, and verified working. An agent can do something on behalf of a user: book, inquire, get a quote, query real-time information, or initiate a process.

Requirements

Agent Interface

  • MCP (Model Context Protocol) server deployed and accessible. Server card present at /.well-known/mcp.json or discoverable via documented mechanism. MCP server must expose minimum one tool that agents can call.
  • Acceptable minimum capabilities: appointment booking initiation, quote request submission, availability query, FAQ query with real-time response, product/service search, document retrieval, intake form submission.
  • A2A (Agent-to-Agent) agent card present at /.well-known/agent-card.json declaring entity identity, capabilities summary, supported protocols, and interaction terms.
  • Agent instructions published — plain language guidance for agents on: how to interact, what capabilities are available, what actions are permitted, what requires human involvement, and any rate or scope limits.

Authentication and Security

  • OAuth 2.1 with PKCE implemented for any protected or state-changing actions. Read-only informational queries may be unauthenticated.
  • Scoped token issuance — agents receive minimum necessary permissions for their declared purpose.
  • All agent-facing endpoints use HTTPS with valid certificates.
  • Rate limiting enforced and documented. Rate limit responses use HTTP 429 with Retry-After header. Not enforcing rate limits is a security failure, not a leniency.
  • Typed, structured error responses on all agent-facing endpoints. No HTML error pages returned to API calls. No untyped 500 responses. All error states documented.
  • No critical OWASP vulnerabilities on agent-facing endpoints (OWASP Top 10 current version).
  • Coordinated disclosure policy published for security researchers.
  • Privacy policy updated to explicitly address: what data is collected when agents interact, how agent-interaction data is handled, data retention for agent logs, and user rights over agent-generated data.
  • Terms of service updated to explicitly address: permitted agent uses, prohibited agent behaviors, rate limits and fair use, and liability for agent-initiated actions.
  • Agent interaction audit log maintained. The entity must be able to produce a log of agent interactions for any 30-day period upon legitimate request.
  • Human oversight boundaries declared in published agent instructions: specific actions that require human confirmation before execution are named and enforced technically.

Documentation

All exposed capabilities documented with: capability name, plain language description, required and optional parameters with types, response format and example, all possible error states with codes and descriptions, and at least one complete example call and response.

---

Verification

Automated Checks (all must pass)

  • [ ] MCP server responds to capability discovery query at declared endpoint
  • [ ] Agent card fetchable and validates against A2A specification
  • [ ] Minimum one callable tool documented and responding
  • [ ] Auth endpoints functional and returning correct OAuth 2.1 responses
  • [ ] Rate limiting active — 429 with Retry-After returned on exceeding limits
  • [ ] Agent-facing endpoints return JSON error responses (not HTML) on error conditions
  • [ ] HTTPS enforced on all agent-facing endpoints
  • [ ] Agent instructions file fetchable and contains required sections

Human Review (Knov reviewer)

  • Live agent interaction test: Reviewer uses an actual AI agent (Claude, ChatGPT Operator, or equivalent) to successfully complete at least one full interaction cycle: discovery of capability → authentication → action execution → result received. The interaction is logged and documented.
  • Documentation completeness: reviewer confirms a developer could implement an agent integration using only the published documentation without additional information.
  • Privacy policy and ToS review: do they adequately and specifically address agent interactions?
  • Audit log verification: entity demonstrates they have a retrievable log of agent interactions from the past 30 days.
  • Edge case testing: reviewer sends malformed requests, out-of-scope requests, and unauthenticated requests to verify graceful handling.
  • Security review: reviewer checks agent-facing endpoints for OWASP Top 10 critical vulnerabilities.

Successful Verification

A Knov reviewer, using a real AI agent, successfully completes a live interaction with the entity through its documented agent interface — from capability discovery through action completion. The interaction is logged, the result is accurate and useful, the entity's systems handle it gracefully, and edge cases are handled without failure. The verified capability is documented in the Knov directory listing.

---

Level 4: Transactable

Definition

Agents can complete commercial transactions on behalf of users — purchases, bookings, contracts, or payments — with appropriate user authorization. The entity has implemented agent-safe commerce infrastructure that does not require human intervention at any step after initial user authorization.

Requirements

Commerce Protocol

  • At minimum one agent commerce protocol implemented and functional. Acceptable protocols: ACP (OpenAI/Stripe Agentic Commerce Protocol), UCP (Google Universal Commerce Protocol), x402 (Coinbase/Cloudflare HTTP 402 payment protocol), or equivalent emerging standard with documented specification and active adoption.
  • Real-time pricing accessible to agents — either a pricing API returning current prices or structured price data updated at minimum daily.
  • Real-time availability or inventory accessible to agents — stock levels, appointment slots, or service capacity queryable programmatically.
  • Order confirmation and status accessible programmatically after agent-initiated transaction — agents can query the outcome and status of transactions they initiated.
  • Cancellation, refund, and modification policy machine-readable — structured data or documented API endpoint returning current policy terms.

Agent Authorization

  • User-delegated agent authorization implemented. Transactions require and record explicit user authorization scope — what the agent is permitted to purchase or commit to, up to what value, under what conditions, for what time period.
  • Authorization scope is logged with the transaction record and auditable by the user whose agent acted.
  • Clear, enforced distinction between: transactions agents can complete autonomously within authorized scope, and transactions that require explicit human confirmation before execution.
  • Maximum transaction value configurable per agent authorization — agents cannot exceed the scope the user has granted.

Trust and Safety

  • No agent-blocking authentication (CAPTCHA, SMS verification, knowledge-based authentication) present in documented agent transaction paths.
  • Agent identity verification implemented. Either Web Bot Auth (RFC 9421 HTTP Message Signatures) or equivalent mechanism allowing the entity to verify that an agent calling their transaction endpoints is a legitimate, authorized agent and not a malicious bot.
  • Fraud and abuse controls distinguish authorized agents from malicious bots without blocking legitimate agent traffic.
  • Dispute resolution process documented for agent-initiated transactions — what happens when a transaction initiated by an agent needs to be disputed or reversed by the user.

Audit and Receipts

  • Complete transaction record maintained for every agent-initiated transaction including: agent identity or signature, user authorization record, authorization scope at time of transaction, transaction details, timestamp, and outcome.
  • Transaction receipts accessible to the authorizing user through their account.
  • Dispute initiation mechanism available to users for agent-initiated transactions.

---

Verification

Automated Checks (all must pass)

  • [ ] Commerce protocol endpoint present and responding with correct content types
  • [ ] Pricing API or structured price data returns current values
  • [ ] Availability API returns current, structured data
  • [ ] No CAPTCHA or human-only auth present in declared agent transaction paths
  • [ ] Agent identity verification (RFC 9421 or equivalent) present on transaction endpoints
  • [ ] Transaction status endpoint returns structured data

Human Review (Knov reviewer)

  • End-to-end transaction test: Reviewer completes an actual or fully documented simulated agent transaction — from product/service discovery through payment authorization through confirmation through receipt. For entities where live transactions cannot be tested (high-value services, regulated industries), a complete documented test environment demonstrating the full flow is required.
  • Authorization scope review: is the delegation model clear, technically enforced, auditable, and appropriately scoped to prevent unauthorized transactions?
  • Dispute handling review: reviewer walks through what happens when a user disputes an agent-initiated transaction — is the process clear, accessible, and functional?
  • Fraud control review: entity demonstrates their systems distinguish authorized agents (passing RFC 9421 signatures or equivalent) from unsigned bot traffic.
  • Audit trail verification: reviewer confirms complete transaction records exist and are retrievable.

Successful Verification

A Knov reviewer documents a complete agent transaction flow from initiation through completion through receipt, demonstrating that a user's AI agent can execute a commercial action with the entity — within user-authorized scope — without human intervention. The transaction is correctly attributed, reversible within stated policies, and auditable. The entity's commerce protocol implementation is documented in the Knov directory listing with supported protocols and transaction capabilities.

---

Level 5: Operable

Definition

AI operates workflows inside the entity's business. The entity runs as a documented human-AI hybrid system — agents handle defined operational processes end to end, with formally defined and technically enforced human oversight boundaries. This is machine-operability in the fullest sense: the business can be substantially operated with AI, not just interacted with from outside.

Requirements

Internal Agent Infrastructure

  • At minimum one core business workflow substantially operated by AI agents end-to-end. Acceptable workflows: customer inquiry intake and routing, appointment scheduling and confirmation, quote generation and delivery, order processing and fulfillment, invoice generation, support ticket triage and resolution, lead qualification, document processing, or equivalent operational function with comparable scope.
  • Internal MCP server or equivalent infrastructure exposing core internal business systems (CRM, scheduling, inventory, communication, knowledge base) to authorized internal agents.
  • Agent-accessible internal knowledge base: the entity's operational knowledge, SOPs, decision criteria, and escalation rules are structured and accessible to their operating agents.
  • Deployed agent framework or platform managing the internal agent workflows (examples: LangChain, LlamaIndex, CrewAI, Salesforce Agentforce, Microsoft Copilot Studio, custom orchestration — platform agnostic, but must be documented and operational).

Human-AI Governance

  • Human oversight boundaries formally documented and technically enforced. Specific decision categories requiring human approval are: named explicitly, technically blocked from autonomous agent completion, and logged when triggered.
  • Agent handoff protocols defined and functional: formal specification of when agents hand off to humans (triggers, conditions, handoff data format) and how humans hand back to agents (re-entry conditions, state transfer).
  • Human review of consequential AI decisions tracked: for any AI-made decision above defined thresholds (financial, customer-facing, legal, or otherwise defined by the entity), a human review record exists and is retrievable.
  • Staff documentation: team members who work alongside AI agents have documented operational knowledge of: what the agents do and don't do, what their error patterns are, how to identify when an agent has made a mistake, and how to intervene and correct.

Operational Visibility

  • Operational metrics tracked and reportable: at minimum — percentage of workflow handled by agents vs. humans, agent error rate, human intervention rate, and average processing time. These metrics must be accessible to Knov.ai during the verification review.
  • Agent activity log maintained with sufficient detail to reconstruct any agent action for audit: action taken, input received, decision made, output produced, timestamp, agent identity.
  • Incident response procedure documented and demonstrated: what happens when an agent makes an error, takes a wrong action, or fails to complete a task? The procedure must include detection, containment, correction, and user notification steps.

Data Governance

  • Data governance policy explicitly addresses agent-generated data, agent-accessed data, and agent logs — including retention periods, access controls, and deletion procedures.
  • PII handling in agent workflows complies with applicable regulations: GDPR (EU/UK), CCPA (California), HIPAA (healthcare), or other applicable jurisdiction-specific requirements. Compliance is documented.
  • Data retention policy covers agent interaction logs with defined retention periods and deletion procedures.

---

Verification

Automated Checks (all must pass)

  • [ ] Internal agent infrastructure: minimum one operational workflow documented with evidence of continuous operation (logs covering minimum 30 days prior to verification)
  • [ ] Operational metrics endpoint or report accessible to Knov.ai reviewer
  • [ ] Agent activity log confirms retrievable records from minimum 30-day period
  • [ ] Incident response contact and procedure document accessible

Human Review (Knov reviewer — this is a structured half-day review)

  • Operational demonstration: Entity demonstrates (live or via documented evidence) an AI agent handling a real operational workflow from initiation to completion. Reviewer observes or reviews the full flow including agent decision points, handoff triggers, and output.
  • Governance documentation review: human oversight boundaries, handoff protocols, and staff documentation reviewed for completeness. Are the governance structures real and operational, or only documented on paper?
  • Incident response review: entity must demonstrate or document at least one instance of the incident response procedure being invoked — what triggered it, what happened, how it was resolved.
  • Data governance review: data policy reviewed for completeness and regulatory appropriateness for the entity's jurisdiction and industry.
  • Staff interview (minimum one person actively working alongside the AI systems): confirms they have practical understanding of agent behavior, limitations, and intervention procedures.
  • Metrics review: reviewer examines operational metrics to confirm AI is genuinely handling a meaningful portion of the declared workflow — not just technically connected but dormant.

Successful Verification

A Knov reviewer has observed or reviewed documented evidence of AI agents handling a real operational workflow within the entity's business — not a demo, but production operation. Human oversight boundaries are technically enforced. The entity can demonstrate they know what their agents are doing, can audit what they've done, can intervene when needed, and have governance documentation that would satisfy a basic operational audit. Verification at Level 5 results in the entity being listed in the Knov directory as a verified machine-operable organization.

---

Changelog

VersionDateChanges
1.05-28-2026Initial specification draft

---

Governance

OARS is published and maintained by Knov.ai. The standard is open — any entity may implement it without license or fee. Changes to the specification are proposed publicly, reviewed with community input, and published with version history.

To get started, run a free self-assessment against the standard. To earn a verified badge and directory listing, request verification — a Knov.ai reviewer completes the human review.