​

Mission Control workflow handover

​

Intended product requirement

The goal is valid and should not be discarded:

• Different customers must be able to use different sequence-status flows.
• A single customer must be able to run two projects on the same dataset at the same time.
• Each project must be able to progress its own work without forcing the other project to use the same status.
• Cuboid approval must be independent from segmentation progress. For example, cuboids can be approved while segmentation is still being labeled.
• Existing customers such as Lucid must keep their current hard-coded flow when no dataset configuration is assigned.

The problem is the current Mission Control implementation. It does not provide these guarantees in a clear or usable way.

​

Decision

Revert the Mission Control workflow experience now. Do not continue patching the current UI. Restore the legacy sequence status experience as the user-facing system while the replacement is designed. Keep any server data only when it is safe to keep and does not affect legacy behavior. Revisit customer and project-specific workflows as a new design.

​

What was built

Two different workflow systems were added:

1. Sequence deliverable workflow (#15997). This adds dataset-level cuboid and segmentation tracks, workflow states, approval states, and legacy-status projection.
2. Frame semseg workflow (#16025). This adds per-frame events, group checks, dataset and station matching, editor locks, and review actions.

These systems are independent, but MC presents parts of both systems next to the legacy sequence status. Users cannot tell which value controls the work. The implementation also attaches workflow state to the dataset or sequence in places where it needs to be scoped to the project and deliverable. That does not safely support two projects on one dataset.

​

Observed failures

• The semseg editor became unresponsive when a frame was in a protected state or the workflow check returned an unusable result.
• Group membership was used as an editing gate. This blocked valid staff and coworker users.
• Dataset-name matching was used to decide where the feature applied. A name change could change product behavior.
• The UI showed long labels in narrow controls. Text was truncated and hard to read.
• Workflow state, approval state, and legacy status were shown together without a clear primary status.
• Errors were reduced to generic messages. Users could not see whether a transition was blocked, invalid, or failed temporarily.
• export_blocked could not be selected in the v2 workflow. It is a legacy mapping value, not a declared v2 transition target. The mapping preserves old data; it does not make that status editable.

​

Current code and release history

• #15997: sequence deliverable workflow and legacy projection.
• #16025: frame semseg workflow with locks and group gates.
• #16102: improved handling when the frame workflow cannot answer.
• #16120: disabled the frame workflow as a Serve opt-out after the editor incident.
• #16157: removed frame-workflow-based mask editing locks, but retained the workflow and its UI.

Important server locations:

• server/server/apps/task/semseg_workflow.py
• server/server/apps/dataset/sequence_deliverable_workflow.py
• server/server/apps/dataset/sequence_status_transition_manager.py
• server/docs/serve_sequence_status_workflow_v2.json

Important MC locations:

• mission_control/lib/datasets/sequences/view/widgets/sequence_deliverable_workflow_menu.dart
• mission_control/lib/annotation_editor/object_mask/widgets/semseg_frame_workflow_actions.dart
• mission_control/lib/annotation_editor/object_mask/data/image_segmentation_result_repository.dart

​

Rollback requirements

1. Remove the frame workflow UI from MC.
2. Remove frame workflow locks and group-based editing gates.
3. Stop using dataset slugs, station IDs, or customer groups to enable editor behavior.
4. Restore the legacy sequence status control for existing datasets.
5. Ensure datasets without an explicitly assigned workflow use the existing hard-coded flow.
6. Do not rewrite existing sequence.status values during rollback.
7. Leave event and workflow tables untouched unless a migration owner confirms that deletion is safe.
8. Verify that 2D image, video, and other non-LiDAR datasets remain unchanged.

​

Later redesign constraints

If per-dataset workflows return, the replacement must meet these rules:

• One clear primary status in MC.
• Workflow ownership must be explicit: customer, dataset, project, and deliverable scope must not be mixed.
• Two projects on one dataset must have independent workflow and approval state.
• Approval is separate from work progress.
• No editor lock from workflow state.
• No group membership as a product permission gate.
• No dataset-name or station-name heuristics.
• Clear labels with enough width to read them.
• Explicit, visible transition reasons.
• Legacy datasets keep the legacy flow without configuration changes.
• Operational export states such as export_blocked and export_in_progress must either remain legacy statuses or be explicit editable states. A migration mapping alone is not enough.
• The design must support cuboid approval while segmentation continues.

​

Acceptance checks for the rollback

• A Serve coworker can open, edit, save, and submit a semseg frame.
• A staff user can change each legacy status allowed by the existing status manager, including the valid recovery path from export_blocked.
• MC shows one readable legacy status instead of competing status controls.
• Lucid and other datasets with no assigned revision behave exactly as before.
• No frame workflow group is required for normal editing.
• No generic workflow overlay blocks clicks.
• Existing sequence status history remains intact.

​

Owner request

Emal should own the rollback and the later redesign decision. Please land the rollback as a focused change, verify the acceptance checks above, and do not add more UI or transition rules to the current implementation before a new design is approved.