threejs-visual-validation

Visual Validation

Validate claims, not polished frames. Keep each verdict scoped to one declared claim so evidence for appearance cannot substitute for mechanism, timing, or lifecycle proof. The owning subject skill defines mechanism truth and failure signatures; this skill defines how to falsify them.

1. Predeclare every claim

For each claim, record:

• class: visual, mechanism, temporal, performance, GPU attribution, resource, or lifecycle;
• invariant and truth source;
• observable and the diagnostic that isolates it;
• native-domain metric, units, alignment, mask, and aggregation;
• acceptance gate fixed before candidate inspection;
• blocking failure and required evidence.

Label every claim-driving number Authored, Derived, Measured, or Gated and record its unit and source. Keep unknown values unknown.

This step is complete when every claim has a direct falsifier and no claim is supported only by the final image.

2. Freeze the run

For a purely CPU-side numerical, byte-layout, or metadata claim, freeze its actual execution environment without inventing a renderer dependency. Such results do not prove a GPU shader, rendered image, or target-performance claim. The initialized-backend gate below applies to renderer-dependent claims.

Freeze the exact Three.js revision, renderer and initialized backend, target, browser/GPU, camera matrices, seed, time or deterministic step, viewport, DPR, quality state, assets, and color/output graph. Construct the renderer with timestamp tracking before initialization whenever a declared claim needs GPU timing:

const renderer = new WebGPURenderer( {
  trackTimestamp: gpuTimingRequirement === 'required'
} );

await renderer.init();

if ( renderer.backend.isWebGPUBackend !== true ) {
  throw new Error( 'Canonical WebGPU validation is unavailable on this target.' );
}

Record the blocker when canonical WebGPU is unavailable. Reach $threejs-compatibility-fallbacks only when the user explicitly asks for that branch.