Lower-confidence caveat: unlike the other loops in this analysis, there is no separate end-to-end process document for the CI register — only the register itself. Everything here is reconstructed from the register's column structure and a ~38-row sample (IMP000308–IMP000345, Jul–Dec 2024). Where a stage is genuinely evidenced, it's stated plainly; where inferred, it's flagged; one stage has no evidence at all and is shown as a gap, not assumed.
flowchart TD
A["Issue/idea identified
(staff member, any function/level)"] --> B["CI request submitted via form
(captures: raised by, department, related-to category,
resulting-from category, gap identified, description)"]
B --> C["Risk rating assigned
(Low / Moderate / No risk)"]
C --> D["Due date auto-set from risk rating
(Low=60 business days, Moderate=30, No risk=90)"]
D --> E{"Approval for Processing"}
E -->|Approved| F["Owner + Executive Responsible assigned
(two-tier: operational owner does the work,
an executive is named accountable)"]
E -->|Not Approved| Z["Closed — not proceeded
(evidenced: at least one entry in sample)"]
F --> G["Status tracked: In Progress → Completed"]
G --> H["Completion logged with a templated closure note
e.g. 'Thank you for completing the assigned Improvement Request'"]
H --> I{"Does the loop close back
to the original raiser?"}
I -->|"inferred, not confirmed — closure note's addressee is ambiguous in the data"| J["Possible notification to raiser"]
H -.->|"GAP — no evidence in source"| K["No visible theme/pattern analysis across entries"]
K -.->|"GAP — no evidence in source"| L["No visible reporting of CI trends to ELT/Board"]
M["Incident Management loop
(CEO Notifiable Incident reviews)"] -.->|"evidenced feed-in:
e.g. IMP000320, IMP000343"| B
N["External audit findings
(e.g. McGrathNicol Payroll Review)"] -.->|"evidenced feed-in: IMP000339"| B
H -.->|"evidenced feed-out:
IMP000325, IMP000330, IMP000331"| O["Training/eLearning content updates"]
style K fill:#f4dad7,stroke:#b3352f
style L fill:#f4dad7,stroke:#b3352f
style I fill:#f6e9cd,stroke:#c8841a
Columns: CI ID, Date Submitted, Due Date, Actual Completion Date, Raised By, Raised By (Email), Job Title, Work Phone, Department, Related To, Resulting From, Risk Rating, Gap Identified, Improvement Description, Owner Email, Improvement Category, Improvement Request Owner, Executive Responsible, Status, Completed Document, Approval for Processing, Approval for Processing Comments, Created.
Continuous Improvement Register (1).xlsxEvery row's Risk Rating maps directly to a due-date window in the same field — Low: 60 business days, Moderate: 30, No risk: 90 — and the Due Date column is consistent with that window relative to Date Submitted across the sample.
Continuous Improvement Register (1).xlsxNearly every row has a distinct "Improvement Request Owner" (does the work) and "Executive Responsible" (named accountable executive) — frequently different people, sometimes different functions to the raiser.
Continuous Improvement Register (1).xlsxAn "Approval for Processing" field with Approved/Not Approved values exists. At least one sampled entry (IMP000337, an accessibility request from a supported-employee raiser) was marked Not Approved and closed without an owner or executive assigned — the gate can and does reject, not just rubber-stamp.
Continuous Improvement Register (1).xlsxThe "Completed Document" field contains stock phrases ("Thank you for completing the assigned Improvement Request") that read as addressed to whoever completed the work, not necessarily a notification back to the original raiser. Where Raised By and Owner are the same person the loop plainly closes; where they differ, the data doesn't show whether the raiser is separately told.
Continuous Improvement Register (1).xlsxIMP000320 originates from "Review of recent CEO reportable incident follow-ups"; IMP000343 from "the investigation into an incident at Badajoz Road" — direct, dated instances, not assumptions.
Continuous Improvement Register (1).xlsxIMP000325 documents the originating CEO Notifiable Incident Report policy change; IMP000330 and IMP000331 each describe that change being manually pushed into "Incident Management eLearn" and "Zero Tolerance Framework eLearn" content respectively.
Continuous Improvement Register (1).xlsxIMP000339 originates from "one of the McGrathNicol Payroll Review audit recommendation[s]" — the register also tracks actions from external audits, not only staff-raised ideas.
Continuous Improvement Register (1).xlsxThe intake-to-completion mechanics (submit → risk-rate → approve/reject → assign owner + accountable executive → complete → templated closure) are well evidenced and look like a genuinely functioning workflow. The proposal's diagnosis that "the mapping is singular — one problem, one solution" Mar26_Achieve proposal_Connecting the System — Supporting Potential.pdf is consistent with what the data shows: each row closes on its own terms, but nothing in the register's own structure closes the loop at the pattern level. Whether aggregation happens elsewhere (a manual quarterly review, a QMS report, a board paper) is unknown — this register provides no evidence that it does, not evidence that it doesn't.
The other genuine unknown: whether raisers are told the outcome when they aren't also the owner. If not, the register may function as an internal ticketing tool for the owner/executive layer without closing the loop back to the frontline or functional staff who raised the issue — which matters for whether staff trust the mechanism enough to keep using it.
PII handling: no individual's name, email, or phone number from the register has been reproduced in this document or its source markdown, per the PII flag on the source file. All references to who does what use role/function/title language only.