The Eye: observing a product with rules, not a model

#Why look at the product itself

Most proof on Upvera comes from accounts a founder connects: a repository, a store listing, a revenue tool. Some products leave no such trail. A site hosted on a plain server has no deploy history Upvera can read, and a team that works in a private repository may not want to connect it. Yet the product is there, on the open web, for anyone to visit.

The Eye reads that public product. Once a founder has verified a domain, the Eye visits the site regularly and writes down what it saw. It does not ask the founder anything, and nothing it records is typed by a person.

The design question was narrow: how do you observe a product so that the same page always produces the same record, a release can be told apart from a text edit, and the observer cannot be talked into a different answer? The answer was to keep any model out of the observation itself.

The Eye visits only a domain whose owner has proved control of it, by a DNS TXT record or a file under the domain's /.well-known path. Verifying the domain is the founder's consent. One verified name belongs to one startup. If verification lapses, the Eye stops; if the founder disconnects the site, the Eye stops and the raw copies it kept are deleted.

It behaves like a polite crawler. It identifies itself with its own user agent, sends no cookies, follows redirects only within the same site and resolves every name before connecting, refusing private and local network addresses. Because the owner verified the domain, it always reads the home page and the sitemap; beyond those, it does not fetch paths that the site's robots.txt disallows. It sees only what a logged-out visitor sees.

#What it records

Each visit produces a small set of features, all integers or hashes:

Reach: whether the site answered, over HTTPS, after how many redirects, and how quickly.
Structure and text: a 64-bit SimHash of the page's tag structure and another of its visible text. Two pages that differ a little have hashes that differ in a few bits, which is how near-duplicate detection works at web scale.
Bundle: a fingerprint of the scripts and stylesheets the page loads from its own site, computed over the sorted list of their paths and content digests.
Routes: a fingerprint of the same-site links and sitemap paths.
Stage: a level on a fixed ladder, from unreachable to a product that takes payments.

No string longer than a short label reaches the record. The page's text is not stored in the observation or in any event. The full capture of a visit is kept encrypted and apart, for a limited period, so that a later version of the rules can recompute old observations, and is then deleted.

#Telling a release from an edit

Modern bundlers put a digest of each file's contents into its file name. A new release produces new file names; a new blog post or a changed headline does not. So the Eye treats a change in the bundle fingerprint as a candidate site release, and a change in text alone as no release at all.

A candidate becomes a site release only after the new state holds, so a flicker or a rollback does not count. A rebuild that changes almost nothing is recorded separately and does not count. A site release is stronger when another source agrees: a push to the startup's verified repository, a live deploy on Vercel or Netlify, or a new version in its verified store listing. The record keeps confirmed and unconfirmed site releases apart. This is separate from the ship chain, where a release counts only when a commit, a build and an App Store version confirm each other.

This works without knowing where the product is hosted. A site on a managed platform and a site on its own server look the same to the Eye: if the code it serves changed, something shipped.

#The stage ladder

The Eye places a product on one of five levels:

Level	What the page shows
0	No answer from the site
1	A parked domain or a name for sale
2	A landing page or a waitlist
3	A working product with a sign-in
4	A product that takes payments

The signs behind each level are cheap to add, so the stage is recorded as an observation of what the page shows, not as a verified fact. A level changes only when the new reading holds, and the record keeps it apart from facts that a second source confirms.

#Same answer everywhere

The core that turns a capture into features is written in Rust with few dependencies. It parses HTML with its own tokenizer rather than a third-party parser, so an update to someone else's parser cannot change its output. The same source compiles natively and to WebAssembly, and on a shared set of test vectors the two builds produce byte-identical results. Each observation records the fingerprint of the build that produced it.

That is what observing with rules buys. A language model reading the page could be swayed by text written for it, and its answer could change between runs. The Eye's observation has no model to persuade. Given the same capture, it returns the same features, every time.

#A screenshot history for store listings

The App Store lets developers change a listing's screenshots, and Apple's lookup service shows only the current set. Once a set is replaced, the old one is hard to find. So for a verified iOS app, Upvera keeps its own copy of each set and a fingerprint of every image.

Each image is identified first by Apple's asset path; a new upload gets a new path. Its content is fingerprinted with a difference hash (dHash) computed with integer arithmetic, so the fingerprint is the same on every platform; an independent implementation matched it on a sample of real App Store screenshots. Re-uploading the same image, or reordering the set, is not a change. A screenshot change on its own is not counted as a release either, since a listing's images can be updated independently of a new version; it only supports a release that arrives with a new version at the same time. The history is shown to the startup's owner, in the Upvera app.

#What people see

A signed-in visitor to a startup's page sees a recent capture of its site as the Eye saw it, its place on the stage ladder and its most recent release. The founder also sees quality facts about their own site: how often it answered, how quickly, which security headers it sends and when its certificate expires. Those facts come from a single vantage point and are cheap to improve, so they stay with the owner. Both views are live in the Upvera app and on the web.

#An assistant on top, kept apart

On top of the Eye, Upi, Upvera's AI assistant, can write a short card about the product from the page text the Eye captured: what it does and who it is for. The card is labeled as Upi's reading and dated, and the founder can hide it. It is kept apart on purpose. The card is not a line of proof; it never changes what the Eye observed, and it never feeds a stage, a release or a seal. The Eye's own path from page to record contains no model.

#Into the record

The Eye's observations become events in Upvera's record and are sealed into the same minute blocks as everything else, so its history cannot be quietly rewritten either. Under the value rule in force today, they are recorded as evidence and are not inputs to Upvera Value, which is computed by Upvera, unitless; not a price and not what a company is worth. Any change to that is a new rule version in the public release archive.

#Limits

The Eye sees public pages only. Anything behind a sign-in is out of view, by design.
A site that serves its code under fixed file names, without content digests, shows no release through its bundle. Its releases appear only when another source confirms them.
Response times come from one vantage point and say nothing about users elsewhere.
The stage ladder reads signs that are easy to place on a page. It describes the page, not the business.
Screenshot history covers iOS apps. Google Play listings are not tracked this way.