The result is only useful when the method is visible.

Four protocol classes, one interaction rule

InputProof groups tests into input events, visual inspection, permission-based media and system capability snapshots. Every protocol starts with one primary action, keeps raw data local and separates browser evidence from claims the browser cannot prove.

Seven versioned browser protocols

Protocol IDs remain stable across UI and exported evidence. Version changes are explicit when signals, calculations or report semantics change.

Units must describe the signal actually observed

What each suite actually does

A permission grant is a measured lifecycle

Audio and Camera separate the Permission API preflight, getUserMedia request, live MediaStreamTrack, device-label exposure and release check. Request latency ends when getUserMedia resolves; slower device enumeration is not counted as permission latency.

Permission API support is optional and never substitutes for the actual getUserMedia result. Safari or Firefox may report the preflight as unsupported while still granting a live Track. An unanswered native prompt becomes awaiting-user after eight seconds without being classified as a denial. Permission denial, missing devices, busy devices, unsupported constraints, insecure contexts and unexpected Track endings have separate recovery and retest instructions.

Camera v1.6 starts a separate three-second first-frame window after the Track becomes live. VideoFrameCallback is preferred; loadeddata is the fallback signal. This does not replace the independent ten-second frame-delivery protocol.

Stopping a protocol calls stop on every Track and verifies that each Track reports an ended readyState. Evidence contains only low-dimensional permission and Track metadata, never audio samples or video frames.

Thirty-seven entries share seven measurement engines

Specialist pages are search and workflow entry points, not cloned calculators. Each page states one diagnostic intent, controlled steps, expected outputs, likely causes and measurement limits, then deep-links to the relevant live protocol module.

This keeps formulas, thresholds and Evidence generation in one implementation while allowing a user to start from a symptom such as frame skipping, microphone noise or webcam FPS.

Evidence becomes a finding, action and retest

Display v1.5 plus Audio and Camera v1.6 pass low-dimensional results into deterministic diagnostic rules. A finding includes the observed Evidence, plausible causes, ordered actions and a concrete retest condition. Severity is one of Pass, Info, Review or Action.

Rules do not infer a hardware defect from a browser symptom alone. For example, weak camera frame delivery can come from tab scheduling, lighting, negotiated constraints or the media path. The action sequence asks the user to control those variables and repeat the same protocol before replacement advice.

Controller measurement boundary

The browser Gamepad API exposes normalized axes, button values, connection state, mapping type and an implementation-defined timestamp. It does not expose firmware calibration tables, USB descriptors in a portable way, physical force, sensor temperature or the exact deadzone configured by a game.

Idle capture protocol

The controller rests untouched on a stable surface while the page remains visible. InputProof samples the selected gamepad during a five-second window. Frames captured while a strong button or axis interaction is visible are excluded.

preflight → 5 second foreground window
→ discard interrupted / interacted frames
→ require minimum evidence
→ calculate both stick distributions
→ assign finding + confidence

optional sweep → 6 second full-edge movement
→ X/Y range + 36 angular bins
→ coverage + circularity reference

Robust statistics before labels

For each stick we calculate median X/Y center, median radial offset, P95 radial offset, maximum observed offset and a P95 distance from the median center as a jitter indicator.

P95 is the primary idle metric. It captures persistent high deviation without allowing one isolated frame to determine the verdict.

Initial classification thresholds

These are versioned InputProof product thresholds. They are not published manufacturer limits and will be recalibrated against a documented physical controller matrix.

Verdict and confidence are separate

A large deviation can appear in a low-quality capture. That is why severity never stands alone. Confidence incorporates eligible sample count, capture duration, stable frame ratio and foreground continuity.

A significant finding with low confidence leads to a retest, not a replacement recommendation.

Capability-gated rather than browser-branded

InputProof tests the API surface at runtime. A missing control is reported as unsupported or unreported instead of being replaced with a guessed browser result.

Local baselines require an explicit opt-in

Completing or exporting a test does not save history. Each suite exposes a separate opt-in toggle and Save local baseline action. The consent state itself is not persisted.

Saved summaries can be exported or cleared per protocol. Mouse repeatability uses the latest three to five complete eight-second runs only when protocol version, coarse runtime and Pointer API match. Event-rate maximum deviation, stability range and dropout range are scored separately; the worst status becomes the displayed result. Thresholds and excluded-run counts remain visible and are included in the history export.

This comparison cannot verify that the same physical mouse or settings were used. It describes browser-delivered repeatability, not USB polling rate or hardware certification.

Versioned evidence

Exported reports include a report schema and threshold-set version. When thresholds change, older reports keep their original version so the result remains interpretable.

Every Evidence envelope records its protocol version, a millisecond report ID, local runtime environment, evidence field count and explicit raw-signal exclusion. Display uses v1.5, Audio and Camera use v1.6, and the other suites remain on v1.4.