> For the complete documentation index, see [llms.txt](https://t420.gitbook.io/t420/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://t420.gitbook.io/t420/f1-pitstop-coordination-model.md). # FleetOS F1 Pitstop Coordination Model ## Core idea For FleetOS to become the "F1 pitstop" for fleet service coordination, it cannot stop at request tracking. It must help coordinate the **4 critical operational resources** that determine whether work actually gets done efficiently: 1. **Bay** 2. **Technician** 3. **Vehicle** 4. **Parts** If any one of these is missing, work slows down or stalls. *** ## Verdict This is **not too far** as a vision. It is the right direction. However, it **can become too much too early** if implemented as a giant all-at-once feature set. The correct move is: * keep the current scheduling block as the core UI wedge * expand it into a real coordination tool step by step * model the roles and handoffs explicitly * let different people contribute their own data once, in the right place * train OpenClaw by observing and assisting these role-specific workflows So the answer is: * **vision = correct** * **scope = must be phased carefully** *** ## The operational model ### The 4 critical resources #### 1. Bay Questions: * Is a bay required? * Which bay is available? * When is it available? * Does the bay have the right equipment/clearance? #### 2. Technician Questions: * Which technician is qualified? * Is the technician available in the required time window? * Is the technician already assigned elsewhere? #### 3. Vehicle Questions: * Where is the vehicle now? * Is it arriving at the shop, roadside, or mobile service location? * Has it been delivered / checked in / made accessible? * Is it ready for work to begin? #### 4. Parts Questions: * What parts are needed? * Are they in stock? * If not, who is sourcing them? * What is ETA / supplier / price / PO status? * Will missing parts block the schedule? *** ## People / roles involved These are the real-world roles FleetOS should model. ### 1. Fleet Coordinator Owns: * vehicle details * urgency / business context * approvals * delivery / pickup coordination * external communication from fleet side ### 2. Service Coordinator Owns: * orchestration of the whole job * schedule decisions * technician / bay alignment * ensuring all dependencies are satisfied * status updates and bottleneck management ### 3. Parts Department Person Owns: * part identification * part ordering * inventory / stock check * supplier interaction * price / PO / ETA / location / substitutions ### 4. Technician Owns: * diagnostic reality * what parts are actually needed * readiness to perform the job * service execution and completion details ### Important note In smaller shops, one person may wear 2-4 of these hats. In larger shops, these roles may be distinct. FleetOS should support both. *** ## Key product principle **Information should be entered once by the person closest to the truth.** Examples: * Fleet coordinator enters vehicle context and urgency * Parts role enters part source/ETA/PO data * Technician confirms actual service need / parts need / service completion * Service coordinator aligns bay + tech + vehicle + parts into one executable plan This is exactly why the product has real value. It is not just adding more fields. It is preventing duplicated admin and reducing coordination failure. *** ## Why this matters strategically FleetOS only becomes truly defensible if it owns the **coordination layer**, not just the intake layer. A lot of tools can: * intake a request * show a job * send messages Far fewer tools deeply coordinate: * bay readiness * technician readiness * vehicle readiness * part readiness * quote / approval / delivery timing That is where the product becomes serious. *** ## OpenClaw / Blade implication OpenClaw should not be trained on vague "tickets." It should be trained on **decision-quality coordination workflows**. That means it should learn to assist and eventually partial-autonomously handle the work of: * **Service Coordinator** * **Parts Department Person** ### To do that properly, OpenClaw must see: * who provided what information * when information became available * what was missing * what blocked the job * what action happened next * whether the job moved faster or stalled This is exactly why role-specific and dependency-specific tracking matters. *** ## What OpenClaw should learn over time ### As Service Coordinator assistant OpenClaw should eventually help with: * identifying missing scheduling inputs * recommending bay assignment * recommending technician assignment * flagging scheduling conflicts * spotting when parts or vehicle readiness block the schedule * recommending next-best action * generating follow-up prompts/messages ### As Parts Desk assistant OpenClaw should eventually help with: * identifying likely required parts * normalizing part requests * checking whether part data is complete * tracking ETA / supplier / price / PO info * flagging missing/late part dependencies * preparing parts request summaries *** ## The danger to avoid Do **not** try to build a giant ERP module immediately. This becomes too much if you add: * full inventory system * full technician HR/scheduling suite * full bay calendar suite * full procurement suite * full workflow engine * all roles + permissions + automation at once That would slow the product and confuse the wedge. *** ## The right phased roadmap ## Phase 1 — Dependency visibility Goal: Make the 4 critical resources visible inside the work order. ### Ship * current scheduling block tightened * explicit fields/statuses for: * Bay * Technician * Vehicle readiness * Parts readiness * each one can be in a clear state, e.g.: * unassigned * pending * blocked * ready * complete * lightweight role attribution: who last updated each block ### Outcome FleetOS becomes a real coordination board, not just a request tracker. *** ## Phase 2 — Role-specific updates Goal: Let each role contribute only the information they own. ### Ship * Fleet coordinator updates vehicle/delivery/approval fields * Service coordinator updates schedule alignment * Parts role updates parts request / ETA / supplier / PO * Technician updates diagnosis / execution readiness / completion ### Outcome Information gets entered once, by the right person. *** ## Phase 3 — Bottleneck logic Goal: Make blockers explicit. ### Ship * dependency status model * show job readiness as a composite of: * bay ready? * tech ready? * vehicle ready? * parts ready? * visible blockers: * waiting on part * waiting on approval * waiting on vehicle delivery * waiting on technician assignment ### Outcome FleetOS starts acting like a coordination engine. *** ## Phase 4 — OpenClaw assist mode Goal: Let Blade assist, not control. ### Ship * suggestions for missing info * suggested next actions * suggested role follow-ups * parts request drafting * schedule conflict alerts * decision-point logging for training ### Outcome OpenClaw becomes useful without pretending to replace humans too early. *** ## Phase 5 — Narrow autonomy on safe tasks Goal: Let OpenClaw handle low-risk coordination tasks. ### Examples * ask for missing part ETA * request missing vehicle details * remind about technician assignment * nudge parts PO follow-up * summarize schedule blockers ### Outcome OpenClaw saves real admin time without taking unsafe actions. *** ## Suggested product model ### Add a dependency/readiness layer to each work order For each work order, track: * `bay_status` * `technician_status` * `vehicle_status` * `parts_status` And optionally: * `bay_owner` * `technician_owner` * `vehicle_owner` * `parts_owner` * `last_updated_by` * `last_updated_at` ### Add a simple composite indicator Example: * **Ready to Start** only if all four are green * otherwise show the blocker This is powerful because it instantly makes the job operationally truthful. *** ## Parts request implication The attached form is useful because it shows the kind of structured data the parts workflow may need: * work order * fleet / unit / serial / make / model * requester * date/time * PO * supplier * line items FleetOS does not need to recreate the entire paper form visually at first. It does need to model the critical data and workflow: * what part is needed * who requested it * from whom * ETA / price / PO / location * does it block the job? *** ## Final recommendation ### I agree with the direction You are **not going too far** in terms of strategic product direction. ### I disagree with doing it all at once Do **not** turn FleetOS into a giant shop-management suite overnight. ### Best path * keep the wedge * add dependency visibility first * add role-specific updates second * add blocker logic third * add Blade assist mode fourth That is how FleetOS becomes the F1 pitstop coordination layer without losing focus. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://t420.gitbook.io/t420/f1-pitstop-coordination-model.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.