feat: name the classes a pre-label run will and will not ask for - #703
Merged
Conversation
detectable_classes computed the exclusions and discarded them, so both reasons a class is absent from the prompt — no bbox among its geometries, or a required attribute a bare prediction carries no value for — were invisible to every surface. prompt_plan returns both halves, and detectable_classes reads its asked list so the prompt and the published plan cannot be two derivations. pre_label gains on_plan, announced after every refusal and before the first forward pass, which is what lets a surface name the prompt a run is actually about to use.
A run's prompt is invisible in its outcome: a schema whose vehicle class
requires an attribute completes a run, labels no vehicles, and says
nothing about why. GET /batches/{id}/pre-label answers asked_classes and
excluded_classes, each exclusion carrying every reason that holds against
it, so a client can name the prompt before a run starts.
Guarded on the launch's own terms — a batch nobody may pre-label and a
schema with no askable class refuse here with the same codes — and free
of the connection, since the prompt is a property of the pinned schema
alone.
PreLabelExclusionReason is an open vocabulary: it travels as a list a
client renders member by member, so a third reason must not cost an older
client the whole plan.
… does not Printed to stderr before the first forward pass, where it is still actionable — a class the prompt omits labels nothing, and afterwards there is only the silence to explain.
The dialog said a batch's schema becomes the prompt without saying which classes survive the narrowing, so a run that legitimately labels nothing read exactly like a run that should have labeled something. It now reads the plan when it opens and shows both halves: the classes it asks for, and beside them each class it does not with the reason — no box, or an attribute a prediction cannot supply. Shown again under a settled run's summary, which is where a run that labeled nothing is actually read. The lists come off the wire rather than being derived from the pinned schema here: the same narrowing decides what the run really prompts with, and a browser-side copy is how a dialog comes to name a class no run asks about. A schema with nothing askable refuses the read, and the dialog renders that refusal and leaves Start dead rather than waiting for the press to produce it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A pre-labeling run's prompt is the batch's pinned schema narrowed to the classes a bare box
prediction can be written as. A class is dropped for either of two reasons — it does not admit
bbox, so a detection has no shape to land as, or it declares a required attribute, which amodel's answer carries no value for — and until now both exclusions were silent everywhere.
Somebody with a
vehicleclass requiring acolorstarted a run, watched it complete, and foundno vehicles labeled, with nothing anywhere saying why. That is the gap this closes (#677).
prompt_planinvisionset/inference/prelabel.pynow returns both halves of the split, anddetectable_classesreads its asked list rather than computing its own, so the prompt a run usesand the plan a surface publishes cannot be two derivations.
reasonsis a list because bothreasons can hold against one class: a caller told only that a class admits no box would add one
and watch it stay absent from the next run's prompt.
GET /batches/{batch_id}/pre-labelpublishes the plan before a run starts. It guards on thelaunch's own terms, so a batch nobody may pre-label and a schema with no askable class refuse
there with the codes the launch already answers, and it takes no connection, since the prompt is
a property of the pinned schema alone. The dialog reads it on open and shows the asked-for classes
with the left-out ones beside them, and shows them again under a settled run's summary, which is
where a run that labeled nothing is actually read. At a terminal,
visionset batch pre-labelwrites the same two lines to stderr before the first forward pass.
PreLabelExclusionReasonis an open vocabulary. It travels as a list a client renders member bymember, so a release that finds a third way a class cannot hold a detection must not cost an older
client the whole plan. The browser drops a reason it cannot word and still names the class, which
is the half that must not be lost.
Found, not fixed
The MCP surface gets nothing here:
pre_label_batchstill says nothing about the prompt. Thatwork is on a follow-up branch stacked on this one.
Issue-number references exist in prose in
docs/batches.mdanddocs/mcp.mdthat predate thischange. They are left alone rather than swept in.
Test plan
Every stage run on the rebased branch, each exiting 0:
Nine mutations were run against the new tests to show they fail when the code is wrong: dropping
each exclusion reason, silencing the plan announcement, truncating the route's exclusion list,
hiding the dialog's excluded line, hiding it in done-mode, removing the unknown-reason filter, and
removing the launch guard. Each reddened exactly the tests that claim it.
Closes #677