Why this topic matters to me now
If UA is a claim, then Web API is the surface by which that claim can be checked.
The idea is simple. Browsers publish release notes. New APIs appear in those notes. So the “floor” of capabilities can be judged not by a digit in a string, but by what is actually present at runtime.
I call this feature-floor — a version floor by capabilities.
Feature-detection vs version parsing
Version parsing answers: “what did the browser call itself?” Feature-detection answers another question: “what can it do right now?”
Those questions diverge more often than SEO and antifraud practice would like.
An old engine with a new UA — a low floor under a high claim. A new engine with a trimmed or odd UA — a high floor under a modest badge. Flags, previews, partial implementations — a floor “with a mezzanine.”
Public pages like x-bot.tech show exactly this logic: look at APIs and platform consistency, do not pray to one string. I unpack the idea as literacy, not as copying someone else’s production.
Marker types in plain words
In the lab it helps to think in three buckets — without internal flag names.
Strict markers. APIs that should already exist on a given branch. Their absence under a high claimed number is a strong contradiction.
Optional. Features that depend on platform, policy, permissions. Absence alone says little.
Preview / experimental. Present for some users, absent for others. You cannot hang a verdict on them.
A beginner’s mistake is to turn the whole feature calendar into a “bot/not bot” checklist. The right habit is to look for a floor-vs-claim contradiction, not to collect “suspicious absences.”
Where to get the calendar
Not from your head and not from a closed file on a laptop if the goal is public literacy.
Chrome release notes / New in Chrome. Firefox Releases on MDN. WebKit / Safari blogs.
Plus open educational detectors as examples of method, not as ground truth.
I deliberately do not list concrete APIs “for checking Chrome N” here. The list goes stale. The method stays: claim → expected floor → measurement → mismatch.
Link to the previous note
UA said “I am high.” The version floor said “floor is lower.” That is not automatically a bot. That is a hole in the story.
Sometimes the hole is my outdated matrix. Sometimes a strange build. Sometimes privacy and disabled surfaces.
So the next note is about MDN browser-compat-data: how to cross-check the calendar offline and why you must not drag BCD straight into a runtime verdict.
Public anchors: https://x-bot.tech/chrome/version1/ https://developer.chrome.com/release-notes/ https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases https://webkit.org/blog/
Public frame (links)
I cross-check the feature calendar with Chrome release notes, Firefox Releases and the WebKit blog. A practical public example of the thinking is x-bot version1.
What this changes in detect and/or in the build (without specifics)
In detect I more often write “the surface looks like era N±” than “version proven.” In the build I check whether I am creating one era’s surface under another era’s claim. The mirrors look at each other again. False precision like “version = 131.4” is less useful to me than a consistency interval and a list of contradictions.
What I will not say, and why
I do not publish tables of internal markers, thresholds, or recipes for “painting a version floor for a site.”
Short first-person takeaway
Feature-floor teaches humility: a browser is a floor of capabilities, not a sticker on a box. I calibrate the floor against open release notes and check consistency.
