PROTO-001 SAFECHAIN™ Prototype Specification™
SAFECHAIN™ | PROTOTYPE DEVELOPMENT SERIES | PROTO™
PROTO-001 — Version 1.0 | PROTOTYPE SPECIFICATION
SAFECHAIN™ PROTOTYPE
SPECIFICATION™
The Governance and Operational Blueprint for the First SAFECHAIN™ Vulnerability Verification Prototype
Document Reference: PROTO-001
Series: Prototype Development Series™
Version: 1.0
Author: Samantha Avril-Andreassen FRSA
Status: Published — Implementation Partner Distribution
Date: June 2026
Classification: Restricted — Implementation Partner, Government and Investor Distribution
Technical Architecture Reference: SAT-001 — SAFECHAIN™ Technical Architecture™
Publisher: SAFECHAINN Ltd (Company No. 12038453)
Contact: samantha@safe-chain.org | safe-chain.org
Executive Summary
The SAFECHAIN™ Prototype Specification™ (PROTO-001) is the governance and operational blueprint for the first SAFECHAIN™ vulnerability verification prototype — the working implementation of the NVI™ five-layer infrastructure model in a defined, bounded, and independently evaluable operating environment. It defines what the prototype does, what it must demonstrate, how it is governed, how it is evaluated, and what the successful completion of the prototype phase enables in terms of the national implementation and adoption journey.
The prototype is not a proof of concept. The SAFECHAIN™ constitutional stack — the SIS™, NVI™, and NOM™ series — has already established the conceptual architecture. The prototype is a proof of operation: the demonstration that the governance and operational architecture defined in that stack can be implemented in real institutions, with real practitioners, handling real safeguarding intelligence, under real governance obligations, and producing measurable improvements in real safeguarding outcomes.
PROTO-001 is a governance and operational document. The technical architecture that underlies the prototype — the identity management, data architecture, API specifications, security architecture, and technology stack — is defined in SAT-001 (SAFECHAIN™ Technical Architecture™). PROTO-001 defines what the prototype must achieve and how its governance operates; SAT-001 defines how the technical infrastructure achieves it. The two documents are complementary and should be read together by implementation partners responsible for both governance and technical delivery.
This specification covers: the introduction and prototype's position in the NVM architecture; the theoretical foundation for prototype-first implementation; governance principles specific to the prototype phase; the prototype scope and operating boundaries; the implementation framework across five governance domains; the operational model for the prototype's day-to-day governance; the evaluation architecture; the technical governance interface; the pathway to pilot programme; and the conclusion.
1. Introduction
1.1 Why a Prototype Precedes the Pilot
The NVI-010 pilot programme (three regional sites, 24-month evaluation) is the SAFECHAIN™ operating system's primary evidence-generation vehicle for national adoption. But the pilot programme cannot begin without a working, tested, governance-compliant version of the NVI™ five-layer infrastructure being available to pilot site institutions. The prototype phase, defined in PROTO-001, builds that working version — testing the governance and operational architecture in a controlled environment before deploying it in the full pilot programme.
The prototype-before-pilot sequencing reflects a discipline that complex governance infrastructure programmes consistently fail to apply: the discipline of testing governance architecture in practice before committing to it at scale. The pilot programme will test whether the NVM network works in diverse real-world safeguarding environments. The prototype tests whether the NVM network's governance architecture works at all — whether the EPE™ governance sequence operates as designed, whether the CIF™ records the intelligence the VVS™ requires for verification, whether the IAR™ creates the accountability records the Trust Authority's Constitutional Integrity Audit needs, and whether the consent architecture of NVI-002 is operationally functional in the complex, multi-party consent environments of live safeguarding practice.
1.2 Prototype Scope
The prototype operates in a single institution cluster — a defined set of institutions that together represent all five NVM participant categories: police, local authority (adult and children's social care), housing authority, NHS Trust, and at minimum one FCA-regulated financial institution. The cluster is connected through the prototype NVI™ network infrastructure, implementing all five layers of the NVI-001 five-layer model in a real safeguarding intelligence environment. The prototype handles real safeguarding intelligence about real individuals, under full NVI-002 consent governance, and generates real accountability records in the prototype IAR™.
The prototype does not use synthetic or anonymised data — because the governance architecture it tests is a governance architecture for real safeguarding intelligence, and the consent, proportionality, and accountability obligations it must demonstrate can only be demonstrated with real intelligence under real governance conditions. This creates the most significant governance challenge of the prototype phase: ensuring that the individuals whose intelligence is within the prototype system are fully informed, genuinely consented, and completely protected under all NVI-002 rights provisions.
2. Theoretical Foundation
2.1 The Governance-First Prototype Principle
PROTO-001 is built on the Governance-First Prototype Principle: the principle that the prototype's primary purpose is to demonstrate governance operation, not technical capability. The technical capability of the NVM infrastructure — secure data transmission, CIF™ record generation, EPE™ governance sequence execution, IAR™ tamper-evident logging — is specified in SAT-001 and is demonstrable in a controlled technical environment without real safeguarding intelligence. The governance capability — whether institutions actually use the CIF™ correctly under live safeguarding pressure, whether practitioners complete the proportionality assessment accurately in real exchange events, whether the consent architecture of NVI-002 functions in the complex, emotionally charged, time-pressured environments of live domestic abuse safeguarding — can only be demonstrated in a real governance environment.
The Governance-First Prototype Principle determines the prototype's design at every level: the prototype is evaluated against governance outcomes, not technical metrics; the prototype governance body (defined in Section 5) exercises genuine governance authority over the prototype's operation, not merely advisory oversight; and the prototype's evaluation outputs are governance assessments, not technical test reports.
2.2 What a Successful Prototype Demonstrates
A successful PROTO-001 prototype demonstrates six governance propositions that the NVM pilot programme and national rollout depend on:
1. That participating institutions can generate CIF™-compliant intelligence records in the course of their existing safeguarding practice without disproportionate additional burden on practitioners.
2. That the VVS™ five-domain verification process produces reliable, consistent quality ratings that meaningfully differentiate between high-quality and low-quality intelligence submissions.
3. That the EPE™ seven-step governance sequence completes within operationally viable timeframes for standard exchange events while maintaining the full governance rigour the NVI-002 consent and proportionality framework requires.
4. That the IAR™ accountability record is sufficient, in its depth and attribution, to support the accountability tracing that the NOM-005 SAAF™ audit framework requires.
5. That the NVI-002 consent architecture is operationally functional in the complex consent environments of live domestic abuse safeguarding — including the four-tier consent architecture's Tier 3 and Tier 4 provisions.
6. That the multi-institutional Intelligence Engine cycle (SIS-001 Recognition → NVI-003 Exchange → SIS-004 Vulnerability Assessment → SIS-006 Trajectory Alert) produces demonstrably improved safeguarding intelligence for participating institutions' safeguarding decisions.
3. Governance Principles Specific to PROTO-001
Prototype Principle 1: Real Governance, Not Simulation
The prototype operates under the full NVI™ governance architecture — not a simplified or simulated version. Every CIF™ submission is verified against the full VVS™ five-domain standard. Every exchange event runs the full EPE™ seven-step sequence. Every IAR™ record meets the full accountability documentation standard. Every individual's consent is obtained under the full NVI-002 four-tier architecture. Simulating the governance reduces the prototype to a technical demonstration and eliminates its value as a governance proof.
Prototype Principle 2: Failure Is Learning
The prototype is expected to identify governance design gaps — elements of the NVI™ architecture that do not function as designed in real operational conditions. This is not a failure of the prototype; it is its purpose. Every governance gap identified in the prototype phase is a governance gap that is addressed before the pilot programme deploys the architecture across three sites simultaneously. The prototype governance board (defined in Section 5) treats governance gaps as learning events requiring design response, not as failures requiring explanation.
Prototype Principle 3: Individual Rights Are Absolute
The prototype's real-intelligence, real-consent approach means that the individuals whose safeguarding intelligence is within the prototype system have full NVI-002 rights — to access, correction, challenge, and withdrawal — that are enforced unconditionally. The prototype does not sacrifice individual rights for operational convenience. An individual who withdraws consent during the prototype receives immediate removal of their intelligence from the prototype network within the same timeframes that apply in the full NVM network. The prototype's operational demands cannot create exceptions to individual rights.
Prototype Principle 4: Evaluation Is Independent
The prototype evaluation (defined in Section 7) is conducted by an evaluator independent of SAFECHAIN™, independent of the participating institutions, and independent of the government departments funding the prototype. The evaluation findings are published without qualification. If the evaluation finds that the prototype governance architecture does not function as designed, that finding is published and the architecture is revised. The independent evaluation is the prototype's primary deliverable — not the technical implementation itself.
4. Prototype Scope and Boundaries
4.1 Operating Boundaries
The prototype operates within defined boundaries that make it governable, evaluable, and reversible. The geographic boundary is a single local authority area with a defined catchment that enables all five participant institution categories to be represented within a manageable network. The case scope boundary limits the prototype to domestic abuse safeguarding cases that meet the defined prototype eligibility criteria — ensuring that the governance architecture is tested in the case category for which it was primarily designed and that case complexity is manageable within the prototype governance capacity. The duration boundary sets the prototype at 12 months of operational running, with a six-month setup period for CIF™ implementation, practitioner training, consent architecture deployment, and governance body establishment.
4.2 What the Prototype Does Not Do
The prototype does not test the full NVM network at scale — that is the pilot programme's function. It does not test the Predictive Governance Model™ (Layer 5) in its full operational form — the data volume required for trajectory analysis at statistical confidence is not achievable in a single-area, 12-month prototype. It does not test the SAF™ accreditation process — participating institutions are assessed against provisional Foundation Certification criteria during the prototype, with full SAF™ certification following prototype completion. And it does not test the NOM-006 FSM™ five-stream funding model — prototype funding is provided through a dedicated prototype budget, not through the diversified funding architecture that the full network requires.
5. Implementation Framework: Five Governance Domains
Domain 1: Prototype Governance Body
The Prototype Governance Body (PGB) is the temporary governance authority for the prototype phase — exercising the functions that the NVI™ Oversight Body, Trust Authority, and Standards Board will exercise in the full network. The PGB comprises: a PGB Chair (independent — not employed by SAFECHAIN™ or any participating institution); a SAFECHAIN™ Governance Representative (Samantha Avril-Andreassen FRSA as constitutional authority); one representative from each participating institution category; an Independent Information Governance Adviser (for NVI-002 consent architecture oversight); a Lived Experience Representative (drawn from the domestic abuse survivor advocacy community); and the Independent Evaluator (non-voting, advisory capacity).
The PGB meets monthly during the prototype operational phase and holds an emergency session within 72 hours of any significant governance event — a consent breach, an IAR™ integrity issue, or a material deviation from the VVS™ verification standards. PGB decisions are recorded and published in the prototype governance log, which is publicly available throughout the prototype phase. The PGB's authority over the prototype is real: it can halt the prototype, require design changes, and publish adverse governance findings without prior reference to SAFECHAIN™ or to the funding government department.
Domain 2: Consent Architecture Deployment
The prototype's most significant governance implementation challenge is the deployment of the NVI-002 four-tier consent architecture in a real safeguarding environment. The consent architecture requires: accessible information provision in multiple formats and languages; trauma-informed consent engagement from trained practitioners; a fully functional four-tier consent recording system (from Active Informed Consent through Statutory Override); real-time consent record maintenance; and a functional withdrawal mechanism that produces immediate, verified removal of withdrawn intelligence from the prototype network within 24 hours.
The prototype consent architecture is implemented six months before the prototype operational phase begins — giving participating institutions and practitioners full training and practice with the consent engagement approach, the consent recording system, and the withdrawal mechanism before real safeguarding intelligence enters the prototype network. The Independent Information Governance Adviser conducts a consent architecture readiness assessment before the operational phase begins; the PGB receives the assessment report and makes a governance decision on readiness before authorising the operational launch.
Domain 3: CIF™ Implementation and Practitioner Training
CIF™ implementation in the prototype phase uses certified CIF™ middleware — a translation layer between participating institutions' existing information management systems and the NVI™ CIF™ standard — rather than requiring native CIF™ implementation within those systems. This approach reduces the prototype's technical burden on participating institutions while testing the governance outcomes that CIF™ implementation is designed to produce. The middleware approach is the expected implementation pathway for the majority of institutions during the early adoption phase; its prototype testing provides the operational evidence needed to refine the middleware certification standards before the pilot programme requires them at scale.
Practitioner training is delivered through the MØPIT™ recognition module and the prototype-specific CIF™ recording training programme, completing at least four weeks before the prototype operational launch. Training completion is a prerequisite for individual practitioner participation in the prototype; no practitioner generates prototype intelligence without completing the full training programme and passing the competency assessment.
Domain 4: VVS™ Verification Operations
The prototype VVS™ verification operation is staffed by SAFECHAIN™-accredited provisional verifiers — practitioners who have completed the NVI™ Verifier Accreditation Programme's foundation assessment and are operating under the supervision of a Senior Verifier during the prototype phase. Provisional verification under supervision is the governance pathway for building the verification workforce capacity required for the pilot programme while generating real verification quality data for the prototype evaluation.
The prototype targets a verification turnaround of seven working days for standard submissions and 48 hours for priority submissions — one working day longer than the full network targets, reflecting the additional governance oversight that provisional verification under supervision requires. All prototype verification findings — domain pass rates, quality rating distributions, remediation rates, and verifier supervision reports — are included in the prototype evaluation dataset.
Domain 5: IAR™ Accountability Recording
The prototype IAR™ is the accountability infrastructure that makes the prototype's governance outcomes auditable. Every prototype transaction — every CIF™ submission, every VVS™ verification event, every EPE™ exchange, every consent validation, every proportionality assessment — generates an IAR™ record that is maintained in the prototype accountability register. The register is tamper-evident, independently held by the prototype evaluator, and accessible to the PGB, to SAFECHAIN™, and to the Independent Information Governance Adviser. It is the evidential foundation for the prototype evaluation.
6. Operational Model
6.1 A Week in the Prototype
In a typical week of prototype operation, the Intelligence Engine cycle operates as follows. Domestic abuse cases meeting the prototype eligibility criteria — identified through the police, IDVA service, or local authority adult social care intake — are subject to the prototype consent engagement process. Where Active Informed Consent (Tier 1) is obtained, the practitioner generates a CIF™ intelligence submission within five working days of the recognition event. The submission is pre-screened by the CIF™ middleware for mandatory field completion; complete submissions are submitted to the provisional verifier. Verification is completed within seven working days; the institution receives the quality rating and Verification Certificate or Remediation Report. Verified intelligence is accessible through the prototype NSIE™ to the four other participating institutions; EPE™ exchange events — where one institution accesses another's verified intelligence — run the full seven-step governance sequence and generate IAR™ records. The PGB receives a weekly summary governance report covering submission volumes, verification outcomes, exchange events, consent events, and any governance exceptions.
6.2 Governance Exception Handling
The prototype identifies governance exceptions — events where the architecture does not operate as designed — and records them in the Prototype Exception Register. The Exception Register is the prototype's primary learning output: the documented record of the governance design gaps, operational challenges, and unexpected complexity that the prototype reveals in the NVI™ architecture. Every exception generates a design response — either an immediate operational adaptation within the prototype or a design amendment recommendation for the pilot programme architecture. The Exception Register is included in full in the prototype evaluation report.
7. Evaluation Architecture
7.1 The Five Evaluation Questions
7. Operational functionality: Does the prototype NVI™ five-layer infrastructure operate as designed across all five governance domains — consent, CIF™, VVS™, EPE™, and IAR™?
8. Rights compliance: Are the NVI-002 individual rights — access, correction, challenge, withdrawal — operationally effective in the prototype environment?
9. Governance quality: Is the intelligence generated in the prototype environment of demonstrably higher quality, for the institutions that access it, than the intelligence available to them before prototype participation?
10. Practitioner experience: Is the prototype's governance burden — consent engagement, CIF™ recording, proportionality assessment — manageable within existing safeguarding practice, and does it produce governance value that practitioners recognise as worth the investment?
11. Safeguarding intelligence value: Does the cross-institutional, verified intelligence available through the prototype NSIE™ produce demonstrably better-informed safeguarding decisions — as assessed by participating practitioners and the independent evaluator — than the intelligence available before prototype participation?
7.2 Evaluation Outputs
The prototype evaluation produces three reports. The Interim Evaluation Report at Month 6 provides early operational learning — particularly on the consent architecture deployment and CIF™ implementation burden — that enables operational adjustments within the remaining prototype period. The Final Evaluation Report at Month 12 provides the comprehensive assessment of all five evaluation questions, the complete Prototype Exception Register analysis, and the specific design recommendations for the pilot programme. The Evaluator's Public Statement — a plain-language summary of the evaluation findings addressed to the general public and the domestic abuse survivor community — is published simultaneously with the Final Evaluation Report.
8. Technical Governance Interface
8.1 SAT-001 Reference
The SAFECHAIN™ Technical Architecture™ (SAT-001) defines the technology specifications that the prototype governance architecture operates on — the identity management framework (OpenID Connect / OAuth 2.0 with multi-factor authentication); the data architecture (CIF™ schema, IAR™ tamper-evident logging, VPM™ profile management); the API specifications (EPE™ API, CIF™ middleware API, IAR™ read API); the security architecture (zero-trust network model, AES-256 encryption, NCSC Cloud Security Principles alignment); and the resilience architecture (99.9% availability target, defined failover procedures, IAR™ integrity preservation during outage events).
PROTO-001 governs the governance architecture that operates on this technical foundation. The governance and technical architectures are designed to be interdependent but distinct: the governance architecture can be assessed and evaluated independently of the specific technology implementation, and the technical architecture can be updated or replaced without changing the governance obligations it supports. This separation of governance and technical specification is a constitutional design principle of the NOM™ operating doctrine — the governance architecture must not be technology-dependent in ways that make it obsolete when the technology changes.
8.2 Security Governance
The prototype's security governance operates under the prototype PGB's oversight — the PGB receives monthly security reports covering: access log anomalies, authentication event patterns, encryption key management status, and any security incidents affecting prototype intelligence. The PGB's Independent Information Governance Adviser conducts a quarterly security governance review against the SAT-001 security architecture specification. Any security incident affecting prototype intelligence is disclosed to the PGB within 4 hours, to the affected individuals within 72 hours, and to the relevant regulatory authority (ICO) within the DPA 2018 72-hour notification timeframe.
9. Pathway to Pilot Programme
9.1 Prototype Completion Criteria
The prototype is complete — and the pathway to the pilot programme is open — when four completion criteria are met: the Final Evaluation Report confirms that all five evaluation questions are answered affirmatively; the Prototype Exception Register has been reviewed and all significant design exceptions have received design responses endorsed by the PGB; the provisional verifiers have demonstrated competency sufficient for promotion to full prototype verifier status under the NVI™ Verifier Accreditation Programme; and the participating institutions have achieved provisional Foundation Certification readiness as assessed by the PGB governance culture assessment.
Where any completion criterion is not met, the prototype phase is extended — by up to six months — to address the outstanding criterion. Extension is not failure; it is the governance discipline that prevents the pilot programme from deploying an architecture whose design gaps have not yet been resolved.
9.2 What the Prototype Delivers to the Pilot
A completed prototype delivers to the pilot programme: a tested, governance-validated NVI™ five-layer infrastructure; a trained cohort of verified verifiers ready for deployment across the three pilot sites; an operational CIF™ middleware product certified against the prototype experience; a refined consent architecture that has been tested in real domestic abuse safeguarding environments; an Exception Register whose design responses have been incorporated into the pilot programme architecture; and — most importantly — evidence that the SAFECHAIN™ governance and operational blueprint works.
The pilot programme does not begin with faith in the architecture. It begins with evidence of the architecture's operational validity. That is what the prototype delivers — and it is the most valuable governance output in the SAFECHAIN™ implementation journey.
Conclusion: Blueprint for a Working System
The SAFECHAIN™ Prototype Specification™ is the governance and operational blueprint for the most important single step in the SAFECHAIN™ implementation journey: the demonstration that the architecture works. Not in principle. Not in design. In practice — in a real institution cluster, with real practitioners, handling real safeguarding intelligence, under real governance obligations.
The prototype is governed rigorously because rigour at the prototype stage prevents failure at the pilot stage. The prototype is evaluated independently because independence at the evaluation stage protects the credibility of the evidence at the adoption stage. And the prototype is built on the full NVI™ governance architecture — not a simplified version — because the governance that vulnerable people deserve in the national operating system is the governance they deserve in the system that proves it works.
The blueprint is complete. The governance is defined. The evaluation framework is specified. The pathway to the pilot is clear. What the prototype requires now is the institutional commitment, the investment resource, and the practitioner participation that transform a governance blueprint into a working safeguarding system.
This document is PROTO-001 in the SAFECHAIN™ Prototype Development Series™. It should be read alongside SAT-001 (SAFECHAIN™ Technical Architecture™) for the technical specifications, NVI-010 (Pilot Architecture™) for the pilot programme that follows prototype completion, and IP-001 (Investment and Pilot Prospectus™) for the investment framework. Cross-references are maintained in the SAFECHAIN™ Master Publication Register™.
COPYRIGHT NOTICE
© 2026 Samantha Avril-Andreassen. All rights reserved.
SAFECHAINN Ltd (Company No. 12038453).
SAFECHAIN™, National Operating Model™, NOM™, Recognition Intelligence™, Continuity Intelligence™, Vulnerability Intelligence™, Accountability Intelligence™, Predictive Safeguarding™, National Vulnerability Verification Infrastructure™, Specialist Safeguarding Architecture™, Safeguarding Intelligence Series™, Governance Series™, National Infrastructure Series™, Trust Authority Framework™, Accreditation Framework™, Governance Council™, Audit and Assurance Framework™, and all associated frameworks, methodologies, governance architectures, operating models, implementation systems, terminology and intellectual property are proprietary works authored and developed by Samantha Avril-Andreassen.
No part of this publication may be reproduced, adapted, implemented, commercialised, incorporated into software or AI systems, used for training artificial intelligence models, or deployed within organisational governance frameworks without the prior written permission of Samantha Avril-Andreassen and SAFECHAINN Ltd.
The SAFECHAIN™ Master Publication Register™ remains the sole authoritative source of publication status, architecture lineage, governance authority, terminology control, implementation hierarchy, version control and intellectual property provenance.