YardMind

Elevator pitch: Retrieval-aware shipyard block planning that packs smarter and cuts future moves.

Comment

Inspiration

YardMind was inspired by a simple observation: shipyard planning is not just about fitting blocks into available space, it is about avoiding expensive problems later. A layout that looks efficient now can create retrieval conflicts, rehandling, and schedule disruption when future blocks need to move. We wanted to build a system that treats the yard as a living, time-dependent operation rather than a static packing puzzle.

We were also motivated by the challenge itself. OGC 2026 sits at the intersection of optimization, scheduling, and operational realism, which makes it a strong test of whether an AI-assisted engineering workflow can move from idea to a working solver quickly and rigorously.

What it does

YardMind is a retrieval-aware optimizer for shipyard block planning. It builds feasible placement and scheduling plans, then improves them with targeted search.

The project currently:

  • loads official-style shipyard problem instances
  • validates candidate solutions against the released baseline feasibility checker
  • generates feasible official operations plans
  • runs an official search pipeline that combines constructive heuristics, order perturbations, bay-bias perturbations, rebuild moves, reinsertion moves, and partial reconstruction
  • compares delegated baseline behavior against YardMind-native heuristics
  • provides a browser-viewable demo and a React presentation surface for explaining the solver

The core idea is that a good placement is not judged only by whether it fits, but also by whether it preserves future mobility and reduces downstream conflicts.

How we built it

We built YardMind as a Python optimization project with a research-first workflow.

At the system level, we split the project into a few clear layers:

  • data loading and official-format parsing
  • feasibility validation and scoring
  • constructive official heuristics
  • search neighborhoods and improvement stages
  • benchmarking, testing, and presentation

Our solver development followed an iterative pattern:

  • add one improvement stage
  • create or tighten a focused regression
  • validate on the official-search slice
  • keep the smoke path green
  • move to the next heuristic only after the previous one was stable

That led to a search pipeline that now includes:

  • diversified native constructive orderings
  • local order neighborhoods
  • targeted bay-bias candidates
  • combined order-and-bay perturbations
  • objective-aware rebuild candidates
  • reinsertion candidates
  • incumbent-fixed partial reconstruction
  • overlap-cluster and bay-neighborhood reconstruction focus sets
  • diagnostics-driven adaptive partial-reconstruction capping

We also built presentation and validation tooling around the solver so the project is not just an algorithm prototype. The demo layer helps explain the optimization choices, and the regression suite keeps the solver from drifting as new heuristics are added.

Challenges we ran into

The hardest challenge was not getting a heuristic to work once. It was proving that it really helped.

Later search neighborhoods often subsumed earlier ones, which made synthetic regressions brittle. A test that originally isolated one improvement could silently stop testing that improvement after a stronger neighborhood was added. That forced us to introduce exact switches and diagnostics hooks so we could compare stages cleanly.

Another challenge was runtime sensitivity. Some official-search regressions depended on tiny stage budgets, and even stdout noise from the vendored baseline solver could perturb outcomes under test capture. We had to stabilize that path so test behavior reflected solver quality rather than logging overhead.

Adaptive search control was another lesson. Our adaptive partial-reconstruction cap looked promising at first, but deeper diagnostics showed that shrinking the candidate set can hurt when the top of the score distribution is flat. We ended up refining that logic with a plateau-aware guard instead of assuming smaller always meant better.

The broader engineering challenge was balancing speed and rigor: moving fast enough for a hackathon, but with enough testing and instrumentation that we could trust what we were improving.

Accomplishments that we're proud of

We are proud that YardMind is not just a concept pitch. It is a working optimization system with a validated official-search path.

Some highlights:

  • we integrated official-format loading and released-checker validation
  • we built both delegated and native official constructive paths
  • we extended official search into a real multi-stage improvement pipeline
  • we added focused regressions that lock exact solver improvements
  • we created demo and presentation surfaces so the project can be understood visually, not only through code
  • we stabilized the official-search path under normal test execution
  • we improved the adaptive partial-reconstruction logic with a more defensible plateau-aware rule

What matters most is that the project now has a repeatable engineering loop: hypothesis, local solver change, focused validation, and documented progress.

What we learned

We learned that optimization engineering is as much about instrumentation as it is about heuristics. Without diagnostics, it is easy to think a new search rule is helping when it is only changing evaluation order or stealing time from better candidates.

We also learned that hybrid optimization works well for this kind of problem. A fast constructive path is essential, but the real gains come from structured improvement moves that target the parts of the incumbent solution causing the most downstream pain.

On the engineering side, we learned the value of narrow falsifiable tests. Small exact regressions gave us much more confidence than broad random searches alone. We also learned that solver stability can be affected by seemingly unrelated details like logging behavior and capture overhead.

Most importantly, we learned how to turn a difficult operations problem into a system that is explainable. That matters for hackathons, but it also matters for real adoption.

What's next for YardMind

The next step is to push YardMind from a strong heuristic search pipeline toward a more powerful official improvement loop.

Our planned next moves are:

  • mine the remaining fixed-better adaptive-cap cases and refine the cap rule further
  • add stronger reconstruction and destroy-repair neighborhoods
  • introduce a local exact repair backend for the hardest official subproblems
  • benchmark more systematically on official-format instances
  • keep improving the demo so judges can see not just the final answer, but why the solver made it

The long-term direction is clear: make YardMind an anytime hybrid optimizer that finds feasible plans quickly, improves them reliably under time limits, and avoids the retrieval conflicts that make real shipyard plans fragile.

Built With

Share this project:

Updates