Safeguarding information may need to sit within the wider learner journey, but it should never become just another tab that everyone around the learner can open. EdiWay is designed to give safeguarding stronger boundaries than ordinary educational, pastoral, SEND, wellbeing or family information.
Authorised safeguarding roles can work with concerns, chronology, actions, referrals and evidence while wider users remain limited to the information their role and purpose justify.
Safeguarding information should not become visible simply because someone teaches the learner, supports them academically, belongs to the same organisation or has access to another part of their record.
EdiWay is built around a connected learner identity. That helps schools avoid creating disconnected versions of the same child across attendance, SEND, learning, wellbeing, family engagement and safeguarding systems.
But a shared learner identity does not mean every connected record has the same access rules.
A learner may experience:
These may initially sit within appropriate pastoral, wellbeing, attendance or SEND workflows.
Behaviour information and safeguarding information may sometimes relate to the same learner. But they have different purposes. A behaviour record may describe:
A safeguarding record may involve information requiring restricted professional consideration, chronology, action or referral.
A behaviour incident should not automatically create a safeguarding conclusion.
And sensitive safeguarding information should not be copied into general behaviour records simply to make it easier to see.
SEND, communication differences, sensory needs, disability or educational difficulty should never be treated as safeguarding conclusions in themselves.
EdiWay keeps the domains connected where appropriate while preserving their different purposes.
SEND information may help an authorised safeguarding professional understand communication or support context.
Safeguarding information may sometimes be relevant to an authorised SEND process.
But access to SEND information does not automatically provide access to the safeguarding record.
And safeguarding concerns should not become diagnostic evidence simply because the same learner is involved.
Safeguarding access requires stronger justification than ordinary learner access. Depending on the workflow, access can consider:
Is the person authorised for safeguarding work?
Are they acting within the correct organisational context?
Does the record concern the person they are authorised to work with?
Are they involved in this safeguarding process?
Why is access required?
Does this information require additional restriction?
What information can the user actually see or act on?
This helps prevent ordinary platform access from becoming a route into safeguarding information.
Sensitive safeguarding actions should not rely on assumptions. Where EdiWay cannot establish the required user, school, learner, case or permission context, the safer outcome is to deny the action rather than infer access. This matters particularly for:
EdiWay's safeguarding foundation is designed around a governed process rather than isolated notes.
An authorised user records the concern against the correct learner or subject.
The concern is connected to the appropriate school and record context.
The DSL or another appropriately authorised safeguarding role reviews the concern.
Relevant actions, responsibilities and referrals can be managed through the safeguarding process.
Material developments remain connected to the case history.
Authorised safeguarding users manage the next state and appropriate closure rationale.
Safeguarding lifecycle controls continue after ordinary operational work ends.
A safeguarding chronology becomes less trustworthy if records can be rewritten without history or if different sources become indistinguishable. EdiWay's safeguarding direction is therefore built around source-linked chronology and preserved record history.
A chronology may bring together authorised:
While retaining the origin of those records. An original concern should not silently change simply because later information becomes available. New information can add to the history. Corrections can be governed. The chronology remains traceable.
Safeguarding information can develop as more becomes known. That does not mean earlier versions should disappear. EdiWay's safeguarding foundation is designed to preserve material version history so authorised users can distinguish:
This strengthens accountability without suggesting that every early concern was ultimately confirmed.
The safeguarding process belongs with appropriately authorised safeguarding roles. A DSL-focused view can support areas such as:
The detailed safeguarding record should not need to be exposed across ordinary staff dashboards simply to keep work moving. Other staff can contribute through the appropriate concern or reporting route without automatically receiving full case visibility.
Safeguarding concerns may lead to actions or referrals. EdiWay can help structure relevant workflow information such as:
What needs to happen?
Who is responsible?
When is action required?
What stage has been reached?
What stage has been reached?
Has information been referred through the appropriate process?
What outcome or acknowledgement has been recorded?
What happens next?
The platform can help organise and preserve the workflow. It does not decide whether a referral should be made or what safeguarding conclusion should be reached. Those decisions remain with appropriately authorised people.
Safeguarding work can involve external organisations or authorised professionals. Where controlled organisation sharing is enabled, EdiWay's direction is to share defined information for a defined purpose rather than opening unrestricted access to the underlying learner record. Relevant controls can include:
Which organisation or authorised person is receiving access?
Why is the information required?
What material is actually included?
What sharing basis has been recorded where relevant?
When should access end?
Can access be withdrawn?
Can the disclosure and subsequent access be traced?
This supports multi-agency working without treating every external participant as a full EdiWay safeguarding user.
Where safeguarding information needs to be disclosed, EdiWay's governance direction supports selected, reviewed information rather than an unrestricted dump of the learner history. A controlled safeguarding pack may contain relevant:
Where supported and appropriately configured, controlled disclosure can be linked to the intended recipient rather than treated as a permanently open file. Governance may include:
These capabilities are intended to strengthen controlled information sharing. Some cross-organisation and end-to-end assurance remains subject to deployment and runtime testing, so availability may depend on the implemented workflow.
Parents and carers are central to much of the learner journey.
But access to a parent or carer workspace does not automatically provide unrestricted access to safeguarding information.
What can appropriately be communicated or disclosed may depend on the safeguarding circumstances, applicable responsibilities, professional judgement and other legal considerations.
EdiWay therefore should not use ordinary family access settings as a shortcut for deciding safeguarding disclosure.
Learner voice can be extremely important. It may also contain sensitive information. EdiWay can help preserve the learner's contribution as attributable evidence while applying appropriate visibility controls.
The system should not promise a learner that information can always remain confidential where safeguarding or other legal responsibilities may require action or disclosure. At the same time, sensitive learner voice should not become broadly visible simply because it sits within a connected learner record.
Trust or group-level safeguarding oversight may require leaders to understand patterns, workload or governance across schools. That does not automatically justify unrestricted access to every safeguarding case. Where broader safeguarding reporting is supported, governance should continue to consider:
Aggregate oversight should not become a backdoor into individual restricted records.
When a learner moves between schools or other education settings, safeguarding information may require a separate controlled transfer process.
This is different from an ordinary learner Transition Pack.
A general Transition Pack may help the next setting understand selected educational strengths, support, evidence and learner voice.
Restricted safeguarding material belongs within its appropriate safeguarding disclosure and transfer workflow.
Safeguarding information can have lifecycle requirements that differ significantly from routine operational records. EdiWay's safeguarding architecture therefore includes retention and legal-hold concepts rather than treating case closure as permission for ordinary deletion.
A closed safeguarding case may still need its history preserved according to applicable organisational and legal requirements.
Safeguarding information is deliberately treated differently from ordinary educational context. EdiWay excludes safeguarding records from broad AI search and retrieval by default.
A general AI assistant should not be able to search through safeguarding chronology simply because a user can access other areas of the learner record. Any AI capability involving safeguarding information would require a separately governed, purpose-specific workflow with stronger controls and appropriate assurance.
EdiWay AI must not independently:
Safeguarding leadership information may help authorised leaders understand areas such as:
But safeguarding data should not be reduced into simplistic predictions of individual learner risk.
Safeguarding assurance cannot rely only on testing successful workflows. Sensitive areas also need negative-path testing. That may include:
Preventing inappropriate access is as important as enabling legitimate safeguarding work.
EdiWay's safeguarding foundation includes substantial governed case, chronology, action, referral and sharing capabilities. Some advanced areas continue to require runtime, migration, accessibility, cross-organisation denial or independent assurance before stronger deployment-wide claims should be made. EdiWay therefore distinguishes between:
Available within documented product boundaries.
Implemented foundations that may still require broader assurance.
Enabled only when the relevant configuration, permission or policy is active.
Not yet claimed as generally available.
EdiWay does not claim that its safeguarding tools alone make an organisation legally compliant or that the platform replaces safeguarding policy and professional practice.
Is this ordinary educational information or does it require safeguarding handling?
Create or connect the concern within the authorised safeguarding process.
Resolve school, learner, role, case and purpose.
Keep clear who recorded the concern and when.
The DSL or another authorised safeguarding role reviews the concern.
Manage appropriate actions and referrals.
Preserve material case developments.
Disclose selected information only where appropriate and authorised.
Record the authorised outcome and closure state.
Apply the required retention or legal-hold lifecycle.
No.
Safeguarding information should be restricted according to role, school, learner, case, purpose and sensitivity.
The safeguarding model is designed so concerns can enter the appropriate workflow without requiring every reporting user to receive full case visibility.
No.
Wellbeing and safeguarding are distinct workflows, although a wellbeing concern may sometimes lead to safeguarding action.
No.
Behaviour records and safeguarding records have different purposes, permissions and decision boundaries.
No.
Ordinary family access does not automatically determine safeguarding disclosure.
Only through an appropriately authorised and scoped relationship or disclosure process where supported.
They should not receive unrestricted access simply because they are involved with the learner.
Where appropriate and authorised, controlled safeguarding information sharing can be supported.
The exact workflow and availability depend on configuration and assurance.
Safeguarding transfer should remain a separate controlled process rather than being silently included in a general learner Transition Pack.
Not necessarily.
Retention and legal-hold requirements may continue after operational closure.
Broad AI search and retrieval of safeguarding information is excluded by default.
No.
AI must not make safeguarding findings or replace DSL and authorised professional judgement.
No.
The platform can support governed records and workflows, while schools and responsible organisations remain accountable for safeguarding policy, practice and decisions.
Manage the detailed operational concern, case and chronology workflow.
Understand the wider access and controlled-sharing model.
Explore platform access, audit and security controls.
See why safeguarding sits outside broad AI retrieval and autonomous decision-making.
Understand the wider responsibilities around personal and sensitive information.
Explore lifecycle, retention and information-rights boundaries.
See how EdiWay distinguishes product capability from deployment and assurance.