What was actually wrong
Progress on an element is a simple fraction: questions answered, over questions the element asks. The problem was never the arithmetic — it was how the second number was kept.
Originally that number was worked out fresh every time it was needed. Always correct, but at this scale the cost of recalculating it for every business on every answer was heavy enough to threaten the whole platform's stability. So it was calculated once, stored, and updated whenever an element changed. That was the right call, and it remains the right call.
A stored number is only right for as long as something keeps it up to date. Every event that should have updated it did. But if one of those updates was ever missed — a background task dropped, a rebuild that didn't finish cleanly — nothing afterwards noticed, and nothing put it right. The stored number simply stayed wrong, quietly, for that element only.
That's the brittleness: not a miscalculation, but the absence of anything that would detect and correct one. Each previous fix repaired the values that had gone wrong; none of them added the mechanism that would catch the next one. Hence the recurrence.
Three things change that. The number is still stored, so the performance characteristics are unchanged. It is now produced by one method rather than several that could disagree. It knows when it might be out of date and recalculates instead of being trusted blindly. And a nightly check verifies every element independently, corrects anything that has drifted, and tells us it happened.
The cases that were visibly stuck — including the element holding a large number of businesses at 99% — have already been corrected directly. Expect no sudden change in your numbers. What changes is that the problem stops returning.
Changes to know about
Rebuilding this meant taking some decisions about how completion should behave. These are decisions, not open questions — but tell us if you disagree with any and we will revisit.
Completion stays with a business when an administrator adds a question later
Elements aren't versioned — there's one current version, and every business is measured against it. So adding a question, or making an optional one required, would show every business that had already finished as incomplete.
Being told you have unfinished work on something you completed two months ago, through no action of your own, is a poor experience. Completion now stays put.
Worth notingThis needs an administrator to change an element after businesses have completed it, so it should be rare. It's protection against a bad experience rather than a response to a frequent one.
But if a business removes its own answer, the element does reopen
The protection above is specifically about administrators changing the element — it isn't a rule that completion can never be lost. Clearing or deleting an answer to a required question correctly makes the element incomplete again.
The distinctionProtected from someone else moving the goalposts; still accountable for its own work.
A catalogue is complete when every element inside it is complete
Catalogue completion used to be calculated by adding up question counts across its elements. That allowed every element in a catalogue to report complete while the catalogue itself did not.
The new rule matches what a user expects: finish the elements, and the catalogue is finished. The percentage still reflects element size, so a 90-question element moves the bar further than a 2-question one.
On releaseA small number of catalogues that had genuinely been finished but weren't recorded as such will correct to complete. One test-organisation catalogue showing complete without having been finished will correct the other way.
Adding a whole new element to a catalogue does reopen it
Deliberately no equivalent protection here. One question added to an existing element is a small change; a new element can be a hundred questions of genuinely new work, and the catalogue should show there's more to do.
Headings, content blocks and calculated values can no longer be marked required
These aren't questions — there's nothing for a business to answer — so marking one required made that element impossible for anyone to complete. The platform used to accept the setting and quietly ignore it, leaving the administrator unaware anything was wrong. It now explains why it can't be applied.
Who noticesAnyone building or editing elements: a clear message instead of a setting that silently does nothing.
Submitting for feedback no longer marks an element complete with questions outstanding
The check happened when the submission screen opened, but not when the submission was made. So an answer cleared in the meantime, or a screen left open a while, could record an element as finished when it wasn't. Submission is now refused, with the outstanding questions named.
Why it matters nowBecause completion is no longer taken away automatically, a record created this way would have stayed wrong. This closes that door first.
In practice
- Nothing genuinely completed is taken away. We checked every completion record on the live platform before building this.
- No visible jump in numbers. The stuck cases are already corrected; a few catalogues will catch up to work already done.
- The system checks itself nightly. Any future disagreement is corrected automatically and flagged to us, rather than waiting for someone to report being stuck.
- Rebuilding an element no longer strands answers. Previously it could leave existing answers uncounted with no way for the business to fix it.
- Completion is now dated. If there's ever a query about why something shows complete, we can answer precisely rather than by inference.
Next steps
This goes into the test environment now, for light testing alongside the rest of the current release before it reaches the live platform.
If any decision above doesn't match how you want completion to behave — particularly the first — let us know and we'll adjust before it goes live.