Moderation is necessary in a software directory, but it doesn't make the directory honest by itself. Moderation asks whether content should remain visible. Provenance answers the question a buyer usually needs first: where did this particular claim come from?
That distinction shapes how we build directree. A clean catalogue can still mislead if crawled facts, model interpretations, and founder-written claims all look equally certain.
Moderation and provenance solve different problems
Moderation is the boundary system. It can catch spam, duplicate submissions, abuse, prohibited content, and attempts to manipulate a listing. It decides what is allowed on the platform.
Provenance is the origin system. It tells you how a piece of information reached the page and who, or what, is responsible for it.
The two systems overlap, but they aren't substitutes:
| Question | Moderation | Provenance | |---|---:|---:| | Is this listing allowed? | Yes | No | | Is this submission spam or abuse? | Yes | No | | Did this field come from the product website? | No | Yes | | Was this sentence inferred by AI? | No | Yes | | Did a verified founder edit this claim? | No | Yes | | How should a correction be handled? | Partly | Yes |
A listing can pass moderation and still contain an inference that a reader mistakes for a verified fact. Nothing is obviously abusive. Nothing needs to be removed. The problem is that the page hides where the claim came from.
The same sentence can carry different authority
Consider a simple listing statement:
The product is best suited to small design teams.
If that wording appears on the product's public website, a crawler can observe it as the vendor's stated positioning. If a model reads the homepage and reaches that conclusion, it is an interpretation. If a domain-verified founder adds it, it is an owner claim.
The words may be identical. Their authority isn't.
This is why directree labels information as Observed, AI-inferred, or Founder-edited. The label isn't a decorative trust badge. It changes how a reader should interpret the field.
- Observed means the information was found on a public product property or can otherwise be checked.
- AI-inferred means a model interpreted available material. It may be useful, but it isn't presented as a verified fact.
- Founder-edited means a verified owner corrected or supplied the field.
Our honesty model explainer covers those labels in detail. Provenance has to live at field level. A single "verified listing" badge at the top can't explain the origin of every statement below it.
Why a page-level badge is too blunt
Software changes continuously. A pricing page may be current while an old feature page remains indexed. A founder may correct the target audience but leave integrations untouched. A crawler may observe that a free trial is mentioned while a model infers who the product is for.
Calling the entire page "verified" compresses all of those states into one reassuring word.
We think that creates false confidence. It also makes corrections harder. If every field has an origin, a correction can be routed according to the kind of information involved:
- An observed fact looks wrong. Re-check the public source and update the crawl result.
- An inference is weak. Replace or revise the interpretation without pretending the old wording was factual.
- A founder claim is disputed. Confirm ownership and treat it as a vendor assertion, not independent evidence.
- The source says nothing. Show that the information isn't stated instead of filling the gap with a guess.
This source-aware correction path is the practical reason provenance matters. It doesn't only explain the past. It tells the directory what to do next.
What we learned from the search results
We searched for software directory transparency and provenance before writing this. The strongest examples focused on source verification, last-checked dates, or avoiding paid placement. Those are useful trust signals.
But they still leave a separate design question: what happens when different fields on the same page come from different actors?
That is the part we believe directory builders need to treat as infrastructure. Provenance shouldn't be a paragraph on an About page. It should travel with the individual claim.
The underlying idea isn't new. The US National Institute of Standards and Technology defines provenance in terms of the chronology of the origin, development, ownership, location, and changes to a system or its data. That definition appears in a US government report on AI accountability and transparency. We apply a smaller, product-directory version of the same principle: preserve enough origin information for a reader to understand what they're seeing.
Provenance doesn't prove truth
This limitation matters.
A public product website can contain stale information. A verified founder can make an optimistic claim. An AI inference can be sensible or wrong. Provenance doesn't magically certify that every statement is true.
It does something narrower and more defensible: it exposes the chain of responsibility.
That makes healthy scepticism possible. A buyer can place more weight on an observed pricing fact than an inferred "best for" description. A founder can see which fields need correction. The directory can stop presenting every sentence in the same authoritative voice.
This is also why we sometimes publish "not stated." As we explained in why honest directories say we don't know, an explicit gap is more useful than a confident invention.
The build cost is real
Field-level provenance creates work that a generic content system avoids.
The database needs to retain source type. The enrichment pipeline needs rules for what qualifies as observed and what must stay inferred. The interface needs labels that remain readable without overwhelming the listing. Founder edits need domain verification. Updates must avoid silently changing an inference into a fact.
It would be easier to generate one polished description, attach a general disclaimer, and move on. It would also make the reader do the forensic work.
Our choice is to make the system carry that burden. Anyone can paste a URL and receive a structured listing in about 30 seconds, but speed doesn't excuse hiding how the result was assembled. You can see the approach across the honest software directory.
A practical test for any directory
When you evaluate a directory, don't stop at "Are listings moderated?" Ask four more questions:
- Can I distinguish vendor claims from independent observations?
- Is AI-written interpretation labelled at the point where it appears?
- Can I tell which fields a verified owner changed?
- Does the directory admit when the available source doesn't answer a question?
If the answer is no, the directory may still be useful. But its clean interface is doing more trust work than its evidence system.
Moderation keeps obvious rubbish out. Provenance helps readers reason about everything that remains. An honest directory needs both.
Frequently asked questions
What is data provenance in a software directory?
It is the recorded origin of a listing claim, such as a public product page, an AI interpretation, or an edit made by a verified founder.
Is a founder-edited field independently verified?
No. The founder's relationship to the product is verified, but the field remains an owner-supplied claim. The label tells readers who supplied it.
Why not label the whole listing as verified?
Because one listing can contain several origins at once. A page-level badge can't distinguish an observed pricing fact from an AI-inferred audience description.
Does provenance prevent incorrect information?
No. It makes the origin visible and gives corrections a clearer path. Sources can still be stale, incomplete, or mistaken.
Can moderation replace provenance labels?
No. Moderation decides whether content is allowed. Provenance explains where an allowed claim came from and how much authority a reader should give it.