UpveraTechnology
UTR-26-01System reportLive · parts reach the app next

Upvera Proof Engine

Upvera Proof Engine reads a startup's work where it lives, in its repositories, its store listings and its running product, and keeps it as evidence that no one typed in.

Published
Updated
Reading
7 min
Plain text
/proof.md
Work is read at its source, passes an ownership check and is appended to the proof history. A typed claim has no way in.Where the work livesGitHubrepositoryApp Storestore listingGoogle Playstore listingVercel · Netlifydeploymentsnpm · PyPI · crates.iopackagesHugging FacemodelsRevenueCat · App Store Connectrevenue bandThe product itselfobserved by the Eye“We hit 10,000 users.”a typed claim · exampleno input for claimsOwnershipVerified ownerDNS TXT record/.well-known fileGitHub AppThe recordproof history · append-onlyRepository activityVersion live on the App StoreProduct stage observedRevenue band readShip chain sealedValue Engine · Proof mass

#Summary

The Proof Engine decides what counts as evidence on Upvera. Its rule is short. If a fact can be read from where the work lives, it is read from there. If it can't, it doesn't appear.

Founders don't type traction into Upvera. There is no field for it: no user counts, no revenue figures, no self-declared milestones. What a startup page shows is what its repositories, store listings, deployments, revenue tools and running product report about themselves, each one tied to an owner Upvera has verified.

The result is a record that grows the way the work grows: a commit at a time, a release at a time, observed rather than announced.

#Read at the source

A source is any place where work leaves a trace that Upvera can read without the founder's help: a GitHub repository, an App Store or Google Play listing, deployments on Vercel or Netlify, packages on npm, PyPI, crates.io, Packagist or Docker Hub, models on Hugging Face, analytics and revenue tools, and the product itself.

Linked sources are read from where they live, not self-reported. A startup page shows how many sources are linked and how many are verified, and every fact in its proof can be traced back to one of them.

#Ownership first

A repository anyone can link is not evidence. So a source counts only after its owner is verified, by one of three methods:

  • a DNS TXT record on the startup's domain,
  • a file served from the domain's /.well-known path, or
  • a GitHub App installed by the owner of the repository.

A verified external record belongs to exactly one startup. Ownership is re-confirmed continuously; a source that can no longer be confirmed stops counting until it can. Its history stays. Since October 15, 2026, verification intervals are appended to a proof history and never rewritten, so a startup's record shows not only what is verified now but when each source was verified, and for how long.

#Oracles

Some facts are too sensitive to show as numbers and too important to leave out. For those, the Proof Engine runs oracles: narrow readers that turn a private source into a public, coarse signal.

Revenue tier

A founder can connect RevenueCat or App Store Connect with read-only access. The oracle reads gross revenue over a rolling window and publishes only a band. The exact figure is never shown, never stored on the page and never typed.

Ship chain

A release counts when three independent confirmations agree: a commit in a verified repository, a build that came from it, and a version that went live in the App Store. Until all three line up, nothing is sealed.

Age

The age of an app listing and of a domain are read from their sources, so “since when” is never a claim either.

#The Eye and Seen

The Eye is a deterministic observer of a startup's own product. It visits only sites and store listings whose ownership is verified and records three things: whether the product is up, what stage it has reached and whether a new version shipped. It is written in Rust, uses no AI, and gives the same answer compiled natively or to WebAssembly. Its observations reach the record as integers and hashes; the raw pages it reads are encrypted and kept only for a limited time. A separate history fingerprints every App Store screenshot change, so the way a product presents itself has a timeline too.

Seen connects words to work. When a founder posts about a change, Upi can suggest the few claims in the post that could be checked. A deterministic matcher, with no AI in it, then looks for each change in the founder's verified site, repository or store listing. When a claim meets a trace, the post is stamped Seen, with a receipt naming the claim, the source and the moment. Until then, only the founder sees that a claim is pending.

#Into value

Proof is one of the four masses of Upvera Value, beside work, people and wings. In the method published in the value guide, it carries 17 percent of the weight. The Eye, Seen and team proof are recorded today but do not move value yet; they will enter only through a published rule version, after a shadow run.

#By the numbers

0fields for self-reported tractionBy design
3independent confirmations to seal a releaseShip chain, live 2026-10-15
1startup per verified external recordOwnership registry, live 2026-09-30
3ways to verify ownership: DNS, a well-known file or a GitHub AppOwnership registry

#Published and private

Published

  • Which sources are linked and which are verified, on every startup page
  • The method, at the level of the public value guide
  • Seen receipts: the claim, the source and the moment
  • Revenue as a band, never as a figure

Kept private, on purpose

  • The thresholds and heuristics that resist gaming, because published they would be gamed
  • The raw pages the Eye reads, encrypted and deleted on a schedule
  • Integration credentials, kept in an encrypted vault
  • Exact revenue, which never leaves the oracle

#Status and releases

The rules described here run on Upvera's servers today, and since version 1.7.0 the Upvera app shows them: domain verification, revenue bands, the ship chain, the Eye and Seen. Store screenshot history is visible to the startup's owner. Team proof counts members who sign with a device key, and device keys are rolling out.

  1. days@0One definition of a build day and a streak, read from the event record.Live
  2. days@1One definition of a build day and a streak.Live
  3. record@0Facts with receipts. No score.Live
  4. record@1The founder record goes live: facts with receipts, no score.Live
  5. SeenA founder's post is stamped when the change it describes shows up in the product itself.Live
  6. Team proofRepository contributors matched to verified people on the startup's team.Rolling out
  7. Store screenshot historyEvery App Store screenshot change is fingerprinted and kept as part of the product's history.Live
  8. The EyeA deterministic observer of a startup's own product: is it up, what stage is it at, did a new version ship.Live
  9. Ship chainA release counts when a commit, a build and an App Store version confirm each other.Live
  10. Proof historyVerification intervals are appended and never rewritten.Live
  11. Revenue tier, read at the sourceRead-only connections to RevenueCat or App Store Connect report a revenue band. Never typed, never exact.Live
  12. Ownership-anchored proof sourcesA source counts only after its owner is verified by DNS, a well-known file or a GitHub App. One record, one startup.Live

#Questions

Can a founder add a number by hand?

No. There is no field for it. If a fact can't be read from a source the founder owns, it doesn't appear.

What happens when a source disconnects?

It stops counting once its ownership can no longer be confirmed. Its history stays, and it counts again when ownership is confirmed.

Does AI decide what counts?

No. Upi may suggest a claim worth checking. Deterministic code decides, and AI output never feeds the Value Engine.