The interface uses precise words — OBSERVED, UNVERIFIABLE, λ, LAPSED— and they're easy to read the wrong way. This page defines each one, including the terms for the things Atlas can’t measure.
What a listing is, and what its state tells you.
One software product, identified by a single canonical URL.
A product is identified by its domain. Two products can share a name, but they can't share a hostname, and the hostname is what Atlas reads. That's why you submit a URL rather than a name: the URL tells Atlas where to look.
The page describing a product: what it does, who it is for, what it costs, and what we measured.
Every listing comes from a crawl of the product's own site. We don't write the copy or pull it from a press release. When a listing states a price or a feature, that text came off a page Atlas read, and the crawl behind it is dated.
A listing built by Atlas reading the product's live site.
This is the default, and the only kind that carries measurements. Because it's built from the product's own pages, Atlas can re-read it on a schedule and compare it to the previous crawl. That comparison is how a material update gets detected.
A listing entered by a person instead of read from a site, labelled as self-reported wherever it appears.
Some products have no crawlable marketing site: a desktop app, a private beta, something behind a login. We accept a written description for these and permanently mark where it came from.
A self-reported listing carries no readings and no freshness date, because there's nothing to re-read. The missing data is the point — this listing was never in a position to be verified, so nothing about it is presented as measured.
Whether anyone has proven they own the product.
A product in the catalog that its builder has not claimed.
An observed listing is a full listing, not a draft. A product appears because it exists and could be measured; paying or asking has nothing to do with it. If it's yours, claiming it lets you edit the description. Claiming doesn't change any measured value or affect where the product ranks.
The short name in a URL — the `murmur` in `/p/murmur`.
Derived from the product name, unique across the catalog, and fixed once assigned. Renaming a product keeps the original slug so existing links don't break.
A screenshot Atlas took of a page during the crawl, stored with the date it was taken.
Captures are of the product's public marketing pages: the hero, pricing, docs, a changelog. They don't show the product's interior, which would need an account we don't have.
We keep them so a listing that states a price can show you the page the price came from.
How recently Atlas read the product's site.
FRESH 2d means Atlas read the site two days ago, and the listing reflects what was there then. It says nothing about when the product last shipped, and the site may have changed since.
Every crawled listing carries a freshness date. An undated claim is exactly what the catalog is built to avoid, so a listing without one would defeat the point.
The main catalog view — every listing, with filters and sorts.
Filter by category, pricing model, access, freshness, or λ, and sort by recency or recent measurement activity. There's no sort by popularity, on purpose.
The shape of what a product charges, read off its pricing page.
This classifies the pricing page; it isn't a judgement of value. A product with a fourteen-day trial and no free tier is paid, since a trial isn't an ongoing tier.
Whether you can actually go and use the thing today.
Kept separate from pricing because the two answer different questions. A product can be free and still be something you can't get into, which is why access is worth stating on its own.
What remains at a delisted listing's URL: a note that it was withdrawn, served with HTTP 410.
A 404 tells a crawler the page might come back; a 410 says it's gone for good. Serving a soft 404 after delisting would leave the page in search indexes for months, so the removal wouldn't really be a removal.
How claims get checked, and how the results are shown. A verdict always opens onto its evidence.
One specific claim, checked against the product's live site, with the result and the evidence kept.
A reading is a single claim narrow enough to test — the free tier exists as stated, the demo completes — together with the result of testing it and the date. It isn't an opinion or a rating.
Every reading is shown with its verdict and its date.
The result of a reading. There are three.
unverifiable does a lot of work. A claim like “works with any git host” can't be tested from outside without an account on every git host. Hiding such claims would make the catalog look more certain than it is; repeating them as fact would make us the vendor's megaphone. So they're shown, quoted, dimmed, and labelled.
The data behind a verdict, expanded under it.
Check counts, response times, when Atlas last checked, the page a price was read from. Every verified reading expands onto this, so you can see what the verdict rests on instead of taking it on faith.
What can currently be measured.
The list is deliberately short and will grow. Adding a kind means committing to check it correctly on every listing indefinitely, which is a bigger commitment than adding a field.
A change between two crawls that a reader would actually want to know about.
Pricing changes matter most, then features, then positioning. A reworded headline doesn't count; a price moving from $19 to $29 does.
The comparison is deliberately cautious about one thing: if a crawl reaches fewer pages than the last one, the missing pages are discounted instead of reported as removals. Otherwise a brief outage on the vendor's side would look like them deleting half their features, and the flow would fill with events that never happened.
A live, time-ordered feed of what Atlas has done: new listings, refreshes, and material updates.
Ordered by time and never by score, so it reads as a record of activity rather than a leaderboard. The ATLAS panel on it shows current queue depth and the median ingest time.
Re-reading a listing so its measurements are current.
Listings are re-crawled on a rotation. You can also request a refresh directly when you need a listing current before its turn comes up. The previous crawl is kept so the two can be compared.
The permanent badge, and why it isn't being awarded yet.
The mark for a product that has sustained real traffic for the first time. It's permanent and can't be bought.
Named for the temperature at which helium becomes a superfluid — the point where it stops behaving like separate particles and starts moving as one. The badge marks a threshold a product has crossed; it isn't a rank.
Two things follow from it being permanent and unbuyable. It counts daily unique visitors held across consecutive days, because a thousand clicks can come from a shell loop while a thousand distinct people across a week can't be faked as easily. And the threshold is an absolute floor — a fixed number, not a percentile or a share of platform traffic — because a relative threshold could be moved by changing other products, handing every listing a lever over the rest.
Currently 25 daily uniques held across 7 consecutive days. Both numbers are settings, and both are provisional.
These are the current defaults in the code. They aren't final, and they're marked as provisional wherever they appear — see below.
Detection runs every day and records the result. Awarding is switched off, and stays off until there's enough real traffic to pick a threshold from.
Every published product is checked against the rule daily, and a full evidence row is written whether or not anything crossed. Only the award itself is disabled.
The badge is permanent, so the threshold has to be right. Any number picked before real traffic exists is a guess, and a guess that awards a permanent mark can't be undone. So we record the traffic distribution first and choose the number from it later. Until then, λ appears in the interface as something defined but not yet awarded.
A recorded human visit from a listing to the product's own site.
Counted narrowly. Bot user-agents, prefetches, HEAD requests, non-navigations, off-site referrers, the owner's own visits, and anything over the rate limit are all rejected before counting, each with the reason recorded.
The strictness matters because these numbers feed λ. A permanent badge computed from a loose counter would be one anyone could manufacture.
Proving a product is yours, and what happens if that proof goes away.
Proving you control a product's domain, which lets you edit its listing.
Claiming changes what you can edit. It doesn't alter what was measured, remove a failed reading, or move the product in any ranking. It gives you control of the description and nothing more, and that limit is what keeps the measurements worth reading.
Three ways to prove you control the domain.
Where a claim stands.
A claim whose proof was valid and has since disappeared.
Kept separate from rejected on purpose. rejected means the proof was never valid. lapsed means it was valid, and then the domain moved, expired, or was reconfigured. Those are different events — one is a failed attempt, the other is a domain changing hands — and merging them would hide the second.
Verified claims are re-checked continuously, not only at the moment they're first verified.
About once a day, Atlas looks for a verified claim's proof again. A single miss doesn't revoke anything: a claim lapses only after the proof has been gone for 7 days across at least 3 consecutive failed checks. DNS propagates unevenly and providers have outages, so one failed lookup means little on its own.
Without re-checking, verification would only ever mean “was true once”, and a domain that changed hands two years ago would still show its old owner. All three numbers are settings; these are the current defaults.
The dated record of everything that has happened to a domain's ownership.
Claims started and abandoned, proofs found and lost, re-checks passed and failed, auto-configuration attempts left incomplete — all recorded as they happen rather than reconstructed later.
Abandoned attempts are recorded on purpose. When you're trying to work out what happened to a domain, an attempt that went nowhere is often the entry you need.
An open standard that lets your DNS provider add the verification record for you, with your approval.
Where your provider supports it, claiming by DNS is: click, review what will be added on your provider's own screen, and approve. We cryptographically sign the request so your provider can confirm it came from Superfluidity and wasn't altered in transit.
We never receive, hold, or ask for your DNS credentials; approval happens entirely on your provider's site. The button appears only when your provider supports the standard and recognises our template. Otherwise you get the record to paste by hand, which works everywhere.
The signals that come from people, and how much weight they carry.
One person saying they use a product and it does what it says.
A vouch is one person's statement that they use a product. It isn't a review, a rating, or a vote, and there's no score or leaderboard attached — Discover has no sort by vouch count, because once popularity becomes a ranking, people start manufacturing it.
A vouch attaches a real identity to a statement of use. Its value is in who's behind it, so it's recorded as a name and carries no numeric weight.
A short written observation about a product, from someone who has used it.
For the things measurement can't reach: what a product is like to live with, where it gets awkward, what it's quietly good at. Each note is attributed, dated, and can't be edited by the product's owner.
Asking the catalog a question in plain language and getting an answer built only from what it has measured.
Answers cite the listings and readings they draw on, and an answer will say when the catalog holds nothing relevant. When that happens, the question is recorded as demand — see gaps. Asking costs credits, since it's work a machine does.
Something people repeatedly ask for that nothing in the catalog does.
When the catalog can't answer a question, the miss is recorded instead of discarded. Similar unanswered questions cluster together, and a cluster that keeps recurring becomes a public gap: a piece of demand with evidence attached that someone could go and build.
It's an idea the platform is built around. A search that returns nothing is usually a dead end; here it becomes one of the most useful things produced that day.
5 different people, across at least 3 different days, asking for substantially the same thing.
Both halves matter. Counting distinct people stops one person manufacturing demand by asking over and over. Requiring distinct days stops a single moment — a link going around, one conversation — from looking like sustained need.
Clustering is by meaning rather than wording, so “turn my voice memos into a changelog” and “changelog from audio notes” count together. Promoted clusters go to human review before they appear. Those thresholds are settings; these are the current defaults.
Where a gap stands.
A generated geometric mark that stands in for you. The platform has no profile photos.
It's derived from your handle, so it's the same everywhere and no one picks it. There are no uploads or photographs.
This is a deliberate decision, not a feature we haven't built. Photographs would turn attribution into presentation, so “who is vouching” would slide into “who looks credible.”
Your name here, at `/@handle`. Chosen once, when you first sign in.
How you sign in: an emailed link, no password.
There's no password to choose, forget, reuse, or leak. The first time you sign in, you pick a handle; after that, signing in is a link in your inbox.
A faster sign-in on a device you've set one up on, using Face ID, Touch ID, Windows Hello, or a security key.
Optional, and offered after you sign in with a magic link. On your next visit from the same device, you can sign in with the passkey instead of waiting for an email.
The crawler, and the terms the pipeline uses.
Our worker. It crawls products, extracts what they are, checks what they claim and writes the listings.
Everything in the catalog passed through Atlas. When the interface says a product was read, indexed, or measured, Atlas is what did it.
Atlas identifies itself honestly on every request as SuperfluidityBot/1.0, obeys robots.txt without exception, and publishes what it does at /bot.
One pass over a product's public site: fetching pages, rendering them, capturing screenshots, extracting facts.
Pages are rendered, not just fetched, because most product sites build their pricing in the browser and a raw fetch would read an empty shell. Only public pages are crawled — nothing behind a login, and nothing robots.txt disallows.
The whole path from a submitted URL to a listing you can review: queued, crawling, reading, writing, ready for review.
One unit of work Atlas has been asked to do, with a status you can watch.
Where a job stands.
Work waiting for a worker. Queue depth is how much of it there is right now.
Shown live at all times. A number that only appeared when it was flattering wouldn't be a status page.
The typical time from submitting a URL to a listing being ready for review.
It's the median, not the mean: one pathological site — a page that renders for ninety seconds — would drag an average away from the experience almost everyone actually gets.
The file a site uses to tell crawlers what they may read. Atlas obeys it.
If a site disallows SuperfluidityBot or *, Atlas stops — there's no override, even for a product someone wants listed. A site that declines to be crawled can still have a self-reported listing.
The check that stops a submitted URL from pointing at anything except the public internet.
Anyone can submit any URL, so anyone could try to point the crawler at a private address, a cloud metadata endpoint, or an internal service. Every URL is resolved and every resulting address is checked against private, loopback, link-local, and reserved ranges before any request is made, then checked again after each redirect, since a public hostname can redirect to 127.0.0.1.
What credits pay for, and what stays free.
The unit for work that costs us money to do — crawling, verifying, answering.
Reading the catalog is free. Browsing, comparing, reading measurements, and following a listing to the product are never metered.
Credits pay for asking a machine to do something: read a site, check its claims, answer a question against the catalog. Prices are on the pricing page. We don't repeat them next to every button, because a price on every click makes a tool feel like a meter running.
100 free credits a month. They expire after 30 days and are always spent first.
Granted credits are spent before purchased ones. Purchased credits don't expire, so spending the granted ones first means the credits with a deadline get used before the ones without, and you don't lose money to an expiry you forgot about.
Credits are held when work starts, and settled at what the work actually cost.
A crawl's cost isn't known until it runs; a four-page site and a four-hundred-page site are different amounts of work. So a hold is placed at the upper bound, and the difference is returned when the job finishes.
Settling below the hold is normal. A job that fails before work begins costs nothing: there's nothing to settle, and the hold is released in full.
Every credit movement on your account, with its reason, in order.
The catalog is readable by software without a key.
The catalog over HTTP. Reads need no key. Asking and writing need one, and cost credits.
Eleven endpoints over the same service layer the site itself runs on, so an answer given to a program is the answer given to a person.
Every endpoint, parameter, default and ceiling is published as OpenAPI 3.1 at /api/v1/openapi.json — generated from the same description that serves /api/v1 and the reference page, so the three cannot disagree. Import it into Postman or Insomnia, or generate a client from it.
Every endpoint with the request built for you, the response shown as it comes back, and the code to do it yourself.
Pick an operation and its parameters become a form — an enum is a list, an integer says its ceiling. The curl, fetch and Python snippets rebuild as you type, and they are the request the Run button sends, so copying one gives you exactly what the button does.
Signed out it is fully explorable: every operation opens on a real captured response, and only Run is gated. Signed in you can issue a console key in place — read and ask, twenty-four hours, never write.
Submitting a URL and refreshing a listing are shown but never run. Running one would crawl a live site and publish a listing, which is an act rather than a try; both have their own pages that say what they cost.
POST /api/v1/ask — one credit, and the answer arrives with the listings it rests on.
The same call the Ask page makes. Each citation carries why the answer used it and how strongly retrieval matched, which is what separates a measured answer from a plausible one.
It needs a key carrying the ask scope, and it charges the key's owner. An answer of "nothing here answers this" is free and says so, so a client can tell a refusal from a result without guessing.
The catalog as tools an AI agent can call directly, over the Model Context Protocol.
The same service layer as the web app, so an agent asking the catalog a question gets the same measured answer, with the same citations, that a person does.
A plain-text summary of the catalog at a fixed path, written for language models rather than browsers.
Reads are open without one. A key raises the rate limit, and is what asking and writing require.
Scopes are chosen per key. Every key can read; ask spends a credit a question and creates nothing; write can submit URLs and trigger re-crawls at twenty-five and ten credits. They are separate switches because they are separate risks.
A key can be given an expiry — a day, a week, a month, ninety days — enforced when the key is resolved rather than by a sweep, so an expired key stops working at the moment it expires. Rotating issues a replacement and leaves the old one alive for twenty-four hours, so swapping over is not an outage.
Revoking is immediate and cannot be undone. The record is kept rather than deleted, so "what was that key doing, and was it used after we killed it" still has an answer.
The current limits of the catalog, listed plainly so you know what it can and can't tell you.
The badge exists and detection runs daily, but nothing has been awarded yet, because the threshold hasn't been chosen from real data.
You'll see λ referenced across the interface. No product currently holds it. The λ section explains why that's deliberate.
The platform operates in the US market only. Other countries are out of scope until the legal position for each is properly worked out.
This is a scope decision, not a technical limit. Handling products, builders, and personal data in other jurisdictions carries obligations we'd rather meet before operating there than after.
Atlas reads public pages. It has no account with any product and cannot see what is behind a login.
Everything measured is visible from outside: the pricing page, the docs, a public demo, the certificate, the uptime of a public endpoint. What a product is like to use once you're inside it is beyond what Atlas can see, which is what field notes and vouches are for.
A listing dated two days ago reflects the site as it was two days ago. The site may have changed since.
Prices and features are read off real pages by a machine, and pricing pages are built to persuade rather than to be parsed.
Enterprise tiers with no number, prices behind a currency selector, feature lists that are really comparison tables — these trip it up. If a listing is wrong, report it; the report goes to a person, and the correction is dated like everything else.
`UNVERIFIABLE` is common, and it's a real answer, not a placeholder.
Integration claims, compliance claims, anything that needs an account somewhere else. These are shown quoted and attributed rather than hidden, so the number of things we couldn't check stays visible alongside the number we could.
It contains what has been submitted and what Atlas has found. It's not every product that exists.
When an answer says nothing in the catalog does what you asked, it means exactly that and nothing more. It doesn't claim nothing exists anywhere, which is why the question becomes a gap instead of being discarded.
Nothing is ordered by vouches, clicks, or traffic, and no placement is for sale.
Ordering by popularity would make popularity the thing to manufacture, and the platform's mechanisms are built to be expensive to game. Claiming a product doesn't move it, and neither does buying credits.
Malware, NSFW content, harassment, impersonation, spam, or plain inaccuracy — each report goes to a person, and the outcome is recorded.