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

# Samples and fitting

> Fitting — the per-style validation record that takes a style from first prototype to a sample approved for bulk, and how the resulting sample links to the order it is being made for.

A <Tooltip tip="The per-style validation record that takes a style from first prototype to a bulk-approved sample across seven fixed stages.">[Fitting](/reference/glossary#fitting)</Tooltip>
is the per-<Tooltip tip="The reusable product record that owns the BOM, cost sheet, and manufacturing orders.">[style](/reference/glossary#style)</Tooltip>
validation record that takes a style from its first prototype to a
<Tooltip tip="A physical prototype of a style, developed and validated through fitting before bulk production.">[sample](/reference/glossary#sample)</Tooltip>
approved for bulk production — the seven-stage proving ground every reusable style
goes through before a customer's order goes on the floor.

## What it is

GarmentFlow keeps a single, canonical **sample** record per style validation
chain, opened and worked from the **Fitting** module. A sample carries an
optional link to one
<Tooltip tip="A customer's commitment to buy specific styles, colorways, and quantities to ship by a given date.">[order](/reference/glossary#order)</Tooltip>
— the order it is being made for — so the same per-style validation can sit
against the order, drive that order's bulk-production phase advance on
**PP** approval, and be re-read by the order detail without having to be
re-keyed there.

* **Fitting** — the per-style validation surface. One Fitting per style,
  seven stages, the proving ground from first prototype to a bulk-confirmed
  top-of-production sample. Fitting is the record the
  [manufacturing order](/concepts/style-vs-order-vs-mo) reads its fitting
  comments, current files, and per-stage materials from, and is the record
  whose pre-production stage approval advances a linked order's work phase
  to bulk. The Fitting module list is the **Samples** list; the first column
  is `Sample No.`
* **Order ↔ sample link.** The sample's `Order` field — set on the sample
  itself, or set from the order's own **Samples** sub-tab — is what wires
  the sample to its order. A sample may sit without any order (proto /
  development / salesman work); when it does carry an order link, that link
  is **one order at a time** and moves rather than copies if you re-point it.
  See *Linking a sample to an order*.
* **Legacy Order Samples.** An older, per-order ledger of customer-approval
  samples used to be the order Samples surface. It is no longer the source
  the order's **Samples** sub-tab or the Overview **Sample Status** card
  read — both now read the lifecycle Sample above — and the standalone
  Order Samples surface is hidden by default. See *The legacy Order Samples
  ledger* at the end of this page for the only escape hatch.

A Fitting is **per-style** and **per-validation-chain**. One Fitting follows a
single style through a fixed sequence of seven stages — **Proto**, **Fit1**,
**Fit2**, **Fit3**, **PP** (pre-production sample), **SMS** (salesman sample),
and **Bulk** (top-of-production sample) — each created automatically when the
Fitting is opened, each with its own status, dates, files, comments, and
per-stage shipments. The team works the stages in order, iterating within a
stage as many times as the work needs, and the Fitting moves on when the
current stage is approved.

A Fitting can carry an **optional link to an order**, and that link is
load-bearing for what happens downstream. Without an order link, the Fitting is
a per-style validation record only — useful for development, but with no
automatic effect on any order. With an order link in place, approving the
**PP** stage automatically advances the linked order's work phase from
**production samples** to **bulk production** (see
[order lifecycle](/concepts/order-lifecycle)).

## Why it exists

A style is a reusable product record. It needs to be proven — does the design
sew up, does the spec measure right, does the prototype fit, does the
pre-production sample match what the order team committed to the customer —
before the platform commits an order's quantities to the factory floor. The
Fitting is that proving ground: one record per style that holds every round of
the validation, every revised spec, every fitting photo, every comment, every
physical-sample shipment, on a fixed seven-stage spine the whole team works to.

Pinning validation to the style (rather than to each order that runs the style)
is what makes the work reusable. The same style can sell to many customers
across many seasons, and the Fitting that proved it once is the record
production reads from. When an order is linked, the Fitting's pre-production
approval is what tells the order's lifecycle that the style is signed off for
bulk — one signal at one place, not a copy of the approval on every order that
runs the style.

## When it is used

* **During style development**, opened against the style being developed — the
  per-style proving ground for everything from a first prototype through to a
  top-of-production sample.
* **Throughout sampling**, as the record the team logs every revised spec,
  every fitting photo, every comment, and every physical-sample shipment
  against, stage by stage.
* **At the pre-production milestone**, as the record whose **PP** approval
  signals that the style is ready for bulk — and, when an order is linked,
  automatically advances that order's work phase.
* **When the MO is composed**, as the record the manufacturing order pulls
  fitting comments, current-version files, and per-stage fabric/trim
  selections from for its rendered content.

The Fitting lives in the **Fitting** module. The Fitting list opens every
Fitting in your tenant; a row opens its detail page with the seven stage tabs
across the top.

## Dependencies

* A **[style](/modules/styles)** to validate. A Fitting is per-style — the
  Add-Sample form leads with a `Style master No.` picker so the new Fitting
  ties to a real style record.
* **Fitting write permission**, for the user creating, editing, working a
  stage, completing a stage, advancing to the next stage, or cancelling /
  archiving the Fitting. Reads are open to any authenticated user in your
  tenant.

A Fitting does not require an order — it can be opened against a style alone
during development. A Fitting **may** carry an optional order link, and that
link is what wires the **PP** approval to the order's phase advance (see
*Business rules*).

## What depends on it

* The **[order](/modules/orders)'s work-phase advance to bulk** — when a
  Fitting is linked to an order, approving the Fitting's **PP** stage
  automatically advances the linked order's work phase from **production
  samples** to **bulk production**. Without an order link on the Fitting, PP
  approval is purely informational. See
  [order lifecycle](/concepts/order-lifecycle).
* The
  <Tooltip tip="A manufacturing order — the production document issued for a specific order's version of a style.">[manufacturing order](/reference/glossary#mo-manufacturing-order)</Tooltip>'s
  **rendered content** — when an MO is composed for an order's version of the
  style, it pulls the Fitting's per-stage comments, the current version of
  each file on the Fitting's category tabs, and the per-stage fabric and trim
  selections into the MO's content so the factory builds from validated
  fitting information rather than an untested design. See
  [style vs. order vs. MO](/concepts/style-vs-order-vs-mo).
* The **style's validation history** — the Fitting record is where a reader
  goes to see how a style's proving rounds went and which round signed off the
  pre-production standard.

## Fields

Group the Fitting's fields by purpose. The Fitting record carries identity,
linkage, sample-level status, and notes; each of the seven stages carries its
own dates, status, comments, per-stage materials, files, and shipments.

### Sample-level — identity

* `Style master No.` — the optional link to the
  [style](/modules/styles) master the Fitting is validating. Picked from the
  same style-master picker
  the order Add-Style step uses: selecting a master auto-fills `Style number`,
  `Style name`, `Season`, and `Customer` from the style record. The picker
  also offers a manual-entry option for early development when the style
  master is not yet created. Linking to a master is preferred — the per-style
  history, the MO content pull, and the readiness view all read off it.
* `Style name` — the style's name on the Fitting. **Required.** Carried
  forward from the style master when one is linked; entered by hand when not.
* `Style number` — the customer-facing style number on the Fitting. Optional.
  Carried forward from the style master when one is linked; the field accepts
  free-text on a manual-entry Fitting.
* `Season` — the selling season the Fitting is for. Optional. Carried forward
  from the style master when one is linked.
* `Customer` — the customer the style is being developed for. Optional.
  Carried forward from the style master when one is linked.

### Sample-level — order link

* `Order` — the **optional** link to an [order](/modules/orders) the Fitting
  is being validated for. Picked from a searchable order picker on the
  Fitting create form and the Fitting detail; the picker searches the full
  tenant catalogue by order number and customer name. The link is
  **1:1**: a sample is on at most one order, and re-pointing it asks for
  confirmation and moves it. Clearing the field unlinks the sample. When
  set, the Fitting's **PP** approval automatically advances the linked
  order's work phase to **bulk production**; when left blank, **PP**
  approval is informational only. The order side has the same link
  exposed as the order Samples sub-tab's **"Link sample"** and
  **"New sample"** actions — see *Linking a sample to an order*.

### Sample-level — status and notes

* `Status` — the Fitting record's own lifecycle label: **active**,
  **cancelled**, or **archived**. A new Fitting opens as **active**. See
  *Status and transitions*.
* `Notes` — internal-facing free text on the Fitting record. Distinct from
  the per-stage `Notes` (see below).

### Per stage — identity

Each of the seven stages is its own row on the Fitting, in fixed order.

* `Stage` — the stage's name. The seven stages are **Proto**, **Fit1**,
  **Fit2**, **Fit3**, **PP**, **SMS**, and **Bulk**. They are created
  automatically when the Fitting is opened; you do not add or remove stages.
* `Stage status` — the stage's own lifecycle label: **pending**, **in
  progress**, **approved**, or **rejected**. The PROTO stage opens **in
  progress** on a new Fitting; the other six open **pending**. See
  *Status and transitions*.

### Per stage — dates

* `ETD` — the planned ship-out date for this stage's physical sample.
  Operator-set, optional.
* `ETA` — the planned arrival date for this stage's physical sample.
  Operator-set, optional.
* `Due date` — the date the stage's work is targeted to complete by.
  Operator-set, optional. The Fitting list flags a stage as overdue when its
  due date is in the past and the stage is not yet approved or rejected.

### Per stage — assignment and materials

* `Assignee` — the user the stage is assigned to. Optional.
* `Fabric master` — the optional fabric-master record used for this stage's
  physical sample. Picked from the per-tenant fabric master list.
* `Trim master` — the optional trim-master record used for this stage's
  physical sample. Picked from the per-tenant trim/accessory master list.
  Both selections feed into the MO's rendered content for the stage. They
  are a per-stage recordkeeping field for what was used on this prototype.
  The style's
  <Tooltip tip="The bill of materials — the list of fabrics and trims a style is made from.">[BOM](/reference/glossary#bom-bill-of-materials)</Tooltip>
  remains the canonical record of what the style is made from.

### Per stage — comments and notes

* `Comments` — a single short summary entered against the stage row, shown in
  the Fitting list's stage cell. Separate from the per-stage comment thread
  on the **Comments** sub-tab (see below).
* `Notes` — internal-facing free text on the stage itself. Distinct from the
  Fitting-level `Notes`.

### Per stage — files (by category)

Each stage has four file categories, kept on the stage's category sub-tabs:

* `SPEC` — the measurement specification files for the stage. Spreadsheet,
  PDF, or image.
* `Fitting Photo` — fitting photos of the sample on the form or model.
  Images only.
* `Grading` — the size-grading documents for the stage. Spreadsheet, PDF, or
  image. The
  <Tooltip tip="The per-stage size-and-tolerance table the team grades a style to, built from the workspace's POM catalog plus any one-off points added on the fitting stage.">[grading table](/reference/glossary#grading-table)</Tooltip>
  the stage works to is built from the workspace's
  [POM Library](/admin/pom-library); a one-off point added in-table
  stays local to that stage.
* `Shipment` — the documents attached to the stage's physical-sample
  shipments. Spreadsheet, PDF, or image.

Files in every category are **versioned by filename**: re-uploading a file of
the same name on the same category records a new version on the stage and
keeps the prior version downloadable. The Fitting Photo category is versioned
on the same rule as the rest.

### Per stage — SPEC measurement table

The stage's **SPEC** sub-tab also carries a structured per-stage measurement
table — one row per point of measure, edited in place on the same sub-tab as
the SPEC file uploads above. The file attachments are the reference spec
(spreadsheet, PDF, or image) the team works to; the structured table is the
QA record of what this round's prototype actually measured to spec. The
two sit side by side on the SPEC sub-tab.

The table's columns are:

* `CODE` — your team's short code for the point of measure. Optional.
* `POINT OF MEASURE` — the measurement point itself (e.g. chest, sleeve
  length, hem). **Required** — a row without one is dropped on save.
* `INSTRUCTIONS` — notes on how to take the measurement. Optional.
* `TOL−`, `TOL+` — the lower and upper tolerances around `REQUESTED`. Free
  text.
* `REQUESTED` — the spec target for this measurement point.
* `VENDOR` — the value the factory measured and sent back.
* `SAMPLE` — the value your team measured on the sample.
* `REVISED` — the next-round target when the spec is being revised.
* `COMMENT` — per-row free text.
* `DIFFERENCE` — **derived, display-only**: `SAMPLE − REQUESTED`, shown
  when both cells parse as numbers and blank otherwise. Plain subtraction
  — there is no tolerance flagging on the column, and the value is not
  stored.

Add rows with **+ Add row** and remove a row with its row-level action.
Saving the table persists the current row set; rows whose `POINT OF
MEASURE` is blank are dropped on save without prompting, so an empty new
row never lands as a blank. The table is per-stage — each of the seven
Fitting stages has its own SPEC table, independent of the others.

The order-scoped per-style **grading grid** is the sibling for sizes: the
SPEC table verifies what one sample measured to spec at a stage; the
grading grid records the spec at every size on the order. See
[Grading](/modules/grading).

### Per stage — physical-sample shipments

Each stage holds **zero or many** physical-sample shipments — the Fitting is
the record of every sample the factory shipped out for that stage. A shipment
row carries the stage's ship-out date, the carrier tracking number, and the
shipment's contents, so a reader can read back which physical sample went
where, when, and on what tracking. The shipment-category files (see above)
attach the supporting documents for the stage's shipments.

### Per stage — review

* `Review` — the per-stage review sub-tab, where the team builds the
  structured review for the stage (sections, comments, and image-anchored
  references) that prints as the stage's review summary. The review is
  per-stage and carries forward stage to stage as the validation history.

## Business rules

1. **A Fitting is per-style.** One Fitting record validates one style. A
   different style — even for the same customer in the same season — is a
   separate Fitting.
2. **The seven stages are fixed.** Every Fitting opens with the same seven
   stages in the same order: **Proto → Fit1 → Fit2 → Fit3 → PP → SMS →
   Bulk**. Stages are not added, renamed, reordered, or removed. The team
   works the stages in order.
3. **PROTO opens in progress; the rest open pending.** On a new Fitting, the
   **Proto** stage's status is **in progress** and the team can start work
   immediately; the other six stages open as **pending** and stay that way
   until the team moves to them.
4. **A stage's status is independent of the sample-level status.** Each
   stage has its own **pending / in progress / approved / rejected**
   lifecycle that progresses through the work; the Fitting record itself
   carries a separate **active / cancelled / archived** lifecycle.
5. **Rejecting a stage requires an approval comment.** The team records the
   reason for the rejection on the stage in the same write; without a
   comment the rejection is refused.
6. **Complete and Advance behave differently.** "Complete" marks the current
   stage approved without moving the pointer to the next stage — used when
   the team wants to sign a stage off and pause. "To Next Steps" marks the
   current stage approved **and** moves the Fitting's current stage to the
   next one in the spine, flipping that stage from **pending** to
   **in progress** in the same write.
7. **You cannot advance past Bulk, and you cannot advance from a rejected
   stage.** "To Next Steps" is refused when the current stage is **Bulk**
   (there is nothing to advance to) and when the current stage is
   **rejected** (the stage needs to be reworked and approved first).
8. **Approving the PP stage advances a linked order to bulk.** Approving the
   **PP** stage — whether via "Complete", "To Next Steps", or a direct edit
   to the stage's status — automatically advances the linked order's work
   phase from **production samples** to **bulk production**. The advance
   only fires when the Fitting carries an `Order` link and the linked order
   is at the **production samples** work phase. Without an order link, the
   approval is informational; if the linked order is already past the
   triggering phase, the advance is a no-op. See
   [order lifecycle](/concepts/order-lifecycle).
9. **A Fitting can be cancelled or archived.** "Cancel sample" moves the
   Fitting from **active** to **cancelled** (the Fitting stops appearing in
   the active list); "Archive sample" moves it to **archived** (kept on
   file, hidden from active views). Cancel and Archive act on the Fitting
   as a whole, not on a stage.
10. **Files are kept by version.** A file uploaded to a stage's SPEC,
    Fitting Photo, Grading, or Shipment category is kept by its filename:
    re-uploading the same filename to the same category writes a new
    version and keeps the prior version downloadable, so the stage's
    revision history is preserved across all four file categories.
11. **The MO pulls validated fitting content.** When a manufacturing order
    is composed for an order's version of the style, the MO content reads
    the Fitting's per-stage comments, the current version of each file
    across the stage's four file categories, and the per-stage fabric /
    trim selections. The MO is the consumer; the Fitting is the source.

## Validations

| When                        | Check                                                     | What happens if it fails                                                             |
| --------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| Create the Fitting          | `Style name` is set                                       | The save is rejected.                                                                |
| Set a stage to **rejected** | An approval comment is recorded with the rejection        | The transition is rejected with a "comment required" message.                        |
| "To Next Steps"             | The current stage is not **Bulk** and is not **rejected** | The advance is refused with the reason (already at Bulk, or current stage rejected). |
| Edit a stage                | The Fitting is **active**                                 | The save is refused on a **cancelled** or **archived** Fitting.                      |

## Date logic

Each stage carries three operator-set dates — `ETD`, `ETA`, and `Due date` —
that the team enters as the work is planned, and that the Fitting list reads
back per stage.

* **`ETD`** — the planned ship-out date for the stage's physical sample. Set
  by the operator on the stage. The Fitting list shows the ETD on the
  stage's cell.
* **`ETA`** — the planned arrival date for the stage's physical sample. Set
  by the operator on the stage.
* **`Due date`** — the date the stage's work is targeted to complete by. Set
  by the operator on the stage. The Fitting list flags a stage as overdue
  when the due date is in the past and the stage is neither approved nor
  rejected.
* **`Completed at`** — set by the platform when the stage's status flips to
  **approved** (whether via "Complete", "To Next Steps", or a direct edit).
  Audit timestamp.

The Fitting record itself does not introduce its own ship-date — Fitting work
is anchored on the style and, where linked, slots into the order's own
backward-scheduled timeline.

## Status and transitions

The Fitting carries **two independent lifecycles** — one on the Fitting record
itself and one on each of the seven stages.

### The Fitting record's lifecycle

* **Active** — the Fitting is open and the stages are workable. A new
  Fitting starts here.
* **Cancelled** — the Fitting has been cancelled (the validation was
  abandoned). Edits to the stages are refused; the Fitting is hidden from
  the active Fitting list. Set via "Cancel sample" on the Fitting detail.
* **Archived** — the Fitting has been archived (kept on file, but no longer
  in active view). Edits are refused; the record stays accessible by direct
  link. Set via "Archive sample" on the Fitting detail.

Transitions:

* (created) → **Active**.
* **Active** → **Cancelled**: via "Cancel sample".
* **Active** → **Archived**: via "Archive sample".

### A stage's lifecycle

* **Pending** — the stage exists on the Fitting but the team has not started
  it yet. Every stage except **Proto** opens here.
* **In progress** — the team is actively working the stage. The **Proto**
  stage opens here on a new Fitting; another stage flips here when the
  prior stage's "To Next Steps" advances onto it, or when the team
  manually sets it here.
* **Approved** — the stage has been signed off. Set via "Complete" (which
  leaves the Fitting on this stage) or "To Next Steps" (which approves
  this stage *and* moves the pointer to the next).
* **Rejected** — the stage has been rejected and needs a rework. The team
  records an approval comment on the same write. The stage stays workable
  for the rework; "To Next Steps" is refused from a rejected stage.

Transitions:

* (created) → **Pending** for stages 2–7; **In progress** for **Proto**.
* **Pending** → **In progress**: when the team starts working the stage.
* **In progress** → **Approved**: via "Complete" or "To Next Steps".
* **In progress** → **Rejected**: via a status edit with an approval
  comment.
* **Rejected** → **In progress**: the team resumes the rework.

Approving the **PP** stage is the system trigger for the order's work-phase
advance to bulk (when the Fitting carries an `Order` link). The approval
itself follows the same per-stage transition rules — Complete, Advance, or a
direct status edit — and fires the order phase advance in the same write.

## Effect of changes

* **Create a Fitting.** A new Fitting opens with the seven stages
  auto-created — **Proto** as **in progress**, the other six as **pending** —
  with the sample-level status set to **active** and any style-master fields
  carried in from the picker.
* **Edit a stage's dates, comments, assignee, materials, or notes.** The
  change saves to the stage. The Fitting list re-reads the affected cell
  on the next view.
* **Edit a stage's status directly.** The platform updates the stage. If the
  target status is **rejected**, an approval comment is required. If the
  target status is **approved** and the stage is **PP**, and the Fitting
  carries an `Order` link to an order at **production samples**, the order's
  work phase advances to **bulk production** in the same write.
* **Click "Complete" on a stage.** The current stage moves to **approved**
  and `Completed at` is set. The Fitting's current stage pointer does not
  move. If the stage is **PP** and the Fitting is order-linked, the
  order's work-phase advance to bulk fires in the same write.
* **Click "To Next Steps" on a stage.** The current stage moves to
  **approved**, `Completed at` is set, and the Fitting's current stage
  pointer moves to the next stage in the spine — flipping it from
  **pending** to **in progress**. If the stage being approved is **PP**
  and the Fitting is order-linked, the order's work-phase advance to bulk
  fires in the same write. The action is refused when the current stage is
  **Bulk** or **rejected**.
* **Upload a file to a stage category.** The file is saved on the stage's
  category as a new version. If a prior version with the same filename
  exists on the same category, the prior version is kept downloadable and
  the new upload becomes the current version that downstream surfaces
  (such as the MO content pull) read.
* **Add a physical-sample shipment on a stage.** The shipment row is
  saved on the stage with its ship-out date, tracking number, and
  contents. Multiple shipments can sit on the same stage.
* **Add to a stage's Comments thread.** The new comment is appended to
  the per-stage thread. Bulk comment import accepts a list of entries
  from an uploaded file and creates one comment per entry; the manual
  add path takes a single free-text comment.
* **Cancel the Fitting.** The Fitting's status flips to **cancelled** and
  the record drops out of the active Fitting list. Edits to the stages
  are refused from this point.
* **Archive the Fitting.** The Fitting's status flips to **archived** and
  the record is hidden from active views. Edits are refused; the record
  stays on file.
* **MO composed for the linked style.** The MO reads the Fitting's
  per-stage comments, current-version files across the four file
  categories, and per-stage fabric / trim selections into its rendered
  content. The MO is the consumer; the Fitting itself is unchanged.

## Working a fitting — the validation walkthrough

The Fitting list opens with one row per Fitting. Each row shows
the linked style's identifiers (`Style master No.`, customer-brand, season),
the Fitting's `Status`, and the seven stages across the row as columns, each
carrying that stage's ETD, ETA, and the stage's `Comments` summary. Filter by
season, customer, stage, or status to focus on the work in front of you. A
pencil-edit icon on each stage cell opens the cell in place so you can edit
the stage's ETD, ETA, and Comments without leaving the list.

The Fitting detail page lays the seven stages out as tabs across the top.
Selecting a stage opens the stage's working area, with sub-tabs for the
stage's **SPEC**, **Comments**, **Fitting Photo**, **Grading**, **Review**,
and **Shipment** work. Files uploaded on the category sub-tabs are kept by
filename: re-uploading the same filename writes a new version on the stage
and keeps the prior version downloadable. The **Comments** sub-tab carries a
per-stage comment thread distinct from the single-line Comments summary
shown on the Fitting list — you add to it by hand or by importing a list of
entries from a file. The **Shipment** sub-tab records the stage's
physical-sample shipments, one row per sample sent out. The **Review**
sub-tab is the stage's structured review record.

At the foot of each stage are two action buttons:

* **Complete** — marks the current stage approved without moving on. Used
  when the team wants to sign a stage off but isn't ready to start the
  next.
* **To Next Steps** — approves the current stage *and* moves the Fitting on
  to the next stage in the spine, flipping that stage from pending to in
  progress.

Iterate within a stage as many rounds as the work needs — log the problems
as comments, upload the revised spec, attach the new fitting photos, and
record each new physical sample as another shipment on the stage. Because
the files are versioned, the whole revision history is preserved, not just
the final result. Only when a stage is right do you complete it or advance
to the next.

The **PP** stage is the milestone the rest of the system reads off. When the
Fitting carries an `Order` link and the order is at the **production
samples** work phase, approving the **PP** stage automatically advances that
order's work phase to **bulk production** — one signal, in one place,
without retyping anything on the order. When no order is linked, **PP**
approval is informational only.

When a [manufacturing order](/concepts/style-vs-order-vs-mo) is composed for
an order's version of the linked style, the MO pulls the Fitting's per-stage
comments, the current version of each file across the four categories, and
the per-stage fabric and trim selections into its rendered content — so the
factory builds against validated fitting information rather than an
untested design.

## Linking a sample to an order

A sample carries an **optional, one-at-a-time** link to an order. The link
is what makes the same per-style validation legible on the order it is
being made for — the order's **Samples** sub-tab and the Overview
**Sample Status** card both read the lifecycle Sample by this link, and
the **PP** stage approval fires the order's work-phase advance only when
the link is set (see *Business rules*).

The link can be set from either side.

### The rules

A handful of plain rules govern the link. Hold them before you act.

* **A sample may sit with no order.** Proto, development, and salesman
  work belong on a sample that is style-anchored without an order link.
  The Fitting still works, the stages still progress, and the order has
  no claim on the sample. The `Order` field is left blank.
* **A sample is on at most one order.** The link is **1:1, optional**:
  a sample is either unlinked or attached to a single order. There is no
  multi-order list and no copy step.
* **Re-pointing the link moves the sample, with confirmation.** Linking
  a sample that is **already on a different order** asks you to confirm,
  then **moves** the sample off the prior order onto the new one. The
  sample is not copied: the prior order loses it the moment the new
  order gains it. This is the rule readers most often guess wrong —
  there is no second sample and no shared sample.
* **You can clear the link.** Setting the sample's `Order` field back
  to blank unlinks it, returning the sample to the order-less state. The
  prior order's **Samples** sub-tab and **Sample Status** card stop
  reading it from that point.

The customer on the sample is the style's customer (carried in from the
style master); the order's customer must match.

### From the order — Link sample / New sample

The order's **Samples** sub-tab is where the order team reaches for an
existing sample or starts a new one against this order. Two actions sit
at the top of the sub-tab:

* **"Link sample"** — opens a dialog titled *Link an existing sample*
  that lists your tenant's lifecycle samples, **defaulted to the order's
  customer**, with a `Search samples…` box and the candidate list
  underneath. Samples already on this order are excluded; samples on a
  different order are shown and, when picked, prompt the move
  confirmation above. The picker is searchable across the candidate list
  — there is no small-row cap.
* **"New sample"** — opens the Fitting create form with this order
  already pre-selected on the new sample's `Order` field. Save the form
  and the resulting sample is born linked to this order; cancel and no
  sample is created.

Neither action lifts the **PP** approval rule: the order's bulk-phase
advance still requires the linked Fitting's **PP** stage to be approved
(see *Business rules*).

### From the sample — the `Order` field

On the Fitting create form and the Fitting detail page, the sample's
`Order` field is a searchable order picker. It searches your tenant's
orders by order number and customer name (server-side), so the full
catalogue is reachable — not just a top-of-list slice. The same field
accepts the cleared state: choose "—" or clear the value and save to
unlink the sample.

When you change a sample's `Order` from one order to another, the same
1:1 move applies — the prior order's **Samples** sub-tab stops reading
the sample on the next refresh, and the new order's sub-tab starts.
There is no two-step "unlink then re-link" — the change is one save.

## The legacy Order Samples ledger

Before the lifecycle Sample model, GarmentFlow ran a separate per-order
**Order Samples** ledger that lived alongside Fitting. It is no longer
the source the order detail reads — the order's **Samples** sub-tab and
the Overview **Sample Status** card both read the lifecycle Sample
above — and the standalone **Order Samples** surface is **hidden by
default**. Its route is still reachable, but only after an administrator
turns its sidebar link back on.

To re-enable the legacy surface, open the
[Sidebar layout](/admin/feature-settings#sidebar-layout) card under
**Feature Settings**, find **Order samples** in the list of toggleable
items, tick it back on, and save. The link reappears in the left
navigation; the standalone Order Samples page is where the legacy
ledger lives. This is a per-tenant choice and is intended only as an
escape hatch for tenants still running the older ledger — new
sample-keeping work belongs on the lifecycle Sample / Fitting record
above.

What the legacy ledger records, for tenants who still use it: one row
per sample of a specific type (**Proto**, **Fit**, **Salesman**, or
**PP**) sent to the customer for an order's style, with when it went,
on what tracking, what the customer's feedback was, and whether they
approved it, asked for a revision, or sent the team back to rework.
Each Order Sample carries its own **Pending / Sent / Approved /
Revision requested / Cancelled** lifecycle with a per-row revision
history. The legacy ledger is independent of the lifecycle Sample —
nothing on a legacy Order Sample drives the order's work phase or any
downstream advance.

If your tenant has the legacy surface turned off, no action is needed —
the lifecycle Sample described above is the only path the order detail
and the platform read.

## Best practices

* **Open the Fitting against a style master.** The Add-Sample form's
  `Style master No.` picker ties the Fitting to a real style record, so the
  per-style history, the MO content pull, and the readiness view all
  resolve correctly. The manual-entry option is for development cases
  where the style master is not yet created — switch the Fitting onto the
  master as soon as the style exists.
* **Link the Fitting to its order before you approve PP.** The **PP**
  approval's work-phase advance only fires when the `Order` link is set
  on the Fitting. Setting the link up front is what wires the validation
  signal through to the order on the day the approval lands.
* **Use Complete to sign a stage off, Advance to move on.** Keeping the
  two actions separate lets you sign a stage off without pressuring the
  team into starting the next; use "To Next Steps" when the next stage's
  work is genuinely ready to begin.
* **Log every round on the stage that produced it.** A stage stays
  workable for as many rounds as it needs — the file versions, comment
  thread, and shipment rows on the stage are the audit trail for how the
  validation actually went. Advance only when the stage is right.
* **Re-upload changed files with the same filename.** Versioning is by
  filename: keeping the filename stable across rounds is what builds the
  stage's revision history. A new filename starts a fresh version chain
  on the same category.
* **Cancel rather than try to delete.** A Fitting that is no longer being
  worked is **cancelled** or **archived** from the detail page —
  cancelled to take it out of the active list, archived to keep it on
  file but out of view.

## Sample identity and trim approval alongside the Fitting

Two records sit alongside the Fitting and the legacy Order Samples ledger
for the physical-sample side of the work.

* **Product cards.** When a sample is about to travel — to a fitting
  session, a factory visit, or a customer review — the team prints a
  <Tooltip tip="The printed four-up A4 sample tag that identifies a physical sample as it travels.">[product card](/reference/glossary#product-card)</Tooltip>
  to identify it. The card carries the order and style, the sample type,
  size, colour, and a short list of the materials the prototype is in,
  on a four-up A4 tag the team attaches to the sample. The card has no
  status and no downstream effect — it is the workspace's record that the
  printed tag exists. The cards live on
  [Product Cards](/modules/product-cards); the PDF layout is set on
  [Feature Settings → Product card PDF](/admin/feature-settings#product-card-pdf-fields).
* **Trim submissions.** A separate record runs in parallel for trim
  approval — one
  <Tooltip tip="The workspace's record of a trim sample being sent out for sign-off and the outcome that came back.">[trim submission](/reference/glossary#trim-submission)</Tooltip>
  per trim, colour, and intent, with the vendor, the approval round, the
  outcome, and the photos that travel with the swatch. Trim submissions
  live on [Trim Submissions](/modules/trim-submissions); they are the
  paper trail for trim approval and do not gate the bulk trim purchase
  order.

## Related pages

* [Style](/modules/styles) — the per-style record the Fitting validates.
* [Order](/modules/orders) — the order whose linked Fitting drives the
  bulk-production phase advance.
* [Order lifecycle](/concepts/order-lifecycle) — the canonical reference
  for the order's work phase and the PP-approval trigger.
* [Style vs. order vs. MO](/concepts/style-vs-order-vs-mo) — how the
  Fitting fits into the wider style → order → MO chain.
* [POM Library](/admin/pom-library) — the workspace's catalog of
  measurement points the per-stage grading tables draw from.
* [Product Cards](/modules/product-cards) — the printed four-up A4 sample
  tag that identifies a physical sample as it travels.
* [Trim Submissions](/modules/trim-submissions) — the paper trail for
  trim approval that runs alongside garment sampling.
* [The style-centric model](/concepts/style-centric-model)