Operator verification at RunLocalAI

What verified-owner means

The ✓Verified owner modifier appears next to a contributor's name on a benchmark row when an editor has reviewed evidence and concluded the contributor probably owns the hardware they are submitting from. That sentence is doing a lot of work, so the rest of this page unpacks it.

Verified-owner is editorial judgment. It is not a credential. It does not represent a cryptographic attestation, a notarized document, or a verifiable on-chain identity. It represents an editor having looked at the contributor's evidence and decided, on balance, that the operator owns the machine they are reporting from. The judgment is reviewable — the audit log records the editor and the rationale — and it is reversible. An operator who loses verified-owner status (because conflicting evidence emerges) loses it on every page where their submissions appear; the change is not silent.

The modifier is intended to surface to readers a useful signal: this submission is from someone an editor has examined enough to believe is a real operator with the hardware in question, rather than an account whose claims are unverified. It is not a stronger claim than that.

Evidence we accept

The evidence base is a small set of weak signals that combine to a moderately strong signal. None of them, alone, is conclusive. The list is intentionally not exhaustive — an editor can accept other forms of evidence and document the rationale in the audit log — but these are the common ones.

Build photos. A photo of the build, ideally with the GPU visible and identifying details (motherboard model, case, peripherals) sufficient to make a copy-paste claim hard. Stock vendor photos do not count. The photo does not need to contain the operator's face or any personally identifying marker — just the hardware.

Public posts about the hardware. A Reddit thread, a Twitter post, a YouTube video, a forum discussion where the operator has previously written about owning the hardware. The post needs to predate the benchmark submission; backdating a post in response to a verification request does not count.

Prior contributions. An operator with three or more reproducible submissions on the same hardware tier across different models is, by behavior, demonstrating ownership. The signal is implicit but strong; the cost of fabricating a consistent measurement profile across many models is high enough that a sustained submission history is meaningful evidence.

Public software profile. A GitHub profile showing engagement with the local-AI ecosystem, a personal blog about hardware, an active presence in a relevant Discord — the kind of public footprint that suggests the operator is who they claim to be. We do not require any one of these; we look at the overall picture.

Editors weigh evidence and document the decision. A submission with build photos and a long contribution history is an easy approve. A submission with no public footprint and one previous comment is hard; the operator can still submit benchmarks (and they will appear with ◯Community submitted), but they will not carry the verified-owner modifier without more evidence accumulating.

What we never require

The list of things contributors are explicitly never asked to provide is shorter and sharper than the evidence list, and the reason it exists is that the privacy floor under contributors is not negotiable.

Real names. Submitters can use a handle, a first-name-only display, an initial, or a pseudonym. We will publish whatever name they ask us to publish, and editorial verification does not require us to know more.

Government identification. No driver's license, no passport, no government-issued ID of any kind. We do not store identity documents. We do not ask to see them. The nearest equivalent is a public software profile, and even that is optional.

Doxxable information. No physical address, no phone number, no email beyond the contact email used for submission communications, no employer disclosure, no any-other- identifier that could be used to locate the operator in the physical world. The contact email is private to editorial; it does not appear on the public page, and the contributor decides what name renders next to their submissions.

Account creation requirements. A submission does not require a permanent account. Operators can submit through the public form, receive editorial communications via email, and never create a persistent profile if they do not want one. Accounts exist for operators who want to track their submissions and reputation; they are optional, not required.

These are floor commitments. They are not adjustable. An editorial process that requires real-name disclosure to verify ownership is a process that excludes operators who have legitimate reasons for not exposing their identity, and we are not willing to make that tradeoff.

The hideContributor flag

Some operators want their numbers published but do not want their handle next to the submission. The use cases vary: professional considerations (a employee whose company prefers not to associate publicly with consumer hardware benchmarking), personal privacy preferences, sensitivity around the specific hardware tier (an operator running on a workstation they would rather not advertise), or simply a preference to contribute without attribution.

The hideContributor flag, set at submission time, causes the public page to render the row without a contributor name. The submission is still attributed in the editorial audit log — editorial knows who submitted it, the verification still applies, the trust state still climbs the ladder normally. The only thing the flag changes is the public attribution. The row renders as “anonymous” or “contributor” depending on context.

Hidden-contributor submissions can still earn verified-owner status; the verification is editorial, and the public absence of a name does not invalidate the underlying evidence. What the public page shows in those cases is the verification badge without the name — the reader sees that an editor has reviewed the submitter, but does not see who the submitter is.

How reputation is earned

We do not have points. We do not have leaderboards. We do not have streak counters or contribution rankings. The trust apparatus is built around measurements, not contributors, and the catalog deliberately avoids the gamification incentives that turn other platforms into submission-velocity contests.

Reputation is editorial. A contributor who has submitted three reproducible benchmarks on the same hardware, with full metadata, that subsequent operators have reproduced successfully — that contributor is, by behavior, trustworthy. Editorial knows. The audit log records it. Future submissions from that contributor get a soft prior of credibility. None of this is rendered as a badge on the contributor's public profile, because the rendering would create a target — a leaderboard incentive that tilts the catalog away from quality and toward submission count.

The verified-owner modifier is the closest thing to a public reputation marker, and even that is per-hardware. An operator verified as the owner of one specific build does not carry that verification across to other hardware they might claim. A new card requires fresh evidence. The discipline is: every verification claim is grounded in something specific.

The honest limits

Three places where the system cannot deliver more than it promises.

We cannot prove ownership. Verified-owner is a judgment about evidence, not proof of evidence. A determined adversary who fakes build photos, runs sustained reproducible submissions, and engages in the public ecosystem in ways consistent with hardware ownership can probably acquire the verified-owner modifier without owning the hardware. The cost is high — fabricating a consistent multi-month behavioral pattern is not free — but the cost is not infinite, and we are honest that the modifier is a probabilistic signal rather than a certainty.

We cannot rule out coordinated behavior. Two operators colluding to reproduce each other's submissions could push a row up the trust ladder without the underlying measurement being independently confirmed. The defense is the independent-reproducer requirement at the highest tier: an independently-reproduced row requires three or more confirming operators, and editorial reviews the contributor profiles of all of them. Two-operator collusion lifts a row to reproduced; it does not reach independently-reproduced.

We cannot make participation costless. The verification process described above asks operators to provide evidence, and reviewing that evidence takes editorial time. We accept that some legitimate operators will not bother — the cost-benefit ratio of contributing a benchmark to a niche site for no compensation is, for many, not in favor. That is a real cost of the floor commitments above. The alternative — making verification cheaper by accepting weaker evidence, or requiring more identity from contributors to reduce review effort — would compromise either trust or privacy. We chose this tradeoff and we live with it.