Crew Design Tool (CDT-V2)

In the early design of a vessel or another complex operation, ambition, automation, workload, staffing, skills, safety rules, and budget influence one another. Yet those decisions are often developed in separate documents. Engineers describe what the system should do, human-factors specialists study the work, and planners estimate a crew later. By then, important design choices are expensive to revisit.

The research behind CDT identified a clear gap: teams could describe a crew concept, but they lacked a quantitative way to test whether that concept was feasible. A proposed crew size did not automatically prove that every watch, task, qualification, rest rule, and peak workload could be covered. CDT was created to make that relationship visible while the design was still changeable.

CDT-V2 is a ground-up rewrite of the earlier Crew Design Tool. We did not want another form-heavy application where the logic disappeared into tables and solver payloads. The central product decision was to make the operational model visible on an editable canvas, so the conversation about the design and the data used by the solver happen in the same place.

A scenario can contain several variations, each with its own graph but shared operational modes. Teams can begin with a rough concept, add detail as evidence becomes available, branch an alternative without destroying the original, and keep the assumptions visible throughout the process. The canvas is not a presentation laid over the model. It is the source from which the solve-ready model is compiled.

The demand side describes why work exists. It follows a hierarchy from core function to specific function, activity, and work procedure. At the detailed level, a work procedure carries timing, duration, required headcount, required skills, education level, and the operational modes in which it applies. Higher-level estimates can keep an unfinished branch usable while the team is still discovering the process.

The supply side describes who could perform that work. Crew pools group capabilities, while worker profiles define concrete archetypes with skills, education, cost weight, mode eligibility, and fixed, capped, or automatically sized headcount. Constraint nodes add rules such as minimum rest, maximum consecutive work, profile bounds, active time windows, and incompatible skills.

Operational knowledge usually starts as prose: a staffing note, doctrine, requirement, interview, or PDF. Manually translating every sentence into a structured planning model is slow and easy to get wrong. CDT-V2 gives the assistant typed tools that can create or update canvas nodes, manage modes, branch variations, clean up the layout, and load solve history and diagnostics.

The important design choice is that AI output never becomes an untouchable answer. It becomes editable model data. A planner can inspect the worker profiles the assistant created, correct an overly broad skill, change a headcount cap, remove an inferred relationship, and solve again. Destructive changes require confirmation, while the human-readable canvas remains the review surface.

When a team runs a solve, CDT-V2 compiles the visible graph into a normalized bundle of modes, worker profiles, task requirements, support links, and constraints. A Python planning service uses OR-Tools CP-SAT to search the combined space of crew composition and assignments. This is not a language model estimating a number. It is a constraint solver testing whether the proposed people can cover the proposed work.

Exact solve is deliberately strict: every task unit must be assigned without breaking the modeled rules. Flexible solve is designed for earlier exploration. It allows a controlled repair, reports uncovered task units and violation pressure, and helps the team understand the smallest change that could make the concept feasible. Diagnostics expose missing candidates, slot pressure, skill supply versus demand, and problematic profile assumptions.

Our clearest demonstration starts with a small craft launch and recovery scenario. The first variation contains mission demand only: launch and recover the RHIB, maintain bridge and engineering watches, and perform davit work. The assistant reads a normal staffing brief and adds crew pools and worker profiles. One assumption intentionally caps davit-capable deck operators at two.

Exact solve refuses the manual concept because that cap cannot cover all work. Flexible solve finds a 12-person repair but identifies three uncovered task units across launch, recovery, and line handling. After the planner raises the cap from two to three, exact solve succeeds with a 13-person crew. An automated variation removes part of the manual deck workload, adds ICT support, and solves with 12. The value is not the one-person difference; it is the traceable explanation of how the work and skill mix changed.

A crew total on its own is difficult to defend. CDT-V2 therefore renders the result as a roster by operational mode, time slot, worker lane, and task segment. Stakeholders can see who is assigned, what they are doing, where the tight coverage occurs, and whether any work remains uncovered.

Solve-generated support relationships can be applied back to the canvas, turning solver output into reviewable graph context. Overlays highlight blockers and assignment pressure. Saved runs make it possible to return to an earlier result and ask the assistant to explain the rules, warnings, profile bounds, or bottlenecks that shaped it.

CDT-V2 brings four disciplines into one workflow: visual operational modeling, AI-assisted authoring, mathematical optimization, and explainable decision output. Each part compensates for a weakness in the others. The canvas makes assumptions visible, the assistant reduces modeling effort, the solver provides rigor, and the roster makes the result understandable to operational stakeholders.

The product also keeps a deliberate boundary between AI and optimization. The language model helps structure knowledge and explain results, but it does not decide whether the schedule is feasible. The solver does that. This separation gives users the flexibility of AI without asking them to trust a generated headcount as if it were proof.

CDT-V2 already includes the canvas model, scenario variations, operational modes, YAML import and export, AI editing tools, document extraction, solve preparation, CP-SAT-backed exact and flexible solves, diagnostics, solve history, overlays, and roster output. It is a working foundation for structured trade studies, not a static design prototype.

It is also honest to say that a general crew-design product requires more domain semantics than one demonstration. Alternative procedure logic, richer timing for early estimates, broader scheduling constraints, candidate-generation safeguards, and some constraint-scoping behavior are still being tightened. We treat those as domain engineering work to solve with the client, not details to hide behind a polished interface.

CDT-V2 is a good example of the work Yellow Orange now takes on as an AI software agency. The starting point was not a request for a chatbot. It was a difficult operational decision with incomplete data, expert knowledge in prose, mathematical constraints, and several types of users who needed to understand the outcome.

We translated that problem into a product architecture where AI, domain modeling, and a specialist solver each do the job they are suited for. The same approach applies beyond crew design: planning, configuration, compliance, engineering, and other workflows where generative AI is useful only when it is connected to structured data, business rules, and a result people can defend.