Perception loss in multimodal stream
An assistant watches a live stream and reports what passes: a serial number on a label, a needle on a gauge, which box on a form is ticked, how many people are in frame. The perception path is lossy in ways nothing reports. Frames are sampled at a low rate, images are resized to the encoder's input, and the encoder's output is a compression whose losses are not itemized anywhere. The stream is buffered for a few minutes for cost and privacy reasons, and after that it is gone.
The failure is a plausible detail that the preserved representation could not have carried. The digits were six pixels tall. The gauge was behind someone's arm in the frame that happened to be sampled. The prior fills the gap, and it fills it the same way every time, so asking again agrees with itself.
Off the table: retraining or swapping the encoder, running the full resolution path over the whole stream, human review, and any detector whose evidence is agreement between repeated passes of a model over the same input, because a strong prior is consistent by construction. You have a small number of re-observations per minute against the live buffer, so re-reading everything is not a design.
Hand in the triage rule that decides which claims get one of those re-observations, and the signals it is allowed to use. Hand in a preservation criterion: what it means for the pipeline to have carried the information a claim asserts, stated so that it can be checked on an instrumented example where you control the source. Hand in the re-observation protocol and the argument for why its answer counts as evidence rather than a second guess. Say what happens when the buffer has aged out and a claim can never be checked, including what the operator is shown. Hand in the experiment separating read from guessed, in which difficulty is varied by degrading the signal rather than by changing the content.
Ties break toward a design that will say this could not have been read, over one that returns a confidence number.
Clarify scale and constraints first. Propose a clean component breakdown, then go deep on the hard parts (data model, bottlenecks, consistency, failure modes) and name the trade-offs you are making.