Seen: matching words to the work
Upvera stamps a founder's post Seen when the change the post describes can be found in the founder's own verified site, repository or App Store listing, with a receipt that names the claim, the trace and the moment.
- Published
- Updated
- Reading
- 5 min
#Words and work
A post that says "we added dark mode" is a statement. Readers either take the founder's word for it or go looking. On most platforms nothing connects the sentence to the product it describes, so a feed fills with announcements that no one checks.
Upvera already reads a startup's work from where it lives: its repositories, its store listing and, through the Eye, its running site. Seen connects the two. When a founder posts about a change (an update, a new feature or a launch), Seen looks for that change in the founder's own verified sources. If it finds it, the post carries a small stamp, and anyone can open the receipt.
The stamp says one thing: a trace of the change the post describes was found in one of the founder's verified sources. It does not say the change is good, finished or used by anyone.
#Two steps, two kinds of judgment
Turning free text into something checkable takes language understanding. Deciding whether a check passed must not. So Seen has two steps, and only the first one involves a model.
Upi suggests. Upvera's assistant, Upi, reads the post, and only the post, and suggests a small number of checkable claims. Each claim names where a trace could appear and the words or path to look for. For a post about dark mode, an example suggestion might be: the phrase "dark mode" in a commit message, a new route such as /settings/appearance on the site, or the prefers-color-scheme media feature in a new stylesheet.
A rule decides. A deterministic matcher, with no model in it, takes those claims and looks for them in the founder's verified sources. It either finds a trace or it does not. The same claims and the same sources always give the same answer.
This split keeps third-party content away from the model. Upi never reads the pages, commits or release notes being checked, so none of them can carry instructions to it. Its only input is the founder's own post. Whatever Upi suggests, a stamp still needs a trace the matcher finds, and the receipt shows the exact claim that matched.
#What counts as a trace
The matcher looks only at sources whose ownership is verified, and only around the time of the post. Each kind of source has its own rule:
| Source | What counts |
|---|---|
| Site, text | the words are absent from the page before a release and present after it |
| Site, route | a new path appears among the site's own links or its sitemap |
| Site, style | a new CSS feature appears in the stylesheets of a new release |
| Repository | a commit pushed to the default branch, by a person rather than a bot, that matches the claim |
| App Store | the release notes of the verified app's current version carry the words |
A site trace counts only when it arrives with a site release the Eye has recorded, meaning the code the site serves actually changed. The before and after observations have to sit on either side of that release.
#A stamp that has to be earned twice
When the matcher finds a trace, the stamp is not written on its word. At the moment of sealing, the database looks up each trace again in Upvera's own record: the source must still be verified, belong to the same startup, and the release, commit or version must be there, in time. If any trace cannot be found again, no stamp is set.
The stamp and its later removal are events in Upvera's record, sealed into minute blocks like everything else. A stamp cannot be backdated, and its history cannot be quietly rewritten.
#What the receipt shows
Everyone sees the stamp on the post and can open its receipt. The receipt shows the claim that was checked, the kind of trace that matched, the source and when the trace appeared relative to the post. For a site trace, it shows the Eye's captures from before and after the release.
The receipt leaves things out on purpose. It does not quote commit messages or release notes, and it does not name a repository, which may be private; it says only that the trace came from GitHub. Upi's part is stated plainly in the receipt: Upi suggested the claim, a trace stamped it.
#Silence for others, honesty for the founder
A post that finds no trace looks like any other post. Nobody but its author sees that a check happened. The founder sees more: that a claim is still waiting for a trace, that no trace was found, or that no checkable claim could be read from the post.
One rule matters here. When a check cannot be completed, the result is no verdict, not "not found", and the check is tried again later. A failure on Upvera's side is not reported as a gap in the founder's work.
#When a stamp goes away
A stamp rests on its sources. If the founder disconnects a source that a stamp depends on, the stamp is lifted, and that is recorded as an event too. If the post is deleted, the stamp goes with it.
#Where it shows
Seen is live in the Upvera app and on the web, as a single line on the post card. The stamp is a display of evidence. Under the value rule in force today it is not an input to Upvera Value, which is computed by Upvera, unitless; not a price and not what a company is worth.
#Limits
- Seen checks that a described change left a trace. It cannot tell whether the change works well or matters to anyone.
- A claim Upi does not suggest is not checked, so a real change can go unstamped.
- App Store release notes can be read only for an app's current version, and Google Play notes are not read.
- Changes that leave no public trace, such as work behind a sign-in or in a repository that is not connected, cannot be seen.