One record, three jobs

In Session 10 you built the operator screen for the first-off check on Line 3 of Acme's press shop (an illustrative plant). Each check is now a row in the database. Two people need it next. The supervisor on the shift must decide, quickly, whether a check with a value outside its limits means stop and adjust the die, or whether it can stand. The manager must see, at a glance and without asking anyone, whether the press shop is starting its batches right, and what changed when it is not.

Neither surface needs new data. Both are views on the same records under the same Role and Exposure Matrix from Session 6. The supervisor's role may write a review; the manager's role may read totals; neither may edit what the operator entered. That is what makes the numbers trustworthy.

How it is scored

The element is complete when you have opened every chapter and taken the assessment, and passed at 80% or more. Homework 3 (three surfaces) is due at the end of week 4; this element and Session 10 together cover it.

What review is for

Without a review step, every entry goes straight into the charts, including the mis-tap and the check done on the wrong press. With a review step that only says approve or reject, supervisors approve everything because the screen gives them nothing to judge by. A good review queue makes the decision easy and the record of it permanent.

Show the difference

The card shows each measure, the value entered, the limits from the drawing and the difference, computed by the server. Values inside their limits stay quiet. A value outside is the only thing in colour, with the amount and direction in words: +0.11 above limit. The last result on the same press sits underneath, because a sudden jump means something different from a slow drift.

Keep every decision

Each decision is a new row in a reviews table: which record, who decided, what, why and when. Nobody can change or delete a review. The current state of a check is simply its latest review. Regulated manufacturers will recognise this: the FDA's rule for electronic records requires secure, computer-generated, time-stamped audit trails that record who did what and when, where a change never hides the earlier entry ^[1], and its data integrity guidance asks that records be attributable, legible, contemporaneous, original and accurate (ALCOA) ^[2]. Even outside regulated industries it is the right design: a decision nobody can trace is a decision nobody owns.

create table first_off_reviews (
  id          uuid primary key default gen_random_uuid(),
  check_id    uuid not null references first_off_checks(id),
  reviewer    uuid not null default auth.uid(),
  decision    text not null check (decision in ('approved', 'rejected', 'concession')),
  reason      text,
  decided_at  timestamptz not null default now(),
  check (decision = 'approved' or length(trim(coalesce(reason, ''))) >= 5)   -- a reject or concession says why
);
alter table first_off_reviews enable row level security;

-- Insert only: a supervisor approves or rejects, a quality engineer grants a concession, never on their own check. No update or delete policy exists.
create policy review_others on first_off_reviews for insert to authenticated with check (
  reviewer = auth.uid()
  and ((decision <> 'concession' and has_role('supervisor'))         -- has_role() is generated from the matrix in Session 7
       or (decision = 'concession' and has_role('quality_engineer')))
  and exists (select 1 from first_off_checks c where c.id = check_id and c.entered_by <> auth.uid())
);

With row-level security on and no policy for update or delete, Postgres refuses both for signed-in users ^[3]. The check constraint makes a reason compulsory for a rejection or a concession, in the database, where no screen can skip it.

Separation of duties

The person who enters a record must not be the person who approves it. Security frameworks call this separation of duties: dividing a task so no one person can complete it alone ^[4]. Hiding the Approve button on your own entries is not enough, because anyone can send a request without the button. The rule belongs in the database, as in the policy above, and a test proves it: sign in as the operator, try to review your own check, expect a refusal.

Routing and waiting time

A queue that grows unseen is worse than no queue. Show each supervisor the checks for their shift and lines first (routing by shift or line is the exemplary level of Homework 3), sort the oldest at the top, and show how long each has waited. Put the age of the oldest waiting check on the manager board too: if checks wait longer than the time it takes to run a batch, the review is happening after the parts are made.

Start from the intent

Session 2's intent names the decision and the data it needs. Acme's manager decides each week which press needs die maintenance first, from first-pass yield on first-off checks and rejected checks by press. So the board shows first-pass yield against target, first-off checks done against due, and how long checks are waiting for review. It does not show every field in the table. A dashboard, in the sense the visualisation literature uses, is the most important information needed for one or more objectives, arranged on one screen so it can be monitored at a glance ^[1]. If a measure does not change a decision, it belongs in a report, not on the board.

Tiles that read at a glance

Colour follows the same rule as the operator surface: quiet when normal, colour only when something needs attention, and never colour alone, because WCAG requires that colour is not the only way information is conveyed ^[2]. Lean plants have used the same idea for decades with andon boards: a signal anyone on the floor can read from a distance that says where help is needed ^[3].

Readable from across the room

The letter-height rule from Session 10 applies with a longer distance. At 22 minutes of arc, a capital letter must be about the viewing distance divided by 156: 19 mm at 3 m, 38 mm at 6 m. On a board read across a control room, that means one number per tile and very few words. Test it the same way: put the board where it will hang, stand where people will stand, and read every tile aloud.

Refresh on its own

A board that needs someone to press refresh shows yesterday. Two ways keep it fresh:

Whichever you choose, show updated 20 s ago on the board, and grey the whole board with the words Not updating if the stamp is older than three refresh periods. A frozen board that looks live is worse than a blank one. On a wall display, the Screen Wake Lock API keeps the screen from sleeping while the page is open ^[6].

Not every dip is news

Every process varies. If the board turns red each time first-pass yield dips half a point, people learn to ignore it, or worse, chase noise. Statistical process control, which Walter Shewhart developed in the 1920s, separates common-cause variation, the ordinary scatter of a stable process, from special-cause variation, a real change with a reason worth finding ^[1]. The tool is the control chart: the data in time order, with a centre line at the mean and control limits, usually three standard deviations either side ^[2].

Control limits are not specification limits

A point outside the control limits but inside specification is still a signal: the process has moved, and it will make bad parts if nobody looks. A process whose control limits sit outside the specification will make bad parts however carefully it is run, and the answer is to change the process, not to inspect harder. The NIST/SEMATECH handbook gives the rules for reading control charts, starting with the simplest: a single point beyond three standard deviations ^[2].

Say what changed

The exemplary level of Homework 3 asks the manager view to show the trend and what changed it. Keep a small table of process events (die change, new material lot, maintenance done, new operator on the press), entered where they happen, and draw them on the trend as labelled lines. A manager who sees yield fall right after the new coil lot asks the supplier the right question in one meeting instead of three.

create table process_events (
  id          uuid primary key default gen_random_uuid(),
  line        text not null,          -- the ISA-95 names from Session 5
  press       text,
  kind        text not null check (kind in ('die_change', 'material_lot', 'maintenance', 'other')),
  note        text not null,
  happened_at timestamptz not null,
  entered_by  uuid not null default auth.uid()
);
alter table process_events enable row level security;