Three Attempt Records, One Model Outcome: Qwen3.8 Flash Scores 76 on Triage Desk

One preregistered Triage Desk run produced three immutable attempt records. Only one contained model work that could be judged.

That completed artifact earned 76/100 with high confidence. It passed all ten frozen requirements, including composed filters, blank-resolution validation, synchronized queue counts, preserved resolution state, keyboard operation, responsive behavior, and the selected incident remaining coherent as its state changed.

But the most important result came before there was an artifact to score.

The first attempt was compromised by a Proofrun persistence defect. The second ended with an HTTP 429 provider incident. Neither was treated as evidence about Qwen3.8 Flash’s product-building ability. Only the third attempt—a normal, completed generation routed to Alibaba—entered the model-outcome analysis.

Testing models also means refusing to turn failures in the surrounding infrastructure into model verdicts.

Three attempt records, one model outcome

This was not an open-ended sequence of retries until something looked good. The condition had been preregistered before dispatch, and every attempt remained linked to the same frozen model, prompt, route, reasoning setting, temperature, token contract, timing policy, and cost ceiling.

The preserved lineage is:

1. No submission — Proofrun protocol exception.
   A revision-3 routing-normalization defect prevented Proofrun from durably recording the provider’s immediate error. No artifact, provider generation identifier, usage receipt, or resolved-provider metadata survived. The defect was disclosed and the attempt was excluded from model-outcome analysis.

2. No submission — provider incident or capacity.
   The separately approved corrected attempt received an HTTP 429 through OpenRouter. It preserved no model artifact or usage receipt. Because no resolved provider was recorded, the incident cannot be attributed more specifically from the durable packet.

3. Completed submission — normal terminal outcome.
   The single provider-incident retry allowed by the preregistration completed normally, with Alibaba recorded as the resolved provider. This is the only artifact that received a score.

The successful attempt exhausted the preregistered retry allowance. The first two records were not hidden, rewritten, or averaged into the artifact judgment—but neither were they mislabeled as model failures.

That distinction is not administrative trivia. Folding those events into the score would have measured Proofrun’s persistence bug and a provider-routing incident alongside the interface Qwen actually produced.

The result

This was a solo artifact test, not a comparison, and no winner was designated. The claim is limited to one frozen run of qwen/qwen3.8-flash on Triage Desk. It is not a universal rating of the model or an estimate of its reliability across providers and prompts.

The authoritative human score profile was:

The locked rationale reads:

“Comparable overall polish to Terra, but the hierarchy and queue/detail layout feel less resolved and require slightly more effort to scan.”

Terra was not an opponent in this run. That wording records the evaluator’s prior experience as a personal calibration point, not a head-to-head result.

The score profile tells the more useful story. The artifact was strongest where product prototypes often break: state consistency, validation, interaction mechanics, and accessible control behavior. Its principal weakness was the organization and density of the interface around that working core.

What the model made

Qwen produced one self-contained HTML document with its CSS and JavaScript inline. Source inspection found no external scripts, stylesheets, fonts, images, API calls, or other network dependencies.

The initial queue contained exactly the four frozen incidents, including their supplied IDs, titles, customers, severities, channels, ages, assignees, and Open states. Desktop and mobile evidence both showed aggregate counts for Open, Critical, Unassigned, and Resolved incidents. Severity treatments, assignment labels, status badges, and a critical-unattended warning made the urgent ticket distinguishable without first opening it.

Selecting an incident retained the queue context and exposed its facts, customer report, activity timeline, severity and owner controls, internal-note field, and resolution action.

Search, status, and severity predicates shared one filtering path. The queue also included an explicit empty-result state, a description of the active filters, and a reset action.

The strongest preserved interaction was the resolution of INC-204. After assignment to Mira Chen and resolution, the incident remained selected and appeared as Resolved in both the queue and detail views. Counts changed coherently to 3 Open, 0 Critical, 0 Unassigned, and 1 Resolved, while the detail displayed a success banner.

That dependent state update is where superficially assembled interfaces often come apart. Here, the preserved demonstration remained synchronized.

Source inspection also supported the required blank-note guard. The handler trims the note and refuses to change incident state when it is empty. It shows incident-specific guidance, marks the field invalid, directs focus to the note, and announces the problem through a live region. On a valid resolution, it appends the internal note to a new timeline event before rerendering the dependent views.

The blank-note path was checked during human review, but it was not captured as separate publication evidence. The lower timeline entry was likewise outside the visible area of the preserved resolution frame, so its implementation is supported by source inspection rather than directly visible in that screenshot.

Where the craft score stopped at 76

Passing every requirement did not make the interface fully resolved.

My main reservation was information design. The queue and detail relationship worked, but the hierarchy felt less deliberate than the underlying workflow logic. The interface asked for slightly more scanning than I wanted, and some of its density could have been organized more compactly.

That is why Information design received 6/10, while Interaction & accessibility reached 9/10 and State robustness reached 10/10. The weakness was not a broken workflow. It was the amount of effort required to read and orient within a workflow that otherwise behaved very well.

An optional post-lock source audit also surfaced two implementation risks. These did not occur in the preserved runtime evidence and did not determine the already-locked human score.

First, the search field uses a 130-millisecond debounce whose callback captures the previous query. Clearing the search or resetting all filters does not cancel a pending timer. If either action occurs inside that narrow window, the old callback could restore stale search state while the visible field remains empty.

Second, after a successful resolution, the interface rerenders the detail and disables the now-inapplicable Resolve incident button. The handler then attempts to return focus to that disabled control. Native disabled buttons generally cannot receive focus, so keyboard focus could be lost or move unpredictably after the primary action.

Both are bounded source-inferred warnings, not reproduced failures.

The accessibility work was otherwise substantial. Labels were associated with controls, queue buttons exposed useful accessible names, visible :focus-visible styling was defined, live announcements were used, and the queue supported Arrow, Home, and End keys. The mobile layout supplied a back control and Escape handling, and the recorded mobile queue showed no apparent horizontal clipping.

At the controlled 583 × 520 viewport, the automated probe completed resize, click, drag, burst-click, and reset actions without runtime errors or reported artifact issues.

The earlier Qwen result—and what revision 3 does not prove

This was not Qwen3.8 Flash’s first Triage Desk appearance in Proofrun.

The earlier published result ran under Protocol v0.8 revision 1 with High reasoning and one shared 24,000-token completion ceiling. It reported 12,118 reasoning tokens, leaving approximately 11,882 tokens for visible output before reaching a length stop. The truncated artifact remained reviewable, but its core incident workflow did not initialize and it scored 19/100.

The present run used Protocol v0.8 revision 3: 16,000 tokens available for reasoning plus a protected 24,000-token artifact budget, for a 40,000-token total ceiling.

This time the model used 6,555 reasoning tokens and 21,862 completion tokens in total. Subtracting the reported reasoning usage leaves approximately 15,307 visible completion tokens. The generation then stopped normally.

That contrast is interesting, but it is not causal proof that the larger ceiling fixed the model. This successful response used fewer than 24,000 completion tokens in total and therefore would fit numerically beneath the earlier shared ceiling. The runs also represent separate stochastic generations under different frozen protocol conditions.

What revision 3 changed was the contract available before dispatch. Reasoning could no longer consume the capacity reserved for the visible artifact. This run completed comfortably within that protection, but one successful outcome cannot establish how often the protection will matter—or whether this particular artifact required it.

Time and cost

The successful generation took 197.268 seconds, or approximately 3 minutes 17 seconds, wall-clock.

First activity arrived after 5.071 seconds. Visible HTML began after 78.247 seconds, showing why a meaningful reasoning allowance and a separate artifact-start deadline matter even when the final response finishes comfortably inside its ceiling.

The successful attempt used:

• 612 prompt tokens
• 21,862 completion tokens
• 6,555 reported reasoning tokens
• Approximately 15,307 visible completion tokens
• $0.01036694 in reported generation cost

That is the known cost of the completed attempt, not a known total for the entire three-record sequence. The two no-submission attempts preserved no usage receipts, so their costs remain unknown rather than being assumed to be zero.

What I took from it

The final score did not surprise me.

The artifact is functional, unusually coherent in its dependent state changes, and more accessibility-minded than many generated product prototypes. It handled the difficult parts of the brief instead of merely presenting a convincing static shell.

I still dislike parts of the layout. The queue/detail arrangement could be tighter, clearer, and more deliberately prioritized. That is an editorial judgment rather than a newly measured defect, and the locked 6/10 Information-design score is where that judgment belongs.

The more durable lesson is procedural.

The completed artifact showed strong state handling and competent product construction. The surrounding attempt history showed how easily infrastructure incidents could be mistaken for model unreliability if a testing platform did not preserve provenance and classify failures before assigning a verdict.

Proofrun had to disclose its own defect, preserve the provider incident, respect the preregistered retry limit, and judge only the evidence the model actually produced.

That is what transparency looks like when the inconvenient part of the record belongs to the testing platform itself.

Limitations

This report covers one frozen solo artifact and cannot establish general performance or reliability for Qwen3.8 Flash across other prompts, routes, providers, or runs.

The earlier 19/100 result and this 76/100 result were produced under different protocol conditions and are not a controlled paired comparison. Their contrast does not establish that revision 3 caused the improvement.

The preserved runtime evidence did not exhaustively exercise every search, status, and severity combination. The blank-note guard was assessed during human review and supported by source inspection, but no dedicated publication screenshot preserves that failure state. The resolution frame does not visibly include the lower timeline entry containing the note.

Mobile evidence covers the initial queue, not the complete mobile selection, editing, resolution, and return workflow. No screen-reader session, accessibility-tree capture, or complete recorded keyboard traversal was preserved. Offline behavior is inferred from the absence of external references and network-call code rather than a supplied network trace.

The debounce and post-resolution focus risks are static-code inferences. Neither was reproduced in the preserved runtime evidence.

Finally, the optional evaluator smoke check was rated insufficient. Its synthetic repeated and side-swapped packets did not produce a stable calibration result. The accepted source findings remain supporting observations reviewed by the human editor, not independent verification or a general estimate of evaluator reliability.

Assistance note: Evidence analysis was provided by openai/gpt-5.6-sol, and article drafting was assisted by openai/gpt-5.6-sol. The human evaluation, finding decisions, framing, revisions, and publication approval remain the editor’s.