Cannot Reproduce on the Eight-Gigabyte Card

Cannot Reproduce describes the tester's rig, not the defect. The reproduction recipe is already in the report: 8 GB VRAM, driver branch 551.xx, and 90-plus minutes of continuous play reaching 7.9 GB committed against an 8 GB budget. QA's 12 GB card never has to make the allocation decision that crashes, so it cannot exhibit this bug at any sample size. Concluding Won't Fix from an environment that is structurally incapable of reproducing it is not a finding, it is an absence of testing.

Next twenty-four hours:

• Move the bug to a machine with an 8 GB card on 551.xx, or cap VRAM on the pool machine, and run a scripted two-hour soak on Ashen District at the quality preset from the reports.
• Pull the allocator high-water mark and the last sixty seconds of allocation events from the dumps; request instrumentation from rendering if the build does not carry it.
• Re-examine the duplicate link honestly. The earlier leak was fixed nine months ago and this dump has a different top frame and a different trigger; either re-open it as a suspected regression with evidence or unlink it, but do not let a stale link stand in for analysis.
• Tell production, with dates and numbers, that the demo laptops match the affected configuration.

The downgrade should follow the evidence, not precede it.

• Summary: from a generic title to 'Crash to desktop loading Ashen District after 90+ min session on 8 GB VRAM / driver 551.xx (6/6 reports)'. Configuration and trigger belong in the title so the bug is searchable and cannot be waved away as generic instability.
• Environment: GPU model, VRAM, driver and OS build, quality preset, resolution, upscaling mode, platform, build number.
• Preconditions: continuous session of at least 90 minutes, committed memory at or above 7.8 GB, level entered from the hub.
• Steps: numbered, and executable by anyone with the hardware.
• Expected versus actual: level loads; instead an access violation in the texture streaming allocator, with the dump attached.
• Reproducibility: '6/6 on 8 GB, 0/22 on 12 GB'. That single line is the argument, and it is what converts the report from opinion to evidence.
• Evidence: two dumps, client log, allocation high-water trace, and a video of one occurrence.
• Component and owner: rendering, texture streaming, assigned to a named engineer rather than a team queue.
• Severity and priority with a one-line rationale each, plus a link to the demo dates and the affected-hardware query.

The rewrite does not add new information so much as stop burying the information that already existed.

Severity is impact. A crash that also discards an hour and a half of progress is S1 by any consistent definition, and frequency does not change that: a crash affecting a meaningful slice of the install base is still a crash. The existing S3 almost certainly came from 'we cannot reproduce it', which is a confidence statement smuggled into an impact field where it does not belong.

Priority is scheduling, and this is P1 or P2. The affected configuration is a real share of the install base, and in five days twenty publisher laptops with that exact configuration will run two-hour sessions, which means the demo will hit a 90-minute trigger on camera, repeatedly. That converts a background stability issue into a same-week business risk regardless of how rare it is among players.

State them separately in the report: severity S1 (crash plus progress loss), priority P1 (demo exposure, install-base reach). Then name the fact that would move priority without touching severity: if the demo build ships with a memory cap keeping committed memory below 7.5 GB, priority can drop to P2 and stay S1. Severity never drops because a deadline is inconvenient; only the schedule does.