> ## 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.
# Grading
> The per-style size-and-tolerance reference table — a POM-by-size grid that captures how a style's measurements scale from sample size out to every size the order runs, finalised one version at a time.
A **grading table** is the per-[style](/reference/glossary#style)
size-and-tolerance reference the team grades a sample to. It is a
**POM-by-size grid**: one row per
[point of measurement](/reference/glossary#pom-point-of-measurement)
the team grades against, one column per size the order runs, plus a
tolerance column the team works to. Each cell is the **target measurement**
at that point for that size — the figure the factory sews to and the team
measures the bulk sample against.
## What it is
A grading table is a **reference document**, not a calculation. The platform
**stores** the figures the team enters or imports; it does not derive sizes
from a base size, does not compute increments, and does not validate a
measurement against the tolerance. The grid is what the team has agreed —
brand spec, factory counter-proposal, or the team's own target — read back
exactly as it was entered or imported, on every screen that reads it.
A grading table lives **per style, per order**. A style on two orders has
two grading tables — one per order — because each order may run the style
through a different size set, season, or factory, and the grading table is
the size-scaling reference for *that* order's bulk run. The order is the
scope; the style is the subject.
Each grading table carries a **version**. The team finalises one version at
a time and supersedes it with a new draft when the spec changes — the same
versioning shape used by the
[BOM](/reference/glossary#bom-bill-of-materials)
and the [cost sheet](/modules/cost-sheet), so the team can iterate on the
grading reference without losing the version a finished sample was graded
against. The finalised version is the one the
[manufacturing order](/reference/glossary#mo-manufacturing-order)
workbook's Grading tab renders from.
## Why it exists
A style does not ship in one size. The team agrees the chest, sleeve, and
body figures at a sample size, and then runs every other size off that
agreement — a 3 cm step up the chest, a 1.5 cm step on the sleeve, and so on.
The grading table is where that agreement is written down once, kept on
the order, and read by everyone downstream: the factory grading the
pattern, the QC team measuring the bulk sample, the merchandiser comparing
two rounds, and the
[PMS document](/reference/glossary#pms-document)
the MO issues to the factory.
Without one canonical grading table per order, the size figures live in an
email thread, get re-typed onto every fitting comment, and disagree by the
time the bulk sample is measured. The grading table is the team's agreed
reference — one place, one version, read by everything that needs it.
## When it is used
* **When the team accepts a brand-provided grading sheet** for a new
development — the file the customer sends is imported as the **brand-
provided** baseline.
* **At every fitting round** where measurements need to be re-set — Proto,
Fit 1, Fit 2, Fit 3, Size Set, PP, SMS — each round opens a new draft
version of the grading table, the team revises the figures, and finalises
before the next round.
* **At MO issuance**, where the finalised grading table binds into
the MO workbook's Grading tab — POM rows × size columns with
tolerance, rendered into the workbook the factory receives.
* **When measuring a bulk sample**, where the team records the actual
figures into a separate **measured-actual** version and compares it to
the target version side by side.
You reach the grading table from the order detail's **Grading** sub-tab.
The same grid is also reachable from the style detail's **Grading** tab —
but only when the style is open *under an order context*, since the
grading table lives per order-style. Opening a style without an order
shows a hint that grading is order-scoped and offers no grid to edit.
## Dependencies
A grading table depends on:
* The order's style — the grid lives on the order's per-style record, so
the style must already be on the order.
* The workspace's [POM Library](/admin/pom-library) — the points of
measurement the grid is built from. Every grading table draws its POMs
from this library; the tolerances follow the library record onto the
table.
A grading table does **not** depend on the
[fitting](/reference/glossary#fitting)
record. The fitting record carries per-stage comments and files; the
grading table is its own surface with its own versioning. The two are
read together by the MO workbook, but neither needs the other to
exist.
## What depends on it
* The
[MO](/reference/glossary#mo-manufacturing-order)
workbook's **Grading** tab is rendered directly from the finalised
grading table — POM rows down the side, the size columns across, and
the per-POM tolerance, exactly as the table reads on the Grading
sub-tab. The binding is **finalised-only**: a style with no table,
or a table still in **Draft**, leaves the tab with its header block
only. Multiple grading rounds as separate dated tabs are not yet
supported — the finalised grading is what renders on the single
fixed Grading tab. See
[Build a manufacturing order (MO)](/modules/build-an-mo) for the
wider tab-by-tab picture.
## Versions and statuses
Every grading table is a versioned record with three statuses:
* **Draft** — the version is editable. POMs, sizes, measurements,
tolerances, and annotations all open for change. A draft is the only
state the grid accepts measurement edits in.
* **Finalised** — the team locks the version for measurement edits. A
finalised version is the one the MO workbook's Grading tab renders
from; it can still gain annotations (per-POM notes), but the
measurement cells are read-only.
* **Superseded** — a later version of the same grading table has been
finalised, retiring this one. Superseded versions stay readable on the
table list and remain eligible for the side-by-side comparison view —
the history is preserved.
### Version type
Each version carries a `Version Type` that labels what the version
represents. The platform's options are:
* `BRAND_PROVIDED` — the customer-supplied baseline grading sheet.
* `PROTO`, `FIT_1`, `FIT_2`, `FIT_3` — measurements taken or set at the
named development round.
* `SIZE_SET` — the size-set run's measurements.
* `PP` — the pre-production sample's measurements.
* `SMS` — the salesman-sample run.
* `BULK_TARGET` — the target the bulk run is graded to.
* `MEASURED_ACTUAL` — the figures measured off a finished sample.
* `COMPARISON` — a version held for the side-by-side comparison view.
* `OTHER` — anything else the team needs to capture.
The version type is a label, not a workflow gate — any type can be
finalised, and any two finalised or superseded versions can be compared.
## The grid
### POM rows
Each row is one point of measurement, carried from the
[POM Library](/admin/pom-library):
* `POM` — the English name of the point (`Chest Width`, `Sleeve Length`),
picked from the library when the row is added.
* `中文` — the optional Chinese name of the same point, carried over from
the library record.
* `Tol.` — the tolerance the team works to, as the inch fraction recorded
on the library record. Shown alongside every row so the team can read
the tolerance at a glance. **The platform does not validate measurements
against this tolerance** — it is a reference value the team reads, not
a check the system enforces.
A row can also be added as a **one-off POM** on the grid itself, for a
point a style needs that the library does not yet hold. A one-off POM
stays local to the grading table it was added on; it is not promoted to
the library catalog automatically.
### Size columns
Every column to the right of the tolerance column is a size:
* The default canonical template ships with **XS, S, M, L, XL** as a
starting size run.
* **Size labels are data, not a fixed enum.** A team that grades in
numeric sizes (`48`, `50`, `52`) or that runs `XXL`, `XXS`, `2XL`, or
any custom label simply enters that label. The grid grows the column.
* The team adds a size by typing a label and pressing **Add size**. Every
POM row gains an empty cell for that size; the team fills the cells in.
Every cell holds the **target measurement** for that POM at that size —
the figure the factory sews to and the QC team measures the sample
against. Cells are numeric and accept fractional inputs in the
workspace's working unit.
### Annotations
Each POM row can carry **annotations** — short notes against the point
that record a direction (`Increase`, `Decrease`, `Note`) and an optional
date. Annotations are append-only and the most recent one shows in the
row's comment indicator. They are a discussion record against a
specific point of measurement, not a measurement; they survive
finalisation and remain visible on superseded versions.
## Header fields
Each grading table version carries header fields the team fills in at
creation:
* `Version Label` — the team's free-text name for the version (`Bulk
Target v1`, `Brand sheet from 2026-04-12`). Required.
* `Version Type` — one of the values above. Required.
* `Sample Round` — the round this version corresponds to (`PP`, `Fit 2`).
Optional.
* `Base Size` — the base size of the grading run (`M`, `52`). Optional.
* `Season` — the season the table belongs to. Optional.
* `Vendor` — the factory the table is graded with. Optional.
* `Description` — a free-text note on what the version captures.
Header fields are reference metadata. They are read on the table list
and on the side-by-side comparison, but they do not drive validation or
gating.
## Importing a grading sheet
A grading table can be created from an Excel or PDF sheet via the
**Import** action on the table list. The workspace ships a **canonical
grading template** the team can hand to a brand or a factory — a CSV
with the columns:
* `POM` — the point of measurement.
* `TOL +/-` — the tolerance.
* One column per size the team grades to (the default template ships
with `XS`, `S`, `M`, `L`, `XL`, but a tenant whose size run differs
simply renames or adds size columns).
The import dialog runs in two steps:
1. **Pick a mapping spec and upload the file.** The mapping spec tells
the platform which header is the POM column and which is the
tolerance. Every other non-empty column is treated as a size column —
so the import handles size sets the workspace did not anticipate
without any per-tenant configuration.
2. **Review the rows.** The dialog shows the parsed POMs, the tolerance,
and one cell per detected size. The team can edit the rows in place
before committing.
Committing the import lands the rows as a **new draft version** of the
grading table — never an overwrite. Drafts can then be edited, finalised,
and compared like any other version.
The import is per-workspace optional and may be turned off by the
administrator; if it is not enabled, the **Import** affordance does not
show.
## Comparing versions
When two or more versions of a grading table are **finalised** or
**superseded**, the table list shows a **Compare tables** action. The
comparison view places two versions side by side:
* **Table A (Target)** — the target the team is comparing against (a
bulk target, a brand-provided baseline, an earlier round).
* **Table B (Actual)** — the version being checked (a measured-actual,
a later round, the actual sheet returned from a factory).
For every POM that appears on both versions, the view shows the value
on each, the tolerance, and the **delta** between them. The delta is a
reading the team uses to discuss what to adjust; the platform does not
flag out-of-tolerance cells.
Only **finalised** or **superseded** versions can participate in the
comparison — draft versions are excluded so the comparison is always
against figures the team has agreed to.
## Status and transitions
* **Draft → Finalised.** The team locks the version through the
**Finalize** action on the version's editor. The measurement cells
become read-only; the version becomes the one the comparison view
shows and the MO workbook's Grading tab renders from. Annotations
remain open.
* **Finalised → Superseded.** A later version of the same grading table
becoming **Finalised** supersedes earlier finalised versions. The
superseded version stays readable, remains eligible for the
comparison view, and continues to carry its annotations.
* **No reopen.** A finalised or superseded version cannot be returned
to draft. A change is captured as a new draft version that supersedes
the prior finalised one.
## Business rules
1. **A grading table is per order-style.** A style on two orders has
two grading tables. The order is the scope; the style is the subject.
2. **The grid is a reference, not a calculation.** The platform stores
the figures the team enters or imports; it does not derive cells,
does not compute increments from a base size, and does not validate
a cell against the row's tolerance.
3. **Size labels are data.** The team enters whatever labels the style
runs — alpha (`XS`–`XL`), numeric (`48`–`56`), or anything else —
and the grid grows the column.
4. **Tolerances ride with the POM.** A POM's tolerance is set on the
[POM Library](/admin/pom-library) and carries onto every grading
table the point is added to.
5. **Versions are first-class.** Every grading table is versioned; only
one version is current-finalised at a time, and superseded versions
are preserved for the comparison view.
6. **Draft is the only editable state.** Measurement edits, size edits,
and POM additions only happen on a draft. Finalised and superseded
versions are read-only for measurements (annotations stay open).
7. **The MO workbook reads the finalised version.** The workbook's
Grading tab renders from the finalised grading table — POM × size
with tolerance — when one exists; a style with no table, or a
table still in **Draft**, leaves the tab with its header block
only.
8. **Comparison requires two finalised or superseded versions.** The
comparison view excludes drafts so the diff is always between figures
the team has agreed.
## Best practices
* **Import the brand sheet as the first version.** The customer's grading
sheet is the agreed starting point — import it as the `BRAND_PROVIDED`
baseline, finalise it, and supersede it with subsequent rounds. The
history of how the team got from the brand baseline to bulk target is
then on the version list.
* **Match the version type to the round.** Use `PROTO`, `FIT_1`–`FIT_3`,
`SIZE_SET`, `PP`, `SMS`, `BULK_TARGET`, and `MEASURED_ACTUAL` honestly
so the comparison view's pairings make sense — a `MEASURED_ACTUAL`
against a `BULK_TARGET` reads cleanly months later.
* **Keep the POM Library tidy.** The grid reads its POMs and tolerances
from the library — if the team is reaching for one-off POMs often, that
is a signal to widen the library so future grading tables draw from a
shared vocabulary.
* **Use annotations for discussion, not for measurements.** A
measurement change goes in a new draft version; an annotation captures
the *reason* the change is needed.
* **Finalise before MO issuance.** The MO workbook's Grading tab
renders only from a finalised version — leaving the target as a
draft leaves the tab header-only on the file the factory receives.
## Related pages
* [Orders](/modules/orders)
* [Samples and fitting](/modules/samples-and-fitting)
* [POM Library](/admin/pom-library)
* [PMS Templates](/admin/pms-templates)
* [Production](/modules/production)
## What it is
A grading table is a **reference document**, not a calculation. The platform
**stores** the figures the team enters or imports; it does not derive sizes
from a base size, does not compute increments, and does not validate a
measurement against the tolerance. The grid is what the team has agreed —
brand spec, factory counter-proposal, or the team's own target — read back
exactly as it was entered or imported, on every screen that reads it.
A grading table lives **per style, per order**. A style on two orders has
two grading tables — one per order — because each order may run the style
through a different size set, season, or factory, and the grading table is
the size-scaling reference for *that* order's bulk run. The order is the
scope; the style is the subject.
Each grading table carries a **version**. The team finalises one version at
a time and supersedes it with a new draft when the spec changes — the same
versioning shape used by the