Owner-Verified Directories Need Proof of Domain

A listing is not the same as a claim

A software directory can accept a URL in several ways. It can let anyone submit a record. It can ask for an account. It can require a review. Or it can ask the person filing the record to prove that they control the product's domain.

These are not cosmetic differences. They determine what a directory can honestly say about the record in front of you.

An open submission proves only that someone knew the URL and wanted it listed. That can still be useful. Community submissions are often how new tools, side projects, and obscure utilities become discoverable. But the directory should be clear about the distinction between submitted and confirmed by the owner.

Owner verification adds a second fact: the operator who filed or brought the record online could make a controlled change to the product's web presence. That does not prove that the software is excellent, solvent, secure, or destined for greatness. It proves something narrower and more useful: the person making the claim has a credible connection to the domain.

A RECORD WITHOUT PROOF IS A RUMOUR WITH GOOD FORMATTING.

What domain proof actually establishes

Domain verification is a control test. The directory gives the operator a one-time or domain-specific instruction, and the operator completes it somewhere only a domain controller should be able to change.

The common patterns are familiar from other web services. Google documents several site-ownership methods, including uploading a file to the root of a site and adding a DNS record. Its documentation explains that verification depends on access to the site or its domain configuration, not merely on knowing the address. Google's site verification guide describes the practical difference between URL-prefix and domain-level verification.

For a software directory, the result is not a legal identity check. It is a technical ownership signal. A founder can verify a domain. So can a developer, agency, employee, or contractor with legitimate access. A domain can also be compromised, misconfigured, or abandoned later. Verification is evidence, not prophecy.

That narrower claim is exactly why the label matters. A good directory should not turn a technical check into a grand statement about the company behind the product.

Open submission still has a place

Open submission is useful at the discovery layer. It lowers the barrier for people who find a tool and want to recommend it. A user, journalist, investor, or fellow maker may know about a product before its owner has ever heard of the directory.

That path is especially valuable for:

• Small projects whose makers are busy building rather than promoting.
• Open-source tools maintained by a distributed community.
• Older software that still works but has no active marketing department.
• Products discovered through a repository, forum, or personal recommendation.

The weakness is accountability. If anybody can create a public record and edit its important fields, the directory has fewer grounds for trusting changes to the product name, URL, description, pricing, or status. A malicious edit may redirect attention. A careless one may make a living product look dead. A fan may describe a tool generously. A critic may do the opposite.

Open submission should therefore be treated as an intake mechanism, not as a certification system. It is a way to place a candidate in the archive. It is not a reason to pretend that the candidate has been endorsed.

Why The Director separates filing from dominion

ARCHIVE-9 permits a record to begin locally before its operator proves dominion. This is deliberate. The archive can receive a URL and assemble a draft record without granting the submitter authority over a public listing.

To bring that record online, the operator must prove control of the product's domain. The current proof of dominion manual provides two routes:

1. Add a unique meta tag to the site's head, then let the crawler check it.
2. Add a DNS TXT record at _archive9.yourdomain.com, then request a check.

The meta-tag route is usually convenient when the operator can edit the site template. The DNS route is useful when the site is managed by a platform, the page code is locked, or the operator prefers to keep the proof outside the visible page. The value is supplied by the terminal and is unique to the domain. It is not a badge of quality. It is a key that answers one question: can this operator change the domain's control surface.

Once dominion is established, the record can be brought online and maintained by the verified operator. The record becomes accountable without requiring every visitor to create an account or trust an anonymous editor.

I DO NOT ASK WHO YOU SAY YOU ARE. I ASK WHAT YOU CAN CHANGE.

What verification does not protect against

Verification is powerful because it is limited. It does not solve every directory problem.

It does not guarantee that a product is safe. It does not validate a security claim. It does not confirm that pricing is current. It does not tell you whether the team is responsive or whether the company will exist next year.

It also does not stop a legitimate operator from neglecting the listing. A verified record can become stale when a pricing page changes, a product pivots, a domain is sold, or a project quietly shuts down. Domain control and record maintenance are separate duties.

This is why a directory should combine verification with signal checks and visible update paths. A record needs a way to say what was observed, when it was observed, and whether the owner has corrected it since. Visitors should be able to distinguish owner-entered information from archive observations. The more important the claim, the less sensible it is to hide its origin.

For operators, the practical lesson is simple: verification gets you authority over the record, but it does not maintain the record for you.

How to choose the right submission path

Use open submission when you are recommending someone else's software, filing a project you discovered, or adding a useful candidate that has not yet been claimed. Include the source of your information when possible. A short, accurate submission is more valuable than a promotional paragraph written by a stranger.

Use owner verification when you control the product domain and want to correct, extend, or maintain its public record. Start with the bring your record online guide, then complete the proof step before treating the listing as yours to manage.

If you are filing your own software from the beginning, submit it to the archive. The terminal will gather the initial information, offer a local record, and explain what is needed before public filing.

Do not choose a directory solely because it offers a verified label. Inspect what the label means. Does it mean domain control, email confirmation, manual review, or a paid profile? Does the directory re-check important signals? Can the owner update mistakes? Can a visitor see the difference between a claim and an observation?

The word verified is useful only when the mechanism behind it is visible.

A small proof for a larger archive

The best directories do not confuse openness with trust or verification with perfection. They use both.

Open submission gives the archive breadth. Owner verification gives important records a clearer chain of responsibility. Signal checks expose changes after filing. Maintenance tools give operators a way to correct the public record before a small error becomes the entire story.

That is the sensible arrangement for software discovery: let the archive hear from everyone, then ask the people who want authority to demonstrate it.

ARCHIVE-9 will accept a rumour as an intake event. It will not promote the rumour to dominion without evidence.

THE DOMAIN IS THE WITNESS. THE RECORD IS THE TESTIMONY.