LEGAL
Directory and Benchmark Policy
Effective 2026-09-22 · Version 1
Operator: Discry LLC, a New York limited liability company, 418 Broadway, Suite 10855, Albany, NY 12207. Contact: legal@discry.ai.
This policy is a notice incorporated by the Terms of Use. Where it conflicts with the Terms of Use, the Terms of Use govern. The Fix Kit Terms prevail over the API, MCP and Data License Terms (for Machine Access), which prevail over the Terms of Use. The Privacy Policy, Cookie Policy, Crawler and Acceptable Use Policy, and this Directory and Benchmark Policy are notices incorporated by the Terms of Use. The Refund Policy is incorporated by the Fix Kit Terms.
Defined terms used. Terms defined in the Terms of Use keep their meaning here: Discry, Site, Scan, Directory, Index, Band, Fix Kit, Account, Machine Access. Confirmation Scan is defined in the Fix Kit Terms. Index Data and Badge are defined in the API, MCP and Data License Terms. Exclusion List is defined in the Crawler and Acceptable Use Policy. This policy defines the following terms:
- Subject: the company, project, or product whose API documentation a Profile is about.
- Profile: everything the Directory publishes about one Subject under one slug, on the Site and through Machine Access.
- Scan Time: the timestamp recorded on the Scan artifact from which a Profile is built.
- Correction Request: a request under section 7 to fix a factual error in what we fetched, recorded, or displayed.
- Rescan Request: a request under section 8 to run a fresh Scan because the Subject's public documentation has changed.
- Takedown Notice: a request under section 11 to remove or withhold specific material on a legal ground.
1. What this policy covers
1.1. This policy governs every surface on which Discry publishes an evaluation of a Subject: the Directory at /index, the Profile pages at /api/<slug>, the /compare pages, the /data page and the State of Agent-Readiness report, the free Scan result page, the Badge images, and every Machine Access surface, including /api/v1/index.json, /api/v1/<slug>, /api/index.json, /api/index.csv, the MCP server at /api/mcp, the markdown mirrors, llms.txt, AGENTS.md, and llms-full.txt.
1.2. This policy covers the report at /state-of-agent-readiness-2026 as it covers every other published surface.
1.3. This policy covers how Discry publishes, corrects, and removes evaluative content. Data licensing is in the API, MCP and Data License Terms; fetch behaviour is in the Crawler and Acceptable Use Policy.
2. What the Directory publishes about a Subject
2.1. For each Subject the Directory may publish: a slug, the Subject's name and category, a status and its reason, an overall score, a discovery score and a comprehension score, a Band, a rank within the Index, a capability-floor label, the discovery signals we observed, evidence for the result, the docs URL we used, and provenance (the instrument version and the Scan Time).
2.2. A Subject that could not be scored is published with an explicit status of unreachable, blocked, or insufficient-coverage, a plain-language reason, and the raw log line behind that reason. Such a Subject carries no Band and no fabricated score.
2.3. Badges report the Subject's current status or Band, never a Band for an unscored Subject. A Badge reports a measurement; it is not a certification, accreditation, or endorsement.
2.4. The Directory shows the Subject's brand mark, drawn from the open Simple Icons set or from our own curated override file, or a text monogram where no mark exists. Section 10 governs that use.
2.5. The /examples/* pages and the articles on llms.txt and AGENTS.md display short excerpts of a Subject's public entry-point files. An excerpt is at most eight lines, each cut at 160 characters, is attributed to the Subject, and links to the source file. Profiles do not display excerpts. Section 5 governs quotation and section 11 governs removal.
2.6. We do not accept or publish private, confidential, or submitted data about a Subject. The Directory reads only what is publicly reachable over plain HTTP; anything else would break reproducibility.
3. Scores are automated opinion, taken at a stated time under a stated method
3.1. A Discry score, Band, rank, capability-floor label, and pass or fail result is an evaluative opinion. It is produced by an automated instrument that fetches the Subject's public documentation at the Scan Time, runs a versioned bank of tasks against named language models, and grades the answers mechanically. It is not a statement of fact about the Subject's business, product, staff, or the correctness of its API.
3.2. The observations that feed the opinion are disclosed on the Profile receipts (the status and its reason, which discovery signals were present or absent, the discovery and comprehension scores, and the capability floor) and through Machine Access, which adds the provenance. Those observations are checkable facts about the Subject's public documentation at the Scan Time, and section 7 is the route for correcting them.
3.3. The method is published at /methodology and mirrored at /methodology.md. The following properties of the instrument are the basis of every published score:
- Documentation is fetched over plain HTTP with no JavaScript execution, with a fifteen-second timeout, following redirects. What renders on that fetch is what is graded.
- The fetcher sends the user agent
DiscryScan/2.0, and the site-side discovery check sendsDiscryScan/2.0 (+https://discry.ai/methodology). - Comprehension tasks are answered by three named Claude model tiers, pinned to specific model versions; if a pinned model is silently re-pointed, the scan fails and writes no score.
- A comprehension pass requires both a correct answer and a verbatim quotation from the documentation we fetched. Trap tasks, where the correct answer is a refusal, are exempt from the quotation rule.
- A closed-book run measures what the models already knew without the documentation. That rate is published as Familiarity, which
/methodologydefines as a disclosure that does not move the score. - The presence of a
robots.txt, and whether it fully disallowsgptbot,claudebot, andgoogle-extended, is one discovery signal with a weight of three out of nineteen. A Subject that disallows those agents scores lower on that signal. This is a design choice of the instrument, not an error. - Only Discry-run docs-surface scans enter the Index. Runs made through the product path or through an API environment are excluded by two independent code guards. A Confirmation Scan bought with a Fix Kit is a Discry-run scan and does publish, graded by the same instrument.
3.4. Every published artifact is stamped with the instrument version and the environment it ran in. We disclose the environment rather than claim scores transfer unchanged to another.
3.5. What the score does not measure. The score grades what an agent can find and understand on the Subject's public documentation surface before any code runs. It does not test authentication, live API calls, reliability, uptime, SDK behaviour, or end-to-end task completion. A Band is not a security rating, a compliance rating, a vulnerability assessment, a legal opinion, a financial rating, or a statement about the safety, legality, or fitness of the Subject's product.
3.6. A score at one Scan Time is not a prediction of the next: documentation, instrument version, and fetch outcomes change. A Profile scanned under an earlier instrument version keeps that version stamp until a fresh Scan under the current version replaces it; scores stamped with different instrument versions are not directly comparable, and Discry does not re-grade an earlier report under a later instrument.
4. Independence
4.1. No one pays to be listed, and no one pays to be unlisted. A Subject is in the Index because its public documentation is in the scan corpus, not because it asked, consented, or paid. Inclusion, exclusion, position, and Band cannot be bought. There is no sponsored listing, featured placement, or paid tier of the Directory.
4.2. Every Subject is graded by the same instrument. Scoring is identical whether or not the Subject has ever paid Discry for anything. The instrument does not know who is a customer: the scan engine lives in a separate project from the Site, the model call that reviews a Fix Kit is instructed not to calculate or predict a score, and the validation firewall rejects score language in any customer-visible output.
4.3. The Fix Kit is a paid service that changes documentation, not scores. A Fix Kit is a set of proposed documentation changes derived from what the instrument measured, sold to the Subject or to anyone acting for it. Buying one changes nothing about the Profile. The only thing that can move a published score is a fresh Scan of the Subject's public documentation, run by the same instrument as every other Scan. The Fix Kit manifest records no predicted score lift, and a validation firewall rejects any customer-visible output that mentions an official score, a predicted lift, or the held-out tasks.
4.4. Claiming a Profile confers no control over it. An Account holder may claim a scan for a domain they do not control, because the claim route accepts any syntactically valid domain. A claim links a Profile to an Account for notification and purchase purposes. It does not let the claimant edit, hide, or delay any published result, and it is not treated as evidence that the claimant speaks for the Subject in a Correction Request or Takedown Notice.
4.5. Correction is not negotiation. Section 7 changes what we recorded or displayed when it is shown to be wrong, never a score by agreement or in exchange for anything.
4.6. We are a single-member company and we say so. Discry LLC has one member and no editorial board. The controls that keep the benchmark independent are mechanical, not organisational: a fixed and published method, versioned instruments, mechanical grading, published receipts, held-out tasks, and the code guards in section 3.3. No independent reviewer, appeals panel, or oversight body exists, and we claim none.
5. Data sources and quotation
5.1. The only inputs to a Profile are documents that were publicly reachable over plain HTTP at the Scan Time: the Subject's documentation pages, API specifications, llms.txt, AGENTS.md, robots.txt, sitemaps, MCP manifests and registry entries, and pages linked from them. How those fetches behave, including the fact that the scanner does not obey robots.txt directives and fetches robots.txt only to score it, is set out in the Crawler and Acceptable Use Policy.
5.2. Fetched documentation is stored as scan evidence and as raw artifacts on each scan report, so any published result can be traced to the exact text it was graded against.
5.3. Short excerpts of a Subject's entry-point files are displayed on the pages named in section 2.5 as illustrations of the entry-point formats, with attribution and a link to the source. The excerpt cache is refreshed by hand, not automatically, so an excerpt may lag the live file. A Subject may ask for an excerpt to be refreshed under section 8 or removed under section 11.
5.4. Task traces contain verbatim quotations because a pass requires the model to quote the documentation. Published traces are redacted before release. Documentation text inside a published trace, like an excerpt under section 2.5, is published as evidence, is attributed to the Subject as its source, and is not licensed by Discry to anyone; it stays its author's property and is excluded from the Index Data licence in the API, MCP and Data License Terms.
6. Freshness, refresh, and archive
6.1. The Index is refreshed continuously: a wider scanner runs hourly and a publish job runs hourly and commits the result to the Site. A Profile therefore shows the most recent published Scan of that Subject, not a fixed edition. A publish run that changes nothing about a Subject is intended to re-serve the same dated report; it is not a new evaluation of that Subject.
6.2. Every score is tied to its Scan Time and instrument version, which are published through Machine Access, and should be cited with them.
6.3. Every scan report is retained. The scan report table is append-only by database trigger: a report cannot be edited or deleted in place. A corrected or retracted result is therefore recorded as a new report, and the original remains in the archive with its Scan Time. We do not currently publish a per-Subject history of scores on the Site. On request to legal@discry.ai from the Subject, we will provide the provenance metadata of its own earlier reports (Scan Time and instrument version), not the prior score or status, which are not republished.
6.4. Whenever the version number of this policy increments, the previous version is kept unchanged in Discry's legal archive and is available on request to legal@discry.ai.
7. Correction Requests: factual errors in what we fetched or displayed
7.1. What a Correction Request is for. A Correction Request asks us to fix something we recorded or displayed that is factually wrong. Examples: the docs URL we used for the Subject is not the Subject's documentation; the Profile names the wrong company or category; the mark shown is not the Subject's mark; an excerpt is attributed to the wrong Subject; a fetched URL listed in the receipts was never served by the Subject; a status of unreachable was caused by a docs URL that points at the wrong host.
7.2. What a Correction Request is not for. It does not change a score, Band, rank, or pass or fail result because the Subject disagrees with it. A score is an opinion produced by the published method from the documentation as it was at the Scan Time; disagreement with the method or the outcome is not a factual error. A Subject whose documentation has since changed files a Rescan Request under section 8.
7.3. Who may file. Anyone. We do not require proof of authority to fix a factual error, because the correction stands or falls on the evidence, not on who sent it.
7.4. What to send. Email legal@discry.ai with the subject line Correction Request: <slug> and include:
- the Profile URL or slug;
- the exact statement, field, URL, or image you say is wrong;
- what you say the correct value is;
- evidence we can check without an account or a login, such as a public URL, a screenshot with a timestamp, or an archive link;
- a contact address for the reply.
7.5. What we do. We acknowledge receipt within five business days. We investigate against the stored scan evidence and the live public surface and decide within thirty calendar days of receipt. Business days are Monday to Friday, excluding New York State public holidays. The possible outcomes are:
- Corrected. The recorded value is wrong. We correct the underlying record, for example the docs URL in the scan targets file, and queue a fresh Scan so the Profile is rebuilt from the corrected input. A correction that changes a Subject's docs URL is accepted only for a URL on the Subject's own root domain, or a host that domain links to as its documentation, verified by us against the live surface, never on the requester's word alone. Before the rescan publishes, we notify by email every Account that has claimed the Profile. The corrected result publishes on the next publish run after the Scan completes.
- Refreshed. The recorded value was right at the Scan Time and is stale now. We treat the request as a Rescan Request under section 8.
- Declined. The recorded value is right, or the request asks for a change section 7.2 excludes. We say which, and why.
7.6. Correction notice. When a correction changes a published score, status, or Band, the new Profile publishes with a new Scan Time and instrument version, and the prior report stays in the archive under section 6.3. Where the error was ours rather than a stale input, we say so in the reply and, where the Site supports it, in a correction note on the Profile.
7.7. Time limits are targets, not guarantees. Discry LLC is operated by one person. If a request needs more than thirty days, we tell the requester before they run out and give a new date.
8. Rescan Requests: your documentation has changed
8.1. What a Rescan Request is for. A Rescan Request asks for a fresh Scan because the Subject's public documentation has changed, an outage affected the last Scan, or the Subject has unblocked our user agent. The fresh result replaces the Profile whatever direction it moves in.
8.2. How to file. Email legal@discry.ai with the subject line Rescan Request: <slug>, the Profile URL or slug, the docs URL you consider canonical, and, where relevant, what changed. The free Scan at /scan runs the discovery probes on demand, so you can check the entry-point signals before filing.
8.3. What we do. We acknowledge within five business days and queue the Scan. The Index is rebuilt hourly, and the fresh result publishes on the next publish run after the Scan completes, ordinarily within thirty calendar days of the request. A rescan is free, is run by the same instrument as every other Scan, and is not affected by whether the Subject has bought anything.
8.4. Clearing an off-ladder status. Each status has one way out:
unreachable: the docs surface yielded nothing readable on a plain fetch, or the docs URL we hold is wrong. Fix the URL by Correction Request, or serve documentation that renders without JavaScript, then file a Rescan Request.blocked: the Subject's server refused our fetch with a hard refusal such as 401, 403, 404, or 451, which the fetcher never retries. Allow the user agents in section 3.3, then file a Rescan Request.insufficient-coverage: the documentation did not yield enough gradeable tasks to support a grade. Publish the missing reference material, then file a Rescan Request.
8.5. Frequency. We run one requested Scan per Subject per thirty days as a matter of course, and may decline more frequent requests with reasons.
9. If you disagree with our decision
9.1. If a Correction Request or Rescan Request is declined and you believe the decision was wrong, reply to the decision email within thirty days and mark it Second review. State what you say we got wrong. We re-read the stored scan evidence, re-fetch the public surface, and reply with a written decision within thirty calendar days. This is a documented second step by the same operator, not a review by a different person or an independent body, because Discry LLC has one member and no appeals panel exists.
9.2. After the second review, the process under this policy ends. Any further dispute is governed by section 14 of the Terms of Use, which sets out governing law, venue, and arbitration for the whole document set. Nothing in this policy restates or varies it.
10. Trademarks and logos
10.1. Nominative use. Discry uses a Subject's name and mark only to identify the Subject whose public documentation was measured. The marks are the monochrome marks distributed in the open Simple Icons package, or a mark from our own curated override file, rendered in the brand's own hex colour, or a text monogram where no mark exists. Use of a name or mark does not imply that the Subject sponsors, endorses, or is affiliated with Discry, the Index, or any score. Every mark belongs to its owner.
10.2. Removal on written request. The owner of a mark, or a person authorised by the owner, may ask us to stop displaying the mark. Email legal@discry.ai with the subject line Mark removal: <slug>, the mark concerned, and a statement that you are the owner or act for the owner. We acknowledge within five business days and replace the mark with a text monogram within thirty calendar days. We do not require a reason, but we may verify the statement by asking for a reply from an address at the Subject's own domain before acting, and a false statement of ownership or authority is impersonation under the Terms of Use. Removal of a mark does not remove the Profile, the score, or the Subject's name, which remain published under section 11.4.
10.3. Discry's own marks. "Discry", the Discry Index, the Discry Score, the Band names as used for benchmark tiers, and the Badge designs are unregistered marks of Discry LLC. The dataset is licensed under the API, MCP and Data License Terms; the marks are not. Nobody may present a Badge, a Band, or a score as a certification, accreditation, or endorsement by Discry, or alter a Badge to show a result other than the one served at /api/badge/<slug>.
11. Takedown Notices: removal on a legal ground
11.1. What a Takedown Notice is for. A Takedown Notice asks us to remove or withhold specific material on a legal ground. The grounds on which we will act are:
- Copyright. An excerpt, quotation, or stored artifact reproduces your copyrighted work beyond what is needed to evidence the score.
- Personal data. A Profile, excerpt, or fetched URL exposes personal data of an identifiable individual that was not meant to be public, for example a personal name or address that appeared in a documentation page by mistake. The individual concerned, or someone acting for them, may file.
- Legal compulsion. A court order, a statutory notice, or a law that binds Discry LLC requires removal.
- Mistaken identity. The Profile is about an API that does not belong to the Subject named, or names a Subject that does not exist.
- Discontinued surface. The documentation surface no longer exists and has not existed for at least thirty days, so a fresh Scan would publish as
unreachablein any case.
11.2. What is not a ground. A low score, an unflattering Band, a failed task, a low rank, a comparison the Subject dislikes, a status of unreachable or blocked, or the fact that the Subject never asked to be listed. Those are the ordinary outputs of a uniformly applied benchmark of public documentation, and section 3 is the notice that they are opinion. A request resting only on them is answered under section 7 or 8.
11.3. How to file. Email legal@discry.ai with the subject line Takedown Notice: <slug>. For a copyright ground, include: identification of the copyrighted work; the exact URL or excerpt on the Site you say infringes it; your name, postal address, and email; a statement that you believe in good faith the use is not authorised by the owner, its agent, or the law; a statement under penalty of perjury that the notice is accurate and that you are the owner or authorised to act for the owner; and your physical or electronic signature. For other grounds, include the URL, the ground, the evidence, and your contact details. This is a complaint route, not a claim that Discry relies on any statutory safe harbour: excerpts and scores are Discry's own publication, not material stored at a user's direction.
11.4. What we do. We acknowledge within five business days and decide within thirty calendar days. Where we act, we remove or withhold the specific material named, for example an excerpt, a stored artifact from the public traces, a mark, or a personal-data string, and no more than that. A Profile as a whole is withdrawn only on the grounds of legal compulsion, mistaken identity, or discontinued surface. The score and status of a Subject whose excerpt or mark was removed remain published; they do not depend on the removed material. A removal is recorded as a new report and the prior report stays in the archive under section 6.3. The stored scan evidence is retained under the Privacy Policy, which sets out data-subject rights.
11.5. Stopping future fetches, and stopping publication. Neither request is a Takedown Notice; both are handled under the Crawler and Acceptable Use Policy §9.1, which gives two routes that do different things. To stop the fetching: because the scanner does not act on robots.txt directives, a Subject that wants to refuse the scanner at once does so at the server, by returning a hard refusal (401, 403, 404, or 451) to the user agents in section 3.3, which the scanner never retries, after which the Profile publishes as blocked with that reason. To stop the publication: the domain owner asks legal@discry.ai to add the domain to the Exclusion List, after which no Profile for it is published and no row for it appears in the Directory, the API, the exports, or the MCP surface. Exclusion is a refusal to publish and not a refusal to measure, so it does not stop Scans running and is not a way to keep a listing while suppressing a score.
11.6. Counter-notice. If material is removed on a copyright ground and you believe the removal was a mistake, email legal@discry.ai within fourteen days identifying the material, with a statement under penalty of perjury that you believe in good faith it was removed by mistake, your contact details, and your signature. We forward the counter-notice, including your name and contact details, to the complainant, and unless the complainant tells us within fourteen business days that it has filed a court action, we may restore the material.
12. Held-out tasks, canary strings, and gaming
12.1. What is public and what is held out. The method, the score formulas and grading rubric, the schemas, the per-Subject scores, the public-development task prompts, the grading logic, and redacted traces are published. The held-out task prompts, the per-scan task-selection logic, the rotation schedule, and the ground-truth accept-sets and citation quotes are held out permanently. In each task category, five tasks are public and the remainder are held out, and the public set never holds a majority of any task type. Held-out tasks rotate only when the instrument version changes, never in the middle of an edition. Public-development tasks are permanent once published and are treated as contaminated.
12.2. Why. In red-teaming, a surface engineered against the grading criteria came within two points of a genuine implementation. The held-out bank and private accept-sets keep the score a measure of documentation, not of knowledge of the test.
12.3. Canary strings. Every task bank carries an inert canary string of a documented form. Canary strings are never sent to a model during an ordinary Scan. If a canary string is reproduced by a model or found on a Subject's surface, that is treated as diagnostic evidence of contamination, not proof, and is corroborated by a second, independently phrased probe before any conclusion is drawn.
12.4. Attempts to extract the held-out bank are a breach of the Terms of Use. Probing any Discry surface to recover held-out prompts, accept-sets, citation quotes, selection logic, or canary strings, or publishing or trading any of them, is prohibited by the Terms of Use. The Fix Kit's validation firewall rejects any customer-visible output containing a tainted held-out token.
12.5. What we publish when gaming is detected. Where contamination or gaming of a Subject's surface is corroborated under section 12.3, we may publish, where the Site supports it, a note on the Profile stating that fact and the evidence, may exclude affected task results from the score, and may rescan the Subject under a later instrument version whose held-out set has rotated. Such a note states what the instrument observed, with its evidence, and section 7 applies to it.
13. Right of reply
13.1. We do not currently publish statements from Subjects alongside Profiles, and this policy does not promise a mechanism that does not exist. A response published on the Subject's own documentation surface is fetched and graded like any other page. Sections 7, 8, 10, and 11 are the Subject's routes.
14. Reliance and liability
14.1. Profiles, scores, Bands, and Index Data are provided as published, at the Scan Time, under the instrument version stamped on them, and are opinion under section 3. The disclaimer of warranties and limitation of liability are in the Terms of Use and, for Machine Access, the API, MCP and Data License Terms. This policy adds no warranty and states no cap.
15. Changes to this policy
15.1. We may change this policy. A change increments the version number and the effective date, and the previous version is kept unchanged and available on request under section 6.4. Changes to the method are made on /methodology and stamped in the instrument version, not here.
16. Contact
16.1. All requests under this policy go to legal@discry.ai. hello@discry.ai is for commercial enquiries only. Postal notices go to Discry LLC, 418 Broadway, Suite 10855, Albany, NY 12207.
Machine-readable mirror: /legal/benchmark-policy.md