The instinct, when safeguarding information is scattered, is to consolidate: find one platform that does everything and move it all in.
That instinct is wrong, for reasons that have nothing to do with the merits of any product.
Safeguarding information is scattered because it is generated in different places by different processes. Attendance comes from delivery. Progress comes from the e-portfolio. Employer changes come from the MIS. Staff DBS status comes from HR. Concerns come from the safeguarding log. Those systems are each doing their job, and each is tied to obligations you can’t unpick: your MIS to funding submissions, your e-portfolio to awarding body requirements, HR to employment law.
Consolidating means either a migration programme measured in years, or accepting that the “single platform” will still need to import from the systems you didn’t move. You end up back where you started, with a new vendor.
What you need is not one platform. It is one view. The distinction is the whole design.
A single place where the safeguarding-relevant picture can be seen whole, while the underlying data stays in the systems that own it.
Concretely, for any learner, someone with the right permissions should see together:
And at provider level:
No data has moved. Nothing has been migrated. The systems still own their own records: they are simply readable together.
Sequencing matters, because each step is only worth doing if the previous one holds.
Before joining anything, make sure concerns are captured consistently. A structured form that captures the same fields every time (including verbatim disclosure where appropriate) is the precondition. Free-text notes in inconsistent formats cannot be aggregated later, and no amount of joining fixes that.
Every case needs a state (open, in progress, monitoring, resolved, archived, cancelled) and a named owner. Without this you can count cases but not manage them, and you cannot answer the single most common governance question: what happened to the ones from last time?
Join the concern to attendance, progress, employer and support needs. This is the step that turns incident handling into pattern recognition, because it is the first point at which a concern can be assessed against everything else happening to that learner.
DBS, safeguarding training, Prevent, online and overseas checks, right to work, as a live status per staff member. This is separate from case data and often forgotten until an inspection asks.
Only once 1–4 are in place is aggregate reporting meaningful. Trends built on inconsistent capture are confidently wrong, which is worse than absent.
Who knew what, when, and what they did, captured automatically as people work, not reconstructed afterwards. If this is a by-product of the process, inspection evidence is always current.
Attempting step 5 before step 1 is the most common mistake. It produces dashboards that look authoritative and aren’t.
Don’t rip and replace. Your delivery systems are tied to obligations that make migration expensive and risky. Read from them instead.
Don’t build it in a spreadsheet. Manual joining is slow, unrepeatable, and produces different answers depending on who did it. It also ages instantly, the picture is true on the day it was assembled and drifts every day after.
Don’t gate it behind the DSL. If only one person can see the joined view, you have moved the bottleneck rather than removed it. Role-aware access lets operations see what operations needs and governance see patterns, without exposing case detail inappropriately.
Don’t confuse a policy repository with oversight. Version-controlled policies with review dates are necessary. They tell you nothing about whether safeguarding is working.
Don’t wait for inspection to test it. The question “could we evidence this tomorrow” should be answerable on an ordinary Tuesday.
The differences are practical rather than dramatic:
Joining data across delivery systems without replacing them is what a provider management system does. Your LMS or e-portfolio remains where learners are engaged and where their work lives; AiVII wraps around it, reading across your delivery stack (it integrates directly with Bud, Aptem and OneFile) so safeguarding can be seen whole.
Nothing about that requires learners to change how they work, or your MIS to change how it submits.
Do we need a single safeguarding platform? No. Safeguarding data is generated across delivery, MIS, HR and case systems, each tied to its own obligations. What you need is one view across them: consolidation usually means a long migration that still ends in importing from systems you didn’t move.
What should be joined to a safeguarding concern? Attendance and engagement, progress and review history, employer and any change of employer, support needs, and prior concerns and outcomes. A concern assessed alone is assessed on severity; a concern assessed in context is assessed on pattern.
Who should be able to see the joined view? Access should be role-aware. The DSL needs full case detail; operations needs enough to act; governance needs aggregate patterns without individual detail. Restricting everything to the DSL recreates the bottleneck.
How long does it take to get a joined-up view? It depends far more on data consistency than on technology. Providers already capturing concerns through a structured form with clear status and ownership are close. Those with free-text notes in inconsistent formats need to fix capture first, aggregate reporting built on inconsistent data is confidently wrong.