0025: Retire The Detached Visual Evidence Pipeline

Status: Accepted

The decision below to retain a separate native-review capability declaration is superseded by ADR 0026. The engine-native workflow and named-consumer export decisions remain current.

Date: 2026-07-21

Context

STAGE maintained a detached visual pipeline with request, shot planning, capture indexing, media verification, AI and human review, contact sheets, baselines, comparisons, receipts, migrations, schemas, command-line tools, tests, and synthetic dogfood. It was deterministic and internally consistent.

The only real project director who used it rejected it as a development workflow. The package made placeholder and weakly composed subjects look complete, duplicated state already owned by the game engine, slowed visual tuning, and required substantial maintenance. Only the Enemy Arrival sequence was useful, because its stills and motion answered one concrete question.

This repository is private and has one maintainer. No named external consumer depends on the detached interfaces. Continuing to operate them for hypothetical compatibility conflicts with Earned Infrastructure and the Product Utility Gate.

Decision

• Remove the detached visual request, plan, manifest, review, baseline, comparison, receipt, contact-sheet, migration, validator, and synthetic dogfood interfaces from the active repository.
• Preserve their implementation in Git history and retain a narrow Circussy lesson containing the useful Enemy Arrival sequence and the rejection.
• Keep Visual Review engine-native and consumer-complete.
• Prefer a product-native Gallery or Almanac when recurring visual questions earn a persistent surface.
• Permit screenshots, videos, builds, comparisons, and decision records only as project/engine-native outputs for a named consumer. STAGE does not define a universal evidence-package protocol.
• At this checkpoint, retain the Native Visual Review Capability Declaration and its compatibility-named visual-almanac interface. ADR 0026 later retired it after Lanternworks showed that the ordinary project map already carried the useful operation contract.
• Treat user behavior and observed decision utility as stronger local evidence than technical conformance of an unused tool.

Consequences

• The release gate becomes smaller and faster.
• Visual work has one default direction: inspect and tune the production consumer in the engine, then persist only recurring value.
• Historical detached artifacts are no longer accepted by current validators. This is an intentional pre-1.0 compatibility removal with no known consumer.
• A future durable export protocol must be earned by at least one named, recurring consumer and should begin from the smallest project-native output that consumer actually uses.
• Deletion itself becomes STAGE dogfood: unsupported infrastructure is retired rather than hidden behind a "legacy" label indefinitely.

Evidence Boundary

This decision is supported by direct same-owner dogfood and the absence of a repository consumer. It does not prove that contact sheets, screenshot regression, or portable review packages are universally bad. Those can be appropriate when a real team, platform, CI, audit, or release workflow uses them. The rejected claim is that STAGE should own their universal protocol by default.