What Certainty is, and how far up it we have built
Certainty lets a factory point cameras at its production line and have a machine judge the work — spotting defects, measuring parts, or checking that a person followed the written procedure. One installation sits in each factory. What is being built now is the layer above that: a back end that can run, update and watch every customer from one place, instead of each site being an island somebody has to drive to.
The platform
Certainty Core In test
The inspection engine that sits in the factory. It talks to the cameras, the lasers and the machines on the line, runs the inspection, and decides pass or fail.
The single most complete thing on the board, and the reason a demo can be given at all.
Where this definition comes from: Derived from its 49 tickets — OPC UA, SCADA, 3D profilers, the defect-detection pipeline — and matches the architecture review's description of a .NET service on the plant machine.
Code: Code exists — Found in the repositories by the architecture review.
Epics: INTEL-38
In the plan: M3 · Tenant and entitlement — 0 of 20 done, 72h, which also builds Entitlement service, Multi-tenant setup; M4 · Remote monitoring and fault reporting — 0 of 27 done, 97h, which also builds Observability; M2 · Transport security, key escrow and the recipe boundary — 0 of 30 done, 126h, which also builds Certainty Client, Key escrow. open the 77 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
- INTEL-104 [kunald-intelgic] Activity LogDone
- INTEL-143 Vision pipeline exec()s Python named by a recipe, and the comment callTo Do
- INTEL-144 Seventeen unbound names in authored Python -- NameError at runtime in Done
- INTEL-145 flutter_web/ is 40MB of committed build output and the application bunDone
- INTEL-147 No CI -- fourth repository, fourth time, and this one has the most to Done
- INTEL-148 Restore is not reproducible -- no SDK pin, no lockfile, and four declaDone
- INTEL-149 174 build warnings, including 132 platform-compatibility warnings agaiTo Do
- INTEL-150 Losing sqlite-key.enc makes the encrypted database permanently unreadaDone
- INTEL-151 No Python lint configuration exists, so there is no agreed standard toTo Do
- INTEL-152 Only a dev branch exists -- the three-branch model has not reached thiDone
- INTEL-153 About 152MB of vendor SDK binaries committed to gitTo Do
- INTEL-154 Swagger unauthenticated when enabled, BOM breaks .gitattributes, orphaTo Do
- INTEL-244 Activity LogPush to Dev
- INTEL-259 Hardware ManagementPush to Dev
- and 35 more
The vision and AI stack Not on the board
The part that actually looks at the picture: the models that spot a defect, read a label, or measure a part. It runs on the plant machine, not in the cloud.
No epic covers it. It is built, and invisible on the board — so a chart of tickets understates how much of the product exists.
Where this definition comes from: audits/target-architecture/APP-SUMMARY-PROPOSED.md — OpenCV, YOLO/ONNX, SAM2, PaddleOCR, plus local Ollama, RAG and Whisper.
Code: Code exists — Found in the repositories by the architecture review.
In the plan: M7 · Reaching inward: remote command and local AI access — 0 of 19 done, 68h, which also builds Remote update and command. open the 19 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
The plant's own database Not on the board
Everything the site records — inspections, recipes, users, machines — held in an encrypted database on the plant machine. Forty tables.
Two additions are needed and neither exists: a customer id on every record, and an outbox so results can be sent onward safely.
Where this definition comes from: APP-SUMMARY-PROPOSED.md §3.2, verified against the code.
Code: Exists, needs changing — Code is there; this programme changes it.
In the plan: M5 · Outbox, retention and the thin vertical slice — 0 of 18 done, 67h, which also builds API Gateway, Analytics. open the 18 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
Certainty Client In test
The app the operator uses on the factory floor — the screens for running an inspection, seeing results and administering the site.
Carries the security work: today it talks to Core in cleartext over the plant network.
Where this definition comes from: Derived from its 21 tickets — the site admin dashboard, robotics movement and capture points — plus the architecture review, which identifies it as a Flutter app served from Core.
Code: Code exists — Found in the repositories by the architecture review.
Epics: INTEL-39
In the plan: M1 · Critical remediation and distribution unblock — 0 of 21 done, 66h, which also builds Certainty Web; M2 · Transport security, key escrow and the recipe boundary — 0 of 30 done, 126h, which also builds Certainty Core, Key escrow; REL - Release and distribution — 0 of 17 done, 63h, which also builds Licence Portal, Remote update and command. open the 68 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
- INTEL-106 Live plant credentials committed to the repository (incomplete scrub)Done
- INTEL-107 develop fails flutter analyze and 2 tests; broken import hides 9 test Testing
- INTEL-108 Release builds signed with the public Android debug keystore -- blocksTesting
- INTEL-109 Cleartext HTTP globally enabled; credentials and imagery readable on tDone
- INTEL-110 Web builds store the JWT and device clientSecret in plaintext localStoTesting
- INTEL-111 Secret-hygiene gaps: .gitignore misses the paths the project's own docDone
- INTEL-112 No CI has ever existed, while a working quality gate sits unwiredDone
- INTEL-113 Test coverage 28.49%, concentrated not targeted; suite requires a liveTo Do
- INTEL-114 Two live UI defects: stale values submitted silently, and an orphaned To Do
- INTEL-115 Documentation and governance drift: authoritative docs point at contenDone
- INTEL-116 Auth model gaps: device-scoped WebSocket auth and fail-open session vaDone
- INTEL-117 Architecture and dependency debt (non-blocking)Done
- INTEL-156 Admin dashboards render hardcoded sample data with nothing in the UI tTo Do
- INTEL-314 Client imaging screen dynamic renderingTesting
- and 7 more
Licence Portal Not on the board
Where Intelgic issues and manages customer licences — who has bought what, how many machines they may run it on.
Its epic is marked Done with no tickets underneath it at all. The licence work is really happening inside Certainty Web.
Where this definition comes from: APP-SUMMARY-PROPOSED.md — a Flutter web app against the entitlement service.
Code: Code exists — Found in the repositories by the architecture review.
Epics: INTEL-205
In the plan: M10 · Cloud control plane: admin, tenancy and payment status — 0 of 24 done, 72h, which also builds API Gateway, Who is allowed to do what; REL - Release and distribution — 0 of 17 done, 63h, which also builds Certainty Client, Remote update and command. open the 41 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
API Gateway Not started
The single front door everything else talks through. Nothing reaches the cloud without passing it.
Where this definition comes from: Derived from its 3 tickets, all of which are design rather than build, and APP-SUMMARY-PROPOSED.md §2.
Code: Does not exist yet — No code in any repository.
Epics: INTEL-294
In the plan: M10 · Cloud control plane: admin, tenancy and payment status — 0 of 24 done, 72h, which also builds Licence Portal, Who is allowed to do what; M5 · Outbox, retention and the thin vertical slice — 0 of 18 done, 67h, which also builds Analytics, The plant's own database. open the 42 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
- INTEL-305 Design the API Gateway architectureTo Do
- INTEL-306 Build the Gateway with authentication readyTo Do
- INTEL-307 Make the Gateway observable and safe to operateTo Do
Multi-tenant setup Not on the board
Keeping each customer's data and access separate inside one shared back end. Without it, one back end cannot safely serve two customers.
There is no epic and no ticket for this anywhere on the board. It is a blocker that is currently invisible in every progress figure.
Where this definition comes from: Named by Lindsey as a precondition for deploying: “The multi-tenant is set up so we can deploy. And then we can start pushing the servers.”
Code: Does not exist yet — No code in any repository.
In the plan: M3 · Tenant and entitlement — 0 of 20 done, 72h, which also builds Certainty Core, Entitlement service. open the 20 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
Entitlement service Not on the board
The system of record for licences and seats — which machines are allowed to run Certainty, and how many.
Built, and tracked under Certainty Web rather than under the Licence Portal epic.
Where this definition comes from: APP-SUMMARY-PROPOSED.md §3.1 — eight tables today, verified from the database migrations.
Code: Exists, needs changing — Code is there; this programme changes it.
In the plan: M3 · Tenant and entitlement — 0 of 20 done, 72h, which also builds Certainty Core, Multi-tenant setup. open the 20 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
Analytics Not on the board
Inspection history kept beyond what the plant machine can hold, one database per customer, so trends can be asked about over months.
Where this definition comes from: APP-SUMMARY-PROPOSED.md §3.3, carried from Intelgic's own architecture as a customer commitment.
Code: Does not exist yet — No code in any repository.
In the plan: M5 · Outbox, retention and the thin vertical slice — 0 of 18 done, 67h, which also builds API Gateway, The plant's own database; M6 · Analytics service — 0 of 19 done, 74h. open the 37 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
Observability Not on the board
Knowing that a plant machine is healthy, and being told when it is not, without phoning the customer.
Where this definition comes from: APP-SUMMARY-PROPOSED.md §2 — logs, metrics and fault grouping.
Code: Does not exist yet — No code in any repository.
In the plan: M4 · Remote monitoring and fault reporting — 0 of 27 done, 97h, which also builds Certainty Core. open the 27 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
Remote update and command Not on the board
Sending a new version or an instruction to a site without anyone travelling there. The plant asks the cloud for work; the cloud never reaches in.
This is the capability the whole back-end push is for.
Where this definition comes from: APP-SUMMARY-PROPOSED.md decision 5.5. Taylor: “the front ends aren't even installed to where we can remote deploy at all.”
Code: Awaiting a decision — Design decision recorded, not yet made.
In the plan: M7 · Reaching inward: remote command and local AI access — 0 of 19 done, 68h, which also builds The vision and AI stack; REL - Release and distribution — 0 of 17 done, 63h, which also builds Certainty Client, Licence Portal. open the 36 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
Fleet management Not on the board
Seeing every customer site at once — which are healthy, which are behind, which need attention — rather than one at a time.
Where this definition comes from: audits/target-architecture/MOTHERSHIP-HOW-IT-WORKS.md. Scoped as Engagement 2, which has not been bought.
Code: Does not exist yet — No code in any repository.
In the plan: no milestone covers this, because it is Engagement 2 work and Engagement 2 has not been bought — so a zero here is a commercial fact, not a team that is behind.
No developer ticket on the board tracks this one. The plan line above is what there is.
What may leave a customer's site Not on the board
An explicit gate deciding what data is allowed to leave a factory. The stated commitment is that defect information may cross and pictures never do.
Where this definition comes from: MOTHERSHIP-HOW-IT-WORKS.md and APP-SUMMARY-TARGET.md.
Code: Does not exist yet — No code in any repository.
In the plan: no milestone covers this, because it is Engagement 2 work and Engagement 2 has not been bought — so a zero here is a commercial fact, not a team that is behind.
No developer ticket on the board tracks this one. The plan line above is what there is.
Every piece, floor by floor
The inspection engine that sits in the factory. It talks to the cameras, the lasers and the machines on the line, runs…
Certainty Core In test
The inspection engine that sits in the factory. It talks to the cameras, the lasers and the machines on the line, runs the inspection, and decides pass or fail.
The single most complete thing on the board, and the reason a demo can be given at all.
Where this definition comes from: Derived from its 49 tickets — OPC UA, SCADA, 3D profilers, the defect-detection pipeline — and matches the architecture review's description of a .NET service on the plant machine.
Code: Code exists — Found in the repositories by the architecture review.
Epics: INTEL-38
In the plan: M3 · Tenant and entitlement — 0 of 20 done, 72h, which also builds Entitlement service, Multi-tenant setup; M4 · Remote monitoring and fault reporting — 0 of 27 done, 97h, which also builds Observability; M2 · Transport security, key escrow and the recipe boundary — 0 of 30 done, 126h, which also builds Certainty Client, Key escrow. open the 77 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
- INTEL-104 [kunald-intelgic] Activity LogDone
- INTEL-143 Vision pipeline exec()s Python named by a recipe, and the comment callTo Do
- INTEL-144 Seventeen unbound names in authored Python -- NameError at runtime in Done
- INTEL-145 flutter_web/ is 40MB of committed build output and the application bunDone
- INTEL-147 No CI -- fourth repository, fourth time, and this one has the most to Done
- INTEL-148 Restore is not reproducible -- no SDK pin, no lockfile, and four declaDone
- INTEL-149 174 build warnings, including 132 platform-compatibility warnings agaiTo Do
- INTEL-150 Losing sqlite-key.enc makes the encrypted database permanently unreadaDone
- INTEL-151 No Python lint configuration exists, so there is no agreed standard toTo Do
- INTEL-152 Only a dev branch exists -- the three-branch model has not reached thiDone
- INTEL-153 About 152MB of vendor SDK binaries committed to gitTo Do
- INTEL-154 Swagger unauthenticated when enabled, BOM breaks .gitattributes, orphaTo Do
- INTEL-244 Activity LogPush to Dev
- INTEL-259 Hardware ManagementPush to Dev
- and 35 more
The part that actually looks at the picture: the models that spot a defect, read a label, or measure a part. It runs o…
The vision and AI stack Not on the board
The part that actually looks at the picture: the models that spot a defect, read a label, or measure a part. It runs on the plant machine, not in the cloud.
No epic covers it. It is built, and invisible on the board — so a chart of tickets understates how much of the product exists.
Where this definition comes from: audits/target-architecture/APP-SUMMARY-PROPOSED.md — OpenCV, YOLO/ONNX, SAM2, PaddleOCR, plus local Ollama, RAG and Whisper.
Code: Code exists — Found in the repositories by the architecture review.
In the plan: M7 · Reaching inward: remote command and local AI access — 0 of 19 done, 68h, which also builds Remote update and command. open the 19 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
Photographs each part several times at different brightnesses, so a shiny or dark surface is still readable. Without i…
Dynamic camera exposure In progress
Photographs each part several times at different brightnesses, so a shiny or dark surface is still readable. Without it, half the defects are invisible to the camera.
Nearly finished. No architecture document mentions it at all.
Where this definition comes from: Derived from its 15 tickets — the exposure bracket planner, and showing one representative frame per bracket rather than all of them.
Code: Code exists — Found in the repositories by the architecture review.
Epics: INTEL-321
In the plan: no milestone in the estimate maps to this component, so the plan says nothing about it either way. Whether that is a gap in the estimate or work genuinely outside it has not been settled.
- INTEL-334 Fix captures-root path traversal guard in imaging endpointsDone
- INTEL-335 Frame-level exposure telemetry on the MindVision capture pathDone
- INTEL-336 ExposureBracketPlanner — pure ladder computation, unit testedDone
- INTEL-337 MindVisionBracketRunner and BracketOptionsDone
- INTEL-338 Capture sidecar schema v2 with exposure and bracket blocksDone
- INTEL-339 Consolidate the two history implementations, then extend once for bracDone
- INTEL-340 Imaging capabilities endpoint and the bracket_capture socket routeDone
- INTEL-341 Write the imaging bracket protocol spec for the Flutter repoDone
- INTEL-354 Move the bracket trigger from the client to an imaging-bracket.json flDone
- INTEL-357 A stale frame latches the confirm countdown, so SettleConfirmFrames reDone
- INTEL-358 A bracket rung whose target equals the camera's current exposure neverDone
- INTEL-360 A bracket refused as camera_busy falls back to a frame another bracketDone
- INTEL-361 Test client's exposure-restore verdict reads an un-awaited capabilitieDone
- INTEL-362 StopCameraAsync destroys a MindVision settings session before checkingTo Do
- and 7 more
Watches a person carry out a written procedure across several cameras and judges each step, then the job as a whole. T…
SOP monitoring In progress
Watches a person carry out a written procedure across several cameras and judges each step, then the job as a whole. This is the capability Bobrick is buying.
Where this definition comes from: Derived from its 4 tickets — multi-camera integration, a multi-region rule engine, and a runtime screen with step-wise and final decisions.
Code: Code exists — Found in the repositories by the architecture review.
Epics: INTEL-295
In the plan: no milestone in the estimate maps to this component, so the plan says nothing about it either way. Whether that is a gap in the estimate or work genuinely outside it has not been settled.
- INTEL-308 Multi-camera integration with the SOP pipelineDone
- INTEL-309 Multi-model integration with the SOP pipelineDone
- INTEL-310 Multi-camera, multi-region, multi-detection rule engineTo Do
- INTEL-311 Multi-feed runtime screen with step-wise and final decisionsTo Do
Everything the site records — inspections, recipes, users, machines — held in an encrypted database on the plant machi…
The plant's own database Not on the board
Everything the site records — inspections, recipes, users, machines — held in an encrypted database on the plant machine. Forty tables.
Two additions are needed and neither exists: a customer id on every record, and an outbox so results can be sent onward safely.
Where this definition comes from: APP-SUMMARY-PROPOSED.md §3.2, verified against the code.
Code: Exists, needs changing — Code is there; this programme changes it.
In the plan: M5 · Outbox, retention and the thin vertical slice — 0 of 18 done, 67h, which also builds API Gateway, Analytics. open the 18 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
The app the operator uses on the factory floor — the screens for running an inspection, seeing results and administeri…
Certainty Client In test
The app the operator uses on the factory floor — the screens for running an inspection, seeing results and administering the site.
Carries the security work: today it talks to Core in cleartext over the plant network.
Where this definition comes from: Derived from its 21 tickets — the site admin dashboard, robotics movement and capture points — plus the architecture review, which identifies it as a Flutter app served from Core.
Code: Code exists — Found in the repositories by the architecture review.
Epics: INTEL-39
In the plan: M1 · Critical remediation and distribution unblock — 0 of 21 done, 66h, which also builds Certainty Web; M2 · Transport security, key escrow and the recipe boundary — 0 of 30 done, 126h, which also builds Certainty Core, Key escrow; REL - Release and distribution — 0 of 17 done, 63h, which also builds Licence Portal, Remote update and command. open the 68 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
- INTEL-106 Live plant credentials committed to the repository (incomplete scrub)Done
- INTEL-107 develop fails flutter analyze and 2 tests; broken import hides 9 test Testing
- INTEL-108 Release builds signed with the public Android debug keystore -- blocksTesting
- INTEL-109 Cleartext HTTP globally enabled; credentials and imagery readable on tDone
- INTEL-110 Web builds store the JWT and device clientSecret in plaintext localStoTesting
- INTEL-111 Secret-hygiene gaps: .gitignore misses the paths the project's own docDone
- INTEL-112 No CI has ever existed, while a working quality gate sits unwiredDone
- INTEL-113 Test coverage 28.49%, concentrated not targeted; suite requires a liveTo Do
- INTEL-114 Two live UI defects: stale values submitted silently, and an orphaned To Do
- INTEL-115 Documentation and governance drift: authoritative docs point at contenDone
- INTEL-116 Auth model gaps: device-scoped WebSocket auth and fail-open session vaDone
- INTEL-117 Architecture and dependency debt (non-blocking)Done
- INTEL-156 Admin dashboards render hardcoded sample data with nothing in the UI tTo Do
- INTEL-314 Client imaging screen dynamic renderingTesting
- and 7 more
Named as the browser version of Core's screens. Most of its work so far has been the security tightening the platform …
Certainty Web In test
Named as the browser version of Core's screens. Most of its work so far has been the security tightening the platform needed — closing the findings from the code audit — plus the licence back end.
The security work was necessary and is real progress. The care needed is only in reading the number: this epic is the closest to done on the board, and that is hardening finished, not the web product finished.
Where this definition comes from: Derived from its tickets: of 32, only INTEL-48 is about web screens; the rest are audit remediation and licensing.
Code: Exists, needs changing — Code is there; this programme changes it.
Epics: INTEL-40
In the plan: M1 · Critical remediation and distribution unblock — 0 of 21 done, 66h, which also builds Certainty Client. open the 21 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
- INTEL-118 Application does not build -- CardTheme/CardThemeData type error blockDone
- INTEL-119 No SDK pin; declared Dart constraint understates what actually resolveDone
- INTEL-120 pubspec.lock contradicts pubspec.yaml -- SSO removal was half-completeDone
- INTEL-121 Test suite: 32 pass, 37 fail; one file never loads; tests assert removDone
- INTEL-122 Session identity and role are read from browser storage without serverDone
- INTEL-123 /admin route has no role guard; any authenticated user can load the adDone
- INTEL-124 Public registration accepts an arbitrary role on an unauthenticated enDone
- INTEL-125 No CI, no analysis_options.yaml, and bin/eh does not existTo Do
- INTEL-126 Token refresh is broken and never invoked; no 401 handling anywhereDone
- INTEL-127 Tokens stored in browser localStorage on web, with no CSPDone
- INTEL-128 .env ships as a public web asset, and the house docs teach putting APIDone
- INTEL-129 eng-os/ governance was copied from certainty-client and describes a diDone
- INTEL-130 Correctness bugs: customer list crash, stubbed validation shipped as aDone
- INTEL-131 Dead code, hardcoded colours, doc drift, and committed generated filesDone
- and 18 more
Where Intelgic issues and manages customer licences — who has bought what, how many machines they may run it on.
Licence Portal Not on the board
Where Intelgic issues and manages customer licences — who has bought what, how many machines they may run it on.
Its epic is marked Done with no tickets underneath it at all. The licence work is really happening inside Certainty Web.
Where this definition comes from: APP-SUMMARY-PROPOSED.md — a Flutter web app against the entitlement service.
Code: Code exists — Found in the repositories by the architecture review.
Epics: INTEL-205
In the plan: M10 · Cloud control plane: admin, tenancy and payment status — 0 of 24 done, 72h, which also builds API Gateway, Who is allowed to do what; REL - Release and distribution — 0 of 17 done, 63h, which also builds Certainty Client, Remote update and command. open the 41 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
The product documentation a customer is given.
User manual Done on the board
The product documentation a customer is given.
Where this definition comes from: One ticket exists. Lindsey: “user manual, I'm not overly concerned with. That comes as you build a product.”
Code: Does not exist yet — No code in any repository.
Epics: INTEL-41
In the plan: no milestone in the estimate maps to this component, so the plan says nothing about it either way. Whether that is a gap in the estimate or work genuinely outside it has not been settled.
- INTEL-60 [MadhuSudanM-Intelgic] DOC: Certainty AI Tech DocDone
The single front door everything else talks through. Nothing reaches the cloud without passing it.
API Gateway Not started
The single front door everything else talks through. Nothing reaches the cloud without passing it.
Where this definition comes from: Derived from its 3 tickets, all of which are design rather than build, and APP-SUMMARY-PROPOSED.md §2.
Code: Does not exist yet — No code in any repository.
Epics: INTEL-294
In the plan: M10 · Cloud control plane: admin, tenancy and payment status — 0 of 24 done, 72h, which also builds Licence Portal, Who is allowed to do what; M5 · Outbox, retention and the thin vertical slice — 0 of 18 done, 67h, which also builds Analytics, The plant's own database. open the 42 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
- INTEL-305 Design the API Gateway architectureTo Do
- INTEL-306 Build the Gateway with authentication readyTo Do
- INTEL-307 Make the Gateway observable and safe to operateTo Do
Keeping each customer's data and access separate inside one shared back end. Without it, one back end cannot safely se…
Multi-tenant setup Not on the board
Keeping each customer's data and access separate inside one shared back end. Without it, one back end cannot safely serve two customers.
There is no epic and no ticket for this anywhere on the board. It is a blocker that is currently invisible in every progress figure.
Where this definition comes from: Named by Lindsey as a precondition for deploying: “The multi-tenant is set up so we can deploy. And then we can start pushing the servers.”
Code: Does not exist yet — No code in any repository.
In the plan: M3 · Tenant and entitlement — 0 of 20 done, 72h, which also builds Certainty Core, Entitlement service. open the 20 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
The system of record for licences and seats — which machines are allowed to run Certainty, and how many.
Entitlement service Not on the board
The system of record for licences and seats — which machines are allowed to run Certainty, and how many.
Built, and tracked under Certainty Web rather than under the Licence Portal epic.
Where this definition comes from: APP-SUMMARY-PROPOSED.md §3.1 — eight tables today, verified from the database migrations.
Code: Exists, needs changing — Code is there; this programme changes it.
In the plan: M3 · Tenant and entitlement — 0 of 20 done, 72h, which also builds Certainty Core, Multi-tenant setup. open the 20 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
Roles and permissions, enforced on the server rather than merely hidden in the app.
Who is allowed to do what In progress
Roles and permissions, enforced on the server rather than merely hidden in the app.
Where this definition comes from: Derived from its 12 tickets — seeing only what your role allows, enforcing roles server-side, and blocking deletion of a role that still has users.
Code: Does not exist yet — No code in any repository.
Epics: INTEL-293
In the plan: M10 · Cloud control plane: admin, tenancy and payment status — 0 of 24 done, 72h, which also builds API Gateway, Licence Portal; M8 · Identity standardisation — 0 of 18 done, 72h, which also builds Single sign-on. open the 42 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
- INTEL-301 Manage users and roles from within the clientTo Do
- INTEL-302 See only what my role allowsTo Do
- INTEL-303 Enforce roles on the server, not just in the UITo Do
- INTEL-304 Migrate existing users onto the role modelTo Do
- INTEL-503 Role-Based Permission Backend on Server SideIn Progress
Letting a customer's staff sign in with their own company login instead of another separate password.
Single sign-on In test
Letting a customer's staff sign in with their own company login instead of another separate password.
Where this definition comes from: Derived from its 4 tickets — one unified identity, and configuring an organisation's own identity provider.
Code: Does not exist yet — No code in any repository.
Epics: INTEL-292
In the plan: M8 · Identity standardisation — 0 of 18 done, 72h, which also builds Who is allowed to do what. open the 18 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
- INTEL-297 Sign in to the Certainty Client with a single, unified identityTesting
- INTEL-298 Configure an organization's own identity providerTesting
- INTEL-299 End a session cleanly, everywhere it existsTesting
- INTEL-300 Map SSO identities to Certainty user recordsTo Do
- INTEL-536 [Backend] Exchange an SSO id_token for a Certainty token (POST /auth/sTesting
- INTEL-542 [Backend] Harden SSO against token replay with a server-issued nonceTo Do
Inspection history kept beyond what the plant machine can hold, one database per customer, so trends can be asked abou…
Analytics Not on the board
Inspection history kept beyond what the plant machine can hold, one database per customer, so trends can be asked about over months.
Where this definition comes from: APP-SUMMARY-PROPOSED.md §3.3, carried from Intelgic's own architecture as a customer commitment.
Code: Does not exist yet — No code in any repository.
In the plan: M5 · Outbox, retention and the thin vertical slice — 0 of 18 done, 67h, which also builds API Gateway, The plant's own database; M6 · Analytics service — 0 of 19 done, 74h. open the 37 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
Knowing that a plant machine is healthy, and being told when it is not, without phoning the customer.
Observability Not on the board
Knowing that a plant machine is healthy, and being told when it is not, without phoning the customer.
Where this definition comes from: APP-SUMMARY-PROPOSED.md §2 — logs, metrics and fault grouping.
Code: Does not exist yet — No code in any repository.
In the plan: M4 · Remote monitoring and fault reporting — 0 of 27 done, 97h, which also builds Certainty Core. open the 27 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
Sending a new version or an instruction to a site without anyone travelling there. The plant asks the cloud for work; …
Remote update and command Not on the board
Sending a new version or an instruction to a site without anyone travelling there. The plant asks the cloud for work; the cloud never reaches in.
This is the capability the whole back-end push is for.
Where this definition comes from: APP-SUMMARY-PROPOSED.md decision 5.5. Taylor: “the front ends aren't even installed to where we can remote deploy at all.”
Code: Awaiting a decision — Design decision recorded, not yet made.
In the plan: M7 · Reaching inward: remote command and local AI access — 0 of 19 done, 68h, which also builds The vision and AI stack; REL - Release and distribution — 0 of 17 done, 63h, which also builds Certainty Client, Licence Portal. open the 36 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
A safe copy of the key that unlocks a plant database, so a dead machine does not take a customer's data with it.
Key escrow Not on the board
A safe copy of the key that unlocks a plant database, so a dead machine does not take a customer's data with it.
Where this definition comes from: APP-SUMMARY-PROPOSED.md decision 5.4.
Code: Awaiting a decision — Design decision recorded, not yet made.
In the plan: M2 · Transport security, key escrow and the recipe boundary — 0 of 30 done, 126h, which also builds Certainty Client, Certainty Core. open the 30 cards. None of them has been started yet. These counts belong to the milestone, not to this box on its own.
No developer ticket on the board tracks this one. The plan line above is what there is.
Seeing every customer site at once — which are healthy, which are behind, which need attention — rather than one at a …
Fleet management Not on the board
Seeing every customer site at once — which are healthy, which are behind, which need attention — rather than one at a time.
Where this definition comes from: audits/target-architecture/MOTHERSHIP-HOW-IT-WORKS.md. Scoped as Engagement 2, which has not been bought.
Code: Does not exist yet — No code in any repository.
In the plan: no milestone covers this, because it is Engagement 2 work and Engagement 2 has not been bought — so a zero here is a commercial fact, not a team that is behind.
No developer ticket on the board tracks this one. The plan line above is what there is.
An explicit gate deciding what data is allowed to leave a factory. The stated commitment is that defect information ma…
What may leave a customer's site Not on the board
An explicit gate deciding what data is allowed to leave a factory. The stated commitment is that defect information may cross and pictures never do.
Where this definition comes from: MOTHERSHIP-HOW-IT-WORKS.md and APP-SUMMARY-TARGET.md.
Code: Does not exist yet — No code in any repository.
In the plan: no milestone covers this, because it is Engagement 2 work and Engagement 2 has not been bought — so a zero here is a commercial fact, not a team that is behind.
No developer ticket on the board tracks this one. The plan line above is what there is.
Every piece, and how we know what it is
| Piece | What it is | Where it stands | Epic | Definition from |
|---|---|---|---|---|
| Certainty Core The platform — one of these per factory |
The inspection engine that sits in the factory. It talks to the cameras, the lasers and the machines on the line, runs the inspection, and decides pass or fail. |
In test Code exists |
INTEL-38 | Derived from its 49 tickets — OPC UA, SCADA, 3D profilers, the defect-detection pipeline — and matches the architecture review's description of a .NET service on the plant machine. |
| The vision and AI stack The platform — one of these per factory |
The part that actually looks at the picture: the models that spot a defect, read a label, or measure a part. It runs on the plant machine, not in the cloud. |
Not on the board Code exists |
none | audits/target-architecture/APP-SUMMARY-PROPOSED.md — OpenCV, YOLO/ONNX, SAM2, PaddleOCR, plus local Ollama, RAG and Whisper. |
| Dynamic camera exposure The platform — one of these per factory |
Photographs each part several times at different brightnesses, so a shiny or dark surface is still readable. Without it, half the defects are invisible to the camera. |
In progress Code exists |
INTEL-321 | Derived from its 15 tickets — the exposure bracket planner, and showing one representative frame per bracket rather than all of them. |
| SOP monitoring The platform — one of these per factory |
Watches a person carry out a written procedure across several cameras and judges each step, then the job as a whole. This is the capability Bobrick is buying. |
In progress Code exists |
INTEL-295 | Derived from its 4 tickets — multi-camera integration, a multi-region rule engine, and a runtime screen with step-wise and final decisions. |
| The plant's own database The platform — one of these per factory |
Everything the site records — inspections, recipes, users, machines — held in an encrypted database on the plant machine. Forty tables. |
Not on the board Exists, needs changing |
none | APP-SUMMARY-PROPOSED.md §3.2, verified against the code. |
| Certainty Client The people who use it |
The app the operator uses on the factory floor — the screens for running an inspection, seeing results and administering the site. |
In test Code exists |
INTEL-39 | Derived from its 21 tickets — the site admin dashboard, robotics movement and capture points — plus the architecture review, which identifies it as a Flutter app served from Core. |
| Certainty Web The people who use it |
Named as the browser version of Core's screens. Most of its work so far has been the security tightening the platform needed — closing the findings from the code audit — plus the licence back end. |
In test Exists, needs changing |
INTEL-40 | Derived from its tickets: of 32, only INTEL-48 is about web screens; the rest are audit remediation and licensing. |
| Licence Portal The people who use it |
Where Intelgic issues and manages customer licences — who has bought what, how many machines they may run it on. |
Not on the board Code exists |
INTEL-205 | APP-SUMMARY-PROPOSED.md — a Flutter web app against the entitlement service. |
| User manual The people who use it |
The product documentation a customer is given. |
Done on the board Does not exist yet |
INTEL-41 | One ticket exists. Lindsey: “user manual, I'm not overly concerned with. That comes as you build a product.” |
| API Gateway The cloud — the part that lets you run many customers at once |
The single front door everything else talks through. Nothing reaches the cloud without passing it. |
Not started Does not exist yet |
INTEL-294 | Derived from its 3 tickets, all of which are design rather than build, and APP-SUMMARY-PROPOSED.md §2. |
| Multi-tenant setup The cloud — the part that lets you run many customers at once |
Keeping each customer's data and access separate inside one shared back end. Without it, one back end cannot safely serve two customers. |
Not on the board Does not exist yet |
none | Named by Lindsey as a precondition for deploying: “The multi-tenant is set up so we can deploy. And then we can start pushing the servers.” |
| Entitlement service The cloud — the part that lets you run many customers at once |
The system of record for licences and seats — which machines are allowed to run Certainty, and how many. |
Not on the board Exists, needs changing |
none | APP-SUMMARY-PROPOSED.md §3.1 — eight tables today, verified from the database migrations. |
| Who is allowed to do what The cloud — the part that lets you run many customers at once |
Roles and permissions, enforced on the server rather than merely hidden in the app. |
In progress Does not exist yet |
INTEL-293 | Derived from its 12 tickets — seeing only what your role allows, enforcing roles server-side, and blocking deletion of a role that still has users. |
| Single sign-on The cloud — the part that lets you run many customers at once |
Letting a customer's staff sign in with their own company login instead of another separate password. |
In test Does not exist yet |
INTEL-292 | Derived from its 4 tickets — one unified identity, and configuring an organisation's own identity provider. |
| Analytics The cloud — the part that lets you run many customers at once |
Inspection history kept beyond what the plant machine can hold, one database per customer, so trends can be asked about over months. |
Not on the board Does not exist yet |
none | APP-SUMMARY-PROPOSED.md §3.3, carried from Intelgic's own architecture as a customer commitment. |
| Observability The cloud — the part that lets you run many customers at once |
Knowing that a plant machine is healthy, and being told when it is not, without phoning the customer. |
Not on the board Does not exist yet |
none | APP-SUMMARY-PROPOSED.md §2 — logs, metrics and fault grouping. |
| Remote update and command The cloud — the part that lets you run many customers at once |
Sending a new version or an instruction to a site without anyone travelling there. The plant asks the cloud for work; the cloud never reaches in. |
Not on the board Awaiting a decision |
none | APP-SUMMARY-PROPOSED.md decision 5.5. Taylor: “the front ends aren't even installed to where we can remote deploy at all.” |
| Key escrow The cloud — the part that lets you run many customers at once |
A safe copy of the key that unlocks a plant database, so a dead machine does not take a customer's data with it. |
Not on the board Awaiting a decision |
none | APP-SUMMARY-PROPOSED.md decision 5.4. |
| Fleet management The fleet — many plants, one view |
Seeing every customer site at once — which are healthy, which are behind, which need attention — rather than one at a time. |
Not on the board Does not exist yet |
none | audits/target-architecture/MOTHERSHIP-HOW-IT-WORKS.md. Scoped as Engagement 2, which has not been bought. |
| What may leave a customer's site The fleet — many plants, one view |
An explicit gate deciding what data is allowed to leave a factory. The stated commitment is that defect information may cross and pictures never do. |
Not on the board Does not exist yet |
none | MOTHERSHIP-HOW-IT-WORKS.md and APP-SUMMARY-TARGET.md. |
Who is buying what
One product, sold as four different capabilities. A customer sits in a bucket because of what their work actually is, not because of what the account is called.
| Capability | Customers, and tickets done |
|---|---|
| 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. | Polyplex 2/37 Stakes MFG 0/16 Reynolds Tobacco 0/5 |
| SOP monitoring Watching a person carry out a written procedure and checking each step was done, rather than inspecting the product afterwards. | Bobrick 2/2 |
| Measurement Measuring a physical part against its drawing — sizes, hole positions, distances — rather than judging how it looks. | Kalpataru 3/3 |
| 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. | Reliant Cellular 0/19 |
What the tickets do not say, and the correspondence does
Reynolds Tobacco Defect detection — cellophane wrap INTEL-348
Inspecting the clear wrap on cigarette cartons as they come down the line: unacceptable wrinkles, tears and rips, damage to the wrap, and — added at the plant visit — crushed and deformed cartons. The customer set their own fence: cellophane only, for this project.
Source: Voltaire Gomez to Taylor, 2026-09-04, and Taylor's reply of 2026-09-07.
Reliant Cellular Still genuinely open INTEL-206
A vision deployment at the goods receiving and shipping docks. A workflow and screen mockups exist, but the central question of what the cameras must read has not been answered.
Source: Soumen's workflow of 2026-09-09; management review 2026-09-10; the drafted reply to Voltaire, which has not been sent.
What the system captures, and what it keeps
What it captures
Images from the cameras, the result of each inspection, the recipe that was run, who was signed in, and the machine's own health. On the SOP side, video of a procedure being carried out.
APP-SUMMARY-PROPOSED.md §3.2 — the 40-table plant database.
What is allowed to leave a site
The stated commitment is defect and inspection metadata only. Imagery stays on the plant. That is a promise made to customers, and the gate that would enforce it has not been built yet.
APP-SUMMARY-TARGET.md; MOTHERSHIP-HOW-IT-WORKS.md.
What is kept, today
Everything, for ever. The system has no retention logic at all — the “about a week” figure in the architecture document is an intention, not a behaviour. A site's disk fills until somebody clears it by hand.
CONFORMANCE-RATIONALE.md §22; APP-SUMMARY-CURRENT.md.
What could be kept, once the cloud exists
Inspection history per customer, held long enough to answer questions across months rather than days — the basis for telling a customer their defect rate is falling.
APP-SUMMARY-PROPOSED.md §3.3 — one analytics database per customer.
The licensing database — what Intelgic knows about who bought what
A company that has bought Certainty.
- customer_id
- company_name
- country
- holds licenses
- employs users
A template: how many machines and how long.
- plan_id
- plan_name
- default_hosts
- default_expiry_days
- templates licenses
What one customer actually bought.
- license_id
- license_key
- customer_id
- total_hosts
- used_hosts
- expiry_date
- activated on license_hosts
- issues offline_activation_codes
One row per machine using a seat. The change that makes seat management possible at all.
- id
- license_id
- installation_id
- first_seen
- last_seen
- revoked_at
Activating a machine with no internet — normal in a factory.
- id
- activation_code
- license_id
- machine_id
A running installation and when it was last heard from. What the monitoring screens would read.
- installation_id
- customer_id
- core_version
- last_heartbeat
- claims license_hosts
- escrows to key_escrow
The safe copy of a site's database key.
- installation_id
- wrapped_key
- escrowed_at
What the plan says, and where that leaves us
The twelve milestones, and what each one builds
| Milestone | What it is | Scope | Its own stories | The platform parts it builds |
|---|---|---|---|---|
| M0 Skeletal |
CI, gating and reproducibility CI wiring in all four repositories, toolchain pinning, branch protection, CODEOWNERS and PR templates |
26 86h |
8 of these may duplicate existing tickets |
Not on the board Engineering process: CI, pinned toolchains and branch protection across the four repositories. It produces no new part of the product, which is exactly why it is first -- everything after it is safer to change. |
| M1 Skeletal |
Critical remediation and distribution unblock The four Critical findings, the failing test suites, the production runtime, dependency CVEs and the Android signing certificate |
21 66h |
11 of these may duplicate existing tickets |
In test Certainty Client Certainty Web |
| M9 Skeletal |
AWS account topology and federated access The AWS organisation, its four accounts, service control policies, the organisation audit trail, IAM Identity Center with its permission sets, per-env |
19 79h |
Not on the board Cloud account structure: the AWS organisation, its four accounts, the guardrails and federated access. Infrastructure the product sits on rather than a piece of the product. | |
| M3 Slim |
Tenant and entitlement license_hosts and seat management, signed entitlement at activation, customer_id in Core, feature gating, Core as an OS service, Entitlement Service A |
20 72h |
In progress Certainty Core Multi-tenant setup Entitlement service | |
| M4 Mid |
Remote monitoring and fault reporting Telemetry egress from Core, automatic fault capture in all four components, edge scrubbing, fault grouping, central aggregation, correlation ids, aler |
27 97h |
In progress Certainty Core Observability | |
| M10 Mid |
Cloud control plane: admin, tenancy and payment status The tenant-scoped admin API, client and user management served from the cloud, payment status recording and its derived view, repointing the four exis |
24 72h |
8 of these may duplicate existing tickets |
In progress Licence Portal API Gateway Who is allowed to do what |
| M2 High |
Transport security, key escrow and the recipe boundary mTLS on the Core API, client trust, SQLCipher key escrow and recovery, recipe signing and permission gating, and the two client token-lifecycle defect |
30 126h |
4 of these may duplicate existing tickets |
In progress Certainty Core Certainty Client Key escrow |
| M5 High |
Outbox, retention and the thin vertical slice Core outbox, outbound sync worker, acknowledgement-driven retention, backpressure, sync-lag alerting, gateway ingestion, one provisioned analytics dat |
18 67h |
2 of these may duplicate existing tickets |
Not started The plant's own database API Gateway Analytics |
| M6 High |
Analytics service Ingestion at volume, automated provisioning, retention per plan, reporting APIs, cross-database schema migration and the analytics dashboards |
19 74h |
2 of these may duplicate existing tickets |
Not started Analytics |
| M7 High |
Reaching inward: remote command and local AI access Command queue, command executor with a bounded vocabulary, read-only diagnostics first, per-capability consent, full command audit, and client access |
19 68h |
1 of these may duplicate existing tickets |
Not started The vision and AI stack Remote update and command |
| M8 High |
Identity standardisation Provider selection and setup, token validation in Core and the backend, both clients migrated, user migration and retirement of the bespoke endpoints |
18 72h |
In test Who is allowed to do what Single sign-on | |
| REL Skeletal |
REL - Release and distribution Core installer and update channel, store submission for the client, portal deployment, promotion and rollback rehearsal, production runbooks |
17 63h |
3 of these may duplicate existing tickets |
In progress Certainty Client Licence Portal Remote update and command |
Possible duplication, for a person to settle
| Existing ticket | Its summary | Status | Stories pointing at it |
|---|---|---|---|
| INTEL-269 | Client Management | Push to Dev | 8 |
| INTEL-201 | Database | Backlog | 3 |
| INTEL-272 | Workstation Management | Done | 2 |
| INTEL-270 | User Management | Done | 2 |
| INTEL-218 | Design | Backlog | 2 |
| INTEL-190 | flutter analyze error on certainty-client is invisible on dev because the quality gate ski | To Do | 2 |
Scope figures: Certainty Platform - remediation, cloud platform and control plane storyboard - Admin September 2026.xlsx, extracted 2026-09-14. Board state: live query over the twelve milestone epics, 2026-09-16 19:09 UTC. Milestone-to-component mapping is hand-written in weekly/milestones.py and each milestone's own scope text is printed beside it so the mapping can be checked.
The programme’s fixed dates
| Date | What it is | How firm i | When | Stated in |
|---|---|---|---|---|
| 2026-10-01 | Stage 0 / Stage A — make the platform safe to change AppsTango's proposed staging, not yet signed off by Intelgic. Stage 0 changes no architecture; it makes the current one safe to change, and is the only stage that must complete by 1 October. | estimated | 15d away | audits/target-architecture/PROPOSED-ARCHITECTURE.md:558-570 (section 7, 'Target' column) and audits/operational-readiness/OPERATIONAL-READINESS.md:405 |
| 2026-10-15 | Investor raise NOT a delivery deadline. It is the date Intelgic's funding round is built around; the programme is scheduled so Engagement 1 is substantially demonstrable before it. | committed | 29d away | audits/target-architecture/WHOLE-SHAPE.md:153-155 and PROGRAM-SUMMARY.md:473-475 ('Fixed dates' milestones) |
| 2026-11-01 | Contractual date — Engagement 1 committed scope The date the committed Certainty Platform scope (M0-M10 + REL, 211 stories, 573.5h) must be inside. SCOPE.md:341 - 'there are two weeks of margin, and that margin is the testing time rather than slack.' | committed | 46d away | audits/target-architecture/SCOPE.md:72 and :341; PROGRAM-SUMMARY.md:478-479 |
Customer deployments i
| Epic | Workstream | Where we are i | Where the plan says i | Unassigned |
|---|---|---|---|---|
| INTEL-359 | Polyplex i | no stated target No document states one. Not inferred from the data. |
28 | |
| INTEL-206 | Reliant Cellular withheld quote that Lindsey said does not cover cost. [Source: _context/email-voltaire-reliant-timeflow-2026-09-10.md; estimates/certainty-mothership-sep-2026/_context/how-intelgic-actually-quotes.md:66-73]" data-tip="Cellular-manufacturing customer. No agreed scope or kickoff date. Two contested sizings exist: 379.9 story points at an unstated velocity, and 'four people for fifteen weeks' against a withheld quote that Lindsey said does not cover cost. [Source: _context/email-voltaire-reliant-timeflow-2026-09-10.md; estimates/certainty-mothership-sep-2026/_context/how-intelgic-actually-quotes.md:66-73]">i | gated, not scheduled Reliant Cellular has no kickoff date. Two contested estimates exist - 379.9 SP at an unstated velocity, and 'four people for fifteen weeks' against a withheld quote, which Lindsey called not covering cost. Neither is a date. |
18 | |
| INTEL-212 | Stakes MFG withheld for the first system and withheld for seven, on 30/40/30 payment milestones (purchase order / shipment and pre-installation / post-installation commissioning). Current scope adds dynamic recipe and camera settings plus roughly 50 new error codes. [Source: estimates/certainty-mothership-sep-2026/_context/how-intelgic-actually-quotes.md:12,34-51; _context/day-2026-09-08.md:50]" data-tip="Manufacturing customer, quoted 18 Dec 2025 at withheld for the first system and withheld for seven, on 30/40/30 payment milestones (purchase order / shipment and pre-installation / post-installation commissioning). Current scope adds dynamic recipe and camera settings plus roughly 50 new error codes. [Source: estimates/certainty-mothership-sep-2026/_context/how-intelgic-actually-quotes.md:12,34-51; _context/day-2026-09-08.md:50]">i | gated, not scheduled Stakes MFG is quoted on payment MILESTONES, not dates: 30/40/30 against purchase order, shipment-and-pre-installation, and post-installation commissioning (18 Dec 2025 quotation). Triggers, not a schedule. |
14 | |
| INTEL-348 | Reynolds Tobacco i | gated, not scheduled Reynolds Tobacco: quote still in flight, imagery not received, not yet marked active. |
5 | |
| INTEL-283 | Kalpataru i | no stated target No document states one. Not inferred from the data. |
— | |
| INTEL-43 | Bobrick VAAV withheld billed over about eighteen months and unpaid. Nothing ships until that is settled; capability is built platform-first and delivered once paid. [Source: _context/day-2026-09-08.md:67-75]" data-tip="Bobrick VAAV. Paused on payment grounds, not cancelled — roughly withheld billed over about eighteen months and unpaid. Nothing ships until that is settled; capability is built platform-first and delivered once paid. [Source: _context/day-2026-09-08.md:67-75]">i | gated, not scheduled Bobrick is paused on payment grounds, not scheduled. _context/day-2026-09-08.md:67-75 - nothing ships to Bobrick until they pay (roughly withheld billed over ~18 months). Capability is platform-first, delivered once paid. This is an explicit refusal to set a date, not a missing plan. |
— | |
| INTEL-346 | Bobrick (3) i | gated, not scheduled Bobrick, payment-gated as above. |
— | |
| INTEL-296 | Dynamic Defect Types (Stakes) i | tracking Certainty Platform update - dynamic defect types (Stakes) estimated for 2026-09-25, in 9d Source: Jira epic INTEL-296 description, 'Release: Certainty Platform update, 25 September 2026' |
— |
Certainty product i
| Epic | Workstream | Where we are i | Where the plan says i | Unassigned |
|---|---|---|---|---|
| INTEL-38 | Certainty Core i | no stated target No document states one. Not inferred from the data. |
5 | |
| INTEL-40 | Certainty Web i | no stated target No document states one. Not inferred from the data. |
1 | |
| INTEL-39 | Certainty Client i | no stated target No document states one. Not inferred from the data. |
1 | |
| INTEL-321 | Dynamic Camera Exposure i | no stated target No document states one. Not inferred from the data. |
3 | |
| INTEL-292 | SSO for Certainty Client i | target date passed Portal SSO (Google, Microsoft, offline login) was estimated for 2026-09-11, 5d ago Source: team-briefs/2026-08-25/TEAM-MESSAGE.md:51 |
— | |
| INTEL-293 | Role-Based User Management i | tracking Certainty Platform update - role-based user management estimated for 2026-09-25, in 9d Source: Jira epic INTEL-293 description, 'Release: Certainty Platform update, 25 September 2026' |
4 | |
| INTEL-295 | SOP Monitoring i | tracking Certainty Platform update - SOP monitoring estimated for 2026-09-25, in 9d Source: Jira epic INTEL-295 description, 'Release: Certainty Platform update, 25 September 2026' |
2 | |
| INTEL-294 | API Gateway Layer i | tracking Certainty Platform update - API gateway layer estimated for 2026-09-25, in 9d Source: Jira epic INTEL-294 description, 'Release: Certainty Platform update, 25 September 2026' |
3 | |
| INTEL-41 | Certainty User Manual i | no stated target No document states one. Not inferred from the data. |
— |
POC i
| Epic | Workstream | Where we are i | Where the plan says i | Unassigned |
|---|---|---|---|---|
| INTEL-355 | IntelgicPOC i | no stated target No document states one. Not inferred from the data. |
— |
Internal & ops i
| Epic | Workstream | Where we are i | Where the plan says i | Unassigned |
|---|---|---|---|---|
| INTEL-42 | Demo Setup i | no stated target No document states one. Not inferred from the data. |
— |
Unsegmented i
| Epic | Workstream | Where we are i | Where the plan says i | Unassigned |
|---|---|---|---|---|
| — | Under an epic not in the lane map i | no stated target No document states one. Not inferred from the data. |
5 | |
| — | No epic anywhere up the parent chain i | no stated target No document states one. Not inferred from the data. |
26 |
Top findings
- INTEL-3 — [Taylor] Ongoing call review + staffing/estimate coordination (Aug 13
open 5d
32d since the status last changed (now To Do, taylor) - INTEL-9 — QA-E6: Draft staging environment requirements + regression suite archi
open 5d
32d since the status last changed (now To Do, Derek) - INTEL-10 — CERT-E5: Review decisioning-path test coverage gaps against the exampl
open 5d
32d since the status last changed (now To Do, Derek) - INTEL-12 — QA oversight framework + checklist setup (check on our side per Russ's
open 5d
32d since the status last changed (now To Do, erikdon.p) - INTEL-14 — INF-E1: Define CI secret-scanning policy + pre-commit hook spec for th
open 5d
32d since the status last changed (now To Do, erikdon.p) - INTEL-17 — Draft Python code-review standards + checklist (using the example BE r
open 5d
32d since the status last changed (now To Do, Erven.j) - INTEL-22 — [Taylor] Risk register + skills matrix consolidation from 1:1 data
open 5d
32d since the status last changed (now To Do, taylor) - INTEL-25 — [Taylor] OPS-E7: Team Jira training sessions (two time zones) + dashbo
open 5d
32d since the status last changed (now To Do, taylor)
Open questions
- Bobrick — three separate epics -- INTEL-43 'Bobrick VAAV' (To Do), INTEL-345 'Bobrick' (To Do, no children), INTEL-346 'Bobrick' (Done). Reported separately until someone says which is live.
How the board is put together
Epic
A whole area of work with a name a customer would recognise — Polyplex, SOP monitoring, Certainty Core. It finishes when everything under it finishes, which can be months.
19 on this board.
Story or task
One deliverable thing, worth a few days — “program the defect logic for meniscus breaks”. This is the unit every percentage on these pages counts, because it is the only one that is comparable between teams.
354 on this board.
Sub-task
A step inside a story, often a few hours. Counting these flatters whoever writes the most of them, so they are deliberately left out of every progress figure here.
153 on this board.
Definitions
| Term | What it means |
|---|---|
| Certainty product | The product itself Work on the Certainty platform that every customer shares: Core, Web, Client, and the cross-cutting features (SSO, role-based access, the API gateway, SOP monitoring, camera exposure). Not specific to any one site. |
| Customer deployments | Work for a named customer Delivery to a specific site or account — Polyplex, Reliant Cellular, Stakes MFG, Reynolds Tobacco, Kalpataru, Bobrick. Each is its own epic and is tracked separately, because progress on one says nothing about another. |
| POC | Proof of concept, not committed delivery Prototype work with no customer waiting on it — the Fanuc robot environment and the IntelgicPOC. Held apart from delivery so that prototype activity never reads as progress against a customer commitment. Called POC rather than R&D at Lindsey's request, 2026-09-14. |
| Internal & ops | Running the programme Project management, demo setup and internal infrastructure. Real work, but not something a customer receives. |
| Unsegmented | Belongs to no epic Issues with no epic anywhere up their parent chain. They roll up to no product line and no customer, so they appear on no segment view. They are listed rather than filtered out: a quarter of this project sits here, and a dashboard that hid them would look complete while omitting them. |
| top-level issues | The comparable unit Stories, Tasks and Bugs — everything except sub-tasks. Progress is counted this way because teams break work down very differently: one segment splits 15 stories into 100+ sub-tasks and another writes none at all. Counting every item would rank bookkeeping style rather than size. |
| sub-tasks | Breakdown, shown separately Children of a story or task. Counted and shown, but kept out of the progress percentage so segments stay comparable. |
| done | Reached Done or QA-pass An issue whose status is Done or QA-pass. Note that this team uses Done to mean merged to the dev branch, not shipped to production — see the promotion gap figure for what has actually reached staging and prod. |
| unassigned | Open work with no owner An issue that is not Done and has nobody in the assignee field. Nobody is accountable for it and it will not appear in anyone's queue. On the summary cards and segment tables this counts top-level issues only, the same unit as the progress figure beside it; the headline table counts sub-tasks too. |
| stale | No status change in 14 days An open issue whose STATUS has not moved in 14 days. Deliberately measured from status history rather than the 'updated' field, because 'updated' moves for a label edit, a description fix or a bulk sweep — so an untouched board can be made to look busy. An issue that has never transitioned at all is measured from its creation date. |
| stale by updated | The misleading version, shown for contrast The same question answered using Jira's 'updated' field. It is shown ONLY so the two numbers sit side by side. A large gap between them means the board is being edited rather than worked — the gap is the finding, which is why this number is reported and never used. |
| overdue | Past its due date, not done Counted only among issues that carry a due date at all, which is a small minority of this project. The coverage figure is printed with the count for that reason: a low number here is a statement about those issues, not about delivery as a whole. |
| bulk-edit fingerprint | A day the board was tidied, not worked A day on which more than 20 issues were edited but their status never changed. This is the signature of a bulk update — housekeeping that looks like activity to any measure watching the 'updated' field. |
| unreviewed merge | Merged with nobody reviewing it A pull request that was merged where no one other than its own author submitted a review. Nothing stopped it reaching the shared branch, and no second person looked at the change. |
| promotion gap | Commits on dev that never reached staging or prod A branch comparison: how many commits exist on dev that are not on staging, and on staging that are not on prod. This is a fact about branches. It is NOT a statement that any particular fix is undeployed — that inference needs checking per fix, and getting it wrong in both directions has already happened on this project. |
| unsegmented work | Work attached to no epic Open issues with no epic anywhere up the parent chain. They belong to no customer and no product line, so no segment view or roll-up includes them. |
| on track | 70% or more of top-level issues done A stated threshold, not a judgement, so the same data always produces the same verdict and nobody has to agree with an opinion. |
| behind | 30-69% of top-level issues done A stated threshold, not a judgement. |
| at risk | Under 30% of top-level issues done A stated threshold, not a judgement. It includes workstreams that have simply not started yet. |
| not checked | We could not measure this The source did not answer — an expired token, an outage, a missing dependency. Shown as 'not checked' with the reason rather than as zero, because a zero here would certify the very thing the check exists to catch. A collection run with any of these does not report success. |
| none found | We looked and there was nothing Different from 'not checked': the search ran and genuinely returned nothing. The scope of that search is always printed underneath, so you can see what was actually looked at before believing the absence. |
| coverage | How much of the project could answer Printed inside the cell rather than as a footnote — e.g. '30 (75 of 529 — 14% have a due date)'. A figure computed over an eighth of the project is a real number about that eighth and a misleading one about the whole. |
| flag | Something an automated check noticed Not a bug and not a person's judgement: each one is a rule that ran against Jira and GitHub and found a condition worth a look — work that has not moved, work nobody owns, a branch that never got promoted. Seven checks raise them, listed with their rules on the Weekly track view. A flag is a question to answer, not a fault; several of these will be deliberate and can be dismissed once someone says so. |
| new | First seen this run This blocker was not present the last time the report ran. |
| aged | Open 14 days or more Raised at least a fortnight ago and still true. These are the ones worth reading first — a blocker nobody has cleared in two weeks is usually blocked on a decision, not on effort. |
| standing | Seen before, under 14 days old Raised on a previous run and still open, but not yet aged. |
| resolved | Was open, now gone Present last run and absent now. Reported once and then dropped, so if it comes back it is correctly reported as new rather than inheriting a months-old first-seen date. |
| first seen | When this blocker first appeared Held in a small ledger, because it is the one thing that cannot be recomputed from Jira — a blocker is a property of a check at a moment, not a fact stored on a ticket. |
| proposed | Where the plan says we should be Taken from a document that actually states a target. Where no document states one, this reads 'no stated target' rather than showing a guess — an invented plan line makes actual progress look like a shortfall against a commitment nobody made. |
| actual | Where the board says we are Computed from Jira status history at the moment the report ran. |
The workstreams
| Workstream | What it is |
|---|---|
| INTEL-38 | The Certainty engineering backlog for the core platform — the shared engine every customer deployment runs on. The largest single workstream on the board. Source: Jira epic (import boilerplate only); scope from the target-architecture documents in audits/target-architecture/ |
| INTEL-39 | The operator-facing desktop application — what someone on a plant floor actually looks at and clicks. Source: Jira epic (import boilerplate only); audits/target-architecture/ |
| INTEL-40 | The web side of Certainty, including the licence portal. Source: Jira epic (import boilerplate only); audits/target-architecture/ |
| INTEL-41 | End-user documentation for Certainty. Source: Jira epic summary |
| INTEL-205 | First version of the OEM licence portal: a licence data model (key, product, expiry, seat/device count, OEM owner), a cryptographically signed key generation and validation service, and an OEM-facing portal UI. Source: Jira epic description |
| INTEL-292 | Operators sign in through the customer's own identity provider (OIDC), so Certainty stops being a separate password to manage. Additive — existing logins keep working. Source: Jira epic description |
| INTEL-293 | Administrators manage users, roles and permissions from inside the Certainty Client with no developer involvement, and every role gate is enforced on the server rather than merely hidden in the UI. Source: Jira epic description |
| INTEL-294 | One controlled entry point for all cloud-routed traffic, with authentication validated at the edge, instead of each service handling its own routing, TLS, rate limiting and auth. Source: Jira epic description |
| INTEL-295 | SOP monitoring judges a procedure step on combined evidence — several cameras, several regions of interest, several detection models — and shows the operator both the step-by-step and the final decision. Source: Jira epic description |
| INTEL-321 | Runtime control of camera exposure: read a camera's exposure range and drive it deliberately during capture, rather than fixing it once in the MindVision settings dialog. Raised for the Stakes account. Source: Jira epic description |
| INTEL-359 | No description on the Jira epic, and not named in any planning document in this workspace. Worth asking for one. This is the largest customer epic on the board (31 stories, 123 sub-tasks, none started, 150 unassigned). Source: Jira epic (empty); document sweep 2026-09-11 found no mention |
| INTEL-206 | Cellular-manufacturing customer. No agreed scope or kickoff date. Two contested sizings exist: 379.9 story points at an unstated velocity, and 'four people for fifteen weeks' against a withheld quote that Lindsey said does not cover cost. Source: _context/email-voltaire-reliant-timeflow-2026-09-10.md; estimates/certainty-mothership-sep-2026/_context/how-intelgic-actually-quotes.md:66-73 |
| INTEL-212 | Manufacturing customer, quoted 18 Dec 2025 at withheld for the first system and withheld for seven, on 30/40/30 payment milestones (purchase order / shipment and pre-installation / post-installation commissioning). Current scope adds dynamic recipe and camera settings plus roughly 50 new error codes. Source: estimates/certainty-mothership-sep-2026/_context/how-intelgic-actually-quotes.md:12,34-51; _context/day-2026-09-08.md:50 |
| INTEL-296 | For the Stakes account: an administrator can add a new defect category without waiting for a software release. The Imaging screen loads its defect-type list dynamically instead of from a hard-coded set. Existing recorded defects keep their original classification. Source: Jira epic description |
| INTEL-283 | Steel plate measurement inspection using 3D profiling. Source: Jira epic summary (the description field holds only a CSV link) |
| INTEL-348 | Tobacco-manufacturing prospect. The quote is still in flight and sample imagery has not been received, so it is not marked active. The one hard figure is a constraint rather than scope: roughly 16,000 units a minute, with the reject arm firing two seconds downstream. Source: _context/email-voltaire-2026-09-03.md:38-54 |
| INTEL-43 | Bobrick VAAV. Paused on payment grounds, not cancelled — roughly withheld billed over about eighteen months and unpaid. Nothing ships until that is settled; capability is built platform-first and delivered once paid. Source: _context/day-2026-09-08.md:67-75 |
| INTEL-345 | A second Bobrick epic with no children and no stated scope. Recorded on 2026-09-10 as needing a scope line before it can mean anything. Source: _context/ledger-and-plan-2026-09-10.md:125 |
| INTEL-346 | A third Bobrick epic, marked Done, with one child. Which of the three Bobrick epics is the live one has not been settled. Source: Jira epic (empty); ambiguity recorded in segments.AMBIGUOUS |
| INTEL-287 | Fanuc robot cell in a simulation environment, including a configurable virtual safety wall so safety-zone violations can be exercised without hardware. Proof of concept — no customer is waiting on it. Source: Jira epic description |
| INTEL-355 | No description on the Jira epic, and not named in any planning document in this workspace. Worth asking for one. Classified as POC: no customer is waiting on it. Source: Jira epic (empty); document sweep 2026-09-11 found no mention |
| INTEL-42 | Setting up demonstration environments. Source: Jira epic summary |
| INTEL-44 | Delivery-management and coordination work. Source: Jira epic summary |
| No epic anywhere up the parent chain | Open work that belongs to no epic and therefore to no customer and no product line. It appears on no segment roll-up. A quarter of this project sits here. Source: Computed by walking each issue's parent chain up to five levels |
| Under an epic not in the lane map | Work under an epic that has been created since this dashboard's lane map was last updated. Shown rather than dropped, so a new epic is visible the week it appears. Source: Computed |