How verdicts work

DoesItARM is a pipeline: gather signals → resolve one verdict → serve it everywhere → keep it fresh. Meet the concepts here; the callable shape is the Verdict object.

One verdict per title

A title (an app or a game) has exactly one current verdict per scope — a (macOS version, chip) pair. Reports and tests are evidence that roll up into that one answer; they are not themselves the answer. Agents and IT teams need a single answer, not a thread to interpret.

Status — the five answers

Status	Means	Bar to assert
native	arm64-native on Apple Silicon	strong positive: an arm64 binary that ran, or a high-confidence report
rosetta2	x86_64, runs translated under Rosetta 2	strong positive: an x86_64 binary that ran under Rosetta
translation	runs via a layer (Game Porting Toolkit, CrossOver, Whisky, a VM — named)	strong positive for that layer
unsupported	does not run	strong negative — a reproduced failure, never one flaky run
unknown	not enough evidence to assert either way	the honest default

The bar is asymmetric on purpose. We assert a positive or a negative only when the evidence is strong; everything else is unknown (“Needs more data”). A negative needs reproduced strong evidence — a single crash is held as unknown pending another run — so we never publish a false negative. That asymmetry is the trust model.

Confidence, basis, and signals

Alongside the status, every verdict carries:

• confidence — high / medium / low.
• basis — how we know: binary inspection, automated_test, crowd reports, vendor statement, or curator note.
• signals — the individual reports and tests that produced the verdict, newest first. The resolver picks the winner by freshness × confidence and surfaces disagreement rather than hiding it.

Freshness — the moat

A compatibility answer decays, so every verdict carries lastVerified and a stale flag. Re-tests fire on triggers: a new macOS or Game Porting Toolkit release, an app update, a surge of new reports, or a scheduled cadence for popular titles. Freshness is the product’s core promise — see Caching & freshness for how callers read it.

The Rosetta 2 deadline

Because Rosetta 2 is removed in macOS 28 (fall 2027), a title that only runs through Rosetta is living on borrowed time. Verdicts flag this with breaksAtRosettaEol so a person — or a fleet audit — can plan the migration before the floor disappears.

Where the data comes from

Three sources feed each verdict: crowdsourced reports (ProtonDB-style, scales on community), an automated test harness (Preview) that runs titles on a cloud Apple Silicon fleet, and known facts (vendor announcements, binary architecture inspection, Homebrew metadata). DoesItARM never licenses or hosts the software — it gets copies to test cheaply and publishes only the resulting facts. More in The data we expose.