INSTITUTIONALDEPENDENCY-001™
The SAFECHAIN™ Cross-Institutional Dependency, Reliance & Safeguarding Resilience Framework™
Framework Reference: INSTITUTIONALDEPENDENCY-001™
Framework Classification: Cross-Institutional Safeguarding Governance, Dependency Risk, Institutional Reliance, Protective Continuity, Systems Resilience, Accountability, Operational Assurance and Institutional Reform
Parent Architecture: SAFECHAIN™ Integrated Safeguarding Architecture Map™
Primary Safeguarding Lifecycle: Signal → Recognition → Risk → Ownership → Decision → Response → Protection → Adaptation → Assurance → Learning
Cross-Cutting Domain: Institutional Dependency, Responsibility, Continuity and Protective Integrity
Related Frameworks: RESPONSIBILITYCHAIN-001™, RISKOWNERSHIP-001™, HANDOVERINTEGRITY-001™, CONTINUITY-001™, PROTECTIONGAP-001™, PROTECTIVEDEPENDENCY-001™, PROTECTIVEASSURANCE-001™, ERRORPROPAGATION-001™, CORRECTIONINTEGRITY-001™, INSTITUTIONALMEMORY-001™, INFORMATIONASYMMETRY-001™, UNCERTAINTYINTEGRITY-001™, IMPLEMENTATIONGAP-001™, SYSTEMRECOVERY-001™
Version: 1.0
Year: 2026
Author: Samantha Avril-Andreassen, LLB (Hons), LLM, LPC, FRSA
Organisation: SAFECHAINN Ltd / SAFECHAIN™
PART I — FOUNDATIONAL GOVERNANCE ARCHITECTURE
1. Purpose
The SAFECHAIN™ Cross-Institutional Dependency, Reliance & Safeguarding Resilience Framework™ — INSTITUTIONALDEPENDENCY-001™ — establishes a structured governance methodology for identifying, evaluating, managing and assuring the dependencies upon which effective safeguarding protection relies.
Safeguarding rarely operates within one institution.
A protective outcome may depend upon several organisations, professionals, services, systems and decisions functioning in the correct sequence.
One institution may identify the risk.
Another may hold the evidence.
A third may possess the authority to intervene.
A fourth may be responsible for delivering practical protection.
A fifth may be responsible for reviewing whether the intervention has worked.
The existence of these individual responsibilities does not necessarily establish that the protective system operates effectively.
The central vulnerability arises when the protection promised by one institutional actor depends upon action by another actor, but that dependency is neither explicitly recognised nor operationally assured.
An organisation may record that a referral was made without establishing whether it was received.
A professional may assume that another agency is managing the risk.
A service may close its involvement because responsibility has transferred.
A safeguarding plan may depend upon accommodation, transport, communication, specialist assessment or financial assistance that has not been confirmed.
A decision may require information from another institution that has not been supplied.
The protective system may therefore appear complete on paper while remaining incomplete in practice.
INSTITUTIONALDEPENDENCY-001™ addresses this structural vulnerability.
Its purpose is to ensure that institutional safeguarding dependencies are visible, owned, verified, resilient and capable of supporting protection when one component is delayed, unavailable or fails.
2. Core Vulnerability
Safeguarding protection may depend upon multiple institutions performing interconnected responsibilities, while no institution has adequately established whether those dependencies are functioning together as an effective protective system.
3. Core Question
Where safeguarding protection depends upon the action, information, authority, resources or cooperation of another institution, can the responsible organisations demonstrate that the dependency is recognised, operationally owned, appropriately verified and capable of maintaining protection if a component fails?
4. Governing Proposition
An institution should not treat a protective dependency as satisfied merely because the required action has been assigned, requested, referred or assumed.
Where that dependency is material to safeguarding protection, there must be proportionate evidence that it is operational, that responsibility is understood and that failure or delay will trigger an appropriate response.
5. Core Architecture
Safeguarding Need → Required Protection → Institutional Responsibility → Dependency Identification → Dependency Ownership → Operational Confirmation → Protective Delivery → Failure Detection → Contingency Activation → Assurance
6. Expanded Architecture
Signal → Risk Recognition → Protective Objective → Required Capabilities → Institutional Actors → Dependency Mapping → Responsibility Allocation → Information Exchange → Resource Confirmation → Action Sequencing → Operational Handover → Dependency Verification → Protective Implementation → Monitoring → Failure Detection → Escalation → Contingency → Recovery → Independent Assurance
7. Central Institutional Distinction
Responsibility Allocated Does Not Mean Dependency Satisfied.
An institution may identify who should act without establishing whether that actor can act, has accepted responsibility, possesses the necessary information or has completed the required intervention.
8. Foundational Distinctions
Referral Made is not the same as Referral Received.
Referral Received is not the same as Responsibility Accepted.
Responsibility Accepted is not the same as Capacity Confirmed.
Capacity Confirmed is not the same as Action Implemented.
Action Implemented is not the same as Protection Achieved.
Information Shared is not the same as Information Understood.
Professional Agreement is not the same as Operational Coordination.
Multi-Agency Involvement is not the same as Collective Accountability.
A Safeguarding Plan is not the same as a functioning protective system.
A Named Responsible Organisation is not necessarily an effective dependency owner.
Institutional Cooperation is not necessarily institutional resilience.
A Completed Handover is not necessarily continuity of protection.
A Service Available in Principle is not necessarily accessible in practice.
Institutional Capacity is not necessarily available at the point of need.
Individual Compliance is not necessarily system effectiveness.
PART II — THE INSTITUTIONAL DEPENDENCY ARCHITECTURE
9. Institutional Dependency™
A relationship in which the performance of one institutional safeguarding responsibility materially relies upon the information, action, decision, authority, resources or operational capacity of another actor.
10. Protective Dependency™
A dependency whose successful operation is necessary or materially relevant to achieving a safeguarding objective.
11. Dependency Chain™
The sequence of institutional actions or capabilities required to produce a protective outcome.
An illustrative chain is:
Risk Identified → Referral Accepted → Assessment Completed → Protective Decision → Resources Available → Intervention Delivered → Outcome Verified
12. Dependency Integrity™
The extent to which a material dependency is accurately identified, appropriately owned, operationally confirmed and effectively maintained.
13. Dependency Visibility™
The extent to which the institutions involved can identify the material dependencies affecting safeguarding delivery.
14. Dependency Ownership™
The allocation of responsibility for monitoring whether a particular institutional dependency is satisfied.
Dependency ownership does not necessarily transfer legal responsibility for another organisation's independent duties.
It identifies responsibility for monitoring, coordination, escalation or contingency within the relevant actor's authority.
15. Dependency Reliance™
The degree to which an institution's protective decision or action assumes that another institutional component will function.
16. Assumed Dependency™
A material dependency treated as operational without sufficient confirmation.
17. Unverified Reliance™
The institutional practice of depending upon another actor's anticipated performance without proportionate evidence that the necessary action has occurred.
18. Dependency Exposure™
The potential safeguarding consequence arising when protection relies upon a component that may be unavailable, delayed, inaccessible or ineffective.
19. Dependency Concentration™
A condition in which a significant proportion of protective capability relies upon one institution, professional, system, resource or operational pathway.
20. Single-Point Protective Dependency™
A dependency whose failure could substantially compromise protection because no adequate alternative or contingency exists.
21. Dependency Fragility™
The susceptibility of a protective arrangement to interruption, delay or failure within one or more institutional components.
22. Dependency Resilience™
The capacity of a safeguarding arrangement to maintain or restore necessary protective functions when a material dependency is disrupted.
23. Dependency Substitution™
The use of an appropriate alternative institutional action, resource or pathway when an existing dependency cannot function.
24. Dependency Redundancy™
The availability of more than one suitable means of delivering a material protective function.
Redundancy must be proportionate; it is not a requirement to duplicate every service.
25. Dependency Recovery™
The process of restoring a failed institutional dependency or replacing it with a suitable alternative.
26. Dependency Failure Cascade™
A sequence in which failure of one institutional component causes additional failures elsewhere in the protective system.
27. Protective Cascade Risk™
The potential for one failed dependency to compromise several connected protective arrangements.
28. Institutional Dependency Debt™
The accumulated unresolved risk created by repeated reliance upon unverified, fragile or ineffective institutional dependencies.
29. Dependency Assurance™
The process of obtaining and evaluating evidence that material dependencies are operating sufficiently to support the intended safeguarding outcome.
PART III — DEPENDENCY CLASSIFICATION
30. Institutional Dependency Categories
ID1 — Information Dependency™
Protection requires information held by another institution.
ID2 — Decision Dependency™
Action requires a decision or authorisation by another actor.
ID3 — Authority Dependency™
The protective function depends upon powers held elsewhere.
ID4 — Resource Dependency™
Protection requires funding, equipment, accommodation, staffing or other resources.
ID5 — Operational Dependency™
One action must occur before another can be implemented.
ID6 — Professional Dependency™
Protection relies upon specialist assessment, expertise or intervention.
ID7 — Technological Dependency™
A digital platform, database, communication system or technical service is necessary.
ID8 — Communication Dependency™
Effective protection requires timely transmission and understanding of information.
ID9 — Temporal Dependency™
Protective success depends upon actions occurring within a particular period or sequence.
ID10 — Participation Dependency™
An intervention relies upon an affected person's ability to participate, communicate, travel or access the process.
ID11 — Legal or Procedural Dependency™
A protective action requires compliance with a lawful procedural step or authorisation.
ID12 — Verification Dependency™
An institution relies upon another actor to confirm that protective action occurred or remains effective.
31. Dependency Criticality Classification
DC1 — Incidental
Failure is unlikely to affect material protection.
DC2 — Relevant
Failure may cause inconvenience or limited disruption.
DC3 — Material
Failure may impair an important protective function.
DC4 — Serious
Failure may significantly weaken safeguarding protection.
DC5 — Critical
Failure may cause substantial protective breakdown or exposure to potentially severe harm.
Criticality should reflect the actual protective context rather than organisational status or administrative priority.
32. Dependency Operational Status
DS1 — Identified
Dependency recognised but not yet operationally assessed.
DS2 — Requested
Required action or service requested.
DS3 — Accepted
Relevant actor has accepted the request or responsibility.
DS4 — Capacity Confirmed
Necessary operational capability has been established.
DS5 — Active
Required action or service is operating.
DS6 — Verified
Operational performance has been appropriately confirmed.
DS7 — Disrupted
Dependency is delayed, impaired or interrupted.
DS8 — Failed
Dependency cannot presently deliver the required function.
DS9 — Replaced
Suitable alternative arrangements are operating.
DS10 — Closed
Dependency no longer required or has been appropriately discharged.
33. No-Status-Inflation Principle™
A dependency should not be recorded as implemented, operational or completed merely because an earlier administrative stage has occurred.
For example, a referral acknowledgement should not automatically be recorded as successful service delivery.
PART IV — CROSS-INSTITUTIONAL RESPONSIBILITY AND RELIANCE
34. Responsibility–Dependency Separation™
Responsibility identifies who is expected or required to act.
Dependency identifies what must occur for the intended protective outcome to be achieved.
These concepts overlap but are not interchangeable.
35. Distributed Responsibility™
A protective process may require several actors to fulfil distinct responsibilities.
36. Distributed Dependency Risk™
A condition in which material safeguarding dependencies are spread across multiple actors without adequate coordination, verification or contingency.
37. Collective Protection Gap™
A gap arising where each participating institution may perform its assigned task but the combined system fails to deliver the intended protective outcome.
38. Institutional Reliance Gap™
The difference between what an institution assumes another actor has delivered and what that actor has actually delivered.
39. Responsibility Transfer Integrity™
When responsibility transfers, institutions should distinguish:
Notification of transfer.
Acceptance of transfer.
Transfer of material information.
Confirmation of operational capability.
Continuity of protective arrangements.
Confirmation of the receiving actor's next action.
40. No-Unverified-Transfer Principle™
Where ongoing safeguarding protection depends upon a receiving institution, the transferring institution should not assume that the dependency has been satisfied solely because information has been sent.
The extent of continuing responsibility depends upon the applicable legal and operational context.
41. Cross-Institutional Reliance Mapping™
A reliance map should identify:
Institution A: What it needs from Institution B.
Institution B: What it has agreed or is required to provide.
Dependency: What protective function relies upon that action.
Deadline or Trigger: When the action is needed.
Verification: How completion will be established.
Failure Response: What happens if the dependency is not satisfied.
42. Institutional Reliance Transparency™
Material assumptions about another organisation's responsibilities, capacity or actions should be identifiable and capable of appropriate verification.
43. No-Collective-Assumption Principle™
The involvement of multiple organisations should not itself be treated as evidence that safeguarding responsibility has been adequately coordinated.
PART V — PROTECTIVE DEPENDENCY FAILURE
44. Dependency Failure™
A condition in which a material dependency does not deliver the required protective function.
45. Dependency Delay™
A material dependency remains incomplete beyond the point at which its performance is needed.
46. Dependency Timing Failure™
A protective component becomes available too late to serve its intended safeguarding purpose.
47. Dependency Accessibility Failure™
A service exists but cannot realistically be accessed by the person requiring protection.
48. Dependency Capacity Failure™
An institution accepts or holds responsibility but lacks sufficient operational capacity to fulfil the relevant function.
49. Dependency Communication Failure™
Required information is not transmitted, received, understood or acted upon in a sufficiently effective manner.
50. Dependency Authority Failure™
A protective action is expected from an actor who lacks the necessary authority or lawful power.
51. Dependency Verification Failure™
An institution cannot establish whether the action upon which it relies has occurred.
52. Dependency Continuity Failure™
A necessary protective function is interrupted during transfer, transition or service change.
53. Dependency Recovery Failure™
A known dependency failure persists without effective repair, alternative arrangements or appropriate escalation.
54. Dependency Failure Propagation™
A dependency failure can produce consequences beyond its originating institution.
For example:
Delayed Assessment → Delayed Decision → Delayed Resource Allocation → Delayed Intervention → Extended Exposure
55. Dependency Failure Materiality™
Institutions should evaluate not only the failed action but also the protective consequences resulting from its failure.
PART VI — DEPENDENCY AND SAFEGUARDING ACCESS
56. Functional Access Dependency™
A protective service may depend upon the affected person's ability to access transport, communication, identification, documentation, accommodation, technology or professional support.
57. Participation–Dependency Integrity™
An institution should assess whether the practical conditions necessary for participation exist.
A safeguarding plan may be formally available but functionally inaccessible.
58. Hidden Survivor Dependency™
A protective arrangement may depend upon the affected person undertaking substantial coordination that is not explicitly recognised within the plan.
59. Survivor-as-System-Integrator™
A condition in which the affected person becomes responsible for coordinating multiple institutional dependencies necessary for their own protection.
60. No-Survivor-as-Dependency-Manager Principle™
Institutions should not unnecessarily transfer the coordination of material institutional safeguarding dependencies to the person requiring protection.
61. Dependency Burden Transfer™
The movement of coordination, verification or failure-management responsibilities from institutional actors onto affected individuals.
62. Protective Capacity Mismatch™
A condition in which a safeguarding plan assumes a level of personal, financial, physical, technological or administrative capacity that the affected person does not possess.
63. Functional Dependency Review™
For each material protective dependency, assess:
What action is required?
Who must perform it?
What resources are necessary?
What practical barriers exist?
What happens if the affected person cannot perform an assumed task?
Is an alternative available?
PART VII — DEPENDENCY RESILIENCE ARCHITECTURE
64. Protective Resilience™
The ability of the safeguarding system to maintain or restore essential protective functions despite disruption to individual institutional components.
65. Resilience-by-Design Principle™
Critical safeguarding dependencies should be assessed for foreseeable failure before the protective arrangement is relied upon.
66. Dependency Failure Scenario™
A structured examination of what happens when a particular institutional dependency becomes unavailable.
67. Single-Point Failure Test™
Ask:
If this institution, service, person or system became unavailable tomorrow, would the protective arrangement remain effective?
68. Contingency Integrity™
The extent to which alternative protective arrangements are sufficiently realistic, accessible, lawful and capable of activation.
69. Contingency Activation Trigger™
An identifiable condition requiring review or activation of an alternative protective pathway.
70. Recovery Time Integrity™
The relationship between the time needed to restore a failed dependency and the time within which safeguarding protection is required.
71. Protective Tolerance Window™
The period during which a dependency can remain disrupted without materially compromising the protective objective.
72. Dependency Recovery Priority™
Recovery priority should consider:
Potential severity of harm.
Urgency.
Degree of reliance.
Availability of alternatives.
Number of dependent functions.
Existing exposure.
Operational feasibility.
73. No-Paper-Contingency Principle™
A contingency should not be considered effective solely because it appears in a safeguarding plan.
It must be sufficiently realistic to operate when needed.
PART VIII — DEPENDENCY GOVERNANCE INSTRUMENTS
74. SAFECHAIN™ Institutional Dependency Map™
The map should identify:
Protective Objective:
Required Action:
Institutional Actor:
Dependency Type:
Criticality:
Operational Status:
Responsible Owner:
Receiving Actor:
Required Time:
Verification Evidence:
Potential Failure:
Safeguarding Consequence:
Contingency:
Review Trigger:
75. Institutional Dependency Register™
A structured record of material safeguarding dependencies and their operational status.
76. Dependency Reliance Register™
Records the assumptions made by each institution concerning the performance of other actors.
77. Critical Dependency Register™
Tracks dependencies classified DC4 or DC5.
78. Dependency Failure Register™
Records disrupted or failed dependencies, consequences, escalation and remediation.
79. Dependency Recovery Register™
Tracks restoration or substitution of failed protective functions.
80. Cross-Institutional Responsibility Matrix™
Identifies:
Accountable institution.
Operational owner.
Contributing institutions.
Information provider.
Decision authority.
Delivery responsibility.
Verification responsibility.
Escalation route.
81. Dependency Closure Record™
Closure should identify:
Whether the dependency was satisfied.
Whether it remains necessary.
Whether responsibility transferred.
Whether protective continuity was maintained.
Whether outstanding risks remain.
What evidence supports closure.
PART IX — INSTITUTIONAL DEPENDENCY METRICS
82. Core Measurement Architecture
Dependency Identification Rate™
The proportion of sampled material safeguarding plans with identifiable critical dependencies.
Dependency Ownership Rate™
The proportion of material dependencies with an identifiable operational owner.
Dependency Verification Rate™
The proportion of material dependencies supported by appropriate operational confirmation.
Unverified Reliance Rate™
The proportion of material dependencies being relied upon without sufficient verification.
Critical Dependency Failure Rate™
The proportion of critical dependencies experiencing material failure during the assessment period.
Dependency Recovery Time™
The period between recognition of material failure and restoration or substitution of the protective function.
Dependency Contingency Readiness Rate™
The proportion of critical dependencies with appropriate and operationally credible contingency arrangements.
Cross-Institutional Handover Integrity Rate™
The proportion of sampled transfers meeting defined acceptance, information and continuity requirements.
Dependency Cascade Rate™
The proportion of recorded material dependency failures producing additional connected failures.
Protective Dependency Assurance Rate™
The proportion of material dependencies whose operational contribution to protection has been appropriately verified.
83. Measurement Limitations
High referral completion rates do not necessarily establish protective effectiveness.
High dependency verification rates do not establish that the overall safeguarding outcome was achieved.
Metrics should be interpreted alongside case complexity, risk severity, service availability, operational evidence and protective outcomes.
PART X — FIFTEEN DEPENDENCY INTEGRITY GATES
Gate 1 — Protective Objective
What safeguarding outcome is required?
Gate 2 — Dependency Identification
What actions, information, authority or resources are necessary?
Gate 3 — Institutional Mapping
Which actors control the required components?
Gate 4 — Criticality
How serious would failure be?
Gate 5 — Responsibility
Who owns the relevant obligation or operational task?
Gate 6 — Reliance
What assumptions are being made about other actors?
Gate 7 — Capacity
Can the required institution perform the function?
Gate 8 — Accessibility
Can the protective service actually be accessed?
Gate 9 — Timing
Will the dependency operate when needed?
Gate 10 — Communication
Has necessary information been transmitted and understood?
Gate 11 — Verification
Has operational completion been confirmed?
Gate 12 — Contingency
What happens if the dependency fails?
Gate 13 — Escalation
Who responds to disruption?
Gate 14 — Protective Outcome
Has the dependency contributed to the intended protection?
Gate 15 — Assurance
Can the dependency pathway be independently reconstructed and evaluated?
PART XI — DEPENDENCY STRESS TESTS
ST1 — Referral Failure Test™
A safeguarding referral is sent but not accepted.
Does the originating institution identify the unresolved dependency?
ST2 — Capacity Failure Test™
A receiving service accepts responsibility but lacks available capacity.
Does the protective plan adapt?
ST3 — Single-Agency Withdrawal Test™
One essential agency withdraws.
Can the remaining system maintain protection?
ST4 — Communication Failure Test™
Critical information is sent but not received.
Does the system detect the failure?
ST5 — Timing Test™
A required intervention is delayed beyond the point of need.
Is the safeguarding consequence recognised?
ST6 — Authority Test™
An institution is expected to perform an action outside its powers.
Is the responsibility mismatch identified?
ST7 — Survivor Capacity Test™
The protective plan depends upon the affected person performing tasks they cannot realistically complete.
Is an accessible alternative available?
ST8 — Technology Failure Test™
A critical digital system becomes unavailable.
Can safeguarding functions continue?
ST9 — Staff Handover Test™
A responsible professional leaves before the dependency is satisfied.
Does ownership survive the transition?
ST10 — Multi-Agency Assumption Test™
Every organisation believes another actor is managing the risk.
Can the accountability gap be detected?
ST11 — Protective Cascade Test™
One failed dependency disrupts three further protective actions.
Can the institution identify and contain the cascade?
ST12 — Recovery Test™
A critical dependency fails.
Can the system restore or substitute the necessary protective function within an appropriate period?
PART XII — DEPENDENCY COUNTERFACTUALS
84. Single-Point Failure Counterfactual™
Would protection remain effective if the most important institutional dependency failed?
85. No-Referral-Completion Counterfactual™
What would happen if a referral were never accepted, despite having been sent?
86. Survivor Non-Coordination Counterfactual™
Would the safeguarding arrangement continue to function if the affected person stopped coordinating institutional actors?
87. Capacity Counterfactual™
Would the plan remain realistic if the receiving institution lacked the assumed resources?
88. Timing Counterfactual™
Would the protective action still be effective if delivered after the identified risk period?
89. Whole-System Dependency Counterfactual™
Could every institution demonstrate completion of its assigned administrative task while the collective protective objective remained unmet?
PART XIII — FAILURE TAXONOMY
90. Dependency Failure Classifications
DF1 — Identification Failure™: Material dependency not recognised.
DF2 — Mapping Failure™: Required institutional actors not identified.
DF3 — Ownership Failure™: No clear responsibility for monitoring the dependency.
DF4 — Reliance Failure™: Unsupported assumptions about another actor's performance.
DF5 — Capacity Failure™: Required capability unavailable.
DF6 — Accessibility Failure™: Service inaccessible in practice.
DF7 — Timing Failure™: Dependency delivered too late.
DF8 — Communication Failure™: Necessary information not effectively exchanged.
DF9 — Verification Failure™: Operational completion not established.
DF10 — Handover Failure™: Dependency disrupted during responsibility transfer.
DF11 — Contingency Failure™: No effective alternative when the dependency fails.
DF12 — Cascade Failure™: One failure compromises further protective functions.
DF13 — Recovery Failure™: Failed dependency not restored or substituted appropriately.
DF14 — Closure Failure™: Dependency closed while material protective obligations remain unresolved.
DF15 — Assurance Failure™: Institution cannot demonstrate operational effectiveness.
91. Root Causes
DRC1: Fragmented governance.
DRC2: Unclear responsibility allocation.
DRC3: Weak inter-agency agreements.
DRC4: Inadequate information exchange.
DRC5: Resource limitations.
DRC6: Excessive reliance upon individual professionals.
DRC7: Poor contingency planning.
DRC8: Inadequate handover controls.
DRC9: Administrative completion bias.
DRC10: Weak escalation mechanisms.
DRC11: Inadequate outcome verification.
DRC12: Insufficient independent assurance.
PART XIV — IMPLEMENTATION PROTOCOL
92. Implementation Objective
Embed institutional dependency recognition, ownership, verification, contingency and assurance within existing safeguarding operations.
93. Phase 1 — Baseline Dependency Assessment
Review existing:
Safeguarding plans.
Referral procedures.
Multi-agency protocols.
Responsibility matrices.
Information-sharing arrangements.
Escalation routes.
Service-level expectations.
Handover processes.
Contingency plans.
Outcome assurance.
94. Phase 2 — Critical Dependency Identification
Select safeguarding functions where failure could materially compromise protection.
Map the institutions, resources and decisions required to deliver each function.
95. Phase 3 — Responsibility and Reliance Mapping
For each material dependency, record:
Responsible actor.
Required contribution.
Receiving actor.
Operational owner.
Timing requirement.
Verification method.
Failure consequence.
96. Phase 4 — Dependency Acceptance Controls
Establish proportionate confirmation mechanisms for referrals, transfers and other material institutional handoffs.
Distinguish receipt, acceptance, capacity and implementation.
97. Phase 5 — Critical Dependency Monitoring
Prioritise DC4 and DC5 dependencies for enhanced monitoring.
Define review and escalation arrangements according to safeguarding risk.
98. Phase 6 — Contingency Design
Identify realistic alternatives for foreseeable critical dependency failures.
Confirm that alternatives are accessible, lawful and operationally feasible.
99. Phase 7 — Survivor Dependency Review
Examine whether the protective plan places unrealistic coordination or implementation burdens upon the affected person.
100. Phase 8 — Operational Testing
Conduct realistic exercises involving:
Referral failure.
Delayed intervention.
Staff absence.
System outage.
Service withdrawal.
Unavailable resources.
101. Phase 9 — Governance Oversight
Establish reporting of:
Unverified critical dependencies.
Failed handovers.
Dependency delays.
Repeated service gaps.
Contingency failures.
Unresolved recovery actions.
102. Phase 10 — Independent Assurance
Test whether operational evidence supports institutional claims that material dependencies are functioning.
PART XV — OPERATIONAL RESPONSE PROTOCOL
103. Dependency Response Sequence
Identify → Classify → Assign → Confirm → Monitor → Detect Failure → Escalate → Substitute or Restore → Verify → Learn
104. Failure Response Requirements
When a material dependency fails:
Identify the failed component.
Assess the immediate safeguarding consequence.
Determine whether other dependencies are affected.
Identify available interim protection.
Notify relevant responsible actors.
Activate appropriate escalation.
Implement recovery or substitution.
Verify the restored protective function.
Record learning and control improvements.
105. Critical Dependency Escalation
A DC5 failure should trigger urgent consideration of protective consequences and available escalation arrangements.
The response should reflect actual risk, lawful authority, available resources and the need for timely action.
PART XVI — AUDIT AND ASSURANCE PROTOCOL
106. Audit Objective
Determine whether material safeguarding dependencies are identified, owned, operationally confirmed, appropriately monitored and resilient to foreseeable institutional failure.
107. Audit Population
Include:
Single-agency safeguarding plans.
Multi-agency safeguarding plans.
Cases involving critical referrals.
Cases involving service delays.
Cases involving responsibility transfer.
Cases involving inaccessible services.
Cases involving protective failure.
Cases involving contingency activation.
108. Audit Evidence Hierarchy
AE1 — Policy Evidence
AE2 — Control Design Evidence
AE3 — Dependency Record Evidence
AE4 — Operational Confirmation Evidence
AE5 — Protective Outcome Evidence
AE6 — Independent Assurance Evidence
109. Forward Dependency Audit
Trace:
Protective Objective → Dependency → Responsible Actor → Operational Confirmation → Delivery → Outcome
110. Reverse Protective Outcome Audit
Begin with a protective outcome or failure.
Trace backwards to:
Required dependencies.
Institutional responsibilities.
Assumptions.
Capacity.
Handover.
Timing.
Verification.
Contingency.
111. Dependency Failure Audit
Select a material failure.
Determine:
Whether the dependency was previously recognised.
Whether the failure was foreseeable.
Whether monitoring detected it.
Whether escalation occurred.
Whether protection was maintained.
Whether recovery was effective.
112. Cross-Institutional Reliance Audit
Compare the assumptions recorded by participating organisations with their actual responsibilities, acceptance and operational performance.
113. Survivor Burden Audit
Where appropriate, examine whether affected individuals were required to:
Coordinate institutions.
Repeat information.
Chase referrals.
Verify professional actions.
Arrange essential resources.
Resolve responsibility disputes.
Determine whether those burdens were necessary, proportionate and realistically manageable.
PART XVII — AUDIT SCORING
114. Fourteen Audit Domains
Dependency Identification.
Dependency Classification.
Responsibility Allocation.
Institutional Reliance.
Operational Capacity.
Functional Accessibility.
Timing Integrity.
Communication Integrity.
Handover Integrity.
Dependency Verification.
Contingency Readiness.
Failure Detection and Escalation.
Protective Recovery.
Governance Assurance.
115. Scoring Model
Each domain receives a score from 0 to 5.
0 — Absent
1 — Weak
2 — Developing
3 — Functional
4 — Strong
5 — Assured
Maximum score: 70 points.
116. Audit Integrity Bands
0–14: Critical Dependency Integrity Failure™
15–28: Weak Dependency Integrity™
29–42: Developing Dependency Integrity™
43–55: Functional Dependency Integrity™
56–64: Strong Dependency Integrity™
65–70: Assured Dependency Integrity™
These are proposed internal framework bands rather than externally validated performance benchmarks.
117. Critical Override Rule
A favourable aggregate score should not conceal:
An unrecognised critical dependency.
Known critical failure without appropriate protective consideration.
Repeated unverified reliance affecting serious safeguarding decisions.
Systemic failure of critical handovers.
Absence of workable contingency for foreseeable severe disruption.
Material protective failure concealed by administrative completion reporting.
Critical findings require proportionate investigation and governance oversight.
118. Audit Finding Classification
DAF1 — Observation
DAF2 — Improvement Required
DAF3 — Material Weakness
DAF4 — Serious Dependency Integrity Failure
DAF5 — Critical Dependency Integrity Failure
119. Remediation Architecture
Finding → Root Cause → Corrective Action → Owner → Deadline → Implementation → Verification → Retest → Closure
120. Assurance Structure
Operational Dependency Control → Governance Monitoring → Independent Assurance
PART XVIII — INSTITUTIONAL DEPENDENCY MATURITY MODEL
IDM1 — Assumption-Dependent™
Safeguarding relies substantially upon informal or unverified institutional assumptions.
IDM2 — Reactive™
Dependency failures are recognised primarily after disruption occurs.
IDM3 — Structured™
Material dependencies are mapped, classified and assigned.
IDM4 — Integrated™
Dependency verification, monitoring, contingency and recovery are embedded within safeguarding operations.
IDM5 — Resilient and Assured™
Critical dependencies are actively managed, foreseeable failures are tested and protective continuity is supported by independent operational evidence.
PART XIX — INSTITUTIONALDEPENDENCY-001™ INTEGRITY TEST
An institution should be able to demonstrate that:
Material safeguarding dependencies can be identified.
Protective objectives are clearly defined.
Required institutional contributions are mapped.
Information dependencies are recognised.
Decision dependencies are recognised.
Authority dependencies are recognised.
Resource dependencies are recognised.
Operational dependencies are recognised.
Professional dependencies are recognised.
Technological dependencies are recognised.
Communication dependencies are recognised.
Temporal dependencies are recognised.
Participation dependencies are recognised.
Procedural dependencies are recognised.
Verification dependencies are recognised.
Dependency criticality can be classified.
Operational status is accurately recorded.
Referral submission is distinguished from receipt.
Receipt is distinguished from acceptance.
Acceptance is distinguished from capacity.
Capacity is distinguished from implementation.
Implementation is distinguished from protective effectiveness.
Responsibility is distinguished from dependency.
Distributed responsibilities are identified.
Collective protection gaps can be recognised.
Institutional reliance gaps can be identified.
Assumed dependencies are recorded.
Unverified reliance can be detected.
Dependency exposure is assessed.
Dependency concentration is assessed.
Single-point protective dependencies are identified.
Dependency fragility can be evaluated.
Dependency resilience can be assessed.
Dependency substitution can be considered.
Proportionate redundancy can be considered.
Dependency recovery arrangements exist.
Dependency failure cascades can be identified.
Protective cascade risk is assessed.
Institutional dependency debt can be recognised.
Dependency assurance is evidence-based.
Responsibility transfers are recorded.
Receiving actors are identified.
Material information accompanies transfer.
Transfer acceptance can be confirmed.
Operational capacity can be confirmed.
Protective continuity is considered during transfer.
Institutional reliance assumptions are transparent.
Multi-agency involvement is not automatically treated as collective accountability.
Dependency failures can be classified.
Dependency delays can be identified.
Dependency timing failures can be detected.
Dependency accessibility failures can be detected.
Dependency capacity failures can be detected.
Dependency communication failures can be detected.
Dependency authority failures can be detected.
Dependency verification failures can be detected.
Dependency continuity failures can be detected.
Dependency recovery failures can be detected.
Failure propagation can be mapped.
Material safeguarding consequences are assessed.
Functional access dependencies are considered.
Participation dependencies are assessed.
Hidden survivor dependencies can be identified.
Survivor-as-system-integrator conditions can be recognised.
Unnecessary dependency burden transfer is avoided.
Protective capacity mismatch can be assessed.
Relevant personal accessibility needs are considered.
Protective resilience is considered during design.
Foreseeable critical failures are examined.
Single-point failure testing can be performed.
Contingency integrity can be evaluated.
Contingency activation triggers are defined.
Recovery time is assessed against protective need.
Protective tolerance windows are considered.
Recovery priorities reflect safeguarding consequences.
Paper contingencies are distinguished from operational alternatives.
Institutional Dependency Maps can be produced.
Dependency Registers can be maintained.
Reliance Registers can be maintained.
Critical Dependency Registers can be maintained.
Failure Registers can be maintained.
Recovery Registers can be maintained.
Responsibility matrices can be produced.
Dependency closure is evidence-based.
Dependency identification can be measured.
Dependency ownership can be measured.
Dependency verification can be measured.
Unverified reliance can be measured.
Critical dependency failure can be measured.
Dependency recovery time can be measured.
Contingency readiness can be measured.
Handover integrity can be measured.
Dependency cascades can be measured.
Protective dependency assurance can be measured.
Administrative completion is not confused with protective effectiveness.
All fifteen Dependency Integrity Gates can be applied.
Referral failure can be stress-tested.
Capacity failure can be stress-tested.
Agency withdrawal can be stress-tested.
Communication failure can be stress-tested.
Timing failure can be stress-tested.
Authority mismatch can be stress-tested.
Survivor capacity can be stress-tested.
Technology failure can be stress-tested.
Staff handover can be stress-tested.
Multi-agency assumption can be stress-tested.
Protective cascades can be stress-tested.
Recovery capability can be stress-tested.
Single-point failure counterfactuals can be applied.
Referral counterfactuals can be applied.
Survivor non-coordination counterfactuals can be applied.
Capacity counterfactuals can be applied.
Timing counterfactuals can be applied.
Whole-system dependency counterfactuals can be applied.
Dependency failures can be classified consistently.
Root causes can be investigated.
Institutional baseline assessments can be conducted.
Critical dependencies can be mapped.
Responsibility and reliance controls are operational.
Acceptance controls are operational.
Critical dependency monitoring is operational.
Contingency controls are operational.
Survivor dependency burdens are reviewed.
Operational exercises are conducted.
Governance receives visibility of critical failures.
Independent assurance tests operational performance.
Forward dependency audits can be performed.
Reverse outcome audits can be performed.
Dependency failure audits can be performed.
Cross-institutional reliance audits can be performed.
Survivor burden audits can be performed.
Audit evidence supports findings.
Audit scoring is consistently applied.
Critical overrides prevent serious failures being concealed.
Findings are classified.
Corrective actions have responsible owners.
Remediation is verified.
Failed dependencies are appropriately restored or substituted.
Recovery is independently retested where appropriate.
Closure requires evidence of completion.
Institutional maturity can be assessed.
Repeated dependency failures trigger governance review.
Institutional learning informs contingency design.
Dependency management survives personnel changes.
Dependency information survives system transitions.
Critical dependency ownership remains identifiable.
Cross-institutional responsibility disputes can be escalated.
The institution can demonstrate whether essential protective components are functioning.
Protective outcomes are reviewed separately from administrative completion.
The collective safeguarding system can demonstrate that material dependencies are sufficiently recognised, coordinated, verified and resilient to support the intended protective outcome.
PART XX — ULTIMATE INSTITUTIONAL TEST
Can the institutions involved demonstrate that the protective outcome depends upon clearly identified actions, information, decisions, resources and capabilities; that each material dependency has appropriate ownership; that assumptions concerning other organisations have been verified; that referrals and transfers have progressed beyond administrative completion into operational action; that foreseeable failures have realistic contingencies; that disruption triggers timely escalation and recovery; that the affected person is not unnecessarily required to coordinate the institutional system; and that the combined protective arrangement works in practice rather than merely appearing complete within separate institutional records?
If not:
Individual institutional responsibilities may have been allocated, but cross-institutional dependency integrity and safeguarding resilience have not yet been sufficiently assured.
PART XXI — FRAMEWORK STATEMENT
INSTITUTIONALDEPENDENCY-001™ establishes that safeguarding effectiveness cannot be determined solely by examining whether individual institutions have completed their assigned tasks.
Where protection depends upon interconnected institutional actions, safeguarding integrity requires visibility of the entire dependency pathway.
The framework distinguishes responsibility from reliance, referral from acceptance, acceptance from capacity, capacity from implementation and implementation from verified protection.
It recognises that institutional dependencies may be legitimate and unavoidable. The governance failure arises when material dependencies are assumed rather than verified, when failures are not detected, when contingencies are ineffective or when the affected person becomes responsible for coordinating the institutions upon which their protection depends.
SAFECHAIN™ therefore treats dependency mapping, operational confirmation, contingency readiness, recovery and independent assurance as essential components of safeguarding resilience.
The central question is not simply whether each institution performed its task. It is whether the institutions together delivered the protection upon which the person depended.
COPYRIGHT & INTELLECTUAL PROPERTY NOTICE
© 2026 Samantha Avril-Andreassen. All Rights Reserved.
The SAFECHAIN™ Cross-Institutional Dependency, Reliance & Safeguarding Resilience Framework™ — INSTITUTIONALDEPENDENCY-001™ — is an original safeguarding governance, institutional reliance, protective continuity and systems-resilience framework developed and authored by Samantha Avril-Andreassen, LLB (Hons), LLM, LPC, FRSA, Founder of SAFECHAIN™.
The original selection, arrangement and expression of its analytical architecture, classifications, governance controls, registers, dependency maps, metrics, integrity gates, counterfactuals, stress tests, audit methodology, maturity model and Integrity Test are protected to the extent provided by applicable intellectual property law.
Framework-specific expressions include Institutional Dependency™, Protective Dependency™, Dependency Integrity™, Dependency Visibility™, Assumed Dependency™, Unverified Reliance™, Dependency Exposure™, Dependency Concentration™, Single-Point Protective Dependency™, Dependency Fragility™, Dependency Resilience™, Dependency Failure Cascade™, Institutional Dependency Debt™, Dependency Assurance™, Distributed Dependency Risk™, Collective Protection Gap™, Institutional Reliance Gap™, Hidden Survivor Dependency™, Survivor-as-System-Integrator™, Dependency Burden Transfer™, Protective Tolerance Window™ and related SAFECHAIN™ architecture.
No exclusive ownership is claimed over generic concepts of inter-agency cooperation, dependency management, resilience engineering, safeguarding, risk management or organisational governance independently existing outside the original framework.
INSTITUTIONALDEPENDENCY-001™ is a safeguarding governance and systems-analysis instrument. It does not independently establish statutory duties, legal responsibility, regulatory non-compliance, negligence or institutional liability. Application must account for relevant legal authority, professional responsibilities, information-sharing requirements, available resources and applicable safeguarding obligations.
Framework Reference: INSTITUTIONALDEPENDENCY-001™
Version: 1.0
Author: Samantha Avril-Andreassen, LLB (Hons), LLM, LPC, FRSA
Organisation: SAFECHAINN Ltd
© 2026 Samantha Avril-Andreassen. All Rights Reserved.