Specification: Dispatch Reliability and Reconciliation¶

TLDR (Solution Summary)¶

• Define a phased dispatch improvement initiative that first removes operator-facing friction and false signals in BetterFleet Dispatch, then adds assignment CSV reconciliation and first-class manual/ad-hoc block handling.
• Dispatch page layout + fix resize, scroll, and control persistence behavior + search, filters, and tabs remain accessible during manual testing.
• Dispatch block status model + stop surfacing misleading SoC and allocation errors for live or completed work and add explicit completed-route outcomes + operators can trust what still needs action.
• Future dispatch horizon + replace split frontend/backend cutoff logic with one selected-day, depot-local future rule + future allocations stay visible consistently through the selected day.
• Schedule upload and edit flow + remove placeholder schedule failures and enable applicability-period editing + operators can correct schedule periods without retry-driven workarounds.
• Assignment CSV round-trip + add export plus previewed import/apply for block-to-vehicle assignments + dispatchers can seed and reconcile allocations faster.
• Manual and ad-hoc block operations + add first-class create, update, delete, and highlight behavior aligned with assignment CSV semantics + dispatchers can represent replacements, missing work, and late changes explicitly.
• Dispatch relevance model + preserve block source and vehicle-type distinctions and add clearer filters for ad-hoc and non-relevant work + noisy block lists become operationally usable.

1. Summary¶

• Problem statement:
• BetterFleet Dispatch currently creates unnecessary operator friction during manual setup and testing because controls can disappear during resize and scroll interactions, and the current page layout does not reliably preserve access to search and filtering tools.
• Dispatch status and viability behavior can be misleading because started or completed work can still surface insufficient-energy-style action prompts derived from current SoC rather than the block's operational state.
• Future visibility is currently split across frontend and backend logic, producing a rolling-feel horizon rather than one clear operator contract for what should appear in Dispatch.
• Schedule upload and schedule editing flows are brittle because upload can fall through to an invalid placeholder schedule ID and schedule applicability dates cannot be corrected after upload.
• Dispatchers do not have a CSV round-trip for initial assignments, so reconciling paper or external dispatch plans into BetterFleet is manual and slow.
• Dispatchers also do not have first-class manual/ad-hoc block support, so replacement work and missing blocks cannot be represented cleanly or aligned with assignment import/export.
• Goal and success criteria:
• Define one dispatch improvement initiative that raises operator trust first and then adds reconciliation tooling and manual/ad-hoc block handling without destabilizing the existing day-of-operations flow.
• Success is measured by:
  • a dispatcher being able to keep search, filters, and sort controls accessible while manually testing allocations;
  • started and completed blocks no longer surfacing false insufficiency or misleading action prompts;
  • the Future tab consistently showing upcoming work from depot-local current time through the selected dispatch day end;
  • schedule applicability dates being editable after upload and during later schedule management;
  • dispatchers being able to export current assignments and import a CSV with a safe preview before apply;
  • ad-hoc blocks being explicitly visible, manageable, and round-trippable through export/import semantics.
• What will be built in this phase:
• Dispatch page layout + fix control persistence and resize behavior + manual dispatch testing no longer depends on awkward page scrolling.
• Dispatch block status model + show actionable status only for work that still needs intervention + started and completed routes stop looking falsely broken.
• Future tab contract + define and apply one depot-local selected-day horizon + operators can see the same future work in both API-backed data and the UI.
• Schedule upload and edit flow + remove invalid placeholder schedule follow-up behavior and allow applicability edits + schedule management becomes recoverable without re-upload-only workarounds.
• Assignment CSV round-trip + export current assignments and import a validated preview/apply set of assignment changes + dispatch setup can begin from an external dispatch sheet.
• Manual/ad-hoc block operations + create, update, delete, export, import, and highlight manual/ad-hoc blocks + streetcar replacements and other late operational work become explicit dispatch objects.
• Dispatch filtering and relevance model + distinguish schedule-derived versus manual/ad-hoc work and preserve vehicle-type data for better filtering + non-relevant noise becomes easier to suppress and future eBus alignment remains possible.
• Scope (in/out) for this phase:
• In:
  • Dispatch page UI polish and operator-trust bug fixes;
  • a single future-horizon contract for Dispatch;
  • schedule upload and schedule applicability corrections;
  • assignment export and previewed CSV import/apply;
  • manual/ad-hoc block create, update, delete, and highlighting;
  • filtering and relevance improvements tied to block source and type;
  • preserving vehicle-type/source data needed for later better filtering and eBus-aligned dispatch decisions.
• Out:
  • low-level database schema decisions or migration plans;
  • storing uploaded assignment CSVs as durable historical snapshots;
  • a full redesign of the Dispatch information architecture or visual design system;
  • automatic inference of all ad-hoc work from external systems without dispatcher confirmation;
  • a full schedule-generation redesign beyond the corrections needed to preserve relevant block/type data.
• Current baseline (as of April 1, 2026):
• The Dispatch page uses temporary panel height logic that can leave the layout stale after resize, which contributes to controls disappearing while manually testing the page.
• Started and completed blocks can still be assessed using pre-start energy assumptions derived from live SoC, which makes some already-running or already-finished work look incorrectly actionable.
• Future visibility is currently split between backend retrieval cutoffs and frontend tab filtering, with both sides encoding time-window assumptions.
• GTFS upload can fall through to an invalid placeholder schedule ID, and schedule applicability fields are disabled in both upload and edit flows.
• Dispatch has no current assignment export/import workflow.
• Block edit and delete flows exist, but there is no first-class block creation API or UI flow for manual/ad-hoc dispatch blocks.
• Schedule generation currently discards source vehicle-type distinctions by overwriting output type fields with a generic value, which weakens later relevance filtering and eBus alignment.
• Future evolution guardrails:
• The selected-day horizon should remain configurable later without changing the operator contract defined in this phase.
• Assignment CSV structure should remain extensible so later fields can be added without breaking the basic round-trip.
• Manual/ad-hoc blocks must remain explicitly distinguishable from schedule-derived blocks.
• Vehicle-type and block-source data must remain preservable so later dispatch recommendation and filtering work does not depend on reconstructed heuristics.
• Schedule applicability fixes in this phase must not make future repeat-frequency or overlapping-schedule rules harder to introduce.
• Not in scope:
• technical design specifics such as final endpoint shapes, storage schema, queue design, or exact implementation classes.

2. Users and Use Cases¶

• Primary personas:
• Dispatcher running day-of-operations and manually assigning vehicles to blocks.
• Depot planner or duty manager preparing a dispatch sheet before service is fully live.
• Operations lead or support user troubleshooting why blocks are missing, noisy, or incorrectly flagged.
• Product or engineering reviewer validating that dispatch data and flows remain coherent as manual/ad-hoc support is introduced.
• High-level user stories:
• As a dispatcher, I want Dispatch to keep its controls visible and its status messaging trustworthy so manual allocation work is not slowed down by the tool itself.
• As a dispatcher, I want to see the remaining future work for the selected dispatch day consistently so I can prepare vehicles before those blocks start.
• As a depot user, I want to correct schedule applicability after upload so I can recover from schedule overlaps or wrong periods without starting over.
• As a dispatcher, I want to export current assignments and import an external assignment CSV with a preview so I can accelerate initial setup and detect missing blocks.
• As a dispatcher, I want to create and manage ad-hoc blocks directly in Dispatch so late changes such as replacement work can be represented explicitly.
• As a dispatcher, I want ad-hoc and non-relevant blocks to be filterable and highlighted so I can focus on the work that matters right now.
• Edge cases and failure modes:
• Overnight blocks that started before the dispatch day but remain active after midnight.
• Blocks that are already underway or completed when viability is recalculated.
• Upload responses that do not return a valid schedule UUID.
• Imported CSV rows that reference unknown vehicles, duplicate blocks, or malformed identifiers.
• Imported CSV rows that do not match current schedule-derived blocks because the operator sheet includes replacements or late-created work.
• Manual/ad-hoc blocks that overlap schedule-derived blocks.
• Imported CSVs that omit rows for schedule-derived blocks and therefore must not silently delete planned service.
• Ad-hoc blocks that exist in Dispatch and therefore must round-trip cleanly through export and import.

3. Conceptual Model Terms and Decisions¶

Key Terms¶

Decision Ledger¶

4. Domain Model and Eventstorming (Conceptual)¶

• Bounded context and ubiquitous language:
• Dispatch Day Management governs depot-local day setup, block retrieval, visibility windows, and operator-facing block status.
• Schedule Applicability governs whether an uploaded schedule should apply to a dispatch day and how operators correct that applicability.
• Assignment Reconciliation governs assignment export, CSV import preview, matching, and apply.
• Manual Block Management governs manual/ad-hoc block identity, lifecycle, and distinction from schedule-derived work.
• Aggregates and entities:
• Block aggregate: block identity, source, timing, type, assigned vehicle, status-relevant metadata.
• Schedule aggregate: schedule identity, applicability period, descriptive metadata.
• Assignment Reconciliation Session entity: uploaded rows, row match results, proposed changes, apply results. This is conceptually stateful for the user but does not need durable snapshot storage in this phase.
• Block Relevance Classification entity: derived operator-facing classification using source, timing, status, ignore state, and future policy inputs.
• Value objects:
• Future Horizon: current depot-local time through the selected dispatch day end.
• Block Source Classification: schedule_derived or manual_ad_hoc.
• Assignment Row Match Result: matched, unmatched, duplicate, invalid, missing_in_import.
• Block Status Outcome: future, started, completed, actionable_error.
• Domain events and triggers:
• DispatchDayViewed when the user opens or changes the dispatch day.
• FutureHorizonEvaluated when the selected-day future window is applied to dispatch block retrieval and presentation.
• AllocationViabilityEvaluated when a selected block's assignment viability is computed.
• CompletedRouteStateDerived when a block transitions from active work to explicit completed-route presentation.
• ScheduleUploaded when a new schedule is accepted for dispatch use.
• ScheduleApplicabilityUpdated when an operator changes the schedule's applicability period.
• AssignmentExportGenerated when the system creates a CSV from current dispatch state.
• AssignmentImportPreviewBuilt when uploaded CSV rows are matched and summarised without mutation.
• AssignmentImportApplied when confirmed assignment changes are persisted.
• ManualBlockCreated, ManualBlockUpdated, and ManualBlockDeleted when operator-authored block lifecycle events occur.
• Commands, actors, and policies:
• ViewDispatchDay by dispatcher.
• EvaluateFutureHorizon by policy when dispatch day data is requested.
• EvaluateBlockStatus by policy when block state is rendered.
• UploadSchedule and UpdateScheduleApplicability by dispatcher or planner.
• ExportAssignments, PreviewAssignmentImport, and ApplyAssignmentImport by dispatcher.
• CreateManualBlock, UpdateManualBlock, and DeleteManualBlock by dispatcher.
• EvaluateBlockRelevance by policy when filtering or highlighting blocks.
• Invariants and business rules enforced:
• Started or completed blocks must not emit pre-start insufficiency messaging solely because live SoC is lower than estimated energy-at-start assumptions.
• A completed route with no unresolved actionable issue must display a completed-route outcome rather than a generic allocation-error state.
• The same dispatch day must use the same selected-day future horizon in backend retrieval and frontend tab presentation.
• CSV import preview must not mutate dispatch data.
• Import apply must require explicit confirmation.
• CSV row matching should prefer stable block identity and only fall back to secondary matching when a stable identifier is absent.
• Schedule-derived blocks must not be deleted just because they are absent from an uploaded CSV.
• Manual/ad-hoc blocks must remain explicitly identified and exportable/importable with preserved meaning.
• Applicability-period updates must be possible without requiring a full schedule re-upload.
• Vehicle-type and source data must remain preservable through schedule generation and dispatch consumption.
• External systems and integrations:
• GTFS and schedule uploads still depend on the schedule creation flow.
• Dispatch block energy estimation still depends on the existing energy estimation path.
• Operator-provided CSV files become a new dispatch input artifact.
• Assignment persistence in the first reconciliation slice can reuse the current per-block allocation endpoints, while manual-block lifecycle work requires additional dispatch block API support.

Interaction Flow¶

flowchart LR
  User["Dispatcher"] --> View["View Dispatch Day"]
  View --> Horizon["Evaluate Selected-Day Future Horizon"]
  Horizon --> Status["Evaluate Block Status and Relevance"]
  Status --> Work{"Need reconciliation or manual change?"}
  Work -->|No| Continue["Continue dispatching and testing"]
  Work -->|Yes| Export["Export assignments or upload CSV"]
  Export --> Preview["Build reconciliation preview"]
  Preview --> Confirm{"Confirm apply?"}
  Confirm -->|No| Continue
  Confirm -->|Yes| Apply["Apply allocation and manual-block changes"]
  Apply --> Refresh["Refresh Dispatch Day"]

Event Timeline¶

• Mermaid timeline of the main events across corrective and later functional slices

timeline
  title Dispatch Reliability and Reconciliation
  DispatchDayViewed: User opens a depot-local dispatch day
  FutureHorizonEvaluated: Selected-day future window is computed and applied
  AllocationViabilityEvaluated: Block status and actionability are derived
  CompletedRouteStateDerived: Finished work is classified for operator display
  ScheduleUploaded: A dispatch schedule is created successfully
  ScheduleApplicabilityUpdated: Applicability dates are corrected
  AssignmentExportGenerated: Current dispatch state is exported to CSV
  AssignmentImportPreviewBuilt: Imported rows are validated and matched
  AssignmentImportApplied: Confirmed assignment changes are persisted
  ManualBlockCreated: Ad-hoc work is represented explicitly

Event Dictionary¶

• DispatchDayViewed: dispatcher opens or changes the current dispatch day | starts all later retrieval and classification work | depotId, dispatchDate, viewedAt | triggers future-horizon evaluation.
• FutureHorizonEvaluated: the dispatch day applies the selected-day future rule | defines which future blocks are visible now | depotId, dispatchDate, evaluatedAt, horizonEnd | drives retrieval and tab classification.
• AllocationViabilityEvaluated: the system derives whether a selected block still has an actionable assignment problem | keeps operator messaging aligned to live reality | blockId, evaluatedAt, statusOutcome, reasonSet | drives block card and global warnings.
• CompletedRouteStateDerived: a finished block is classified as completed rather than actionable | avoids false operator alarms | blockId, completedAt, statusOutcome | updates block card and tab state.
• ScheduleUploaded: a schedule is created successfully for dispatch use | creates a usable schedule identity | scheduleId, depotId, uploadedAt | enables later applicability editing.
• ScheduleApplicabilityUpdated: an operator changes the schedule period | corrects which days the schedule should cover | scheduleId, startDate, endDate, updatedAt | updates schedule management behavior.
• AssignmentExportGenerated: the system creates a CSV from current blocks and assignments | gives dispatchers a round-trip artifact | dispatchDate, rowCount, generatedAt | supports external reconciliation.
• AssignmentImportPreviewBuilt: uploaded CSV rows are matched and summarised | gives the dispatcher a non-destructive review step | rowCount, matchedCount, invalidCount, unmatchedCount | gates apply.
• AssignmentImportApplied: confirmed changes are persisted | updates dispatch state from the preview contract | appliedCount, failedCount, appliedAt | refreshes visible blocks and allocations.
• ManualBlockCreated: a dispatcher creates an operator-authored block | represents ad-hoc work directly in Dispatch | blockId, source, createdAt | becomes exportable and filterable.

5. Requirements and Constraints¶

• Functional requirements:
• FR-001: The Dispatch page shall keep search, filter, sort, and tab controls accessible during page resize and dispatch-panel scrolling.
• FR-002: The Dispatch page shall not present INSUFFICIENT_ENERGY or equivalent assignment-error messaging for a started or completed block solely because current vehicle SoC is lower than an estimated pre-start energy value.
• FR-003: The Dispatch page shall show an explicit completed-route outcome for a block whose work window has ended and that has no remaining actionable dispatch issue.
• FR-004: The system shall use a canonical future allocation horizon from the current depot-local time through the selected dispatch day end.
• FR-005: Backend block retrieval and frontend block classification shall apply the same future-horizon semantics.
• FR-006: The GTFS upload flow shall fail explicitly when no valid schedule UUID is returned and shall not use a placeholder schedule identifier in follow-up requests.
• FR-007: The schedule upload flow and schedule edit flow shall allow operators to edit applicability start date and end date after upload.
• FR-008: The Dispatch page shall export the current dispatch day's blocks and assignments in a CSV format that can be re-imported for reconciliation.
• FR-009: The Dispatch page shall accept an assignment CSV upload and produce a reconciliation preview showing matched rows, unmatched rows, missing current blocks, duplicate rows, and invalid rows before any mutation is applied.
• FR-010: Assignment import apply shall update block-to-vehicle allocations through the existing dispatch allocation persistence path and shall not require uploaded snapshots to be stored as a separate durable artifact.
• FR-011: The import/export row model shall include enough block identity and source information to round-trip both schedule-derived blocks and manual/ad-hoc blocks.
• FR-012: The system shall support first-class manual/ad-hoc blocks that can be created, updated, and deleted from Dispatch.
• FR-013: Manual/ad-hoc blocks shall be visually distinguished from schedule-derived blocks in list, detail, and import/export contexts.
• FR-014: Dispatch shall provide filtering that can explicitly surface or hide manual/ad-hoc blocks and reduce noise from non-relevant work.
• FR-015: The system shall preserve block source and vehicle-type data needed for relevance filtering and later eBus-aligned dispatch behavior, rather than overwriting all blocks with a single generic type.
• FR-016: Absence of a row in an imported CSV shall not delete schedule-derived blocks automatically.
• FR-017: If deletion is supported through CSV-driven reconciliation, it shall require explicit confirmation and shall apply only to manual/ad-hoc blocks.
• FR-018: Manual/ad-hoc block add, update, and delete behavior shall align with assignment import/export semantics so that a manually created block can later be exported and re-imported without changing its operational meaning.
• Non-functional requirements:
• NFR-001: The same dispatch day shall produce consistent future-horizon and status semantics across backend responses and frontend tabs.
• NFR-002: CSV preview shall be non-mutating, and CSV apply shall provide row-level success or failure feedback suitable for operator recovery.
• NFR-003: The operator-trust fixes in the first delivery slice shall be deliverable and testable independently of CSV and manual-block functionality.
• NFR-004: The selected-day horizon shall remain configurable later without redefining the CSV or manual-block product contract.
• NFR-005: Manual/ad-hoc block support shall remain additive to schedule-derived dispatch rather than replacing uploaded schedules as the default planned-service source.
• NFR-006: The implementation should keep correctness-critical rules for horizon, applicability, source distinction, and reconciliation out of ad hoc UI-only stitching.
• Constraints and assumptions:
• No canonical challenge artifact exists yet, so challenge_ref remains TBD.
• Existing allocation persistence already works one block at a time and is a valid base for the first CSV apply slice.
• Existing block creation support exists below the API layer, but dispatch does not yet expose first-class create-block behavior.
• The selected-day horizon is defined from current depot-local time through the selected dispatch day end, not browser-local time or a fixed rolling-hour window.
• Uploaded assignment CSVs are operational inputs in this phase, not new historical records to store.
• Schedule-derived blocks remain the default source of planned service for dispatch.
• Vehicle-type/source preservation may require coordinated changes across bf-schedule-creator, bf-manage-core, and bf-manage-web.
• Build item coverage mapping:
• Dispatch page layout build item -> FR-001, NFR-003
• Dispatch block status model build item -> FR-002, FR-003, NFR-001
• Future dispatch horizon build item -> FR-004, FR-005, NFR-001, NFR-004
• Schedule upload and edit flow build item -> FR-006, FR-007
• Assignment CSV round-trip build item -> FR-008, FR-009, FR-010, FR-011, FR-016, NFR-002
• Manual and ad-hoc block operations build item -> FR-012, FR-013, FR-017, FR-018, NFR-005
• Dispatch relevance model build item -> FR-014, FR-015, NFR-006
• Verification notes:
• FR-001: validate with resize and scrolling regression checks on the dispatch page.
• FR-002 and FR-003: validate with story-level scenarios for future, started, and completed blocks.
• FR-004 and FR-005: validate with backend and frontend time-window regression checks around the selected-day horizon.
• FR-006 and FR-007: validate with GTFS upload and schedule editing regression scenarios.
• FR-008 through FR-011, FR-016, and FR-017: validate with CSV export/import preview/apply scenarios, including invalid, duplicate, unmatched, and manual-block cases.
• FR-012 through FR-015 and FR-018: validate with manual/ad-hoc block lifecycle and filtering scenarios.

6. Interaction and Flow¶

• User journey or process steps:
• The dispatcher opens a dispatch day and sees a stable layout with accessible controls.
• The system loads blocks and applies one selected-day future horizon and trustworthy block status outcomes.
• The dispatcher optionally corrects schedule applicability if the wrong schedule period is active.
• The dispatcher exports current assignments or uploads a CSV from an external dispatch sheet.
• The system shows a reconciliation preview before any mutation is applied.
• The dispatcher confirms apply for assignments and, in later slices, manual/ad-hoc block changes.
• The dispatcher can create, update, delete, filter, and highlight ad-hoc blocks directly in Dispatch.

Flowchart Dispatch Reconciliation Journey¶

flowchart TD
  A["Open Dispatch Day"] --> B["Load blocks and schedules"]
  B --> C["Apply selected-day future horizon"]
  C --> D["Derive started, completed, and actionable status"]
  D --> E{"Need schedule correction?"}
  E -->|Yes| F["Edit schedule applicability"]
  E -->|No| G["Continue"]
  F --> G
  G --> H{"Need reconciliation?"}
  H -->|No| I["Assign and test manually"]
  H -->|Yes| J["Export current assignments or upload CSV"]
  J --> K["Build import preview"]
  K --> L{"Confirm apply?"}
  L -->|No| I
  L -->|Yes| M["Persist changes"]
  M --> N["Refresh Dispatch Day"]

Sequence Diagram Assignment Reconciliation¶

sequenceDiagram
  participant Dispatcher
  participant DispatchUI
  participant DispatchAPI
  participant CSV

  Dispatcher->>DispatchUI: Upload assignment CSV
  DispatchUI->>CSV: Parse rows locally
  DispatchUI->>DispatchAPI: Fetch current blocks, vehicles, and schedules
  DispatchUI-->>Dispatcher: Show matched, unmatched, duplicate, invalid, and missing rows
  Dispatcher->>DispatchUI: Confirm apply
  loop each confirmed change
    DispatchUI->>DispatchAPI: Save allocation or manual-block change
    DispatchAPI-->>DispatchUI: Per-row result
  end
  DispatchUI-->>Dispatcher: Summarise applied and failed rows

7. Non-Technical Implementation Approach¶

• Approach overview:
• Phase 1: Operator trust and manual-testability foundation
  • Fix dispatch layout and control persistence issues.
  • Remove misleading live-route and completed-route messaging.
  • Apply the canonical selected-day future horizon.
  • Fix GTFS upload placeholder-ID failure behavior.
• Phase 2: Schedule applicability hardening
  • Enable applicability-period editing in upload and later schedule edit flows.
  • Keep this still in the corrective/foundation tranche because it reduces dispatch setup friction before larger feature work.
• Phase 3: Assignment CSV round-trip for existing blocks
  • Ship export first or together with previewed import/apply.
  • Scope the first CSV apply slice to assignment reconciliation against existing blocks, reusing current allocation persistence.
• Phase 4: Manual/ad-hoc block operations and aligned filtering
  • Add first-class manual block create, update, delete, highlight, and filter behavior.
  • Extend export/import semantics so manual/ad-hoc blocks round-trip cleanly.
  • Preserve and consume source/type data for better relevance filtering and later eBus-aware dispatch behavior.
• Design considerations:
• The first delivery slices should optimise for manual testing and operator trust, not breadth.
• CSV import should be safe by default, which means preview-before-apply and narrow deletion semantics.
• Manual/ad-hoc blocks should be explicit product objects because they will otherwise continue to leak into workaround behavior.
• Applicability editing is a dispatch workflow requirement because schedule correctness directly shapes what the dispatcher can reconcile.
• Vehicle-type preservation matters even if richer eBus filtering arrives later, because losing the data now makes later filtering unnecessarily heuristic.
• Dependencies and prerequisites:
• Phase 1 is the prerequisite for efficient manual testing of later slices.
• Phase 3 can begin largely in bf-manage-web by reusing current assignment endpoints in bf-manage-core.
• Phase 4 requires new backend support for manual/ad-hoc block creation and lifecycle.
• Vehicle-type preservation and richer relevance filtering likely require coordinated work in bf-schedule-creator, bf-manage-core, and bf-manage-web.

8. Open Questions¶

• Which columns should be mandatory in the first canonical assignment CSV row model, and which should be optional operator aids?
• Should CSV-driven deletion ship in the same slice as manual/ad-hoc block CRUD, or only after manual UI deletion has proven stable?
• What exact visual treatment should be used to highlight ad-hoc blocks in the block list and details view?
• Should applicability editing allow overlapping schedule periods with warnings, or should overlapping periods be blocked outright?
• Should vehicle-type preservation be treated as mandatory for the same slice as manual/ad-hoc blocks, or can it be delivered as the next immediate follow-on if the operator-trust and CSV work land first?

9. Appendices¶

• Supporting inputs:
• User-reported dispatch issues around search visibility, block-to-dispatch matching, misleading SoC errors, future allocation visibility, ad-hoc replacement work, GTFS upload robustness, and schedule applicability editing.
• Follow-up requirement to support assignment CSV import/export and block add, update, and delete behavior.
• Relevant repos:
• bf-manage-web
• bf-manage-core
• bf-schedule-creator