Limitations and evidence interpretation

These limitations describe the finished-product implementation before final release eligibility. They must be reviewed against the exact frozen candidate before any public compatibility claim.

Validation scope

• The implemented local workflow supports standalone macOS, Windows, and Linux. Retained historical real-player proof is macOS-focused and predates the final 26.9.0 candidate. Windows and Linux remain unclaimed as release-validated until the exact-candidate matrix passes.
• Android, iOS, and WebGL have a customer-facing external capture-kit workflow, but those paths remain unclaimed as release-validated until the exact candidate is built, deployed, captured, imported, and reviewed on the required platform/device matrix.
• No console-platform release claim is included. Consoles remain unsupported/unvalidated until a dedicated implementation and hardware evidence program exists.
• Editor measurements are diagnostic only and must not be presented as player-performance evidence.

Metrics and capability semantics

• GPU timing and other platform counters depend on Unity public APIs, graphics API, player configuration, and hardware. Unsupported, unavailable, permission-denied, unknown, partial, zero-only where positivity is required, or malformed counters remain explicit non-passing evidence states.
• A metric that genuinely does not apply to the selected target remains explicitly NotApplicable with no samples. It is preserved in history and exports, is not treated as comparable supported evidence, produces a dedicated not-applicable budget state, and never silently passes. A mismatched capability/evaluation pair is invalid evidence.
• Extension metric providers are project code. A provider can perturb the workload it measures; customers must keep provider overhead appropriate to the decision and validate provider capability on the target player.
• Scene-loading transitions measure the configured target transition, not every loading path in a project. Custom marker evidence requires the exact configured ProfilerMarker name.
• BuildReport duration is diagnostic unless the build host, cache state, workload, and environment are separately controlled as a benchmark. Output size, inventory, warnings/errors, and build options remain directly reviewable.

Statistics and experiments

• Outlier handling is either none or an explicitly selected Tukey-fence policy; it is never inferred. Changing outlier policy changes the reviewed evidence contract.
• A/B and A-B-B-A comparisons require valid source identity/order and comparable environments. A-B-B-A accepts contiguous A, B, B, A evidence and rejects ambiguous ordering.
• Environment requirements and fingerprint checks can intentionally invalidate otherwise complete measurements. This is a guardrail, not a transport error.

External-device workflow

• Android/iOS customers must retrieve the generated .kplab files from the application data sandbox using the platform's normal development/deployment tooling. Performance Lab does not include a proprietary cloud relay or device file browser.
• WebGL requires the explicit in-player user gesture to download each completed bundle because browser storage is not treated as sufficient customer retrieval evidence.
• A capture kit binds one built player inventory. Rebuilding or modifying that player invalidates the kit identity and requires a new kit/evidence run.

Recovery and retention

• An Editor/domain interruption does not resume a benchmark from the middle. Partial evidence is authenticated and marked recovery-required; retry starts a new reviewed run to avoid mixing uncontrolled machine/process state.
• Performance Lab does not upload or centrally retain customer evidence. Evidence retention, backup, and deletion remain the customer's responsibility.

Release and marketplace state

• Performance Lab is pinned to the exact bundled internal Release Core 26.8.5 package by source commit/tree, archive and manifest SHA-256, canonical inventory SHA-256, API level, and evidence schema. Core is not a standalone publication dependency. Release eligibility remains blocked until exact-current Core consumer, coexistence, installation, and platform suites pass.
• Final Unity/Fab exact-candidate platform/import matrices, deterministic artifacts, official requirements audits, accessibility/manual review, Unity Recorder storefront media, and portal configuration are release gates, not claims made by the current development stack.
• Final website/store copy must not claim a platform or workflow as release-validated until the machine-readable release authority records passing exact-candidate evidence.