SHOW THE RECEIPTS.

WE PUBLISH OBSERVATIONS, NOT TELEPATHY.

The Domain Graveyard records what could be documented at a specific time. A listing today is not proof that it was listed yesterday. A parked page is not proof of motive. A current registrant is not automatically the original registrant. An asking price is not a sale price. Those distinctions are deliberately built into the database.

How a domain reaches the Graveyard

The public database is intentionally narrower than the research database

Internally, the system can retain pending, rejected, expired and historical observations. The public interface reads the latest observation that is both verified and published. Historical verified observations remain available on the individual record so price or status changes can be documented over time.

Original research sample: city + service .com names

Our denominator-first study was defined in phases before each expansion was checked and now contains 3,000 possible .com names created from a fixed cross-product of 100 U.S. city slugs × 30 everyday local-service and business slugs. The original 500-name and 1,500-name cohorts remain preserved rather than being replaced. Every generated name stays in the denominator whether it is unregistered, developed, redirected, parked, blank, or offered for sale.

Phase one used 25 cities and 20 services for 500 names. Phase two added 25 cities and 10 business/service terms, expanding the matrix to 50 cities × 30 terms, or 1,500 names. Phase three keeps the same 30 terms and adds 50 more city slugs, expanding the fixed study to exactly 3,000 unique names. The phase-three cities are Buffalo, Rochester, Syracuse, Albany, Hartford, Providence, Worcester, Bridgeport, Newark, Jersey City, Virginia Beach, Norfolk, Chesapeake, Greensboro, Durham, Winston-Salem, Charleston, Savannah, Augusta, Knoxville, Chattanooga, Birmingham, Montgomery, Mobile, Jackson, Little Rock, Shreveport, Baton Rouge, Corpus Christi, El Paso, Fort Worth, Arlington, Plano, Irving, Fort Lauderdale, St. Petersburg, Hialeah, Tallahassee, Fort Myers, Fresno, Long Beach, Oakland, Anaheim, Riverside, Stockton, Bakersfield, Honolulu, Anchorage, Spokane, and Tacoma. The 10 terms added in phase two remain dentist, attorney, realtor, mechanic, chiropractor, veterinarian, tutoring, salon, bakery, and security.

RDAP is used first to determine whether the generated name is currently registered. Registered names can then receive one conservative public-homepage check. The checker does not crawl links. It follows a limited redirect chain, caps response size, rate-limits requests, records HTTP and redirect metadata, and looks for high-confidence sale, parking, placeholder, redirect, blank, or developed-site signals. Individual domains are automatically published to the Graveyard only when the evidence supports a high-confidence for-sale or parked classification. Other outcomes remain in the aggregate research denominator.

What we can responsibly calculate

Observed asking-price distributions, time between documented observations, registration-age distributions, marketplace concentration, developed-vs-undeveloped ratios, registration/renewal benchmarks, price changes, and documented business stories. Population-style claims are tied to a disclosed sampling rule rather than extrapolated from whichever examples happen to look dramatic.

Asking prices and reported sales are separate datasets

An asking price documents what a seller requested. A reported sale documents a transaction reported as completed by the source marketplace. The two are never silently substituted for one another. The Graveyard stores asking-price observations with the domain record, while marketplace-reported completed transactions live in a separate sales dataset.

Current automated sale-history ingestion uses Sedo's public recent-sales feed. Those rows preserve the reported domain, amount, currency, source feed, and observation time. They are useful market context, but they are not a complete census of domain sales and are not treated as proof that an unrelated domain is worth the same amount.

Why a source appears in a case report

A useful research report should not hand someone a wall of links and call that transparency. A source belongs in a case because it has a specific evidentiary job. We explain that job so a reader can see why the source matters to the question they asked, even when they already found the same page during their own research.

For each material source, the public research desk aims to identify four things: why we used it, what it supports, what it does not establish by itself, and how that limitation fits this methodology. An RDAP record may help establish current registrar or registration data, but it does not reconstruct every historical owner. A marketplace page can document a current asking price, but it does not prove a completed sale or objective value. A redirect or parked page can document current web behavior, but it does not prove motive. An archived page can establish that content appeared at a particular captured time, but it may not tell us who controlled the domain.

The point is not to pretend every visitor is starting from zero. Someone submitting a case may already have screenshots, WHOIS results, broker emails, marketplace pages, or their own timeline. The report brings those pieces together with independently located sources and explains how they relate. Where we have a DSS guide that explains the evidence type in more depth, the report links to it so the reader can inspect the reasoning rather than simply accept the conclusion.

Historical registration data and archived website history

Current RDAP and registry records are freely accessible sources for present-day registration facts, but they do not reconstruct a domain’s full ownership history. Detailed historical WHOIS and registrant-change datasets are commonly maintained by commercial services such as DomainTools and SecurityTrails, and access to those deeper records generally requires a paid subscription or API plan. When those paid datasets are not part of a case, we say so rather than implying the information does not exist.

For historical website use, the public research desk uses the Internet Archive’s Wayback Machine where captures are available. Archived captures can establish that particular public content appeared at particular dates and can reveal major changes such as a developed business site later becoming parked, redirected, or offered for sale. They do not prove continuous operation between captures, identify the registrant or beneficial owner, or replace historical WHOIS records.

When a report cannot establish historical registrant or ownership changes from the free public sources used by this project, its limitation should be read literally: deeper historical registration datasets may exist behind commercial access, while DSS is reporting what it could independently document without paid historical-WHOIS access.

How Evidence Strength works

The Evidence Strength score measures the quality and completeness of the evidence record. It does not decide whether the submitter, registrant, marketplace, broker, or domain owner is morally or legally “right.” A high score means the report has stronger support for what it says. A low score means important facts remain unavailable, inaccessible, or unverified.

Do not read a one-point difference as scientific precision. Public web availability, source accessibility, archive playback, and AI-assisted synthesis can vary between research runs. DSS therefore makes scoring inputs deterministic where practical, publishes the component breakdown, and treats the underlying evidence and evidence band as more meaningful than tiny changes in the total score. A materially different factual conclusion should require materially different evidence, not merely different wording.

Sources and automation

Structured registration enrichment uses RDAP, the standardized Registration Data Access Protocol. Specific-domain research also checks the Internet Archive’s Wayback capture index and samples archived pages so historical website use is not left to ordinary web-search discovery. Marketplace or listing automation will only be added where access is permitted and technically appropriate. We do not treat another site’s Terms of Service as legislation, but we also do not design this project around defeating access controls, CAPTCHAs, authentication, rate limits, or anti-bot systems.

Where a marketplace deliberately publishes a public partner feed or other documented machine-readable interface, we may use that interface for discovery. Feed prices are stored first as candidate snapshots, not automatically promoted to public asking prices. For an individual Graveyard record, a recent price snapshot is attached only when an independent homepage, redirect, or nameserver observation confirms that the same domain is still for sale through the same marketplace.

Some infrastructure signals are strong enough to classify a condition even when a landing page is empty or JavaScript-dependent. For example, Efty documents ns1.eftydns.com and ns2.eftydns.com as its For-Sale landing-page nameservers, while GoDaddy documents ns01.cashparking.com and ns02.cashparking.com as its CashParking nameservers. Those provider-documented signals can support a high-confidence classification without inventing an asking price. Sale-specific BuyDomains infrastructure is treated slightly more conservatively. NameFind nameservers are reported separately as an infrastructure observation rather than automatically relabeled as “for sale” from DNS alone.

Provider references: Efty For-Sale landing pages · GoDaddy CashParking · GoDaddy NameFind portfolio reference.

The research database may retain publicly returned registration fields needed to audit a result, but the public Graveyard API intentionally omits individual registrant names. The project is about market behavior and documented domain conditions, not publishing unnecessary personal information about private registrants.

For verified public case submissions, successful research is automatically published with an evidence-strength score and component metrics. Automation is not treated as certainty: the score measures the completeness and support of the evidence record, while limitations, corrections, later evidence, and contradictory findings remain visible.

Corrections and right of reply

A domain owner, marketplace, broker, company, or other affected party can challenge a factual entry. Corrections should identify the domain, disputed statement, supporting evidence, and requested correction. When credible evidence shows that a published fact is wrong, the record should be corrected while preserving enough history to explain what changed.

USER STORIES START QUESTIONS. THEY DO NOT END THEM.