GFT should scale measured readiness rather than generated output

The source programme's setup, launch, scale and optimise sequence remains the right adoption structure. Setup establishes records and responsibilities. Launch establishes operating measurement. Scale prepares and qualifies new capabilities against that baseline. Optimisation extends only what has passed its conditions. Within that structure, generative specification remains a partnered pilot in the programme's third phase. It is not an asserted installed capability and should not become a hidden dependency for factory launch.

This sequence is not a reason to postpone all creative exploration. GFT proposes a limited refinement: low-risk evaluation using approved public inputs may begin earlier, provided it stays outside the production release path. Such work can test prompt recording, visual review and the usability of generated artefacts without uploading proprietary blocks, buyer designs or wearer data. Its output is an internal learning record, not an approved garment, a procurement decision or evidence that the future factory will perform better. Keeping this boundary permits useful learning without rewriting the programme's staged controls.

Each stage needs an entry condition, an evidence product and an exit decision. A date alone should not move the programme forward. Setup exits when the maker can reconstruct who approved a manual specification and which inputs it used. Launch exits when the baseline measures are defined consistently and their missing records are visible. Scale exits when the bounded partner evaluation has been designed, partner evidence inspected, routine and difficult cases prepared, and failure and correction recording made ready. The partnered pilot then tests the complete handoff. Bounded optimisation begins only with an explicit decision that names the authorised envelope and remaining limitations.

NIST's AI Risk Management Framework makes risk tolerance contextual and does not prescribe a universal tolerance for the organisation.[S19] GFT should apply that principle through local gate decisions rather than adopt a generic maturity score. The accountable team should state what would block release, what would require repair and what degree of uncertainty it is prepared to retain before seeing favourable pilot results. A high volume of attractive outputs cannot compensate for an unresolved condition that the team has designated critical.

Exhibit 56 expresses this logic as a gated roadmap. The positions are sequence markers, not months, deadlines or resource commitments. Early public-input exploration is shown as a separate learning activity because it neither replaces the baseline nor grants access to the production workflow.

The roadmap also makes reversal legitimate. A failed exchange test can return the work to setup if common units and revision rules are absent. An inconsistent baseline can return it to launch. A critical rights or geometry failure can stop the pilot without weakening the core manual workflow. The record should preserve what was learned, which gate failed and what evidence would justify another attempt. Stop and repair are management decisions, not unsuccessful exceptions to a predetermined adoption story.

Launch should make the existing specification workflow measurable before assisted work is compared with it. GFT recommends a baseline covering accepted specifications, lead time, rework causes, physical sample rounds and quality outcomes. The programme's capture and management-cadence design provides the operating context, while its inspection-qualification priority reinforces the need to validate measurement before relying on it. Inherited inspection figures are not local performance and should not be reused as a promise for the new workflow.

A baseline begins with a denominator dictionary. An accepted style means a specification that has met the stated release conditions, not a concept selected for review. An attempted CAD readback means an actual import and inspection in the receiving workflow, not an exported file. An evaluated fit sample means a physical sample assessed against the agreed conditions. A correction hour includes diagnosis, editing, rechecking and expert assistance spent after a candidate enters technical review. These definitions should be stable enough for the manual and assisted comparisons to answer the same question.

The event record can remain compact. It should link the style and brief revision, actor role, activity, start and completion records, outcome, failure category, successor revision and evidence location. Touch time should be separated from queue time, material waiting, buyer waiting and rework. Otherwise a faster editing task can be misreported as a shorter approved-tech-pack lead time even though the specification remains idle downstream. Capture should serve process learning rather than employee surveillance, using role-level analysis wherever that answers the management question.

NIST identifies the need for a human baseline when an AI system augments or replaces human activity and warns that controlled measurements can differ from operational settings.[S19] For GFT, this means the baseline should include the actual product mix and approval conditions the pilot intends to test. Routine approved-block variants and more difficult construction cases should be identifiable. Results should retain their spread and missingness rather than collapse into one average that conceals a different mix of work.

The baseline should also distinguish process failure from evidence failure. A missing timestamp is a capture problem. A rejected collar curve is a geometry outcome. A delayed fabric delivery is a material-waiting event. An absent buyer tolerance is an unresolved requirement. Combining these into a generic delay category would hide the corrective owner. Each review should ask whether the record supports a decision, not merely whether a field contains a value.

Synthetic research data cannot fill this gap. GarmentCodeData uses explicit design distributions, body-model assumptions and quality filtering to generate synthetic garments and sewing patterns.[S30] That makes it useful for understanding a research test domain, not a substitute for observations from the maker's products, fabrics, wearers or buyers. GFT should keep research cases, local development cases and local operating records in separately labelled collections.

Launch is ready for the next stage when the team can produce a baseline report with stable definitions, traceable records and an explicit account of missing observations. The required coverage should follow the product envelope and the decision's consequences rather than an arbitrary universal sample size. If records are sparse, the report should say so and restrict the comparison. A weak baseline is a reason to repair measurement before claiming improvement, not a reason to let the assisted workflow define its own success retrospectively.