JSP 936 Compliance Checklist for AI Suppliers

Most AI suppliers to UK Defence have heard of JSP 936 but few have read it. Those who have often find it describes an “ideal end state” with supporting tools still in development. This post extracts the concrete requirements marked with “must” in JSP 936 V1.1 (November 2024)—the MOD’s directive on Dependable AI—that suppliers must meet today. Part 1 contains mandatory requirements that apply now; Part 2 guidance is still in development.

This guide is for technical leads and delivery managers at companies supplying AI systems to UK Defence, or considering doing so. It covers scope determination, ethical principles, data requirements, lifecycle documentation, and approval pathways.

Scope: Does JSP 936 Apply to You?

The JSP applies to AI systems developed or purchased to meet specific Defence needs:

• Object detection and recognition in ISR systems
• Reinforcement learning in C2 and autonomous systems
• LLMs in HR, decision support, and planning tools
• Any AI meeting MOD-specific requirements

Systems explicitly out of scope include:

• Commercial search engines
• Predictive text on standard messaging applications
• MS Copilot for low-risk administrative tasks

Loading diagram…

The demarcation is risk-based, not technology-based. A transformer model used for internal document search might be out of scope if the risk is low, while a threat-detection classifier requires full compliance. If your AI is “developed or purchased to meet a specific Defence need,” assume it is in scope until a risk assessment says otherwise.

The Five Ethical Principles

JSP 936 mandates compliance with five ethical principles. Each principle has specific requirements and corresponding supplier actions.

1. Human-Centricity

Identify all humans affected by the system’s operation. The JSP requires assessment of impact across seven human security factors: physical, political, economic, cultural, health, environmental, and informational.

Loading diagram…

Supplier action: Document a stakeholder impact analysis covering all seven factors. Identify who is affected by the system’s outputs, who operates it, and who might be harmed by its failure or misuse.

2. Responsibility

Establish clear accountability from operator to governance level. The JSP requires articulation of where human involvement occurs and who is accountable for decisions at each stage.

Supplier action: Provide a responsibility mapping document showing accountability at each lifecycle stage. This should identify the human decision-maker for each significant system action and the escalation path for edge cases.

3. Understanding

Different stakeholders require different levels of understanding. The JSP recognises that full transparency may conflict with security classification or intellectual property protection. The requirement is for “appropriate understanding” tailored to each stakeholder group.

Supplier action: Create stakeholder-specific explanation documentation. An operator needs to understand how to use the system safely; a governance board needs to understand risk exposure; an auditor needs to understand the assurance evidence. Each requires different depth and focus.

4. Bias and Harm Mitigation

Suppliers must analyse data, algorithms, and models for unwanted bias. They must develop monitoring and mitigation strategies before deployment.

Supplier action: Provide a bias analysis report covering training data composition, model evaluation across protected characteristics, and known performance disparities. Include an ongoing monitoring plan for production deployment.

5. Reliability

The Operational Design Domain (ODD) must be defined and communicated. Performance targets must be demonstrated within the ODD, and security analysis must include adversarial threats.

Supplier action: Provide an ODD specification defining where the system is expected to work correctly. Include performance evidence from testing within the ODD, boundary testing at ODD limits, and a security threat analysis covering adversarial inputs.

Ethical Principles Summary

Principle	JSP Requirement	Supplier Action
Human-centricity	Assess impact across seven security factors	Stakeholder impact analysis
Responsibility	Clear accountability chain	Responsibility mapping document
Understanding	Appropriate understanding for each stakeholder	Stakeholder-specific explanations
Bias mitigation	Analyse data/algorithms/models for bias	Bias analysis report + monitoring plan
Reliability	Define ODD, demonstrate performance, analyse threats	ODD specification + test evidence + threat analysis

Data Requirements

JSP 936 is unusually specific about ML data requirements. Your data must meet four quality criteria:

Relevant: Validated against intended behaviour within the ODD. If the system should detect vehicles in desert environments, the training data must include desert imagery that matches the target sensor characteristics.

Complete: Drawn from across the potential input space. Edge cases and boundary conditions must be represented, not just common scenarios.

Balanced: Over-represent rare classes if needed for model performance. A 50/50 split is not inherently correct; the balance should serve the system’s operational requirements.

Accurate: Match the sensor characteristics of the target system. Training on high-resolution imagery for deployment on lower-resolution sensors invalidates the performance evidence.

Attribute	Definition	Evidence Required
Relevant	Validated against intended behaviour in ODD	Dataset validation report against ODD
Complete	Covers potential input space	Coverage analysis, edge case inventory
Balanced	Class distribution serves performance needs	Class distribution analysis, justification
Accurate	Matches target sensor characteristics	Sensor specification alignment documentation

Mandatory Data Controls

Beyond quality criteria, specific controls are mandatory:

• Separation: Training, test, and verification datasets must be separate. Using the same data for training and evaluation invalidates your performance claims.
• Configuration management: All data influencing model output must be under version control. This includes preprocessing parameters, augmentation pipelines, and labelling standards.
• Provenance: Data provenance must be assured from collection to ingestion. You must know where each sample came from, who labelled it, and under what authority.
• Verification data: Where possible, verification data should be collected separately from training data to avoid distribution leakage.

Lifecycle Requirements

JSP 936 is lifecycle-agnostic but mandates specific documentation at each stage.

Loading diagram…

Planning

Version-controlled planning documents must include ethical principle compliance steps. The tools, environments, and standards must be defined before development begins.

This means capturing your approach to each ethical principle in the project plan, not retrofitting compliance documentation after development completes.

Requirements

Hazard analysis must include AI-specific failure modes and data failure modes. Traditional hazard analysis considers hardware failures and software bugs; AI systems add novel failure modes like concept drift, distribution shift, and adversarial manipulation.

Bi-directional traceability should link requirements to implementation where possible. For ML systems where direct traceability is impractical, the alternative is demonstrating that the training algorithm plus data meets high-level requirement intent.

Architecture and Implementation

Justify and document all hyperparameter choices. “We used the defaults” is not sufficient. Justify frameworks and libraries, and verify their outputs.

This requirement addresses the reproducibility problem in ML. Another team should understand why specific choices were made, not just what choices were made.

Verification and Validation

Demonstrate performance across the ODD including boundary conditions. Show safe behaviour outside the ODD: what happens when the system encounters inputs it was not designed for?

Regression testing is required after any updates. Model retraining, framework updates, and deployment environment changes all require re-verification.

Integration and Use

Define the ODD in the operating context. Operators need to know the conditions under which the system works correctly.

Monitor performance at an appropriate rate to address concept drift. The system that passed acceptance testing may degrade as the operational environment changes.

Maintain continuing assurance through modification processes. Hot-fixing a production model without regression testing violates JSP 936 requirements.

Supplier Deliverables

The MOD expects specific documentation from AI suppliers:

Document	JSP Reference	When Required
Statement of AI Ethics Assurance	Para 203	When UK uses non-UK developed AI
Model Card	DAIC MVP guidance	All AI systems
AI Ethics Risk Assessment	DAIC framework	All AI systems
Data Provenance Documentation	Para 161	All AI systems
Safety Case Evidence	System-dependent	Safety-related systems

Model Card

The DAIC (Defence AI Centre) provides MVP guidance for model cards. At minimum, a model card should document:

• Model identity (name, version, architecture)
• Intended use and ODD
• Training data summary
• Performance metrics and limitations
• Known biases and failure modes

Data Provenance Documentation

Data provenance must cover legal and ethical compliance. For each data source:

• Authority for collection
• Consent status (where applicable)
• Licencing terms for reuse
• Chain of custody from collection to ingestion

Intellectual Property

JSP 936 explicitly addresses IP: contracting should “consider through-life support including access to data and algorithms as well as the resulting models” with “clear ownership of intellectual property.”

Suppliers should expect procurement to request access to model weights, training data, and evaluation code. Plan IP agreements accordingly.

Risk Ratings and Approval Pathways

AI projects are rated by ethical risk, and the rating determines the approval authority.

Loading diagram…

Rating	Approval Level	Special Considerations
Minor	TLB-level, delegated	Standard business processes
Moderate	TLB-level, delegated	Standard business processes
Major	JROC/IAC	Must refer to DAU
Severe	2PUS or Ministers	Novel and contentious applications
Critical	2PUS or Ministers	AI in kinetic effects

Systems requiring Major or higher approval must be referred to the Defence AI and Autonomy Unit (DAU). This includes AI in kinetic effects and novel applications without established precedent.

The risk rating is determined by potential harm, reversibility, and the vulnerability of affected populations. A low-accuracy model affecting administrative processes might be Minor; a high-accuracy model affecting operational decisions might be Major regardless of technical performance.

Practical Next Steps

1. Gap Analysis

Compare your current documentation against JSP 936 requirements. Most suppliers find gaps in:

• Formal ODD specification
• Data provenance for pre-trained components
• Stakeholder impact analysis covering all seven human security factors
• Bias analysis across protected characteristics

2. Contact DAIC

Request access to DAIC’s Minimum Viable Product (MVP) guidance, including the model card template, risk assessment framework, and assurance questions. DAIC is the central point of contact for JSP 936 implementation support.

3. Engage Early

JSP 936 explicitly positions responsible AI as a “shared endeavour between MOD and its suppliers.” Discuss uncertainties early rather than discovering them during acceptance testing.

4. Build Competence Evidence

JSP 936 requires suppliers to prove they can deliver systems with assurance levels matching their intended use. Document:

• Staff qualifications and training
• Organisational experience with similar systems
• Quality management processes
• Previous delivery track record

Conclusion

JSP 936 is demanding but not unreasonable. The MOD acknowledges that supporting tools are still in development and expects iterative compliance. Suppliers who engage early and build robust documentation will be better positioned as the AI Model Arena and formal Part 2 guidance come online.

The core message is this: AI assurance in defence is mandatory. Suppliers who treat compliance as an engineering discipline rather than a paperwork exercise will find the requirements tractable.

Resources

• JSP 936 Part 1: Dependable AI in Defence - Primary source document
• Defence Artificial Intelligence Centre (DAIC) - Contact for MVP guidance
• DASA - Innovation funding pathways