Three tracks of work run at once, and they are easy to confuse with each other. Track 1 is the Certainty platform itself, the proposed architecture and the backend it needs. Track 3 is delivery for named customers. A third track, prototype and proof-of-concept R&D, is covered in a separate document rather than here. Within Track 1, two engagements have been estimated. Engagement 1 makes the product deliverable; Engagement 2 makes it compound. The dependency runs one way: Engagement 2 needs what Engagement 1 builds, and Engagement 1 stands alone if the second is never funded. Almost none of either has been built yet — what has happened since August is audit, remediation and getting the four repositories into a state where a change can be trusted.
Track 1 — the shape of the platform
Today
Where the product actually is
- Four repositories, 56 audit findings
- Updates by logging in and downloading from GitHub
- Each plant isolated - nothing learns from anything
- No cloud backend at all
Engagement 1 — the platform
Makes it deliverable
- CI and remediation
- AWS accounts, federated access
- Tenants and entitlement
- Remote monitoring
- Cloud control plane
- Release and update channel
Engagement 2 — the Mothership
Makes it compound
- Sites that learn from themselves
- A fleet that learns across customers
- Analytics, trends, anomalies
- Ask it in plain language
- Recipes as a service
The plant appears in both. Engagement 1 makes it updatable and manageable; Engagement 2 makes it thoughtful. Neither is much use without the other, but they are worth buying in that order.
Track 1 — where we are against that plan
One row per tranche of the plan. A tranche counts as done only when something outside Jira shows it working — a ticket in a Done column is not evidence that a plant can be updated remotely. Where nothing was checked, the row says so and names what would settle it.
| Engagement | Tranche | State | What is actually there |
|---|---|---|---|
| Engagement 1 | CI and remediation | partly there | CI exists and blocks in certainty-license-backend. certainty-core has no .github directory on dev at all; certainty-license has .github but no workflows; certainty-client has CI whose Analyze/Static/Test steps carry continue-on-error: true, so it cannot fail a build (INTEL-190). PR #16 adds CI to certainty-core and was merged to dev on 2026-09-13 (INTEL-147). How we know: Checked on live branches 2026-09-11; PR #16 merge verified by commit containment in dev. |
| Engagement 1 | Remediation of audit findings | partly there | Of roughly 33 findings marked Done, 4 were confirmed live in production. 17 licence-repo security fixes are on dev only: staging and prod on both licence repos are still frozen at the August import. Promotion needs Soumen's authorisation and has not been given. How we know: Bug ledger validated against live dev/staging/prod branches 2026-09-10. |
| Engagement 1 | AWS accounts, federated access | not verified | One account (036437809026) is in use and hosts the demo stack. The four-account topology in ADR Decision 5.7 has no evidence of being stood up, and INTEL-30 (access monitoring) records itself as blocked on that foundation existing. How we know: Not audited this cycle. Would be settled by an AWS Organizations listing. |
| Engagement 1 | Tenants and entitlement | not started | No tenant model found in any repository. The administration screens in the client still talk only to the machine in the plant. How we know: Searched: repository file trees on dev across the four repos, 2026-09-11. |
| Engagement 1 | Remote monitoring | not started | Nothing found. A struggling plant is not visible from outside the plant. How we know: Searched: repository file trees and the Jira board for a monitoring epic. |
| Engagement 1 | Cloud control plane | not started | No cloud backend exists. This is the single largest piece of Engagement 1 and the thing Engagement 2 stands on. How we know: Stated as absent in the target-architecture audit, 2026-09-02. |
| Engagement 1 | Release and update channel | not started | Updates still require logging into a customer's server. staging branches now exist in all four repos (INTEL-152), which is a branch, not a channel. How we know: Branch existence checked live 2026-09-11. |
| Engagement 1 | Test lab online | not started | No test lab is reachable online. staging branches exist in all four repos, but a staging branch is not a staging environment, and no environment requirements document was found (INTEL-9, still open). The hardware bench that industrial testing actually needs has a requirements ticket (INTEL-15) and a procurement ticket (INTEL-32), both unstarted and both blocked on input from Rajesh and Jhantu rather than on their assignee. How we know: Branch existence checked live 2026-09-11; both tickets read on the board. |
| Engagement 2 | Everything | not started | Not begun, and correctly so: it depends on Engagement 1's accounts, tenant model and release channel. INTEL-355 (IntelgicPOC) and INTEL-287 (Fanuc) are the only POC cards on the board, and INTEL-287 has no children. How we know: Board read 2026-09-11. |
What the board says
Jira progress for the same week, counting top-level issues. This measures ticket movement, which is a different thing from the tranches above: most of these tickets are audit findings and remediation, not Engagement 1 features.
| Area | Progress |
|---|---|
| Certainty product | |
| Customer deployments | |
| POC | |
| Internal & ops | |
| Unsegmented |
Track 3 — work for the other clients
Each named customer is its own epic and its own delivery. Progress on one says nothing about another. These counts are top-level issues from the same board read; "nobody assigned" means the item is not Done and has no assignee, so it is in nobody's queue.
| Epic | Customer | Progress | Nobody assigned | Epic status | Note |
|---|---|---|---|---|---|
| INTEL-359 | Polyplex | 28 | To Do | Largest customer epic on the board. 153 of its 154 issues are To Do and 28 of 31 top-level items have nobody assigned. | |
| INTEL-212 | Stakes MFG | 14 | Backlog | Whole epic sits in Backlog, nothing assigned. The separate Dynamic Defect Types epic (INTEL-296) belongs to this customer. | |
| INTEL-206 | Reliant Cellular | 18 | Backlog | Three items in progress. This is the account behind Voltaire's Reliant workflow email and Soumen's 379.9 SP / withheld figures. | |
| INTEL-283 | Kalpataru | — | Done | The one customer epic finished: all 8 issues Done. | |
| INTEL-348 | Reynolds Tobacco | 5 | To Do | Five items, all To Do, none assigned. | |
| INTEL-43 | Bobrick VAAV | — | To Do | One of three separate Bobrick epics. Which is live has not been decided, so they are reported separately rather than merged. | |
| INTEL-346 | Bobrick (3) | — | Done | Second Bobrick epic, marked Done. | |
| INTEL-296 | Dynamic Defect Types (Stakes) | — | To Do | Single unassigned item belonging to Stakes MFG. | |
| INTEL-345 | Bobrick (2) | — | To Do | Third Bobrick epic. No children at all, due date already passed. |
Across these customer epics, 5 of 76 top-level items are finished. Almost all of the rest has not been started and most of it has no owner — which is the headline for this track, not any individual customer.
The two engagements
| # | Engagement | Milestones | Stories | Hours | Cost |
|---|---|---|---|---|---|
| 1 | Certainty platform Makes the product deliverable: it can be built, released, updated and administered, with tenants and monitoring. | 12 | 211 | 940.9 | withheld |
| 2 | Certainty Mothership Makes the product compound: sites learn from themselves, the fleet learns across customers, and recipes become a service. | 11 | 164 | 796.4 | withheld |
Both at a rate held on the internal page with the same AI-assistance convention, so the numbers add honestly. Together: 23 milestones, 375 stories, 1,737.3 hours, withheld.
Either can stop somewhere defensible
| Tier | Engagement 1 | Engagement 2 | Together |
|---|---|---|---|
| Skeleton | withheld | withheld | withheld |
| Slim | withheld | withheld | withheld |
| Mid | withheld | withheld | withheld |
| Everything | withheld | withheld | withheld |
The dates
| Date | What it is | How firm |
|---|---|---|
| 2026-10-01 | Stage 0 / Stage A - make the platform safe to change | AppsTango's proposed staging, not yet signed off by Intelgic |
| 2026-10-15 | Investor raise | Not a delivery deadline. The programme is scheduled so Engagement 1 is substantially demonstrable before it |
| 2026-11-01 | Contractual date - Engagement 1 committed scope | 211 stories, 573.5h. Two weeks of margin, and that margin is the testing time rather than slack |
Known problems with the plan these dates come from
Surfaced rather than resolved — choosing a side would invent a decision nobody has made.
- The schedule's start date did not happen. Every plan line is drawn from a 2 September start. The programme summary says so itself: the margin is being spent while the design question is settled. Stated as recoverable then, and not in three weeks.
- Two developers or three? SCOPE.md:330 and PROGRAM-SUMMARY.md:566 say three. The estimate cover disclaimer and assumption A-06 say two. Both are stated as what puts the committed scope inside 1 November. Unreconciled.
- The two engagements together do not fit three developers. From the plan's own section 3. Engagement 2 can start once Engagement 1's first tranche is down, and that overlap is what makes the staffing question real rather than theoretical.
- Three different September release dates appear in one call. The 2026-09-08 call transcript gives the 23rd, 25th and 26th in three consecutive sentences. None is treated as confirmed.
What has to be true
Neither cost survives these being wrong, so they are stated rather than assumed.
| Assumption | If it fails |
|---|---|
| Three developers at 30 productive hours, from the start | Both dates move. This is the single assumption the whole schedule rests on |
| Design work starts rather than waiting for more whiteboarding | Every week of design gate consumes a week of the margin held for testing |
| Intelgic selects an identity provider early | Engagement 1 M8 and Engagement 2 N9 both wait on it |
| Pierre supplies the existing design assets | The reskin does not happen; the screens ship against the current interface |
| The India team continues on its own branch and the 4 September release | The parallel model collapses into one team and the committed scope reopens |
| a rate held on the internal page stands | Hours are unaffected; only the multiplication changes |
Where this comes from
Plan figures, milestones, tiers and assumptions are quoted from audits/target-architecture/WHOLE-SHAPE.md (2026-09-02, prepared for Pierre), which generates them from the two estimate workbooks (estimates/certainty-platform-aug-2026 and certainty-mothership-sep-2026). Board progress is read from the same evidence file as the weekly dashboard (2026-W38, generated 2026-09-16). Current-state claims were checked against live branches on the dates given in each row. Nothing here is estimated on Intelgic's behalf.
The plan itself, against the dates it has to fit inside
Source: audits/target-architecture/WHOLE-SHAPE.md:137-155 (start 2026-09-02) and PROGRAM-SUMMARY.md:459-476 (start 2026-09-03), Engagement 1 at three developers.