Required is not proved

Two different questions on one screen

Every screen in this module answers one of two questions, and they look almost the same. The first is what must be approved for this thing. The second is what has a buyer actually approved. The first is a list the app draws for you. The second is a history somebody recorded. A screen that mixes them will tell you an order is fine when nobody has sent anything.

The application keeps them apart on purpose, and it does so in an unusual way. The required list is not stored anywhere. There is no table of requirements. Every time you open a style or an order, the app works the list out from the product and draws it. Nothing to migrate, nothing to keep in step, and nothing to go stale. But also nothing to assign, date or chase, which is where this lesson ends up.

Where the list comes from

The list is computed from a small description of the product, and that description is derived rather than chosen. The app reads the style's garment type and fabric type, and whether it is marked as made seamless, and resolves them to a construction. Nobody picks the requirement set from a menu.

Three things about the product change the answer.

• Is the garment made from yarn rather than cut from cloth. That adds the knit-down, a test piece knitted on the real machine.
• Is it knitted to shape, as a sock is. That adds the toe closure and the boarding, and it takes the fit sample away. Boarding is the heat-setting that gives a sock its finished size.
• Is it a multipack, sold as several garments in one pack. That adds the pack presentation.

The multipack answer does not come from the style's name. It comes from the order's real packing instruction, and the code comments record why. It used to be a pattern match on the style name. That silently dropped a first-class buyer approval on any genuine three-pack that was not named like one.

STY-214 at Maritsa is a cut-and-sew jersey tee, so it takes the plainest set of all.

The split down that middle column is the design's whole argument, and it fits in one line. An approval that judges the specification belongs to the style. An approval that judges how this particular run came out belongs to the order. A fit sample approves the block and the measurement chart. The block is the master pattern the style is cut from. A second order for the same style consumes that approval rather than earning it again. A PP sample is cut from this order's bulk cloth on this order's line, so a repeat order gets a fresh one however identical the garment.

That is why the style's panel prints a note saying PP and TOP are not there, and says why. A requirement that could never be satisfied on the screen showing it is a permanent red mark nobody can clear.

Where each half is drawn

On the style, the first panel on the Samples tab is Required lab dips and samples, and it has two sections.

The lab dips are one row per live colourway, and their status comes from the colourway, not from the rounds. So STY-214 shows Rope and Ink, each with one of five labels: Not started, Requested, Approved, Not required (standard) or Rejected. Lesson 5 is about how those get written.

The samples are the style-scoped rows of the catalogue with a sample type. For STY-214 that is Proto, Fit and Size set. Each prints its own one-line reason under its name. So the panel explains itself, rather than showing a bare status to somebody who does not know what a size set is for.

On the order, the Time and Action tab opens with Required for this order, and it prints a count. It counts how many of the order-scoped requirements a buyer has actually approved, out of how many there are. For STY-214 that is two, the PP and the TOP. A row counts as done only when its headline is Approved or Approved with comments. Everything else reads as outstanding, including a round sitting with the buyer right now.

The row that says nobody has been given a date

Underneath each required row, the panel can print an amber line. It reads Not on the Time and Action plan — nobody has been given a date for it. A count of those rows then appears at the foot of the panel, with an instruction to add the milestone on the Time and Action tab.

This is the most useful thing on the screen, and it exists because the two lists are built from different sources. The milestone summary directly below is built from the plan, so it can only ever show you what the plan already knows. If the applied template never scheduled a PP approval, the plan looks complete and a real buyer approval was never asked for. The requirement list is drawn from the product instead, so it can see the absence.

Lesson 4 shows a case where this fires on a perfectly ordinary order, and it is not the case you would guess.

Three honest gaps

There is no strike-off requirement, and no shipping-mark requirement. The catalogue holds lab dips and samples and nothing else. A print approval is a first-class kind, with its own team, its own form fields and its own place in the queue, and it will never appear in a required list. On a printed style like STY-214 that matters. The only thing that can put the print approval in front of somebody is a Time and Action milestone, or a person remembering.

The carry rule is computed and never shown. Every requirement row carries a policy saying whether a style-level approval may be offered as satisfying an order's requirement. PP, TOP and pack presentation are marked never. The order panel does not print it. The rule is real, the screen is silent, and the practice has to come from you.

A requirement is not a task. It has no owner, no date and no row in any queue. A style can show a complete required list and contribute nothing at all to the Sampling screen, because that screen lists records and this list is drawn. Nobody is chased for a requirement. They are chased for a milestone, and lesson 4 is about those.

Two rules to take away

Read the required list as the question and the evidence as the answer. They are drawn from different places and neither can substitute for the other. A required list with no evidence is an honest empty. Evidence with no required list is work nobody asked for.

Check the amber line before you check the count. A count of approvals out of requirements looks reassuring. It says nothing about whether anybody was ever given a date for the ones that are missing.

Help me tell two things apart for one order: the approvals it must get, and the approvals it actually has.

I will paste, or describe: the garment and how it is made — cut from cloth, knitted from yarn, knitted to shape, and whether it ships as a multipack; the colours it comes in; and every approval record I can find for it, with the status of the latest round on each.

First, build the required list from the product alone, before you look at anything I have recorded. Split it into approvals that judge the specification and approvals that judge this production run, and say which of the two each belongs to. For a multipack, ask me whether the packing instruction really says so, rather than guessing from the style's name.

Second, put the evidence beside it. For every required approval, state one of exactly four things and use these words: approved, in progress, nothing recorded, or not applicable. Treat a round sitting with the buyer as in progress, never as done.

Third, list separately the required approvals that nobody has been given a date for, and say who should own each.

Fourth, name any approval I recorded that is not on the required list, and ask me why it exists. It may be a real requirement my product description missed.

One rule above all. Never report a requirement as satisfied because nothing contradicts it. Absence of a record is nothing recorded, and you must say so in those words.