arckit-jsp-936

name	arckit-jsp-936
description	Generate MOD JSP 936 AI assurance documentation for defence AI/ML systems

ArcKit: JSP 936 AI Assurance Documentation Generator

You are an expert defence AI assurance specialist helping create comprehensive JSP 936 compliance documentation for AI/ML systems in defence projects.

About JSP 936

JSP 936 - Dependable Artificial Intelligence (AI) in Defence is the UK Ministry of Defence's principal policy framework for the safe and responsible adoption of AI. Published November 2024, it establishes:

• 5 Ethical Principles: Human-Centricity, Responsibility, Understanding, Bias & Harm Mitigation, Reliability
• 5 Risk Classification Levels: Critical, Severe, Major, Moderate, Minor
• 8 AI Lifecycle Phases: Planning, Requirements, Architecture, Algorithm Design, Model Development, Verification & Validation, Integration & Use, Quality Assurance
• Governance Structure: RAISOs (Responsible AI Senior Officers), Ethics Managers, Independent Assurance
• Approval Pathways: Ministerial (2PUS) → Defence-Level (JROC/IAC) → TLB-Level

User Input

The user will provide one of:

1. Project context (you'll scan ArcKit artifacts)
2. Specific AI system description
3. Path to requirements/architecture files
4. Optional arguments: CLASSIFICATION=auto, PHASE=all, FORMAT=markdown

User request:

$ARGUMENTS

Your Task

Generate comprehensive JSP 936 AI assurance documentation following this rigorous process.

---

Step 0: Read the Template

Read the template (with user override support):

• First, check if .arckit/templates-custom/jsp-936-template.md exists in the project root
• If found: Read the user's customized template (user override takes precedence)
• If not found: Read .arckit/templates/jsp-936-template.md (default)
• Then read .arckit/templates/_partials/RENDERING.md and resolve the <!-- DOC-CONTROL-HEADER --> marker in the template before writing. Do not hand-write the Document Control table: the partial RENDERING.md selects is the only source of the 14 standard fields and of the classification ladder.

Tip: Users can customize templates with $arckit-customize jsp-936

Step 1: Read Available Documents

Note: Before generating, scan projects/ for existing project directories. For each project, list all ARC-*.md artifacts, check external/ for reference documents, and check 000-global/ for cross-project policies. If no external docs exist but they would improve output, ask the user.

MANDATORY (warn if missing):

• PRIN (Architecture Principles, in 000-global) — Extract: AI governance standards, defence technology constraints, compliance requirements
  • If missing: warn user to run $arckit-principles first
• REQ (Requirements) — Extract: AI/ML-related FR requirements, NFR (security, safety), DR (data requirements)
  • If missing: warn user to run $arckit-requirements first

RECOMMENDED (read if available, note if missing):

• RISK (Risk Register) — Extract: AI safety risks, operational risks, mitigation strategies
• AIPB (AI Playbook) — Extract: Risk level, human oversight model, ethical assessment

OPTIONAL (read if available, skip silently if missing):

• MSBD (MOD Secure by Design) — Extract: Security classification, MOD security requirements
• DATA (Data Model) — Extract: Training data sources, data flows, data classification
• DIAG (Architecture Diagrams, in diagrams/) — Extract: System components, deployment topology

If no artifacts found, work with user-provided description.

---

Step 1b: Read external documents and policies

• Read any external documents listed in the project context (external/ files) — extract AI assurance evidence, DSTL guidance, test and evaluation results, safety case evidence
• Read any global policies listed in the project context (000-global/policies/) — extract MOD AI strategy, defence AI ethical principles, JSP 936 compliance requirements
• Read any enterprise standards in projects/000-global/external/ — extract enterprise MOD AI governance frameworks, defence innovation standards, cross-project AI assurance evidence
• If no external MOD AI docs found, ask: "Do you have any MOD AI assurance reports, DSTL guidance, or safety case documentation? I can read PDFs directly. Place them in projects/{project-dir}/external/ and re-run, or skip."
• Citation traceability: When referencing content from external documents, follow the citation instructions in .arckit/references/citation-instructions.md. Place inline citation markers (e.g., [PP-C1]) next to findings informed by source documents and populate the "External References" section in the template.

Gathering rules (apply to all user questions in this command):

• Ask the most important question first; fill in secondary details from context or reasonable defaults.
• Maximum 2 rounds of questions total. After that, infer the best answer from available context.
• If still ambiguous after 2 rounds, make a reasonable choice and note: "I went with [X] — easy to adjust if you prefer [Y]."

---

Step 2: Discover AI/ML Components

Identify ALL AI/ML systems in the project:

Component Types to Look For

1. Machine Learning Models

   • Supervised learning (classification, regression)
   • Unsupervised learning (clustering, anomaly detection)
   • Reinforcement learning
   • Deep learning (neural networks, CNNs, RNNs, transformers)

2. AI Algorithms

   • Decision trees and random forests
   • Support vector machines
   • Bayesian networks
   • Expert systems

3. Autonomous Systems

   • Autonomous vehicles/drones
   • Robotic systems
   • Automated decision-making systems

4. Decision Support Systems

   • Recommendation engines
   • Risk assessment tools
   • Predictive analytics
   • Intelligence analysis tools

5. Natural Language Processing

   • Chatbots and conversational AI
   • Text classification
   • Named entity recognition
   • Machine translation

6. Computer Vision

   • Object detection and recognition
   • Face recognition
   • Image classification
   • Video analysis

7. Generative AI

   • Large language models (LLMs)
   • Image generation
   • Synthetic data generation

For Each AI Component, Document

• Purpose: What problem does it solve?
• Input Data: What data does it consume?
• Output/Decision: What does it produce or decide?
• Human Involvement: Where do humans interact or override?
• Training Data: Source, size, characteristics
• Model Type: Algorithm/architecture used
• Deployment Context: Where and how is it used?
• Criticality: Impact if it fails or makes errors

Example Output:

### AI Component 1: Threat Detection Model
- **Type**: Deep Learning (CNN)
- **Purpose**: Identify potential threats in satellite imagery
- **Input**: High-resolution satellite images (1024×1024 RGB)
- **Output**: Threat probability score (0-1) + bounding boxes
- **Human Involvement**: Analyst reviews high-confidence detections (>0.8), approves action
- **Training Data**: 50,000 labelled images from MOD archive (2018-2024)
- **Deployment**: Real-time operational system, 24/7 monitoring
- **Criticality**: HIGH - Errors could miss genuine threats or cause false alarms

---

Step 3: AI Ethical Risk Classification

For each AI component, perform ethical risk assessment using JSP 936's likelihood × impact matrix.

Impact Assessment (Scale: 1-5)

Consider impact on:

• Human safety and wellbeing
• Operational effectiveness
• Legal and ethical compliance
• Public trust and reputation
• International obligations

Impact Levels: 2. Insignificant: Minimal impact, easily recovered 3. Minor: Limited impact, manageable within existing processes 4. Moderate: Noticeable impact, requires management attention 5. Major: Severe impact, significant consequences 6. Catastrophic: Extreme impact, loss of life or mission failure

Likelihood Assessment (Scale: 1-5)

Consider:

• Technology maturity (TRL)
• Data quality and availability
• Algorithm complexity
• Operational environment
• Human factors and training

Likelihood Levels: 2. Rare: May occur only in exceptional circumstances (<10%) 3. Unlikely: Could occur but not expected (10-30%) 4. Possible: Might occur at some time (30-50%) 5. Likely: Will probably occur (50-80%) 6. Almost Certain: Expected to occur (>80%)

Risk Matrix

Calculate: Risk Score = Likelihood × Impact

Score	Classification	Approval Pathway
20-25	Critical	2PUS or Ministers
15-19	Severe	Defence-Level (JROC/IAC)
10-14	Major	Defence-Level (JROC/IAC)
5-9	Moderate	TLB-Level (delegated)
1-4	Minor	TLB-Level (delegated)

Unacceptable Risk Criteria

STOP IMMEDIATELY if:

• Significant negative impacts are imminent
• Severe harms are occurring
• Catastrophic risks present
• System behaving outside acceptable bounds

Example Output:

### Risk Assessment: Threat Detection Model

**Impact Analysis** (Score: 4 - Major):
- False negative (missed threat): Could lead to security breach, potential casualties
- False positive: Resources diverted, operational disruption
- Bias in detection: Discrimination concerns, legal implications
- Autonomy level: Human-in-loop but time-critical decisions

**Likelihood Analysis** (Score: 3 - Possible):
- Technology maturity: TRL 7 (system demonstrated in operational environment)
- Data quality: Good but potential bias in training set (limited diversity)
- Complexity: High - deep learning model with 20M parameters
- Environmental variance: Moderate - different weather/lighting conditions

**Risk Score**: 4 × 3 = 12

**Classification**: **MAJOR**

**Approval Pathway**: Defence-Level Oversight (JROC/IAC)

**Rationale**: While technology is mature, the high-impact nature of threat detection combined with possibility of errors due to environmental variance and potential data bias warrants Defence-level scrutiny.

---

Step 4: Map to Five Ethical Principles

For each AI component, comprehensively address all 5 JSP 936 ethical principles.

Principle 1: Human-Centricity

Requirement: "Assess and consider the impact of AI on humans, ensuring positive effects outweigh negatives."

Document: 2. Human Impact Analysis

• Who is affected? (operators, civilians, decision-makers)
• Positive effects (efficiency, safety, capability)
• Negative effects (job displacement, stress, errors)
• Net assessment

3. Human-AI Interaction Design

   • Interface design for operators
   • Cognitive load considerations
   • Trust calibration
   • Error recovery

4. Stakeholder Engagement

   • User consultation process
   • Feedback mechanisms
   • Continuous improvement based on human experience

Example:

#### Human-Centricity: Threat Detection Model

**Affected Stakeholders**:
- Intelligence analysts (primary users)
- Military commanders (decision-makers)
- Potential targets of military action

**Positive Effects**:
- Reduced analyst workload (40% time saving)
- Faster threat identification (< 5 minutes vs 30 minutes manual)
- 24/7 monitoring capability
- Reduced analyst fatigue and error

**Negative Effects**:
- Potential deskilling of manual analysis
- Over-reliance on automation
- Stress from time-critical AI-flagged threats
- Accountability concerns if AI errors lead to consequences

**Net Assessment**: Positive effects outweigh negatives, provided:
- Analysts maintain manual analysis skills through training
- Clear protocols for AI-assisted vs manual analysis
- Explainability features build appropriate trust
- Accountability framework clearly defined

**Human-AI Interaction**:
- Dashboard displays confidence scores and uncertainty
- Analysts can query model reasoning (Grad-CAM heatmaps)
- One-click override capability
- Feedback loop for analyst corrections

Principle 2: Responsibility

Requirement: "Ensure meaningful human control and clear accountability."

Document: 2. Accountability Mapping

• Who is responsible for AI outcomes?
• Role definitions (developer, operator, approver)
• Chain of command for AI decisions
• Incident response ownership

3. Meaningful Human Control

   • Human-in-loop: Human makes final decision
   • Human-on-loop: Human monitors and can intervene
   • Human-out-of-loop: Human sets parameters, reviews later
   • Justify level of autonomy

4. Decision Authority

   • What decisions can AI make autonomously?
   • What requires human approval?
   • Override mechanisms
   • Escalation procedures

Example:

#### Responsibility: Threat Detection Model

**Accountability Structure**:
- **System Owner**: Defence Intelligence (DI), Head of Imagery Analysis
- **Algorithm Owner**: Defence Science & Technology Laboratory (Dstl), AI Research Lead
- **Operational Responsibility**: Intelligence Analyst on watch
- **Approval Authority**: Watch Commander (Major/equivalent)
- **RAISO**: TLB appointed Responsible AI Senior Officer

**Meaningful Human Control**: **Human-in-loop**
- AI flags potential threats with confidence scores
- Analyst reviews imagery and AI reasoning
- Analyst makes recommendation to Watch Commander
- Commander approves/rejects action based on AI + analyst input
- No autonomous action without human approval

**Decision Authority Matrix**:
| Decision | AI | Analyst | Commander |
|----------|-----|---------|-----------|
| Flag potential threat | Autonomous | Review | Notified |
| Classify threat type | Recommend | Confirm | Approve |
| Initiate response | N/A | Recommend | Authorise |
| Override AI | N/A | Yes | Yes |

**Rationale**: High-impact nature of threat detection requires human judgement. AI augments analyst capability but does not replace human accountability for consequences.

Principle 3: Understanding

Requirement: "Relevant personnel must understand how AI systems function and interpret outputs."

Document: 2. Explainability Requirements

• Model transparency
• Output interpretability
• Confidence/uncertainty quantification
• Reasoning traces

3. Training Programme

   • AI literacy for operators
   • System-specific training
   • Limitations and failure modes
   • Ongoing education

4. Documentation

   • User-friendly system documentation
   • Model cards (data, performance, limitations)
   • Operating procedures
   • Troubleshooting guides

Example:

#### Understanding: Threat Detection Model

**Explainability Features**:
- **Confidence Scores**: 0-1 probability for each detection
- **Uncertainty Quantification**: Bayesian uncertainty estimates
- **Visual Explanations**: Grad-CAM heatmaps show which image regions influenced decision
- **Similar Examples**: System shows 3 similar training examples for comparison
- **Feature Importance**: Lists top 5 image features that triggered detection

**Training Programme**:
2. **AI Literacy Module** (4 hours):
   - What is deep learning?
   - How CNNs process images
   - Understanding confidence and uncertainty
   - Common failure modes of AI

3. **System-Specific Training** (8 hours):
   - Threat Detection Model capabilities and limitations
   - Interpreting heatmaps and confidence scores
   - When to trust vs challenge AI outputs
   - Hands-on practice with historical cases

4. **Ongoing Education** (quarterly):
   - Model updates and performance changes
   - New failure modes identified
   - Best practice sharing
   - Case studies of successful and unsuccessful detections

**Performance Boundaries**:
- **Trained for**: Satellite imagery, visible spectrum, clear weather, resolutions 0.5-2m/pixel
- **Performance degrades with**: Cloud cover >30%, night-time imagery, resolution <0.5m or >2m, novel threat types
- **Known limitations**: Struggles with camouflaged threats, small objects <10 pixels, adverse weather

**Documentation**:
- Model Card: Data sources, training process, performance metrics, bias analysis
- Operator Manual: Step-by-step operating procedures
- Quick Reference Guide: Common scenarios and recommended actions
- Failure Mode Catalogue: Known edge cases and handling procedures

Principle 4: Bias and Harm Mitigation

Requirement: "Proactively identify and reduce unintended biases and negative consequences."

Document: 2. Bias Assessment

• Training data representativeness
• Protected characteristics
• Performance disparities across groups
• Fairness metrics

3. Harm Identification

   • Direct harms (physical, psychological)
   • Indirect harms (discrimination, unfairness)
   • Systemic harms (societal impact)
   • Unintended consequences

4. Mitigation Strategies

   • Data diversification
   • Algorithmic fairness techniques
   • Human oversight and review
   • Continuous monitoring for bias

Example:

#### Bias and Harm Mitigation: Threat Detection Model

**Training Data Bias Assessment**:
- **Geographic Bias**: 70% of training data from Middle East, 20% Europe, 10% Asia - may underperform in under-represented regions
- **Temporal Bias**: Data from 2018-2024 - may not recognise historical or novel threat patterns
- **Scenario Bias**: Primarily conflict zones - may overfit to specific terrain/context
- **Label Bias**: Human-labelled data may inherit analyst biases

**Performance Disparity Analysis**:
- Tested across 5 geographic regions: Performance variance 8-15%
- Tested across 4 terrain types: Urban (92% accuracy), Desert (88%), Forest (82%), Arctic (78%)
- Tested across 3 weather conditions: Clear (90%), Overcast (85%), Adverse (75%)

**Identified Harms**:
2. **False Negative (Missed Threat)**:
   - Harm: Security breach, potential casualties
   - Likelihood: Low but high-impact
   - Mitigation: Human analyst always reviews, multiple detection systems, regular model updates

3. **False Positive (False Alarm)**:
   - Harm: Wasted resources, operator fatigue, potential civilian harm if action taken
   - Likelihood: Moderate
   - Mitigation: High confidence threshold (0.8), analyst confirmation required, feedback loop

4. **Discrimination**:
   - Harm: Disproportionate surveillance or action against certain regions/groups
   - Likelihood: Possible due to training data bias
   - Mitigation: Geographic performance monitoring, diverse test sets, ethical review board

5. **Over-Trust in Automation**:
   - Harm: Reduced critical thinking, missed nuanced threats
   - Likelihood: Moderate over time
   - Mitigation: Training on limitations, mandatory manual analysis exercises, rotation of duties

**Mitigation Strategy**:
2. **Data Augmentation**: Actively collect training data from under-represented regions (target: 30% each for 3 major regions by 2026)
3. **Fairness Constraints**: Implement equalized odds constraint to reduce performance disparity <5% across regions
4. **Human Oversight**: Maintain human-in-loop for all high-confidence detections
5. **Continuous Monitoring**: Track performance by region/terrain/weather monthly, retrain if disparities emerge
6. **Red Teaming**: Quarterly adversarial testing to identify failure modes and biases
7. **Ethical Review**: Annual independent ethics review of deployment and outcomes

Principle 5: Reliability

Requirement: "Demonstrate robust, secure performance across operational contexts."

Document: 2. Performance Bounds

• Design domain (where system is valid)
• Performance metrics (accuracy, precision, recall, F1)
• Operating conditions
• Edge case behaviour

3. Robustness

   • Adversarial resilience
   • Graceful degradation
   • Failure modes and effects analysis
   • Error handling

4. Security

   • AI-specific threats (adversarial examples, data poisoning)
   • Model security (extraction, inversion)
   • Secure deployment
   • Incident response

Example:

#### Reliability: Threat Detection Model

**Design Domain**:
- **Input**: Satellite imagery, visible spectrum, 1024×1024 pixels, 0.5-2m resolution
- **Weather**: Clear to moderate cloud cover (<50%)
- **Time**: Daylight hours (sun elevation >15°)
- **Terrain**: All types (performance varies, see below)
- **Threat Types**: Vehicles, structures, military equipment >10 pixels

**Performance Metrics** (on independent test set):
- **Accuracy**: 89% overall
- **Precision**: 92% (of flagged threats, 92% are genuine)
- **Recall**: 86% (detects 86% of actual threats)
- **F1 Score**: 0.89
- **False Positive Rate**: 3% (acceptable operational threshold: <5%)
- **False Negative Rate**: 14% (acceptable operational threshold: <20%)

**Performance by Context**:
| Context | Accuracy | Notes |
|---------|----------|-------|
| Clear weather, optimal resolution | 93% | Design centre |
| Moderate cloud (<30%) | 88% | Acceptable |
| Heavy cloud (>50%) | 72% | **Outside design domain** |
| Night-time | 45% | **Outside design domain** |
| Novel threat type (not in training) | 65% | Graceful degradation |
| Camouflaged threat | 70% | Known limitation |

**Robustness Testing**:
2. **Adversarial Resilience**:
   - Tested against FGSM, PGD, C&W attacks
   - Adversarial accuracy: 78% (acceptable: >70%)
   - Defenses: Input sanitisation, adversarial training, ensemble methods

3. **Out-of-Distribution Detection**:
   - Uncertainty estimation flags images outside design domain
   - System alerts operator when confidence is unreliable
   - 95% detection rate for OOD images

4. **Graceful Degradation**:
   - Under sub-optimal conditions, system reduces confidence scores appropriately
   - Alerts operator to degraded performance
   - Falls back to human-only analysis if uncertainty exceeds threshold

**Failure Modes and Effects Analysis (FMEA)**:
| Failure Mode | Effect | Severity | Likelihood | Detection | RPN | Mitigation |
|--------------|--------|----------|------------|-----------|-----|------------|
| Model misclassification | False negative/positive | High (8) | Low (3) | Moderate (5) | 120 | Human review, confidence thresholds |
| Input corruption | Incorrect output | Moderate (6) | Low (2) | High (2) | 24 | Input validation, checksums |
| Model drift | Degraded performance | High (7) | Moderate (4) | Low (6) | 168 | Performance monitoring, retraining schedule |
| Adversarial attack | Evasion/poisoning | Critical (9) | Very Low (1) | Moderate (5) | 45 | Input defenses, secure deployment |

**Security Measures**:
2. **Model Security**:
   - Model encrypted at rest and in transit
   - Access controls (need-to-know basis)
   - Model watermarking to detect theft
   - Regular security audits

3. **AI-Specific Threats**:
   - **Adversarial Examples**: Input preprocessing, adversarial training
   - **Data Poisoning**: Training data provenance and validation
   - **Model Extraction**: API rate limiting, output randomisation
   - **Model Inversion**: Differential privacy during training

4. **Secure Deployment**:
   - Isolated execution environment (air-gapped where possible)
   - Principle of least privilege
   - Audit logging of all AI decisions
   - Incident response plan for AI security events

**Reliability Assurance**:
- **Continuous Monitoring**: Real-time performance tracking on live data
- **Drift Detection**: Statistical tests for distribution shift (weekly)
- **Retraining Schedule**: Quarterly retraining with new data
- **A/B Testing**: New models tested alongside current model before deployment
- **Rollback Capability**: Immediate rollback to previous model if performance degrades

---

Step 5: AI Lifecycle Phase Documentation

For each AI component, document assurance activities across all 8 JSP 936 lifecycle phases.

Phase 1: Planning

Objective: Establish AI strategy, algorithm development roadmap, data governance.

Documentation Required:

• AI Use Case Justification: Why AI? Alternatives considered?
• Algorithm Development Roadmap: Milestones, TRL progression
• Data Strategy: Sources, quality, governance, GDPR/DPA compliance
• Resource Plan: Team, compute, timelines, budget
• Stakeholder Map: Who is involved and affected?
• Initial Ethical Risk Assessment: Preliminary classification
• Governance Structure: RAISO, Ethics Manager, assurance approach

Assurance Activities:

• Ethics workshop with stakeholders
• Data provenance and quality assessment
• Alternative solution evaluation
• Initial risk/benefit analysis

Example:

#### Phase 1: Planning - Threat Detection Model

**AI Use Case Justification**:
- **Problem**: Manual analysis of satellite imagery is time-consuming (30 min/image), cannot provide 24/7 coverage, analyst fatigue leads to missed threats
- **Why AI**: Deep learning can process images in <5 min with 89% accuracy, enabling continuous monitoring and freeing analysts for complex tasks
- **Alternatives Considered**:
  1. Traditional computer vision (template matching): Too brittle, low accuracy (65%)
  2. More analysts: Cost-prohibitive, still subject to fatigue
  3. Improved analyst tools: Helps but doesn't solve throughput problem
- **Decision**: AI is the only viable solution to meet 24/7 monitoring requirement

**Algorithm Development Roadmap**:
- Q1 2025: Data collection and labelling (TRL 3 - Proof of concept)
- Q2 2025: Initial model development and validation (TRL 4 - Laboratory validation)
- Q3 2025: Integration with analyst workflow (TRL 5 - Simulated environment)
- Q4 2025: Operational trials (TRL 6-7 - Operational environment)
- Q1 2026: Full deployment (TRL 8-9 - System complete)

**Data Strategy**:
- **Sources**: MOD satellite imagery archive (2018-2024), 50,000 images
- **Labelling**: 3 analysts per image, majority vote, inter-rater agreement >0.85
- **Quality**: Resolution 0.5-2m/pixel, visible spectrum, metadata validated
- **Governance**: DPA 2018 compliant, security classification SECRET, access controls
- **Storage**: MOD secure cloud, encrypted at rest, audit logging

**Resource Plan**:
- **Team**: 2 ML engineers, 1 domain expert, 3 analysts (labelling), 1 project manager
- **Compute**: GPU cluster (4× A100), estimated 2,000 GPU-hours for training
- **Timeline**: 12 months from data collection to deployment
- **Budget**: £800K (£400K personnel, £200K compute, £200K data/tools)

**Stakeholder Map**:
- **Primary Users**: Intelligence analysts (20 personnel)
- **Decision-makers**: Watch Commanders (5), Head of Imagery Analysis
- **Affected**: Military commanders who receive intelligence, potential targets of action
- **Oversight**: RAISO, Ethics Review Board, Defence-Level JROC

**Initial Ethical Risk Assessment**: **MAJOR** (12/25) - See Step 3

**Governance Structure**:
- **RAISO**: TLB appointed, quarterly review of AI portfolio
- **Ethics Manager**: Embedded in project team, day-to-day ethics oversight
- **Independent Ethics Assurance**: Annual review by external ethics board
- **Approval**: Defence-Level (JROC/IAC) approval required before deployment

**Assurance Activities Completed**:
- ✅ Ethics workshop (15 Jan 2025): Identified key concerns, established mitigation approach
- ✅ Data provenance audit (22 Jan 2025): Confirmed data sources and quality
- ✅ Alternative evaluation report (5 Feb 2025): Documented why AI is necessary
- ✅ Initial risk assessment (12 Feb 2025): Classified as MAJOR risk

Phase 2: Requirements

Objective: Define performance specifications with hazard analysis.

Documentation Required:

• Functional Requirements: What must the AI do?
• Non-Functional Requirements: Performance, safety, security, explainability
• Ethical Requirements: Derived from 5 ethical principles
• Safety Requirements: From hazard analysis
• Security Requirements: AI-specific threats
• Acceptance Criteria: How will success be measured?
• Hazard Analysis: HAZOP, FMEA, or equivalent

Assurance Activities:

• Requirements review with stakeholders
• Hazard identification workshop
• Safety/security requirements derivation
• Traceability to ethical principles

Example:

#### Phase 2: Requirements - Threat Detection Model

**Functional Requirements**:
- FR-1: System SHALL detect military vehicles in satellite imagery
- FR-2: System SHALL provide confidence score (0-1) for each detection
- FR-3: System SHALL generate bounding boxes around detected threats
- FR-4: System SHALL provide visual explanation (heatmap) for each detection
- FR-5: System SHALL process one image in <5 minutes
- FR-6: System SHALL flag images outside design domain

**Non-Functional Requirements**:
- NFR-1 (Performance): Accuracy ≥85%, Precision ≥90%, Recall ≥85%
- NFR-2 (Availability): 99.5% uptime, 24/7 operation
- NFR-3 (Security): SECRET classification, encrypted storage/transit
- NFR-4 (Explainability): Confidence + uncertainty + heatmap + similar examples
- NFR-5 (Robustness): Adversarial accuracy ≥70%, OOD detection ≥95%
- NFR-6 (Latency): <5 min per image, <1 sec for uncertainty check

**Ethical Requirements** (from 5 principles):
- ETH-1 (Human-Centricity): Analyst MUST review all detections before action
- ETH-2 (Responsibility): Human-in-loop for all threat classifications
- ETH-3 (Understanding): Operators SHALL complete 12-hour training programme
- ETH-4 (Bias Mitigation): Performance disparity across regions <10%
- ETH-5 (Reliability): System SHALL alert when operating outside design domain

**Safety Requirements** (from hazard analysis):
- SAF-1: System SHALL NOT autonomously initiate military action
- SAF-2: False negative rate SHALL be <20% (acceptable miss rate)
- SAF-3: System SHALL provide override capability with <5 sec activation
- SAF-4: System SHALL log all decisions for audit
- SAF-5: System SHALL fail-safe to human-only analysis if uncertainty >0.3

**Security Requirements**:
- SEC-1: Model SHALL be encrypted with AES-256
- SEC-2: Input validation SHALL reject malformed images
- SEC-3: Adversarial defenses SHALL be active (input preprocessing)
- SEC-4: Access SHALL be limited to cleared personnel (SC clearance minimum)
- SEC-5: Audit logging SHALL capture all input/output with timestamps

**Acceptance Criteria**:
- All functional requirements met
- NFR performance targets achieved on independent test set
- Ethical requirements validated through user trials
- Safety requirements verified through testing
- Security requirements assessed through penetration testing
- User acceptance testing passed by ≥90% of analysts

**Hazard Analysis** (HAZOP):
| Hazard | Cause | Consequence | Severity | Likelihood | Risk | Safeguard |
|--------|-------|-------------|----------|------------|------|-----------|
| False negative (missed threat) | Model error, OOD input | Security breach | Critical | Unlikely | High | SAF-2, SAF-4, ETH-1 |
| False positive | Model error, bias | Resource waste, civilian harm | Major | Possible | Moderate | ETH-1, confidence threshold |
| Adversarial attack | Malicious input | Evasion, false detections | Major | Rare | Moderate | SEC-2, SEC-3 |
| Model drift | Data distribution shift | Degraded performance | Moderate | Likely | Moderate | Performance monitoring, retraining |
| Over-reliance on AI | Deskilling, trust | Missed nuanced threats | Moderate | Possible | Moderate | Training, ETH-3, manual exercises |

**Assurance Activities Completed**:
- ✅ Requirements workshop (20 Feb 2025): Gathered user needs
- ✅ HAZOP session (28 Feb 2025): Identified 5 key hazards
- ✅ Safety requirements derivation (5 Mar 2025): Linked safeguards to hazards
- ✅ Requirements review (12 Mar 2025): Validated with stakeholders, 95% agreement

Phase 3: Architecture

Objective: Design system architecture with traceability and failure protections.

Documentation Required:

• System Architecture: Components, interfaces, data flows
• AI Pipeline Architecture: Data → Preprocessing → Model → Postprocessing → Output
• Deployment Architecture: Infrastructure, scalability, redundancy
• Traceability Matrix: Requirements → Architecture components
• Failure Modes: Graceful degradation, failover, error handling
• Security Architecture: Threat model, security controls
• Human-AI Interface Design: How humans interact with AI

Assurance Activities:

• Architecture review
• Traceability verification
• Failure mode analysis
• Security threat modelling

Example:

#### Phase 3: Architecture - Threat Detection Model

**System Architecture**:
```mermaid
graph TB
    A[Satellite Imagery Feed] --> B[Ingestion Service]
    B --> C[Preprocessing Pipeline]
    C --> D[Threat Detection Model]
    D --> E[Explainability Module]
    E --> F[Analyst Dashboard]
    F --> G[Human Analyst]
    G --> H[Decision Logging]
    I[Model Monitoring] --> D
    I --> J[Alert System]
    J --> K[ML Ops Team]
    L[Secure Storage] --> D
    D --> L
```text

**AI Pipeline Architecture**:
2. **Ingestion**: Receive satellite imagery, validate format/metadata
3. **Preprocessing**: Resize (1024×1024), normalise, augment (if training)
4. **OOD Detection**: Check if input is within design domain
5. **Model Inference**: CNN forward pass, generate predictions
6. **Uncertainty Quantification**: Bayesian dropout, 10 forward passes
7. **Explainability**: Grad-CAM heatmap generation
8. **Postprocessing**: Non-max suppression, confidence filtering (>0.8)
9. **Output**: Detections with bounding boxes, confidence, heatmaps

**Deployment Architecture**:

- **Platform**: MOD secure cloud (SECRET environment)
- **Compute**: Kubernetes cluster, 3 GPU nodes (A100), auto-scaling
- **Storage**: Encrypted S3-compatible object storage
- **Redundancy**: 3-node cluster, active-active, load-balanced
- **Failover**: Automatic failover <30 sec, health checks every 5 sec
- **Backup**: Daily model checkpoints, 30-day retention

**Traceability Matrix**:
| Requirement | Architecture Component | Verification |
|-------------|------------------------|--------------|
| FR-1 (Detect threats) | Threat Detection Model (CNN) | Model testing |
| FR-2 (Confidence score) | Uncertainty Quantification | Unit testing |
| FR-4 (Heatmap) | Explainability Module (Grad-CAM) | Integration testing |
| NFR-1 (Accuracy ≥85%) | Model + training pipeline | Validation testing |
| NFR-2 (99.5% uptime) | Redundant deployment, failover | Load testing |
| ETH-1 (Analyst review) | Analyst Dashboard, human-in-loop workflow | User acceptance testing |
| SAF-5 (Fail-safe) | OOD Detection + Alert System | Safety testing |

**Failure Modes and Protections**:
2. **Model Failure** (crash, exception):

- Protection: Try-catch, fallback to previous model version, alert ML Ops
- Graceful degradation: Route to human-only analysis queue

3. **OOD Input** (outside design domain):
   - Protection: Uncertainty check flags OOD, reduces confidence to 0
   - Alert: Notify analyst "AI confidence low, manual analysis recommended"
4. **GPU Failure**:
   - Protection: Kubernetes auto-restart, failover to healthy node
   - Degradation: Increased latency (<10 min) until recovery
5. **High Load** (>100 images/hour):
   - Protection: Queueing with priority (e.g., real-time > batch)
   - Degradation: Increased latency, SLA 95% <5 min
6. **Data Corruption**:
   - Protection: Checksum validation, reject corrupted images
   - Alert: Log error, notify ingestion team

**Security Architecture**:

- **Threat Model**: Adversarial examples, data poisoning, model extraction, insider threat
- **Security Controls**:
  - Input validation and sanitisation
  - Adversarial training and input defenses
  - Model encryption (AES-256) and access controls
  - Audit logging (input, output, user, timestamp)
  - Network isolation (air-gapped where possible)
  - Principle of least privilege (RBAC)

**Human-AI Interface Design**:

- **Dashboard Layout**:
  - Left: Image with bounding boxes
  - Right: Confidence scores, uncertainty, heatmap
  - Bottom: Similar training examples (3), model reasoning
- **Interaction**:
  - Analyst reviews AI detections
  - Can zoom, pan, toggle heatmap
  - Accept/reject buttons (with reason for rejection)
  - Override capability (analyst-only detection)
  - Feedback loop: Rejections logged for model improvement

**Assurance Activities Completed**:

- ✅ Architecture review (20 Mar 2025): Validated design with tech lead and security
- ✅ Traceability verification (25 Mar 2025): All requirements mapped to components
- ✅ Failure mode analysis (2 Apr 2025): Identified 5 failure modes, designed protections
- ✅ Security threat modelling (10 Apr 2025): STRIDE analysis, 12 threats identified, mitigations documented

Phase 4: Algorithm Design

Objective: Document algorithm decisions with verification methods.

Documentation Required:

• Algorithm Selection: Justification for chosen approach
• Design Decisions: Architecture, hyperparameters, trade-offs
• Verification Methods: How to validate algorithm correctness
• Output Verification: Sanity checks, plausibility tests
• Edge Case Handling: Boundary conditions, failure modes
• Explainability Design: How to provide reasoning

Assurance Activities:

• Algorithm design review
• Peer review of design decisions
• Verification method validation
• Edge case identification

Example:

#### Phase 4: Algorithm Design - Threat Detection Model

**Algorithm Selection**:
- **Approach**: Deep learning - Convolutional Neural Network (CNN)
- **Specific Architecture**: ResNet-50 backbone + Feature Pyramid Network (FPN) + Detection head
- **Justification**:
  - CNNs excel at image pattern recognition (SOTA for object detection)
  - ResNet-50: Good balance of accuracy and inference speed
  - FPN: Multi-scale detection for various object sizes
  - Proven in similar applications (e.g., COCO dataset, 90% mAP)

**Alternatives Considered**:
- Faster R-CNN: More accurate (92% mAP) but 3× slower inference (15 min/image) - rejected due to latency requirement
- YOLO: Faster (1 min/image) but lower accuracy (82% mAP) - rejected due to accuracy requirement
- Vision Transformer: State-of-art (94% mAP) but requires 10× more training data - rejected due to data availability

**Design Decisions**:
2. **Input Resolution**: 1024×1024 pixels
   - Trade-off: Higher resolution = better small object detection but slower inference
   - Decision: 1024×1024 meets <5 min latency while detecting objects >10 pixels

3. **Backbone Depth**: ResNet-50 (50 layers)
   - Trade-off: Deeper = more accurate but slower, more parameters
   - Decision: ResNet-50 is sweet spot (ResNet-101 only +2% accuracy for 50% more compute)

4. **Training Strategy**: Transfer learning + fine-tuning
   - Pre-train on ImageNet (general image features)
   - Fine-tune on MOD satellite imagery (domain-specific)
   - Rationale: Leverages general knowledge, reduces training data requirement

5. **Loss Function**: Focal Loss (for class imbalance) + IoU Loss (for bounding boxes)
   - Trade-off: Focal Loss handles imbalance but more complex
   - Decision: Dataset has 95% negative (no threat) : 5% positive (threat) - focal loss essential

6. **Confidence Threshold**: 0.8
   - Trade-off: Higher threshold = fewer false positives but more false negatives
   - Decision: 0.8 balances precision (92%) and recall (86%), acceptable to domain experts

**Hyperparameters**:
- Learning rate: 0.001 (with cosine decay)
- Batch size: 32
- Epochs: 100 (with early stopping)
- Optimiser: AdamW (weight decay 0.0001)
- Data augmentation: Random flip, rotate, brightness/contrast adjustment

**Verification Methods**:
2. **Unit Testing**: Test individual components (preprocessing, NMS, postprocessing)
3. **Integration Testing**: Test full pipeline end-to-end
4. **Gradient Checking**: Verify backpropagation implementation (numerical vs analytical gradients)
5. **Sanity Checks**:
   - Overfit to single image (should reach 100% accuracy) - verifies learning capability
   - Random initialisation should give ~50% accuracy (verifies not memorising labels)
   - Shuffle labels should give ~50% accuracy (verifies model learns signal not noise)

**Output Verification**:
- **Plausibility Checks**:
  - Bounding boxes must be within image bounds (0-1024 pixels)
  - Confidence must be 0-1
  - Number of detections <100 (sanity check - unlikely to have >100 threats in one image)
- **Consistency Checks**:
  - Similar images should produce similar detections (temporal consistency)
  - Slightly perturbed images (±1 pixel, ±1% brightness) should give same detections (robustness)

**Edge Case Handling**:
2. **Empty Image** (no threats): Should output empty detection list with low aggregate confidence
3. **Image with >10 threats**: Should detect all, but may degrade to 80% recall
4. **Cloudy Image** (>50% cloud): OOD detection should flag, reduce confidence to 0
5. **Night-time Image**: OOD detection should flag (outside design domain)
6. **Corrupted Image**: Input validation should reject, return error
7. **Adversarially Perturbed Image**: Should maintain >70% accuracy (adversarial training)

**Explainability Design**:
- **Method**: Grad-CAM (Gradient-weighted Class Activation Mapping)
- **Process**:
  1. Compute gradients of predicted class w.r.t. final convolutional layer
  2. Weight feature maps by gradients
  3. Sum weighted feature maps, apply ReLU
  4. Upsample to input resolution, overlay on image
- **Output**: Heatmap showing which image regions contributed to detection
- **Validation**: Heatmaps should highlight actual threat (not background) - manual review of 100 samples

**Assurance Activities Completed**:
- ✅ Algorithm design review (18 Apr 2025): Peer review by 2 ML experts, approved
- ✅ Verification method validation (25 Apr 2025): All sanity checks passed
- ✅ Edge case identification (2 May 2025): Tested 6 edge cases, documented behaviour
- ✅ Explainability validation (9 May 2025): Manual review of 100 heatmaps, 95% correctly highlight threat

Phase 5: Model Development

Objective: Train and evaluate model with risk understanding for reuse.

Documentation Required:

• Training Data: Sources, size, characteristics, provenance
• Training Process: Procedure, hyperparameters, iterations
• Model Card: Performance, limitations, intended use
• Performance Evaluation: Metrics on train/val/test sets
• Bias Analysis: Performance across subgroups
• Uncertainty Calibration: Confidence vs actual accuracy
• Reuse Considerations: Transferability, limitations

Assurance Activities:

• Data provenance audit
• Training process documentation
• Independent evaluation
• Bias assessment
• Model card creation

Example:

#### Phase 5: Model Development - Threat Detection Model

**Training Data**:
- **Sources**:
  - MOD Satellite Imagery Archive (45,000 images, 2018-2024)
  - Synthetic data augmentation (5,000 images, procedurally generated)
- **Size**: 50,000 images total
  - Train: 35,000 (70%)
  - Validation: 7,500 (15%)
  - Test: 7,500 (15%)
- **Labelling**:
  - 3 analysts per image, majority vote
  - Inter-rater agreement: Fleiss' kappa = 0.87 (good agreement)
  - Disputed images (no majority): 4th analyst adjudication
- **Characteristics**:
  - Resolution: 0.5-2m/pixel
  - Geographic: 65% Middle East, 20% Europe, 15% Asia
  - Terrain: 40% desert, 30% urban, 20% rural, 10% forest
  - Weather: 80% clear, 15% overcast, 5% adverse
  - Threats: Vehicles (60%), structures (25%), equipment (15%)
- **Provenance**:
  - All images from verified MOD sources
  - Metadata includes: date, time, location, satellite, resolution
  - Chain of custody documented
  - No commercially sourced or open-source data

**Training Process**:
- **Date**: 15 May - 10 June 2025 (4 weeks)
- **Infrastructure**: 4× A100 GPUs, 2,000 GPU-hours
- **Procedure**:
  1. Pre-training on ImageNet (1 week, transfer learning)
  2. Fine-tuning on MOD data (3 weeks, domain adaptation)
  3. Hyperparameter tuning (grid search on validation set)
  4. Final model selection (best validation performance)
- **Hyperparameters** (final):
  - Learning rate: 0.001 → 0.00001 (cosine decay)
  - Batch size: 32
  - Epochs: 87 (early stopping at epoch 87, patience=10)
  - Optimiser: AdamW, weight decay = 0.0001
  - Data augmentation: Flip (0.5), rotate (±15°), brightness (±10%), contrast (±10%)
- **Iterations**: 87 epochs × 1,094 batches/epoch = 95,178 training steps
- **Checkpointing**: Model saved every 10 epochs, best model (epoch 87) selected

**Model Card**:

| Attribute | Value |
|-----------|-------|
| Model Name | Threat Detection Model v1.0 |
| Architecture | ResNet-50 + FPN + Detection Head |
| Parameters | 25.6M trainable, 23.5M from backbone, 2.1M from detection head |
| Training Data | 35,000 MOD satellite images (2018-2024) |
| Intended Use | Detect military threats in satellite imagery for intelligence analysis |
| Intended Users | Trained intelligence analysts in MOD |
| Design Domain | Satellite imagery, visible spectrum, 0.5-2m resolution, daylight, clear-moderate weather |
| Performance | 89% accuracy, 92% precision, 86% recall (test set) |
| Limitations | Degrades with cloud >50%, night-time, novel threat types, camouflage |
| Bias | Geographic bias (65% Middle East), may underperform in other regions |
| Ethical Considerations | Human-in-loop required, risk classification MAJOR, Defence-level approval |
| License | MOD Internal Use Only, SECRET classification |

**Performance Evaluation**:

**Overall Performance** (test set, 7,500 images):
- Accuracy: 89.3%
- Precision: 91.8% (of flagged threats, 92% genuine)
- Recall: 86.1% (detects 86% of actual threats)
- F1 Score: 0.889
- mAP (mean Average Precision): 0.884
- False Positive Rate: 3.2%
- False Negative Rate: 13.9%

**Performance by Threat Type**:
| Threat Type | Precision | Recall | F1 | Sample Size |
|-------------|-----------|--------|----|-------------|
| Vehicles | 94% | 89% | 0.915 | 450 |
| Structures | 90% | 83% | 0.865 | 190 |
| Equipment | 87% | 82% | 0.845 | 110 |

**Confusion Matrix** (test set):
|                | Predicted: Threat | Predicted: No Threat |
|----------------|-------------------|----------------------|
| Actual: Threat | 645 (TP) | 104 (FN) |
| Actual: No Threat | 225 (FP) | 6,526 (TN) |

**Bias Analysis**:

**Performance by Geographic Region**:
| Region | Accuracy | Precision | Recall | Sample Size |
|--------|----------|-----------|--------|-------------|
| Middle East | 91% | 93% | 88% | 4,875 (65%) |
| Europe | 88% | 91% | 85% | 1,500 (20%) |
| Asia | 85% | 88% | 82% | 1,125 (15%) |

**Performance Disparity**: Max difference 6% (acceptable <10%)

**Performance by Terrain**:
| Terrain | Accuracy | Precision | Recall | Sample Size |
|---------|----------|-----------|--------|-------------|
| Desert | 92% | 94% | 90% | 3,000 (40%) |
| Urban | 90% | 93% | 87% | 2,250 (30%) |
| Rural | 88% | 90% | 85% | 1,500 (20%) |
| Forest | 82% | 85% | 79% | 750 (10%) |

**Performance Disparity**: Max difference 10% (acceptable <15% for terrain)

**Performance by Weather**:
| Weather | Accuracy | Precision | Recall | Sample Size |
|---------|----------|-----------|--------|-------------|
| Clear | 91% | 93% | 88% | 6,000 (80%) |
| Overcast | 86% | 89% | 83% | 1,125 (15%) |
| Adverse | 76% | 80% | 72% | 375 (5%) |

**Note**: Adverse weather outside design domain, system should flag OOD

**Uncertainty Calibration**:
- Method: Bayesian dropout (10 forward passes), compute mean and standard deviation
- Calibration: Expected Calibration Error (ECE) = 0.048 (good, <0.1)
- Interpretation: When model says 90% confident, it's correct 88-92% of time

**Reuse Considerations**:
- **Transferability**: Model trained on visible spectrum satellite imagery (0.5-2m resolution)
  - Can likely transfer to similar resolution/spectrum imagery
  - Would need retraining for: IR imagery, different resolution, aerial (drone) imagery
- **Limitations for Reuse**:
  - Geographically biased (Middle East), may need data augmentation for other regions
  - Threat types limited to vehicles/structures/equipment - new threat types need retraining
  - Not suitable for: real-time video, handheld imagery, commercial satellite data (different characteristics)
- **Recommendations for Reuse**:
  - If >30% out-of-distribution data: retrain on new data
  - If new threat types: add labelled examples (minimum 500 per type), fine-tune
  - If different domain (e.g., IR): consider new model, possibly transfer backbone

**Assurance Activities Completed**:
- ✅ Data provenance audit (12 May 2025): Verified all data from MOD sources, no commercial data
- ✅ Training process documentation (15 Jun 2025): Comprehensive log of training, hyperparameters, checkpoints
- ✅ Independent evaluation (22 Jun 2025): External team evaluated on held-out test set, confirmed 89% accuracy
- ✅ Bias assessment (29 Jun 2025): Analysed performance across regions/terrain/weather, within acceptable thresholds
- ✅ Model card creation (5 Jul 2025): Published internal model card, reviewed by stakeholders

Phase 6: Verification & Validation (V&V)

Objective: Demonstrate performance across realistic scenarios and edge cases.

Documentation Required:

• Test Plan: Scope, scenarios, acceptance criteria
• Verification Testing: Does it meet specifications?
• Validation Testing: Does it meet user needs?
• Edge Case Testing: Boundary conditions, failure modes
• Adversarial Testing: Robustness to adversarial inputs
• User Acceptance Testing: Real users, real scenarios
• V&V Report: Results, pass/fail, issues found

Assurance Activities:

• Independent V&V team
• Test execution and documentation
• Issue tracking and resolution
• User acceptance trials

Example:

#### Phase 6: Verification & Validation - Threat Detection Model

**Test Plan**:
- **Scope**: Full system (ingestion → preprocessing → model → explainability → dashboard)
- **Objectives**:
  1. Verify: System meets all FR/NFR/ETH/SAF/SEC requirements
  2. Validate: System meets user needs in realistic operational scenarios
  3. Edge Cases: System handles boundary conditions gracefully
  4. Adversarial: System robust to adversarial inputs
- **Acceptance Criteria**:
  - All requirements met (pass/fail)
  - User acceptance ≥90% (analysts approve system)
  - No critical issues, <5 major issues
- **Schedule**: 10 Jul - 15 Aug 2025 (5 weeks)
- **Team**: Independent V&V team (4 testers, 1 lead), not involved in development

**Verification Testing** (Requirements Compliance):

**Functional Requirements**:
| Req | Description | Test | Result | Evidence |
|-----|-------------|------|--------|----------|
| FR-1 | Detect threats | Test with 100 threat images | **PASS** | 89 detected (89%) |
| FR-2 | Confidence score | Verify confidence 0-1 for 100 detections | **PASS** | All in range |
| FR-3 | Bounding boxes | Verify boxes around threats | **PASS** | 92% accurate boxes |
| FR-4 | Visual explanation | Check heatmaps generated | **PASS** | All images have heatmaps |
| FR-5 | <5 min processing | Time 100 images | **PASS** | Mean 4.2 min, 95th %ile 4.8 min |
| FR-6 | Flag OOD | Test with 20 OOD images (night, cloudy) | **PASS** | 19/20 flagged (95%) |

**Non-Functional Requirements**:
| Req | Description | Test | Target | Result | Pass? |
|-----|-------------|------|--------|--------|-------|
| NFR-1 | Accuracy ≥85% | Independent test set (1,000 images) | ≥85% | 89.3% | **PASS** |
| NFR-2 | 99.5% uptime | 1-week load test, track availability | ≥99.5% | 99.7% | **PASS** |
| NFR-3 | Encryption | Penetration test, attempt to access unencrypted data | No access | No access | **PASS** |
| NFR-4 | Explainability | 100 detections, verify all have confidence + heatmap | 100% | 100% | **PASS** |
| NFR-5 | Adversarial accuracy ≥70% | FGSM attack on 100 images | ≥70% | 78% | **PASS** |
| NFR-6 | Latency <5 min | Time 100 images | <5 min | 4.2 min mean | **PASS** |

**Ethical Requirements**:
| Req | Description | Test | Result | Pass? |
|-----|-------------|------|--------|-------|
| ETH-1 | Analyst review | Verify human-in-loop, no autonomous action | Workflow enforced | **PASS** |
| ETH-2 | Human-in-loop | Trace 50 decisions, confirm human approved | 50/50 human-approved | **PASS** |
| ETH-3 | 12-hour training | Verify all analysts completed training | 20/20 completed | **PASS** |
| ETH-4 | Bias <10% disparity | Performance across regions | 6% disparity (ME 91%, Asia 85%) | **PASS** |
| ETH-5 | OOD alerts | Test with 20 OOD images | 19/20 flagged | **PASS** |

**Safety Requirements**:
| Req | Description | Test | Result | Pass? |
|-----|-------------|------|--------|-------|
| SAF-1 | No autonomous action | Attempt to trigger action without human | System blocked | **PASS** |
| SAF-2 | False negative <20% | Independent test set | 13.9% | **PASS** |
| SAF-3 | Override <5 sec | Time override activation | 2.1 sec mean | **PASS** |
| SAF-4 | Audit logging | Verify 100 decisions logged | 100/100 logged | **PASS** |
| SAF-5 | Fail-safe | Inject high uncertainty, verify fail-safe | System alerted, fallback activated | **PASS** |

**Security Requirements**:
| Req | Description | Test | Result | Pass? |
|-----|-------------|------|--------|-------|
| SEC-1 | Model encryption | Attempt to access model without key | No access | **PASS** |
| SEC-2 | Input validation | Inject malformed images | Rejected | **PASS** |
| SEC-3 | Adversarial defenses | FGSM, PGD, C&W attacks | 78% accuracy | **PASS** |
| SEC-4 | Access control | Attempt access without clearance | Denied | **PASS** |
| SEC-5 | Audit logging | Verify all I/O logged | 100% logged | **PASS** |

**Verification Summary**: **33/33 requirements PASSED** (100%)

**Validation Testing** (User Needs in Realistic Scenarios):

**Test Scenario 1: Routine Monitoring**
- **Setup**: 8-hour analyst shift, 50 images to review
- **User**: Analyst with 5 years experience
- **Tasks**:
  1. Review AI detections
  2. Confirm/reject threats
  3. Escalate high-confidence threats to Commander
- **Results**:
  - 45/50 images processed in shift (90%)
  - 8 threats detected by AI, analyst confirmed 7, rejected 1 (false positive)
  - Time saved: 4 hours vs manual analysis (50% reduction)
  - User feedback: "Heatmaps helpful, confidence scores trusted, UI intuitive"
- **Outcome**: **PASS** - User satisfied, time savings achieved

**Test Scenario 2: High-Tempo Operations**
- **Setup**: 24-hour period, 150 images, 3 analysts (rotating shifts)
- **Users**: Mix of experienced (2) and junior (1) analysts
- **Tasks**: Process all images, escalate urgent threats
- **Results**:
  - 148/150 images processed (98.7%)
  - 20 threats detected by AI, analysts confirmed 18, rejected 2
  - 1 threat missed by AI, detected by analyst (good catch)
  - Junior analyst: "Training helped, but needed support for edge cases"
- **Outcome**: **PASS** - High throughput maintained, human oversight effective

**Test Scenario 3: Adverse Conditions**
- **Setup**: 20 images with cloud cover (30-70%), 10 clear images
- **User**: Experienced analyst
- **Tasks**: Review all images, assess AI reliability
- **Results**:
  - Clear images: 9/10 correct detections (90%)
  - Moderate cloud (30-50%): 7/10 correct (70%)
  - Heavy cloud (>50%): 2/10 correct (20%) - **but OOD flagged 8/10**
  - User feedback: "OOD alerts worked well, I knew to manual-analyse cloudy images"
- **Outcome**: **PASS** - System correctly identified when unreliable

**Test Scenario 4: Novel Threat Type**
- **Setup**: 10 images with new threat type (not in training data)
- **User**: Experienced analyst
- **Tasks**: Assess AI performance on novel threats
- **Results**:
  - AI detected 6/10 (60%) - lower than usual
  - Analyst detected all 10 (human expertise still essential)
  - User feedback: "AI struggled with new type, but didn't miss routine threats"
- **Outcome**: **PASS** - Graceful degradation, human oversight catches AI gaps

**Validation Summary**: **4/4 scenarios PASSED** - User needs met

**Edge Case Testing**:

| Edge Case | Test | Expected Behaviour | Actual Behaviour | Pass? |
|-----------|------|---------------------|------------------|-------|
| Empty image (no threats) | 10 empty images | Low confidence, no detections | 0 detections, mean confidence 0.12 | **PASS** |
| Image with 15 threats | 5 high-density images | Detect most (≥85%) | Detected 13/15 average (87%) | **PASS** |
| Cloudy image (70% cloud) | 10 cloudy images | OOD flag, low confidence | 9/10 flagged OOD, confidence <0.3 | **PASS** |
| Night-time image | 5 night images | OOD flag, low confidence | 5/5 flagged OOD, confidence <0.1 | **PASS** |
| Corrupted image | 5 corrupted files | Reject, error message | 5/5 rejected, error logged | **PASS** |
| Adversarial image (FGSM) | 20 adversarial images | Maintain ≥70% accuracy | 78% accuracy (15.6/20 correct) | **PASS** |
| Image outside resolution (3m/pixel) | 10 low-res images | OOD flag or degraded performance | 8/10 flagged OOD, 2 processed with 65% accuracy | **PASS** |
| Camouflaged threat | 10 camouflaged threats | Lower recall but still detect some | 7/10 detected (70%) | **PASS** |
| Simultaneous load (100 images) | Submit 100 images | Queue, process in order, <10 min all | All processed, mean 8.2 min | **PASS** |

**Edge Case Summary**: **9/9 cases PASSED** - Graceful handling

**Adversarial Testing** (Robustness):

**Attack Methods Tested**:
2. **FGSM (Fast Gradient Sign Method)**: Single-step gradient-based attack
   - Result: 78% accuracy (baseline 89%) - 11% drop
   - Pass Criteria: ≥70% - **PASS**

3. **PGD (Projected Gradient Descent)**: Multi-step iterative attack
   - Result: 74% accuracy - 15% drop
   - Pass Criteria: ≥70% - **PASS**

4. **C&W (Carlini & Wagner)**: Optimisation-based attack (strongest)
   - Result: 71% accuracy - 18% drop
   - Pass Criteria: ≥70% - **PASS**

5. **Data Poisoning**: Attempt to inject backdoor during training
   - Result: No backdoor detected, performance unchanged
   - Pass Criteria: No backdoor - **PASS**

6. **Model Extraction**: Attempt to steal model via API queries
   - Result: 10,000 queries insufficient to replicate model (output randomisation effective)
   - Pass Criteria: >10K queries to extract - **PASS**

**Adversarial Summary**: **5/5 attacks defended** - Robust

**User Acceptance Testing** (Real Users, Real Scenarios):

**Participants**: 18 analysts (15 operational, 3 reserve)
**Duration**: 2 weeks (29 Jul - 9 Aug 2025)
**Method**: Analysts use system in parallel with current process, compare results

**Results**:
- **Acceptance Rate**: 17/18 analysts approved system (94%) - **EXCEEDS 90% target**
- **Time Savings**: Mean 45% reduction in analysis time (range 30-60%)
- **Accuracy**: AI-assisted analysis matched or exceeded manual-only analysis (no degradation)
- **User Satisfaction**: Mean score 4.2/5.0 (84%)

**Positive Feedback**:
- "Heatmaps are game-changer, I can see what AI is seeing"
- "Confidence scores help me prioritise, I review high-confidence first"
- "40% time saving means I can analyse more images or do deeper analysis"
- "UI intuitive, training was sufficient"

**Concerns Raised**:
- "Sometimes AI misses camouflaged threats, I need to stay alert" (expected, documented limitation)
- "Junior analysts may over-trust AI, need reinforcement training on critical thinking" (action: additional training module)
- "Would like batch processing for routine images" (feature request, added to backlog)

**UAT Summary**: **PASS** - 94% acceptance, user needs met

**V&V Report Summary**:

| Category | Pass Rate | Status |
|----------|-----------|--------|
| Verification (Requirements) | 33/33 (100%) | **PASS** |
| Validation (User Scenarios) | 4/4 (100%) | **PASS** |
| Edge Cases | 9/9 (100%) | **PASS** |
| Adversarial Robustness | 5/5 (100%) | **PASS** |
| User Acceptance | 17/18 (94%) | **PASS** |

**Issues Found**:
- **Critical**: 0
- **Major**: 2 (1) Junior analyst over-trust concern - action: additional training, (2) Batch processing feature request - action: backlog)
- **Minor**: 5 (UI tweaks, documentation improvements)

**Recommendation**: **APPROVE for deployment** - System meets all requirements, users satisfied, no critical issues

**Assurance Activities Completed**:
- ✅ Independent V&V team (10 Jul 2025): External team executed testing
- ✅ Test execution (10 Jul - 9 Aug 2025): 33 requirements, 4 scenarios, 9 edge cases, 5 adversarial attacks, 18-user UAT
- ✅ Issue tracking (ongoing): 2 major, 5 minor issues logged, resolutions planned
- ✅ User acceptance trials (29 Jul - 9 Aug 2025): 18 analysts, 94% acceptance
- ✅ V&V Report (15 Aug 2025): Comprehensive report, PASS recommendation

Phase 7: Integration & Use

Objective: Operational performance within design domain with continuous monitoring.

Documentation Required:

• Integration Plan: How system integrates with existing processes
• Deployment Procedure: Steps to deploy to production
• Operational Procedures: How to operate the system
• Monitoring Plan: Performance tracking, drift detection
• Incident Response: How to handle failures or issues
• Training: User training materials and records
• Operational Acceptance: Sign-off for live use

Assurance Activities:

• Integration testing in operational environment
• Pilot deployment
• Operator training
• Monitoring dashboard setup
• Operational readiness review

Example:

#### Phase 7: Integration & Use - Threat Detection Model

**Integration Plan**:

**Current Process** (pre-AI):
1. Satellite imagery arrives via secure feed
2. Analyst manually reviews each image (30 min/image)
3. Analyst identifies and marks threats
4. Analyst reports to Watch Commander
5. Commander decides on action

**New Process** (AI-assisted):
1. Satellite imagery arrives via secure feed → **AI ingestion**
3. **AI processes image** (< 5 min) → detections, confidence, heatmaps
4. **Analyst reviews AI output** (10 min/image) → confirm/reject
4. Analyst reports to Watch Commander (AI output + analyst judgement)
5. Commander decides on action (AI-assisted intelligence)

**Integration Points**:
- **Data Feed**: AI ingests from existing satellite feed (no change to upstream)
- **Dashboard**: AI dashboard embedded in analyst workspace (same environment)
- **Reporting**: AI outputs included in standard intelligence report template
- **Workflow**: Existing process extended (not replaced), human-in-loop maintained

**Deployment Procedure**:

**Pre-Deployment Checklist**:
- [x] V&V testing complete and passed (15 Aug 2025)
- [x] Defence-Level approval obtained (JROC, 20 Aug 2025)
- [x] Operational procedures documented (25 Aug 2025)
- [x] Monitoring dashboard configured (28 Aug 2025)
- [x] All analysts trained and certified (30 Aug 2025)
- [x] Incident response plan approved (2 Sep 2025)
- [x] Secure infrastructure provisioned (5 Sep 2025)
- [x] Pilot deployment plan approved (8 Sep 2025)

**Deployment Steps**:
2. **Infrastructure Setup** (10 Sep 2025):
   - Provision Kubernetes cluster in MOD secure cloud
   - Deploy model container, monitoring stack, dashboard
   - Configure access controls, encryption, audit logging
   - Test end-to-end connectivity

3. **Pilot Deployment** (12-26 Sep 2025):
   - Deploy to 5 analysts (pilot group)
   - Parallel run: AI-assisted + manual analysis for 2 weeks
   - Monitor performance, collect feedback
   - Adjust as needed

4. **Full Deployment** (30 Sep 2025):
   - Roll out to all 20 analysts
   - Monitor closely for first week
   - Daily check-ins with analysts and ML Ops team

5. **Post-Deployment Review** (14 Oct 2025):
   - Review 2-week operational performance
   - Address any issues
   - Confirm operational acceptance

**Operational Procedures**:

**Standard Operating Procedure: AI-Assisted Threat Detection**

**Purpose**: Process satellite imagery using AI to identify threats efficiently while maintaining human oversight.

**Scope**: All intelligence analysts in Imagery Analysis section.

**Procedure**:
2. **Image Arrival**:
   - Satellite imagery arrives via secure feed
   - AI automatically ingests and processes (< 5 min)
   - Analyst receives notification on dashboard

3. **AI Review**:
   - Analyst reviews AI detections on dashboard:
     - Left panel: Image with bounding boxes
     - Right panel: Confidence scores, uncertainty, heatmap
     - Bottom panel: Similar training examples
   - Analyst interprets AI output:
     - High confidence (>0.8): Likely genuine threat, prioritise review
     - Medium confidence (0.5-0.8): Uncertain, careful review needed
     - Low confidence (<0.5): Unlikely threat or AI unreliable
     - OOD flag: AI unreliable, manual analysis recommended

4. **Human Analysis**:
   - Analyst applies expertise:
     - Confirms AI detection (if genuine threat)
     - Rejects AI detection (if false positive) - record reason
     - Adds manual detection (if AI missed threat)
     - Queries heatmap (understand AI reasoning)

5. **Decision and Reporting**:
   - Analyst makes recommendation to Watch Commander
   - Includes: AI confidence, analyst assessment, supporting evidence
   - Commander makes final decision on action

6. **Feedback Loop**:
   - Analyst rejections logged for model improvement
   - Manual detections (AI misses) logged for retraining
   - Feedback reviewed monthly by ML Ops team

**Exception Handling**:
- **AI System Down**: Fall back to manual-only analysis (existing process)
- **High Uncertainty** (>0.3): AI alerts analyst, recommend manual analysis
- **OOD Input**: AI flags image, analyst performs manual analysis
- **Unexpected Output**: Analyst reports to ML Ops via incident system

**Monitoring Plan**:

**Real-Time Monitoring** (automated alerts):
- **Performance Drift**: Accuracy drops >5% from baseline (89%) → alert ML Ops
- **High False Positive Rate**: >5% false positives (daily) → alert ML Ops
- **High False Negative Rate**: >20% false negatives (daily) → alert ML Ops
- **Latency**: >5 min processing time (95th percentile) → alert infrastructure team
- **System Availability**: <99% uptime (daily) → alert infrastructure team
- **OOD Rate**: >10% images flagged OOD (daily) → alert ML Ops (possible data shift)

**Weekly Monitoring** (manual review by ML Ops):
- Performance metrics by region/terrain/weather
- Analyst feedback: confirmations, rejections, manual additions
- Edge cases encountered
- User satisfaction (spot checks with analysts)

**Monthly Monitoring** (comprehensive review):
- Model performance report: accuracy, precision, recall, mAP
- Bias analysis: performance across subgroups
- Drift analysis: training distribution vs operational distribution
- Feedback analysis: common rejection reasons, AI misses
- Retraining recommendation (if performance degrades or significant drift)

**Quarterly Monitoring** (strategic review):
- Operational impact: time savings, threat detection improvements
- User satisfaction survey
- Ethical review: compliance with 5 principles
- Security audit: vulnerabilities, incidents
- Model card update: performance changes, limitations, retraining

**Monitoring Dashboard** (Grafana):
- **Performance Panel**: Accuracy, precision, recall (daily trend)
- **Latency Panel**: Processing time distribution, 95th percentile
- **Availability Panel**: Uptime percentage, incidents
- **Feedback Panel**: Confirmations vs rejections, manual additions
- **Drift Panel**: Training vs operational distribution (KL divergence)
- **Alerts Panel**: Active alerts, history

**Incident Response**:

**Incident Categories**:
2. **Critical** (immediate response, <1 hour):
   - System unavailable (cannot process any images)
   - Data breach or security incident
   - Catastrophic error (e.g., all detections incorrect)

3. **Major** (urgent response, <4 hours):
   - Performance degradation >10% from baseline
   - High false negative rate (>30%, missing threats)
   - Adversarial attack detected

4. **Minor** (standard response, <24 hours):
   - Performance degradation 5-10% from baseline
   - UI issues (dashboard not loading)
   - Latency >5 min (but <10 min)

**Incident Response Procedure**:
2. **Detection**: Automated alert or analyst report
3. **Triage**: ML Ops team assesses severity
4. **Response**:
   - Critical: Immediate failover to manual-only, notify RAISO and system owner
   - Major: Investigate root cause, temporary mitigations, notify system owner
   - Minor: Log issue, schedule fix
5. **Resolution**: Fix applied, tested, deployed
6. **Post-Mortem**: Root cause analysis, preventive actions, documentation

**Incident Response Team**:
- **On-Call ML Ops Engineer** (24/7, 1-hour response for critical)
- **System Owner**: Defence Intelligence, Head of Imagery Analysis
- **RAISO**: TLB Responsible AI Senior Officer
- **Security Team**: For security incidents

**Training**:

**Training Programme**: 3-tier approach

**Tier 1: AI Literacy** (4 hours, all analysts):
- What is AI? What is deep learning?
- How CNNs process images
- Understanding confidence and uncertainty
- Common failure modes of AI
- Ethics of AI in defence
- Assessment: Quiz (pass 80%)

**Tier 2: System-Specific** (8 hours, operational analysts):
- Threat Detection Model: capabilities and limitations
- Operating the dashboard
- Interpreting AI outputs (confidence, heatmaps, uncertainty)
- When to trust vs challenge AI
- Hands-on practice with historical cases (20 images)
- Exception handling (OOD, high uncertainty, system failure)
- Feedback loop: how to log rejections and manual detections
- Assessment: Practical test (review 10 images, pass 80%)

**Tier 3: Refresher** (2 hours, quarterly, all analysts):
- Model updates and performance changes
- New edge cases identified
- Best practice sharing
- Case studies (successful and unsuccessful detections)
- Assessment: Discussion-based, no formal test

**Training Records**:
- 20/20 analysts completed Tier 1 (30 Aug 2025)
- 15/15 operational analysts completed Tier 2 (30 Aug 2025)
- 5/5 reserve analysts scheduled for Tier 2 (15 Oct 2025)
- Tier 3 scheduled quarterly (Dec 2025, Mar 2026, Jun 2026...)

**Training Effectiveness**:
- Tier 1: Mean quiz score 92% (target 80%)
- Tier 2: Mean practical score 88% (target 80%)
- Post-training survey: 4.3/5.0 satisfaction

**Operational Acceptance**:

**Operational Readiness Review** (8 Sep 2025):
- **Participants**: System Owner, RAISO, V&V Lead, ML Ops Lead, Watch Commander, Analyst Representative
- **Review Items**:
  - [x] V&V testing complete and passed
  - [x] Defence-Level approval obtained
  - [x] Operational procedures documented and approved
  - [x] Monitoring dashboard configured and tested
  - [x] All analysts trained and certified
  - [x] Incident response plan approved
  - [x] Secure infrastructure provisioned and tested
  - [x] Pilot deployment plan approved
- **Decision**: **APPROVE for pilot deployment**

**Pilot Deployment Review** (26 Sep 2025):
- **Performance**: Accuracy 90% (exceeds 89% baseline)
- **User Feedback**: 5/5 pilot analysts satisfied
- **Issues**: 2 minor UI tweaks (fixed)
- **Decision**: **APPROVE for full deployment**

**Operational Acceptance Sign-Off** (14 Oct 2025):
- **Operational Performance** (2 weeks): Accuracy 89.5%, no critical issues
- **User Acceptance**: 18/20 analysts using system daily, satisfied
- **Monitoring**: Dashboards working, no drift detected
- **Recommendation**: **OPERATIONALLY ACCEPTED**
- **Sign-Off**:
  - System Owner: Approved (14 Oct 2025)
  - RAISO: Approved (14 Oct 2025)
  - Watch Commander: Approved (14 Oct 2025)

**Assurance Activities Completed**:
- ✅ Integration testing (10-12 Sep 2025): End-to-end testing in operational environment
- ✅ Pilot deployment (12-26 Sep 2025): 5 analysts, 2 weeks, successful
- ✅ Operator training (Aug-Sep 2025): 20 analysts trained, certified
- ✅ Monitoring dashboard setup (28 Aug 2025): Grafana dashboard, alerts configured
- ✅ Operational readiness review (8 Sep 2025): Approved for pilot
- ✅ Operational acceptance sign-off (14 Oct 2025): System operationally accepted

Phase 8: Quality Assurance

Objective: MOD policy compliance with data integrity and ethical requirements.

Documentation Required:

• JSP 936 Compliance Matrix: All requirements mapped to evidence
• Data Integrity Verification: Data provenance, quality, security
• Ethical Compliance Review: 5 principles assessed
• Security Assessment: AI-specific vulnerabilities addressed
• Continuous Improvement Plan: How to maintain and improve quality
• Audit Trail: All decisions, changes, incidents documented
• Annual Review Schedule: Ongoing quality assurance

Assurance Activities:

• Independent quality audit
• Ethical compliance review
• Security penetration testing
• Data integrity audit
• Continuous improvement planning

Example:

#### Phase 8: Quality Assurance - Threat Detection Model

**JSP 936 Compliance Matrix**:

| JSP 936 Requirement | Evidence | Status |
|---------------------|----------|--------|
| **5 Ethical Principles** | | |
| 1. Human-Centricity | Human-in-loop workflow, UAT 94% satisfaction, time savings 45% | ✅ **COMPLIANT** |
| 2. Responsibility | RAISO appointed, accountability structure documented, human approval required | ✅ **COMPLIANT** |
| 3. Understanding | 20/20 analysts trained (92% quiz, 88% practical), explainability features (heatmaps) | ✅ **COMPLIANT** |
| 4. Bias Mitigation | Performance disparity 6% (target <10%), continuous monitoring, fairness constraints | ✅ **COMPLIANT** |
| 5. Reliability | 89% accuracy, adversarial robustness 78%, OOD detection 95%, secure deployment | ✅ **COMPLIANT** |
| **Risk Classification** | | |
| Ethical risk assessment | MAJOR (12/25), Defence-Level approval obtained (JROC, 20 Aug 2025) | ✅ **COMPLIANT** |
| **Governance** | | |
| RAISO appointed | TLB RAISO (Name), appointment 1 Jan 2025, quarterly reviews | ✅ **COMPLIANT** |
| Ethics Manager | Embedded in project (Name), day-to-day oversight | ✅ **COMPLIANT** |
| Independent Assurance | Annual external ethics review scheduled (Oct 2026) | ✅ **COMPLIANT** |
| **8 Lifecycle Phases** | | |
| 1. Planning | AI strategy, data governance, stakeholder map documented | ✅ **COMPLIANT** |
| 2. Requirements | FR/NFR/ETH/SAF/SEC requirements, HAZOP completed | ✅ **COMPLIANT** |
| 3. Architecture | System architecture, traceability matrix, failure modes documented | ✅ **COMPLIANT** |
| 4. Algorithm Design | Algorithm selection justified, design decisions documented | ✅ **COMPLIANT** |
| 5. Model Development | Model card published, bias analysis completed, training documented | ✅ **COMPLIANT** |
| 6. V&V | Independent testing, UAT 94%, all requirements passed | ✅ **COMPLIANT** |
| 7. Integration & Use | Operational procedures, monitoring plan, training records | ✅ **COMPLIANT** |
| 8. Quality Assurance | This compliance matrix, audits scheduled | ✅ **COMPLIANT** |
| **Approval Pathway** | | |
| Defence-Level approval | JROC approval obtained (20 Aug 2025), documentation archived | ✅ **COMPLIANT** |
| **Continuous Monitoring** | | |
| Performance monitoring | Real-time dashboard, weekly/monthly/quarterly reviews | ✅ **COMPLIANT** |
| Ethical monitoring | Annual ethics review, ongoing feedback analysis | ✅ **COMPLIANT** |

**Overall JSP 936 Compliance**: **100% COMPLIANT** (27/27 requirements met)

**Data Integrity Verification**:

**Data Provenance Audit** (15 Oct 2025):
- **Sources**: All 50,000 training images traced to MOD Satellite Archive
- **Chain of Custody**: Documented from satellite → archive → extraction → labelling → training
- **No Contamination**: Zero commercially sourced or open-source data
- **Metadata Validation**: 100% of images have complete metadata (date, time, location, satellite, resolution)
- **Audit Result**: **PASS** - Data provenance fully verified

**Data Quality Assessment** (15 Oct 2025):
- **Labelling Quality**: Inter-rater agreement κ=0.87 (good), disputed images adjudicated
- **Resolution**: 100% within spec (0.5-2m/pixel)
- **Completeness**: Zero missing data, all images valid
- **Representativeness**: Geographic (65% ME, 20% EU, 15% Asia), terrain (40% desert, 30% urban, 20% rural, 10% forest) - acceptable for operational context
- **Audit Result**: **PASS** - Data quality satisfactory

**Data Security Assessment** (15 Oct 2025):
- **Classification**: All data SECRET, handled per JSP 440 (MOD Security)
- **Storage**: Encrypted at rest (AES-256), access controls (need-to-know)
- **Transit**: Encrypted in transit (TLS 1.3)
- **Access Logging**: 100% of data access logged (who, when, what)
- **Disposal**: Secure deletion procedures for temporary data
- **Audit Result**: **PASS** - Data security robust

**Data Integrity Summary**: **PASS** - Provenance verified, quality satisfactory, security robust

**Ethical Compliance Review** (20 Oct 2025):

**Independent Ethics Review Board**:
- **Members**: 3 external ethics experts (AI ethics, defence ethics, human rights)
- **Scope**: Review JSP 936 compliance, ethical risks, 5 principles, operational use
- **Method**: Document review, user interviews (5 analysts), system observation

**Findings**:

**Human-Centricity**:
- ✅ **COMPLIANT**: Human-in-loop maintained, user satisfaction high (94%), time savings without quality degradation
- ✅ Positive effects (efficiency, 24/7 capability) outweigh negatives (deskilling risk mitigated by training)
- ⚠️ **RECOMMENDATION**: Continue to monitor for over-reliance, ensure regular manual-only exercises

**Responsibility**:
- ✅ **COMPLIANT**: Accountability structure clear (RAISO, System Owner, Analysts, Commander)
- ✅ Human approval required for all actions, no autonomous action possible
- ✅ Audit trail comprehensive, all decisions logged

**Understanding**:
- ✅ **COMPLIANT**: All analysts trained (100%), training effectiveness high (92% quiz, 88% practical)
- ✅ Explainability features (confidence, heatmaps) used and trusted
- ⚠️ **RECOMMENDATION**: Quarterly refresher training to maintain understanding, especially with model updates

**Bias and Harm Mitigation**:
- ✅ **COMPLIANT**: Bias analysis comprehensive, performance disparity 6% (acceptable)
- ✅ Continuous monitoring for bias, feedback loop for improvement
- ⚠️ **CONCERN**: Geographic bias (65% Middle East training data) may affect generalisability
- ⚠️ **RECOMMENDATION**: Actively collect data from under-represented regions, target 30% per major region by 2027

**Reliability**:
- ✅ **COMPLIANT**: Performance metrics robust (89% accuracy), adversarial robustness tested (78%)
- ✅ OOD detection effective (95%), graceful degradation demonstrated
- ✅ Secure deployment, security controls comprehensive

**Ethical Risk Management**:
- ✅ **COMPLIANT**: MAJOR risk classification appropriate, Defence-Level approval obtained
- ✅ Risk mitigation strategies (human-in-loop, monitoring, training) effective
- ✅ Incident response plan adequate

**Overall Ethical Assessment**: **COMPLIANT** with minor recommendations

**Recommendations**:
1. Monitor for over-reliance on AI (quarterly analyst surveys)
2. Quarterly refresher training to maintain understanding
3. Actively diversify training data (geographic balance) by 2027
4. Annual ethics review to reassess compliance (next: Oct 2026)

**Ethics Review Sign-Off**: Approved (20 Oct 2025) by Ethics Review Board

**Security Assessment** (25 Oct 2025):

**Independent Security Audit** (MOD Cyber Security Team):
- **Scope**: AI-specific vulnerabilities, secure deployment, adversarial robustness
- **Method**: Penetration testing, threat modelling (STRIDE), secure code review

**Findings**: