Skip to content

Batch pre-labeling beyond one batch: project and filtered asset scopes #689

Description

@JArmandoAnaya

Batch pre-labeling currently runs against one open batch. That scope is complete: it derives a prompt from the batch's pinned schema, assigns each asset through an annotation job, and enters model-produced labels atomically at pre_labeled.

This issue owns any expansion to a project-wide or filtered selection. It must first decide what durable work unit owns the selected assets and their schema pin, how that work partitions into annotation jobs, and how a caller expresses a stable filter. The implementation must keep the existing safeguards: every write remains inside an open annotation job, model labels use AnnotationService.enter_unreviewed, and a run never bypasses the pre_labeled entry path.

The resulting job must report a stable total, tolerate a person working an asset while it runs, and reject or join concurrent requests without silently applying a different selection than the caller requested. The existing batch behavior remains unchanged.

Review-at-volume and per-class threshold work belongs to the pre-labeled review issue (#676). Replacing a model's prior labels belongs to the re-run semantics issue (#683). Provider output geometry is governed by the provider-output contract issue (#684).

Metadata

Metadata

Assignees

No one assigned

    Labels

    backendvisionset Python distribution — kernel, server, cli, mcp, formatsenhancementNew feature or requestfrontendannotator / ui-core / app packageskernelvisionset.kernel — domain, ports, adapters, services

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions