> ## 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 30, 2026 > The controlled DesignOS pilot and CAD-aware engineering workspace reach their baselines, bringing readiness, change impact, review, and approval into one traceable flow. ## Summary We completed [M5 and M6](/how-it-works/build-path): the controlled DesignOS pilot baseline and the first CAD-aware engineering workspace. The pieces built in earlier milestones now work as one flow. Forge can identify a cited readiness issue, show which recorded parts of the project it affects, place the evidence in the model-review experience, route the proposed action through human approval, and prepare a traceable review package. This baseline is designed for partner use and feedback. It currently uses governed public and synthetic examples so a yard can inspect the workflow without exposing proprietary vessel data. For each partner deployment, Forge adds authenticated, yard-specific access; production key custody, meaning clear control of the signing keys; an agreed deployment or protected-enclave model; and the yard's permitted data and CAD connections. ## What we shipped Milestone [M5](/how-it-works/build-path) (complete as a controlled pilot baseline). * **A governed pilot posture:** a pilot is more than early access to software. It is an operating agreement about what the system may do, who must review its work, how long the pilot runs, and what evidence demonstrates readiness to expand. Forge caps pilot capabilities at **propose with review**: it can prepare an action, but an accountable person remains the decision-maker. The pilot can only advance after both the agreed time window and the required human-confirmed outcomes. * **Build readiness based on cited blockers:** Forge brings open compliance gaps, cases where it stopped because evidence was incomplete (abstentions), and decisions awaiting reapproval into vessel-level and work-package views. Rather than inventing a single readiness score, it shows the state, the counts, and the evidence behind each blocker so program leaders can see what requires action. * **Change impact based on recorded relationships:** when something changes, Forge follows the relationships the project has actually recorded, including design objects, drawings, evidence, rules, and decisions. Where a relationship has not been recorded, Forge says so. This gives teams a defensible impact view without presenting a guess as project knowledge. * **A partner-ready issue package:** readiness blockers and change-impact findings can be prepared as structured, machine-readable JSON and familiar spreadsheet files, preserving their citations for the people and systems that receive them. * **Feedback that becomes learning through review:** partner feedback is captured as a structured event. When a responsible person confirms the result, it can become a signed outcome. That outcome is the evidence Forge uses to understand whether a prior decision held up in practice. * **One readiness view across surfaces:** the same governed readiness information is available through the command line, a reviewable HTML report, and a read-only local dashboard. Each surface reads from the same underlying record. Milestone [M6](/how-it-works/build-path) (complete). * **A CAD-aware engineering workspace:** “CAD-aware” means the review surface understands which vessel objects, measurements, issues, and decisions belong together. It does not replace the yard's CAD authoring tools; it adds the evidence and decision context those tools were not designed to preserve. * **A model viewer with a clear authority boundary:** Forge converts imported geometry into a lightweight display model for fast viewing, highlighting, and annotation. The displayed mesh helps people see the issue, while engineering measurements continue to come from the source geometry. The distinction is explained in [How CAD Becomes Engineering Evidence](/concepts/how-cad-becomes-engineering-evidence). * **Evidence placed in context:** cited measurements can appear beside the relevant geometry; clashes remain visible review flags; annotations remain scoped to the yard; and change-impact highlights appear only when a recorded design relationship supports them. An issue without a geometry link stays visible in the review panel rather than being attached to an arbitrary part. * **Structured geometry acceptance:** an engineer can review a proposed geometry acceptance, resolve the measurements it cites, run the required verification gates, and sign the resulting decision. Viewing the model does not silently create engineering authority; the structured approval action does. * **A repeatable review package:** Forge prepares the viewer, issue files, and a manifest, which is a contents list with digital fingerprints for the included files, in one package. The recipient can confirm exactly which files and evidence were included, making the handoff easier to review, reproduce, and defend. ## What we learned * **A pilot is a governed operating state.** Clear capability limits, review roles, outcome measures, and exit conditions give both Forge and the partner a shared definition of responsible use. * **Readiness is more useful when it is explainable.** A program leader needs the blocker, responsible work area, and cited reason rather than a score whose meaning changes from one project to another. * **Honest impact analysis builds confidence.** Following recorded relationships and showing where project knowledge needs strengthening gives teams something they can verify and improve. * **The model becomes more valuable when evidence is visible beside it.** Naval architects and engineers can inspect the affected geometry, while class, compliance, and program reviewers can follow the cited reasoning without becoming CAD operators. * **Human approval is strongest when it is part of the workflow.** Keeping proposal, review, external-authority involvement, signature, and outcome as distinct steps makes responsibility visible. * **Provenance must survive the handoff.** A review package is trustworthy when the receiving team can trace its issues and measurements back to the same governed records seen inside Forge. ## Blockers & open questions * The controlled baseline is ready to move into partner use and feedback. For each partner, Forge will provide authenticated, yard-specific access; clear custody of the production signing keys; the agreed choice of where Forge runs and how its environment is protected; and a defined pilot window with confirmed outcomes. * ShipConstructor, AutoCAD, CADMATIC, and other yard-system connections will be enabled with each partner where permissions and system contracts allow. This keeps integration aligned with the yard's existing tools, security posture, and data ownership. * Work-package readiness already shows where attention is required. The next layer of partner configuration will strengthen the direct links between engineering records and the work packages they affect, supporting clearer module-level planning. * The read-only review foundation establishes the authority boundary. Rich model selection, browser-based approval, and hosted collaboration can then be introduced alongside authenticated identity and the partner's review process. * We are committed to enlarging the rule and interpretation corpus as the product surface improves. Each addition will remain versioned, cited, and evaluated so broader coverage strengthens trust rather than trading it for speed. ## Next week * Move from the completed M0-M6 baseline into evidence depth and product proof: expand the real regulatory corpus, evaluate how accurately Forge reads and applies it, place rule-backed issues directly on a representative vessel model, and connect those issues to the work packages responsible for resolving them.