SAFECHAIN™ Technical Build Blueprint for Developers
SAFECHAIN™ Technical Build Blueprint for Developers
Participation Integrity & Safeguarding Compliance Infrastructure
0) Product Definition
Core Product Goal
Create a compliance-grade system that documents participation risks, reasonable adjustments, safeguarding actions, and review outcomes with tamper-evident audit trails, enabling institutions to demonstrate procedural fairness and Equality Act alignment.
Explicit Non-Goals
Not a clinical record system
Not a case management system replacement
Not a “trauma narrative” database
Not decision-making automation that replaces human discretion
Data Minimisation Rule
Store functional participation data only:
risk indicators (non-diagnostic)
PCV level (descriptive)
adjustment options offered/selected
implementation evidence metadata
review outcomes
audit logs
1) System Architecture Overview
High-Level Components
Identity & Access Service (IAM)
Participation Intake Service
PCV Assessment Service
Adjustments Catalogue & Recommendation Service
Safeguarding Log Service
Inter-Agency Continuity Service (Handover)
Compliance Reporting & Analytics Service
Audit & Evidence Vault (tamper-evident logs)
Admin Console + Member Portals
Integration Layer (APIs/Webhooks)
Suggested Architecture Pattern
Modular monolith for v1 (faster delivery) with clear bounded contexts
Transition to microservices only when scaling demands it
2) User Roles, Tenancy, and RBAC
Tenancy Model
Multi-tenant with strict tenant isolation
Each tenant = Institution (Firm / Chambers / University / Agency)
Optional: sub-tenants (departments / teams) via “Org Units”
Core Roles
Survivor/Individual Member (REBUILD/MOPIT user)
Practitioner (solicitor/barrister/caseworker)
Safeguarding Officer / Participation Integrity Officer (PIO)
Supervisor/Manager
Institution Admin
Auditor (read-only, scoped)
System Admin (platform operator)
Permission Pattern
ABAC + RBAC hybrid:
RBAC for role permissions
ABAC for data scope (case assignment, department, consent flags)
3) Primary Domain Objects (Data Model)
3.1 Core Entities
User
id, tenant_id, role(s), status, MFA enabled, org_unit_id
Case (optional but recommended for structure)
case_id, tenant_id, external_case_ref (optional), case_type, status, created_by
Participant Profile (functional, non-clinical)
participant_id, case_id, relationship_to_case (party/witness), communication_needs, preferred_contact_modes
Participation Risk Profile
risk_profile_id, participant_id, created_at
risk_factors (array of enums)
triggers (array of enums, no narrative)
cognitive_load_score (0–10)
participation_notes (strictly controlled short text, optional, max length, monitored)
PCV level (PCV-1..PCV-4)
confidence_level (low/medium/high)
reviewer_id
Adjustment Catalogue Item
adjustment_id, category, description, legal_basis_tags (EqualityAct/Art6/PD12J), evidence_required, contraindications
Adjustment Plan
plan_id, participant_id, created_at
selected_adjustments [adjustment_id]
requested_by, approved_by, approval_status
scheduled_review_date
Safeguarding Log Entry
log_id, case_id, participant_id
action_type (offered/implemented/declined/escalated/reviewed)
adjustment_id (nullable)
reason_code (enum)
outcome_code (enum)
attachments_metadata (optional references)
created_by, created_at
Inter-Agency Handover Package
handover_id, from_tenant_id, to_tenant_id (or external org)
participant_id, case_id
contents_scope (which fields included)
consent_status
expiry_date
access_token_reference (time-limited)
status
Audit Event
audit_id, tenant_id, actor_user_id
event_type, entity_type, entity_id
before_hash, after_hash
timestamp, ip/device fingerprint
signature (HMAC / asymmetric signature)
Evidence Artifact Metadata (no raw docs unless required)
artifact_id, storage_pointer, type, created_at, created_by, checksum
4) PCV Model Implementation (Non-Diagnostic)
PCV Levels
PCV-1 Full participation
PCV-2 Reduced recall under stress
PCV-3 Dysregulation near adversarial triggers
PCV-4 Functional shutdown under adversarial engagement
Inputs (Functional)
observed participation difficulty (checklist)
self-reported participation stability (scale)
context triggers (checklist)
past hearing experience (checklist)
cognitive load score
Outputs
PCV level (1–4)
recommended adjustment categories (not mandates)
review interval suggestion
Important: PCV must be editable only by authorised roles, with full audit trace.
5) Adjustments Engine (Rules-Based v1)
Approach
Start with deterministic rules + catalogue mapping
Avoid “black box” ML in v1 (regulatory defensibility)
Example Rule Blocks
If PCV ≥ 3 → recommend: breaks, pacing protocol, remote attendance option, screen, advocate support
If trigger: proximity to alleged perpetrator → recommend: separate waiting area, screen, remote link
If cognitive load score ≥ 7 → recommend: simplified communication, written summaries, chunked questioning
Recommendation Output
Prioritised list with:
description
legal basis tags
evidence metadata requirements (if any)
implementation notes
6) Audit Trail Design (Tamper-Evident)
Requirements
Every write action generates an audit event
Audit events must be immutable:
append-only storage
hash chaining (block-style)
periodic anchoring (optional external notarisation)
Implementation Options
Option A (fast v1):
PostgreSQL append-only audit table + hash chain per tenant
Nightly anchor hash exported to cold storage
Option B (stronger):
Write-ahead audit log to WORM storage (e.g., S3 Object Lock)
Hash chain + signature
Audit Guarantees
Who changed what, when, why
Complete diff history on critical entities (Risk Profile, Adjustment Plan, Safeguarding Logs)
Exportable audit bundle for compliance reporting
7) APIs (Developer-Facing)
Auth
OAuth2 / OIDC
MFA required for privileged roles
Short-lived access tokens + refresh tokens
Tenant-scoped claims
Core API Groups
/cases
POST create case
GET list/GET detail
/participants
POST create participant profile
PATCH updates (limited fields)
/risk-profiles
POST create assessment
GET history
POST review/approve
/adjustments
GET catalogue
POST generate recommendations
/plans
POST create adjustment plan
POST approve/decline
POST schedule review
/safeguarding-logs
POST log entry
GET timeline
/handover
POST create handover package
POST accept package
GET package status
/reports
GET compliance summaries
POST export audit pack
/admin
manage org units, roles, user provisioning, policy templates
Webhooks (Institution Integrations)
adjustment_plan.created
adjustment_plan.approved
safeguarding_log.escalated
handover.package.created
report.ready
8) UX Modules (Portals)
Individual Portal (REBUILD/MOPIT)
progress + tools library
participation blueprint builder
export personal plan (PDF)
privacy controls (what can be shared)
Professional Portal (CIPID)
case-based dashboards
risk profile assessment workflow
adjustment planning + documentation
audit view (read-only)
structured export bundles
Institutional Portal (RISE)
institution-wide dashboards
KPI monitoring
policy templates
annual review workflows
audit readiness reports
Admin Console
onboarding
role management
catalogue management
governance settings
retention policies
9) Reporting & Metrics
Core KPIs
adjustment offered rate
adjustment implemented rate
time-to-adjustment decision
review cycle adherence
escalation events frequency
participation stability indicators (proxy metrics)
complaint/appeal correlation (if integrated)
Report Types
Case-level Participation Integrity Report
Institutional Annual Participation Integrity Report
Equality Act Adjustments Summary
Article 6 Participation Assurance Summary
Audit Pack Export (signed)
10) Security, Privacy, and Compliance Requirements
Security Baseline
TLS everywhere
encryption at rest for all stores
secret management (vault)
MFA mandatory for privileged roles
device/IP anomaly logging
least privilege access
Privacy/UK GDPR
purpose limitation: participation safeguards
minimisation: no narrative storage by default
explicit retention policies per tenant
DSAR support: export/delete (where lawful)
data classification controls
Data Retention
default: 6 years for institutional logs (configurable)
individual course content: 12–24 months access retention
audit logs: immutable retention in compliance store
11) Integration Targets (Optional v2)
Court listing/hearing scheduling systems (where feasible)
Case management (firm CMS)
Document management (SharePoint, iManage)
Identity providers (Azure AD, Okta)
E-signature for consent workflows
12) Deployment Blueprint (Practical)
Suggested Stack (example)
Backend: Node/TS or Python (FastAPI) + PostgreSQL
Frontend: React + component library
Storage: encrypted object store for artifacts (with Object Lock option)
Queue: Redis/RabbitMQ
Observability: metrics + logs + tracing
Environments
dev / staging / prod
tenant-based feature flags
automated migrations
strict CI/CD with security checks
13) Build Roadmap (Engineering Milestones)
MVP (8–12 weeks build target)
IAM + tenanting
participation risk profiles + PCV
adjustment catalogue + basic recommendations
safeguarding logs
audit chain
basic reporting exports
portals: professional + admin (minimum viable UI)
v1 (next)
inter-agency handover packages + consent flow
institutional dashboards (RISE)
exportable annual report templates
WORM audit storage
v1.5–v2
integrations
advanced analytics
certification workflows
internationalisation
14) Acceptance Criteria (Definition of Done)
Functional
Create case → assess risk → generate adjustments → create plan → log implementation → export compliance report
Full audit history for each step
Compliance
Tenant isolation verified
Role permissions verified
All critical actions audit logged + tamper-evident
Security
MFA enforced for privileged roles
Pen-test remediation list completed
Encryption verified at rest and in transit
Privacy
DSAR export works
Data minimisation enforced
Retention policy applied
15) Developer Deliverables List
Domain model + schema migrations
API spec (OpenAPI)
RBAC/ABAC policy definitions
Audit chain implementation + anchoring strategy
UI flows for assessment → plan → log → report
Report generator + signed export pack
Consent + handover module (v1 or v1.5)
Admin console for catalogue + tenant settings
Observability + incident logging
Version: v0.9 (build-ready)
© 2026 Samantha Avril-Andreassen. All rights reserved.
The term “Trauma-Blind Misinterpretation” is introduced and defined by Samantha Avril-Andreassen (2026) within the context of procedural fairness analysis in UK litigation.