Skip to main content

​
Summary

We began M3, the geometry baseline, and this milestone is in progress. We started with the ontology the yard actually works in (the product-oriented work breakdown) and the data backbone geometry needs: a resolver from evidence to vessel, a home for measurement results, stable identities for CAD parts, and the contract a measurement service will write through. We have not touched a geometry kernel yet, by design. We are laying the contracts and citation targets first.

​
What we shipped

Milestone M3 (in progress).
  • The yard’s real unit of work: a product-oriented breakdown (blocks, zones, units, work packages) added alongside the vessel view, because a yard builds in interim products and work packages rather than whole vessels at once. Each work package links back to the system view so the two reconcile.
  • The evidence-to-vessel resolver: a way to walk from a piece of evidence, through the design objects it attaches to, up to the vessel, so the compliance-gap capability from Week 2 can finally take real inputs.
  • The measurement record: a data home for a numeric geometry fact (a distance or a clearance), so no number about the ship can be stated without pointing back to the measurement it came from.
  • Stable CAD identities: each part imported from drawing metadata gets a stable identity with its source and provenance preserved, so a measurement can cite exactly which parts it came from. Re-importing the same file does not create duplicates.
  • The measurement-service contract: the typed seam a future geometry service will use to write measurement records, which checks that every referenced part belongs to the same yard, vessel, and source file before it writes anything.

​
What we learned

  • Modeling the work package against a product-oriented breakdown puts compliance and estimating on the same backbone. The same model that answers “which rules apply” is the one that will later answer “what will this cost to build.”
  • Resolve identity and keep provenance early: a lesson carried in from recent extraction research. A measurement is only trustworthy if you can trace it to the exact part, file, and import it came from.

​
Blockers & open questions

  • This is the data backbone. The geometry engine itself is not built yet: we have not parsed a STEP or IGES file, computed a clearance, or run a clash check. We are laying the contracts and citation targets first, on purpose.
  • The estimating win the yard most wants, turning drawings into a bill of materials, depends on their drawings being structured CAD. Whether that path is on track is gated on confirming the format Conrad uses at the estimating stage; if those are flat 2D prints, it becomes a separate document-reading problem.
  • We are holding off on a geometry kernel dependency until the database guarantees and the rule that numeric output must cite a measurement are locked down.

​
Next week

  • Harden the geometry data guarantees and build the first real measurement: a deterministic clearance or distance computed over imported parts and written as a citable measurement record.