> ## Documentation Index
> Fetch the complete documentation index at: https://www.docs.forgeshipyard.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Week of June 16, 2026

> The geometry baseline begins (M3, in progress): the yard's real unit of work, the evidence-to-vessel resolver, and a citable home for every measurement.

## Summary

We began [M3](/how-it-works/build-path), 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](/how-it-works/build-path) (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.