01 / Executive decision
Own the workflow spine. Buy the commodity edges. Keep AI advisory.
Fieldline should build a narrow scheduling and job-state core, integrate proven identity and messaging services, and keep AI recommendations behind an explicit dispatcher decision until enough operating evidence exists.
Build nowJob state and scheduling rules
BuyIdentity, messaging, and maps
DeferAutonomous dispatch and route optimization
02 / First-release boundary
One workflow with explicit state ownership
01Dispatch deskHuman decision
→02Workflow coreJob state + rules
→03Partner adapterExternal APIs
→04Technician appField execution
→05Evidence logOutcome + exceptions
Primary constraint: job state must remain authoritative inside the product. Partner systems can propose or report changes, but cannot silently become a second source of truth.
03 / Decisions and tradeoffs
Four decisions make the first release buildable.
D-01 / BoundaryStart with a modular monolith and one durable job queue
WhyThe team is small and the core workflow is still changing. Independent services would create deployment and debugging costs before ownership boundaries are proven.
TradeoffModule boundaries must be enforced in code and data access, even though deployment remains shared.
Trigger to revisitSplit only when one module has a distinct scaling, availability, or ownership need supported by production evidence.
D-02 / StateThe product owns job state and transition rules
WhyCRM and partner APIs model partial views of the workflow and cannot represent Fieldline-specific exceptions reliably.
TradeoffAdapters must translate external events and tolerate delayed or duplicated delivery.
Rejected pathUsing the CRM as the operational database would make critical behavior depend on vendor-specific fields and webhook timing.
D-03 / AI boundaryAI recommends. A dispatcher commits.
WhyThe first release lacks enough labeled outcomes to evaluate autonomous assignment safely.
TradeoffThe product captures recommendation, human override, reason, and eventual outcome as training evidence.
Validation gateAutomation can expand only after accuracy, override rate, and exception cost are measured by job type.
D-04 / IntegrationEvery partner call is an explicit workflow step
WhyPartner APIs have different retry, timeout, and consistency behavior.
TradeoffThe adapter layer adds structure but keeps vendor failures from leaking into the domain model.
Required evidenceCorrelation ID, request state, retry policy, and operator-visible failure reason for each external action.
04 / Implementation sequence
Thirty days, in order.
- Days 1-3Prove the riskiest contracts
Spike the two partner APIs, document failure behavior, and validate the technician sync constraint.
- Week 1Ship the job-state core
Implement the state machine, permissions, audit trail, and concurrency tests before UI breadth.
- Week 2Connect one thin path
Run one job from dispatcher creation through technician completion and evidence capture.
- Weeks 3-4Add exceptions and signals
Handle retries, offline work, partner delays, overrides, and the smallest useful operational dashboard.