Research policy

A model fact should be traceable to the document that supports it.

DeviceOK stores the source, verification date and diagnostic boundary with version-sensitive records. A page should not become more confident than the evidence behind it.

Source hierarchy

What gets trusted first

01Tier 1
Manufacturer / OS / app documentation

Model specifications, ports, charging behavior, official errors, permissions, drivers, firmware, repair and native diagnostics.

02Tier 1
Standards body / specification

USB, Bluetooth, W3C web APIs and other protocol behavior where the specification is the authoritative boundary.

03Tier 2
Authoritative technical documentation

Used when a primary source describes the mechanism but not the practical symptom, or when independent implementation notes clarify a browser/device behavior.

04Discovery only
Forums, communities and social posts

Useful for finding a reproducible pattern. Not enough by themselves for a risky repair instruction, exact model specification or compatibility claim.

Claims

How a factual record is reviewed

01
Define the exact question

“Does this laptop have USB-C?” is different from “Does this USB-C port support charging?” and different again from “Does it output DisplayPort video?” Each requires its own evidence.

02
Record model, generation and region when relevant

Names can be reused across hardware revisions. DeviceOK avoids turning one regional specification or generation into a universal claim.

03
Capture the direct answer and the limit

Requirements, caveats, verification steps and the browser/native boundary are stored beside the answer so search snippets do not erase the conditions.

04
Verify graph relationships

A published model, test, compatibility answer or diagnostic path must point to real internal records. The build audit rejects stale model→test and compatibility→model references.

05
Apply the indexability gate

A database record can power internal search without becoming a Google page. Indexable factual records need a distinct intent, provenance, a verification date and enough unique value to resolve the query.

Freshness

“Last verified” is not decorative

It means the cited source and the DeviceOK interpretation were checked on that date. App/browser/OS guidance should be reviewed more frequently than stable concepts such as connector dimensions or long-lived web standards.

A sitemap modification date is changed for meaningful content or source updates—not merely because the application was redeployed.

Conflicts

When sources disagree

DeviceOK narrows the claim to the model, revision, region or software version both sources can support. A newer official specification can supersede older documentation; if the conflict cannot be resolved, the page should show the uncertainty instead of selecting the more convenient answer.

Retail listings and generated compatibility tables do not override the device maker or applicable standard.

Publication guardrails

What DeviceOK deliberately refuses to scale

Driver-download pagesNo unofficial driver, firmware, DLL or “repair utility” mirrors.
Model-name substitutionNo thousands of pages where only the product name changes and the diagnostic answer stays generic.
Invented compatibilityNo battery, cartridge, RAM, SSD, cable or charger certainty without a documented relationship or clearly labeled planning-only rule.
Fake scansNo claims that JavaScript can read protected hardware health metrics merely because those queries attract search volume.