Genace

generation model regression checklist: Maintain a release scorecard with real evidence

A generation model regression checklist should track changes in the complete delivery workflow. Visual quality matters, but a release can also regress parameter handling, collection, or accounting. Use a scorecard tied to saved evidence and leave untested fields explicitly untested.

Freeze the comparison scope

Record the application revision, adapter revision, evaluation set revision, rubric revision, and supported model identifiers. Distinguish changes you control from upstream implementation details you cannot observe.

Select stable cases representing actual use. Include at least one ordinary request and relevant boundary cases such as seed zero, missing optional parameters, or an empty reference selection. These contract cases can often be reviewed offline without generating new media.

For output comparisons, archive the exact previous artifacts. Re-running the old prompt later does not reconstruct the previous release, even with a saved seed.

Separate scorecard sections

Use one section for request contracts: accepted JSON types, alias precedence, defaults, valid duration choices, first-reference mapping, and reviewed extra policy. A changed serialized request is a distinct finding even before its visual effect is known.

Use another section for operational behavior: job identifiers retained, terminal states collected, downloads validated, and unresolved acceptance handled without duplicate submission. A missing collector should not be disguised as a low visual score.

Use a visual section with the frozen human rubric. Record individual judgments and disagreements rather than reducing every task to a vague improvement label. Keep accounting evidence in its own section with held credits, settlement, and refunds.

Define release gates before review

Choose which findings block release for your application. A changed product identity might block a catalog workflow, while a minor background preference might trigger only an editorial note.

Set the decision owner and escalation path. If a criterion cannot be assessed because a file is missing, mark it untested or blocked rather than pass. A blank cell must not be interpreted as zero defects.

When a comparison intentionally changes prompt, model, and ratio together, label it a combined workflow change. Do not attribute the entire result to the model alone.

Report observations narrowly

A scorecard should name the specific cases affected and link their evidence. Do not invent latency distributions, accuracy percentages, or overall rankings when no controlled observations exist. This proposed procedure contains no measured model results.

For a future completed review, report the number of planned and observed cases, missing evidence, review method, and approved exceptions. Preserve prior scorecards so the team’s acceptance standard remains traceable.

Accept the process when another reviewer can find the source request, output, rubric judgment, accounting outcome, and release decision for every case. Continue with prompt test sets, human rubrics, and pricing snapshots when preparing the next release review.

Continue with quality and testing

Where these facts come from

  • codebase: src/app/api/v1/images/generations/route.ts
  • codebase: src/app/api/v1/video/generations/route.ts
  • codebase: src/ai/providers/nano-banana.ts
  • codebase: src/ai/providers/seedance.ts
  • codebase: src/ai/providers/kling.ts
  • codebase: src/ai/providers/veo3.ts
  • codebase: src/ai/providers/types.ts
  • Proposed internal evaluation method; no model runs or benchmark results reported
  • Editorial keyword hypothesis; search volume not measured