Six client engagements, grouped by what the customer is actually buying. Certainty is one product; each of these is a different thing done with it, at a different site, with its own hardware and its own idea of what counts as a defect. What the product itself is lives on The product.
Defect detection
Spotting a flaw on the product itself as it is made — a mark, a misprint, a tear, a break. The bulk of what Certainty is sold for.
Catching defects in plastic film as it runs off the line, using two line-scan cameras watching at production speed. Sold as a pilot first, then a production installation if the pilot passes.
| The defect that matters | Meniscus breaks — the film tearing — in both the machine direction and across it, down to a 2 mm threshold. |
| Line speed | Tests run at 500 metres a minute, which is what makes this a line-scan job rather than an ordinary camera job. |
| How it ends | A formal Polyplex acceptance sign-off. The epic contains the acceptance ticket, so the finish line is written down — which is more than most of this board has. |
Worth knowing: The largest single epic on the board, 154 tickets, and not one of them started. 150 of them have no assignee. It is fully planned and entirely unstaffed, which is a different problem from being behind.
Source: Derived from the epic's own tickets, read 2026-09-14.
Print-quality inspection on garments: checking that what was printed matches what should have been printed, and that the labels are present and in the right place.
| What it checks | Garment colour confirmation, hologram label presence and position, registration errors — where the print layers do not line up — and blur. |
| The second epic | Dynamic Defect Types (INTEL-296) belongs to the same customer: letting Stakes add new defect categories themselves without waiting for a software release. It is a product capability that this customer is paying to bring forward. |
Worth knowing: All 23 tickets sit in Backlog rather than To Do, so this work is not even queued, and none of it is assigned.
Source: Derived from the two epics' tickets, read 2026-09-14.
Inspecting the clear cellophane wrap on cigarette cartons as they come down the line, and rejecting the bad ones automatically.
| The defects, customer-confirmed | Unacceptable wrinkles, tears and rips, damage to the wrap, and — added at the plant visit — crushed and deformed cartons. |
| Rate | 80 to 100 cartons a minute. The 16,000-a-minute figure that has been quoted is cigarettes per making machine, not cartons: 20 to a pack, 10 packs to a carton. |
| Today versus wanted | A Keyence line-scan rig images the top only. Reynolds wants all six sides including the bottom, and there is a break in the conveyor where a bottom camera could sit — which may remove the flip mechanism we had assumed. |
| Reject mechanism | A PLC actuator off the conveyor, not an arm, triggered from the existing barcode scanner controls. |
| Scope fence, theirs | “We have other visual defects but for the purposes of this project, we will focus on cellophane only.” |
Worth knowing: Nobody has defined what makes a wrinkle unacceptable. That is the largest open software risk on this engagement, and it is a judgement call that has to come from Reynolds. The ~4,000 customer images requested as pass and fail buckets on 3 September are still being chased. Four inspection locations were confirmed on the plant visit; only one is scoped.
Source: Voltaire Gomez to Taylor, 2026-09-04, and Taylor's reply of 2026-09-07. Almost none of this is on the board: the epic holds five generic pipeline stories.
SOP monitoring
Watching a person carry out a written procedure and checking each step was done, rather than inspecting the product afterwards.
Watching that a written work procedure is actually followed on the floor, across several cameras, and judging each step as well as the job overall.
| Three epics, one customer | INTEL-43 “Bobrick VAAV”, INTEL-345 and INTEL-346 all exist. Between them they hold two bug tickets. Which one is live has never been settled. |
| Where the real work is | Outside all three: INTEL-249 (send the Bobrick SOP monitoring document, UI and workflow) and INTEL-168 are unparented tasks. The engagement is more active than its epics suggest. |
Worth knowing: The three epics should be merged into one before anyone reads progress off them. As they stand, two are marked Done because the single bug in each was fixed, which makes this customer look finished.
Source: Derived from the three epics and the unparented Bobrick tickets, read 2026-09-14.
Measurement
Measuring a physical part against its drawing — sizes, hole positions, distances — rather than judging how it looks.
Measuring steel plates with a 3D laser profiler: hole diameters, the distances between holes, and their positions — then comparing each against its ideal value and returning pass or fail.
| How it works | Measurements are taken from a point cloud rather than a photograph, which is what makes it measurement rather than inspection. |
| Status | A proof of concept, and the only customer engagement on the board that is genuinely finished — all eight tickets done. |
Worth knowing: Worth knowing what happened next: a completed proof of concept with nothing following it is either a won deal nobody recorded or a demo that went nowhere, and the board does not say which.
Source: Derived from the epic's own tickets, read 2026-09-14.
Counting and verification
Confirming what is physically present against what the paperwork says: how many, of what, and whether the right items are in the right order.
Cameras at the goods receiving and shipping docks, checking what physically arrives and leaves against what the order says.
| What exists | Receiving Station and Shipping Station screen designs, plus imaging and model training stories. A workflow and screen mockups were produced on 2026-09-09. |
| Since decided | Scope simplified to local-only data storage, to bring the build cost down. |
Worth knowing: Two things are unresolved and both are load-bearing. Whether Reliant's orders are serialised handsets or bulk accessories — which decides whether the system has to read serial numbers at all — was asked of Voltaire on 2026-09-07 and has no recorded answer. And the sizing is 379.9 story points at a velocity of 6.43, which carries no unit: 379.9 divided by 6.43 is 59 of something, and whether that is days, weeks or sprints changes the answer completely.
How sure we are: The capability above is a working classification, not a confirmed one. Counting and verification is the best fit for dock work against an order, but the tickets never say what the cameras must read, and the serial-number question is exactly what would settle it. If the answer is serialised handsets this stays counting and verification; if the work turns out to be checking condition on arrival it is closer to defect detection.
Source: Soumen's workflow of 2026-09-09; the management review of 2026-09-10; Taylor's unsent draft reply to Voltaire.