bmad-plus 0.4.4 → 0.6.0

package/src/bmad-plus/packs/pack-shield/references/iso42001/iso42001-controls-annex-a.md

@@ -0,0 +1,155 @@
+# ISO/IEC 42001:2023 — Annex A Controls (All 38)
+
+ISO/IEC 42001:2023 Annex A contains **38 controls** organised across **9 control domains** (A.2–A.10). Within each domain, the .1 sub-clause contains the domain objective statement — the numbered controls begin at .2 (or .1.2 / .2.2 for A.6's two sub-objectives). Annex B provides implementation guidance for each control.
+
+> **How to use:** Controls are selected based on organisational role (provider, user, or both), AI system impact level, and risk assessment outcomes. Inapplicable controls must be justified in the Statement of Applicability (SoA).
+
+---
+
+## A.2 — Policies Related to AI (3 controls)
+
+| Control ID | Control Name | Applies To | Description |
+|-----------|-------------|-----------|-------------|
+| A.2.2 | AI policy | Provider + User | A formal AI policy shall be established, documented, and communicated. The policy shall include the organisation's commitment to responsible AI development or use, alignment with organisational values and legal obligations, and a framework for setting AI objectives. Signed by top management. |
+| A.2.3 | Alignment with other organisational policies | Provider + User | AI-specific requirements shall be incorporated into existing organisational policies (e.g. HR, procurement, IT, data governance, information security) where those policies affect or are affected by AI systems. |
+| A.2.4 | Review of the AI policy | Provider + User | The AI policy shall be reviewed at planned intervals and when significant changes occur, to ensure its continuing suitability, adequacy, and effectiveness. |
+
+**Common gaps:** AI policy exists but lacks specific responsible AI commitments; other organisational policies not updated to address AI; policy review cycle not defined.
+
+---
+
+## A.3 — Internal Organisation (2 controls)
+
+| Control ID | Control Name | Applies To | Description |
+|-----------|-------------|-----------|-------------|
+| A.3.2 | AI roles and responsibilities | Provider + User | Roles and responsibilities for AI governance shall be defined, assigned, communicated, and documented. This includes accountability for individual AI systems, data governance, and AIMS oversight. A RACI matrix or equivalent is recommended. |
+| A.3.3 | Reporting of concerns | Provider + User | Mechanisms shall be established for personnel to raise concerns about AI systems — including ethical concerns, bias observations, unexpected outputs, or policy non-compliance — without fear of reprisal. |
+
+**Common gaps:** AI ownership is informal or split across teams without clear accountability; no channel for staff to report AI concerns.
+
+---
+
+## A.4 — Resources for AI Systems (5 controls)
+
+| Control ID | Control Name | Applies To | Description |
+|-----------|-------------|-----------|-------------|
+| A.4.2 | Resource documentation | Provider + User | The resources required to develop, deploy, operate, and maintain AI systems shall be identified and documented, including compute, data, tooling, and human resources. |
+| A.4.3 | Data resources | Provider | Policies and controls shall govern the acquisition, management, and quality assurance of data resources used in AI systems — covering training, validation, and test data. |
+| A.4.4 | Tooling resources | Provider | Controls shall govern the selection, procurement, and management of AI tooling — including development frameworks, model libraries, and evaluation platforms. |
+| A.4.5 | System and computing resources | Provider | Controls shall govern the compute infrastructure used for AI development and deployment: provisioning, access control, capacity management, and decommissioning. |
+| A.4.6 | Human resources | Provider + User | AI-specific competency requirements shall be documented. Training programmes shall be established for AI developers, operators, and business users. An awareness programme shall be maintained for all staff who interact with or are affected by AI. |
+
+**Common gaps:** No AI-specific competency framework; staff AI awareness training absent; third-party AI tools not inventoried; data resource governance undocumented.
+
+---
+
+## A.5 — Assessing Impacts of AI Systems (4 controls)
+
+| Control ID | Control Name | Applies To | Description |
+|-----------|-------------|-----------|-------------|
+| A.5.2 | AI system impact assessment process | Provider + User | A documented process for assessing the impacts of AI systems shall be established and maintained. The process shall define scope, methodology, frequency of assessment, roles, and how assessment results inform control selection and treatment decisions. |
+| A.5.3 | Documentation of AI system impact assessments | Provider + User | Results of AI system impact assessments shall be documented, retained, and updated when significant changes occur to the AI system or its operating context. |
+| A.5.4 | Assessing AI system impact on individuals or groups of individuals | Provider + User | The impact assessment shall evaluate how AI system outputs may affect individual rights, wellbeing, and autonomy. This includes risks of discrimination, profiling, automated decision-making without meaningful human review, and disproportionate impacts on vulnerable individuals or groups. |
+| A.5.5 | Assessing societal impacts of AI systems | Provider + User | The impact assessment shall evaluate broader societal impacts: potential for misinformation generation, labour market effects, environmental impact of AI compute, reinforcement of systemic bias at scale, and erosion of human autonomy. |
+
+**Common gaps:** Impact assessment performed once at deployment but never revisited; societal impact dimension skipped; no documented process — assessments done ad hoc.
+
+---
+
+## A.6 — AI System Life Cycle (9 controls)
+
+A.6 is divided into two sub-objectives: **A.6.1 Management guidance** and **A.6.2 AI system life cycle**. The .1 sub-clause in each group contains the objective statement; controls begin at .2.
+
+### A.6.1 — Management Guidance (2 controls)
+
+| Control ID | Control Name | Applies To | Description |
+|-----------|-------------|-----------|-------------|
+| A.6.1.2 | Objectives for responsible development of AI system | Provider | Specific, measurable objectives for responsible AI development shall be established, documented, and monitored. These shall align with the AI policy and responsible AI principles (fairness, transparency, accountability, safety, reliability). |
+| A.6.1.3 | Processes for responsible AI system design and development | Provider | Formal processes shall govern AI system design and development to embed responsible AI principles: fairness-aware design, documentation of design decisions, explainability requirements proportionate to AI impact level, and human oversight at key development gates. |
+
+### A.6.2 — AI System Life Cycle (7 controls)
+
+| Control ID | Control Name | Applies To | Description |
+|-----------|-------------|-----------|-------------|
+| A.6.2.2 | AI system requirements and specification | Provider | Requirements for each AI system shall be documented, including intended purpose, performance criteria, operating conditions, input/output specifications, and applicable constraints (legal, ethical, technical). |
+| A.6.2.3 | Documentation of AI system design and development | Provider | Design decisions, architecture choices, model versions, hyperparameters, and development rationale shall be documented to support reproducibility, auditability, and accountability. |
+| A.6.2.4 | AI system verification and validation | Provider | Testing protocols shall be applied before deployment: performance benchmarking, fairness and bias testing across demographic groups, adversarial testing, edge case validation, and go/no-go authorisation criteria. |
+| A.6.2.5 | AI system deployment | Provider | A controlled deployment process shall govern AI system releases: staged rollout, deployment authorisation, risk and impact assessment sign-off, and rollback procedures. |
+| A.6.2.6 | AI system operation and monitoring | Provider + User | Continuous monitoring of AI systems in production shall detect performance drift, output quality degradation, and bias. Alert thresholds and remediation processes shall be defined. |
+| A.6.2.7 | AI system technical documentation | Provider + User | Comprehensive technical documentation per AI system shall be maintained: specifications, intended use, known limitations, performance data, and failure modes. This supports transparency obligations and third-party assessment. |
+| A.6.2.8 | AI system recording of event logs | Provider + User | AI systems shall record event logs sufficient to support incident investigation, audit, performance monitoring, and accountability. Log retention periods and access controls shall be defined. |
+
+**Common gaps:** No model versioning or reproducibility controls; bias testing not documented; no production monitoring for model drift; deployment lacks formal authorisation process; event logs not retained or scoped to AI systems.
+
+---
+
+## A.7 — Data for AI Systems (5 controls)
+
+| Control ID | Control Name | Applies To | Description |
+|-----------|-------------|-----------|-------------|
+| A.7.2 | Data for development and enhancement of AI system | Provider | A governance framework shall define how data is managed across the full AI data lifecycle: acquisition, quality assurance, labelling, versioning, bias testing, retention, and secure deletion. |
+| A.7.3 | Acquisition of data | Provider | Controls shall govern how training, validation, and test data is sourced: legal basis for data use, consent requirements where applicable, provenance documentation, and prohibition on use of unlawfully obtained data. |
+| A.7.4 | Quality of data for AI systems | Provider | Data quality criteria shall be defined for training, validation, and test data — covering completeness, accuracy, representativeness, and recency — and tested before data is used in AI development. |
+| A.7.5 | Data provenance | Provider | The origin, chain of custody, and transformation history of data used in AI systems shall be documented and traceable. This supports accountability, bias identification, and regulatory compliance. |
+| A.7.6 | Data preparation | Provider | Processes for data cleaning, transformation, labelling, and annotation shall include quality controls: human review of labelled data, inter-annotator agreement checks, and identification and remediation of bias introduced in preparation steps. |
+
+**Common gaps:** Training data sourcing undocumented; no data quality criteria or tests; labelling process not auditable; provenance tracking absent; data preparation bias controls missing.
+
+---
+
+## A.8 — Information for Interested Parties of AI Systems (4 controls)
+
+| Control ID | Control Name | Applies To | Description |
+|-----------|-------------|-----------|-------------|
+| A.8.2 | System documentation and information for users | Provider + User | Documentation and information about AI systems shall be provided to users and other interested parties at a level of detail proportionate to the AI system's impact. This includes intended purpose, known limitations, and how to interpret AI outputs. |
+| A.8.3 | External reporting | Provider + User | The organisation shall define what information about AI systems is reported externally, to whom, how frequently, and through what mechanism — including regulatory disclosures, transparency reports, and public-facing AI disclosures. |
+| A.8.4 | Communication of incidents | Provider + User | AI-specific incident communication processes shall be established: internal escalation, notification to affected individuals where required, regulatory reporting (e.g., under sector-specific AI or data protection laws), and post-incident review and disclosure. |
+| A.8.5 | Information for interested parties | Provider + User | Stakeholders — including customers, employees, regulators, and the public — shall be informed of their rights and what to expect from AI systems. A communication plan shall address what to communicate, when, and through which channel. |
+
+**Common gaps:** No disclosure to users that AI is involved in decision-making; incident reporting processes not extended to AI-specific scenarios; no external transparency reporting; stakeholder communication plan absent.
+
+---
+
+## A.9 — Use of AI Systems (3 controls)
+
+| Control ID | Control Name | Applies To | Description |
+|-----------|-------------|-----------|-------------|
+| A.9.2 | Processes for responsible use of AI systems | User (primarily) | Formal processes shall govern how the organisation uses AI systems responsibly, including acceptable use criteria, human oversight of AI outputs, and procedures for escalating or overriding AI decisions. |
+| A.9.3 | Objectives for responsible use of AI system | User (primarily) | Measurable objectives for responsible AI use shall be established and monitored, aligned to the AI policy and responsible AI principles. These objectives drive continual improvement in AI use practices. |
+| A.9.4 | Intended use of the AI system | Provider + User | The intended use of each AI system shall be documented, communicated, and enforced. Use beyond the documented intended purpose shall be identified, assessed, and controlled. |
+
+**Common gaps:** No acceptable use policy for AI; staff using AI tools beyond intended scope; no formal objectives for responsible AI use; human oversight procedures not documented.
+
+---
+
+## A.10 — Third-Party and Customer Relationships (3 controls)
+
+| Control ID | Control Name | Applies To | Description |
+|-----------|-------------|-----------|-------------|
+| A.10.2 | Allocating responsibilities | Provider + User | Where AI systems involve multiple parties (providers, users, customers, partners), responsibilities for responsible AI governance shall be clearly allocated and documented — including who is responsible for impact assessment, monitoring, and incident response. |
+| A.10.3 | Suppliers | Provider + User | AI supply chain risk management shall govern third-party AI providers: tiering by risk, due diligence questionnaires, contractual AI-specific clauses (including data handling, bias controls, and right to audit), and ongoing supplier performance monitoring. |
+| A.10.4 | Customers | Provider | Where AI systems are deployed to customers, the organisation shall define what information customers receive about AI system capabilities and limitations, what obligations customers have in responsible use, and how customer feedback and incidents are managed. |
+
+**Common gaps:** No AI-specific supplier due diligence questionnaire; no contractual AI clauses with key AI vendors; responsibilities between provider and user not formally allocated; no customer-facing AI use obligations.
+
+---
+
+## Summary: Controls by Organisational Role
+
+| Domain | # Controls | AI Provider | AI User |
+|--------|-----------|------------|---------|
+| A.2 Policies | 3 | Both | Both |
+| A.3 Internal Organisation | 2 | Both | Both |
+| A.4 Resources | 5 | Primary (all 5) | A.4.2, A.4.6 |
+| A.5 Impact Assessment | 4 | Both | Both |
+| A.6 AI System Life Cycle | 9 | Primary (all 9) | A.6.2.6, A.6.2.7, A.6.2.8 |
+| A.7 Data | 5 | Primary (all 5) | Limited |
+| A.8 Information | 4 | Both | Both |
+| A.9 Use of AI Systems | 3 | A.9.4 | Primary (all 3) |
+| A.10 Third-Party / Customer | 3 | Both | A.10.2, A.10.3 |
+| **Total** | **38** | | |
+
+**Controls by ID (complete list):**
+A.2.2, A.2.3, A.2.4, A.3.2, A.3.3, A.4.2, A.4.3, A.4.4, A.4.5, A.4.6, A.5.2, A.5.3, A.5.4, A.5.5, A.6.1.2, A.6.1.3, A.6.2.2, A.6.2.3, A.6.2.4, A.6.2.5, A.6.2.6, A.6.2.7, A.6.2.8, A.7.2, A.7.3, A.7.4, A.7.5, A.7.6, A.8.2, A.8.3, A.8.4, A.8.5, A.9.2, A.9.3, A.9.4, A.10.2, A.10.3, A.10.4
+
+> **Note on control ID numbering:** Within each domain, sub-clause .1 contains the domain objective statement (not a control). Controls begin at .2. Domain A.6 has two sub-objectives (A.6.1 Management guidance and A.6.2 AI system life cycle), each with their objective at .1 and controls starting at .2. This is why control IDs in A.6 are formatted as A.6.1.2, A.6.1.3, A.6.2.2 … A.6.2.8.

package/src/bmad-plus/packs/pack-shield/references/itar/compliance-program.md

@@ -0,0 +1,174 @@
+# ITAR Compliance Programme — Penalties, VSD, and TCP
+
+## ITAR Compliance Programme Elements
+
+An effective ITAR compliance programme (recognised by DDTC as a mitigating factor) includes:
+
+### 1. Governance and Leadership
+- Designated **Empowered Official (EO)** (22 CFR § 120.67): A US person with authority to sign licence applications and ensure ITAR compliance; must be in a senior position with ability to override business decisions for compliance reasons
+- Written **ITAR Compliance Policy** signed by senior management
+- Clear escalation path for export control questions
+- Annual management review of compliance programme effectiveness
+
+### 2. Training
+- **Initial training** for all employees with ITAR access within 30 days of hire
+- **Annual refresher training** covering recent regulatory changes, enforcement actions, and company-specific procedures
+- **Role-specific training** for: Empowered Officials, shipping/logistics, engineering/R&D, legal, IT
+- Training records retained 5 years
+
+### 3. Technology Control Plan (TCP)
+
+A TCP controls access to ITAR-controlled technical data, especially by foreign nationals.
+
+**TCP Sections:**
+```
+1. Purpose and Scope
+2. ITAR-controlled items and data inventory
+3. Physical access controls (secure areas, visitor escorts, badging)
+4. IT access controls (network segregation, access lists, encryption)
+5. Foreign national screening procedure
+   - Collect citizenship information at hire/engagement
+   - Screen against denied parties lists
+   - Determine if TAA/licence required before granting access
+6. Visitor and contractor procedures
+7. Annual ITAR training programme
+8. Incident identification, reporting, and response
+9. Records management (5-year retention)
+10. TCP review and update cycle (annual minimum)
+```
+
+### 4. Screening and Due Diligence
+Screen all parties (customers, suppliers, employees, visitors) against:
+- **DDTC Debarred Parties List** (22 CFR § 127.7)
+- **OFAC Specially Designated Nationals (SDN) List**
+- **BIS Denied Persons List, Entity List, Unverified List**
+- **US State Department Watch Lists**
+
+Screening must be documented and re-run at each transaction.
+
+### 5. Jurisdiction and Classification Review
+- Formal **product classification process** for every new item, component, and software
+- Document classification decisions (USML citation or EAR ECCN) with rationale
+- Review classifications when product is modified, use-case changes, or regulations change
+- Consider **Commodity Jurisdiction (CJ)** requests for ambiguous items
+
+### 6. Licence Management
+- Centralised tracking of all active licences, TAAs, MLAs
+- Pre-shipment licence review checklist
+- Licence condition compliance (quantities, end-users, re-export restrictions)
+- Timely licence renewals (track expiry dates with 90-day advance reminders)
+- Post-shipment filing (Automated Export System / Electronic Export Information)
+
+### 7. Audits
+- Annual internal ITAR compliance audit (or third-party audit every 2–3 years)
+- Audit scope: registration currency, licence compliance, TCP effectiveness, training records, screening logs, record retention
+- Findings documented with corrective action plans and owners
+
+---
+
+## Penalties — 22 CFR Part 127 and 22 USC § 2778
+
+### Civil Penalties
+- Up to **$1,369,000 per violation** (amount adjusted annually under the Federal Civil Penalties Inflation Adjustment Act)
+- Each unlicensed export, each unlicensed disclosure of technical data, each brokering violation = separate violation
+- DDTC may impose civil penalties via Consent Agreement without criminal referral
+
+### Criminal Penalties
+- Up to **$1,000,000 fine** per violation (22 USC § 2778(c))
+- Up to **20 years imprisonment** per violation
+- Criminal cases referred to Department of Justice; prosecuted by DOJ National Security Division
+
+### Debarment
+- DDTC may debar any person from ITAR privileges (22 CFR § 127.7)
+- Duration: typically 3 years; can be permanent for egregious violations
+- Debarment prevents: registration, licensing, TAA/MLA participation, US government contracting
+- Published on the DDTC Debarred Parties List
+
+### Other Consequences
+- **Seizure and forfeiture** of articles involved in violations (22 USC § 2778(e))
+- **Suspension of export privileges** pending investigation
+- **Congressional notification** requirements for significant violations involving foreign governments
+- **Reputational harm** — consent agreements are publicly disclosed
+
+---
+
+## Voluntary Self-Disclosure (VSD) — 22 CFR § 127.12
+
+### Why Disclose
+VSD is the strongest available mitigating factor. DDTC's guidelines recognise that companies with effective compliance programmes that self-discover and promptly disclose violations deserve leniency.
+
+### VSD Process
+
+**Step 1 — Initial Notification** (~30 days from discovery)
+- Submit brief written notification to DDTC Director of Compliance
+- Include: company name, registration number, general description of the potential violation, estimated number of occurrences
+- Request a tolling agreement to preserve statute of limitations while investigation proceeds
+
+**Step 2 — Internal Investigation** (30–90 days)
+- Investigate all facts: who knew what, when, what was exported/disclosed, to whom
+- Pull all records (licences, shipping docs, emails, TAA files)
+- Identify root cause (process failure, training gap, deliberate act)
+- Preserve all evidence; place litigation hold if appropriate
+
+**Step 3 — Final VSD Report** (within ~60–90 days of initial notification)
+Submit comprehensive written report including:
+- Detailed factual narrative of all violations
+- CFR sections violated for each occurrence
+- Identification of all parties involved
+- Timeline of events
+- Root cause analysis
+- Corrective actions already implemented
+- Proposed additional remediation
+
+**Step 4 — DDTC Review and Resolution**
+- DDTC reviews report; may request additional information
+- Outcomes: no action, warning letter, civil penalty (usually reduced), or referral for criminal review
+- Most cooperative VSDs resolved within 6–18 months
+
+### Mitigating Factors
+- Voluntary self-disclosure
+- Cooperation with DDTC investigation
+- Effective pre-existing compliance programme
+- Prompt remediation
+- No prior ITAR violations
+- Low national security harm
+- Relatively low transaction value
+
+### Aggravating Factors
+- Wilful/deliberate violation
+- Senior management involvement or awareness
+- Harm to national security
+- Pattern of violations
+- Obstruction or lack of cooperation
+- High-risk end-users (state sponsors of terrorism, arms embargoes)
+- Prior violations
+
+---
+
+## DDTC Blue Lantern End-Use Monitoring
+
+The **Blue Lantern** programme is DDTC's end-use monitoring initiative. US embassy personnel conduct post-shipment verifications to confirm items reached the stated end-user and are being used as authorised.
+
+**Implications for exporters:**
+- Cooperate fully with Blue Lantern checks (failure to cooperate can trigger licence suspension)
+- Maintain accurate shipping records to facilitate verification
+- Include cooperation obligations in contracts with foreign distributors
+- Report if you discover items have been diverted or misused
+
+---
+
+## Checklist — ITAR Compliance Programme Readiness
+
+| Area | ✅ | Key Questions |
+|------|----|--------------|
+| Registration | | Is registration current? Renewal filed on time? |
+| Empowered Official | | Named EO with written authority? |
+| Policy | | IS Policy signed by senior management? |
+| TCP | | Written TCP? Reviewed in last 12 months? |
+| Training | | All ITAR-access employees trained in last 12 months? Records retained? |
+| Classification | | All products/components formally classified? CJ obtained where needed? |
+| Screening | | SDN/debarment screening at every transaction? Documented? |
+| Licence tracking | | All licences logged? Expiry alerts set? Conditions tracked? |
+| Record retention | | 5-year retention in place? Accessible for audit? |
+| Internal audit | | Annual ITAR audit completed? Findings tracked? |
+| Incident response | | VSD procedure documented and communicated? |

package/src/bmad-plus/packs/pack-shield/references/itar/licensing-guide.md

@@ -0,0 +1,146 @@
+# ITAR Licensing Guide — 22 CFR Parts 123–125
+
+## License Types at a Glance
+
+| License / Agreement | CFR Reference | Purpose | Typical Use |
+|--------------------|---------------|---------|-------------|
+| DSP-5 | 22 CFR § 123.1 | Permanent export of defense articles | Hardware sale/transfer to foreign end-user |
+| DSP-73 | 22 CFR § 123.5 | Temporary export | Trade shows, testing, repair abroad |
+| DSP-94 | 22 CFR § 123.6 | Temporary import | Foreign defense article entering US temporarily |
+| DSP-61 | 22 CFR § 123.9 | Import license | Permanent import from certain countries |
+| Technical Assistance Agreement (TAA) | 22 CFR § 124.1 | Export of technical data / defense services | Engineering support, training, design assistance |
+| Manufacturing License Agreement (MLA) | 22 CFR § 124.2 | Licensed foreign manufacture | Overseas production of US defense articles |
+| Warehouse/Distribution Agreement | 22 CFR § 124.14 | Stocking items abroad for resale | Distributor model |
+
+---
+
+## DSP-5 (Permanent Export License)
+
+### When Required
+Any export of USML hardware not covered by an exemption.
+
+### Application Requirements
+Submit via DDTC's D-Trade portal:
+- **Block 1**: Applicant (DDTC registration number)
+- **Block 2**: Country of ultimate destination
+- **Block 3**: Foreign end-user name and address
+- **Block 4**: Description of articles (USML category, quantity, value)
+- **Block 5**: End-use statement (intended use, no re-export without US government approval)
+- **Supporting docs**: Purchase order, end-user certificate, import certificate if required by destination country
+
+### Processing Times
+- Standard: 30–60 days
+- Significant Military Equipment (SME): may require Congressional notification (22 USC § 2776) for sales ≥$14M
+
+### License Conditions (common)
+- Items may not be re-exported without prior DDTC authorisation
+- End-user restrictions apply
+- US government access rights for audits
+- 4-year validity; extendable
+
+---
+
+## DSP-73 (Temporary Export)
+
+### When Required
+Hardware leaving the US temporarily (not for resale/transfer to foreign ownership).
+
+### Key Requirements
+- Describe items precisely; document serial numbers
+- State duration and purpose (e.g., "air show display," "field test," "repair and return")
+- Items must return to the US by the license expiry date
+- License conditions prohibit use in combat, operational deployment
+
+---
+
+## Technical Assistance Agreement (TAA)
+
+### Purpose
+Authorises the export of **technical data** and/or **defense services** to specific foreign persons/entities. Required even for oral disclosure of ITAR-controlled technical data to a foreign national.
+
+### Required TAA Clauses (22 CFR § 124.9)
+1. **Scope of agreement**: Precise description of technical data / defense services
+2. **Parties**: US licensor + all foreign licensees, authorised sub-licensees
+3. **Retransfer prohibition**: No further disclosure/transfer without prior written DDTC approval
+4. **US government rights**: US government may review all records; terminate agreement
+5. **Record-keeping**: 5-year retention
+6. **Audit rights**: US licensor right to audit foreign licensee compliance
+7. **Term**: Normally 5 years; must renew before expiry
+8. **Security classification handling** (if applicable)
+
+### Amendment Requirements
+Any change to scope, parties, or authorised countries requires a formal amendment approved by DDTC.
+
+### Common TAA Uses
+- Sharing engineering drawings with foreign manufacturer
+- Providing maintenance training to foreign military
+- Technical support under FMS (Foreign Military Sales) cases
+- Joint development programmes with foreign partners
+
+---
+
+## Manufacturing License Agreement (MLA)
+
+### Purpose
+Allows a foreign person to manufacture a defense article under US licence — typically for local production under an FMS programme or commercial arrangement.
+
+### Key Differences from TAA
+| Feature | TAA | MLA |
+|---------|-----|-----|
+| What is transferred | Technical data / services | Manufacturing rights + technical data |
+| Foreign party produces? | No | Yes |
+| Sub-licensing allowed? | Conditional | Usually yes, with restrictions |
+| Offset programs | Not typical | Common |
+
+### Required MLA Clauses
+- Licence to manufacture (specific quantities, articles, versions)
+- Quality assurance provisions
+- US government rights (inspection, audit, terminate)
+- Retransfer and re-export controls
+- Royalty / fee structure
+- End-of-programme disposition of tooling and data
+
+---
+
+## ITAR Exemptions (Selected)
+
+Certain transfers do not require a licence if all conditions are met. **Exemptions are NOT blanket authorisations — verify conditions every time.**
+
+### Key Exemptions (22 CFR Part 123–126)
+
+| Exemption | CFR Reference | Conditions |
+|-----------|--------------|-----------|
+| US government | § 126.4 | Export by/for US Dept of Defense, State, etc. with government orders |
+| Canada exemption | § 126.5 | Certain unclassified hardware to Canada only; does not apply to all categories |
+| Australian/UK exemption | § 126.7 | Limited scope for certain Gov-to-Gov and industry-to-industry transfers; requires eligibility verification |
+| Intra-company | § 125.4(b)(9) | Technical data to wholly owned US subsidiary abroad; limited scope |
+| Beta test software | § 125.4(b)(10) | Unclassified software for beta testing by foreign person; narrow conditions |
+| Beta hardware | § 123.16 | Temporary export of unclassified hardware for demonstration; strict limits |
+
+**Australia, UK, Canada Defence Trade Cooperation Treaties**: Provide streamlined licensing for covered defence articles between treaty partners; not a blanket exemption.
+
+---
+
+## Foreign Military Sales (FMS) vs Direct Commercial Sales (DCS)
+
+| Aspect | FMS | DCS |
+|--------|-----|-----|
+| Contract party | US Government (DSCA) | US company directly |
+| ITAR licence | Not required (US Gov exemption) | DSP-5 / TAA required |
+| End-use assurance | US Government provides | US company responsible |
+| Price | Government + administrative fees | Market rate |
+| Delivery risk | US Government manages | US company manages |
+
+---
+
+## Record-Keeping Requirements (22 CFR § 122.5)
+
+All ITAR registrants must maintain for **5 years**:
+- All export/import licences and shipping documents
+- All TAA/MLA agreements and associated records
+- End-user certificates and purchase orders
+- Records of all disclosures of technical data
+- Commodity Jurisdiction requests and determinations
+- Voluntary disclosure records
+
+Records must be available for inspection by DDTC, US Customs, DoD, or other US government agencies.

package/src/bmad-plus/packs/pack-shield/references/itar/usml-categories.md

@@ -0,0 +1,93 @@
+# USML Categories — United States Munitions List (22 CFR § 121.1)
+
+The USML consists of 21 categories. Items **specifically enumerated** here are ITAR-controlled as defense articles.
+
+---
+
+## Category I — Firearms, Close Assault Weapons and Combat Shotguns
+Firearms with calibre ≤ 20mm; rifles, carbines, pistols, revolvers, shotguns intended for military use; suppressors; bayonets.
+
+## Category II — Guns and Armament
+Guns, howitzers, cannons >20mm; mortars; recoilless rifles; flamethrowers (military); launch tubes.
+
+## Category III — Ammunition/Ordnance
+Ammunition for items in Cat I/II; military explosives and propellants; military pyrotechnics; guided projectiles.
+
+## Category IV — Launch Vehicles, Guided Missiles, Ballistic Missiles, Rockets, Torpedoes, Bombs and Mines
+All military rockets, missiles, bombs, torpedoes, depth charges, land mines; space launch vehicles used for military purposes; re-entry vehicles.
+
+## Category V — Explosives and Energetic Materials, Propellants, Incendiary Agents and their Precursors
+Military explosives and fuels (e.g., PETN, RDX, HMX, TATB); incendiary agents; smoke/obscurant materials specifically designed for military use.
+
+## Category VI — Vessels of War and Special Naval Equipment
+Warships (surface and submarine); armed vessels; military SCUBA and underwater breathing devices; naval nuclear reactors.
+
+## Category VII — Tanks and Military Vehicles
+Tanks; armoured combat vehicles; military tactical vehicles; mine-clearing vehicles; military bridges.
+
+## Category VIII — Aircraft and Associated Equipment
+Military aircraft (manned and unmanned) — fighters, bombers, attack, patrol, transport; military aero-engines; related airframes; certain civil aircraft modified for military use; military life support systems.
+
+## Category IX — Military Training Equipment
+Flight simulators; parachutes (military); military survival equipment; training aircraft simulators.
+
+## Category X — Protective Personnel Equipment and Shelters
+Body armour (beyond NIJ Level III+); combat helmets; NBC protective suits; military nuclear/biological/chemical detection equipment.
+
+## Category XI — Military Electronics
+Military electronic systems: radar (military); jamming equipment; IFF (Identification Friend or Foe); military navigation; electronic warfare (EW); targeting systems; military cryptographic equipment (see also Cat XIII).
+
+## Category XII — Fire Control, Range Finder, Optical and Guidance and Control Equipment
+Military targeting optics; laser rangefinders (military); infrared imaging (military); night-vision devices (NVDs); military gyroscopes; fire control computers.
+
+## Category XIII — Auxiliary Military Equipment
+Chemical/biological agents (listed); military nuclear materials; depleted uranium; military explosives detection; military training devices; TEMPEST/emissions security equipment; cryptographic items not in Cat XI.
+
+## Category XIV — Toxicological Agents, Including Chemical Agents, Biological Agents, and Associated Equipment
+Schedule 1, 2, 3 chemical weapons agents and precursors (CWC Schedules applied to USML); biological agents suitable for weaponisation; medical countermeasures (military).
+
+## Category XV — Spacecraft Systems and Associated Equipment
+Military satellites; spacecraft systems for intelligence, surveillance, reconnaissance (ISR); directed energy weapons in space; associated ground control equipment.
+
+## Category XVI — Nuclear Weapons, Design and Testing Related Items
+Nuclear weapons; nuclear weapon design and testing software; all items primarily useful for nuclear weapons development.
+
+## Category XVII — Classified Articles, Technical Data and Defense Services Not Otherwise Enumerated
+Catch-all for classified items. No exports without prior DDTC authorisation.
+
+## Category XVIII — Directed Energy Weapons
+High-energy lasers (military); particle beam weapons; high-power radio frequency (HPM) weapons.
+
+## Category XIX — Gas Turbine Engines and Associated Equipment
+Military gas turbine engines for aircraft/vessels/vehicles; hot section components; military engine test equipment.
+
+## Category XX — Submersible Vessels, Oceanographic and Associated Equipment
+Military submarines; autonomous underwater vehicles (military); deep-submergence rescue vehicles; military sonar.
+
+## Category XXI — Articles, Technical Data and Defense Services Not Otherwise Enumerated
+Catch-all for items not covered by Cat I–XX that are determined to provide critical military/intelligence advantage. Used sparingly via CJ determination.
+
+---
+
+## Key Definitions
+
+**Defense article** (22 CFR § 120.31): Any item or technical data designated on the USML.
+
+**Defense service** (22 CFR § 120.32): Furnishing assistance (training, technical data, engineering) to a foreign person for the design, manufacture, production, operation, maintenance, or modification of defense articles.
+
+**Technical data** (22 CFR § 120.33): Information directly related to defense articles in any tangible form — blueprints, drawings, specifications, software source code, test reports.
+
+**Specially designed** (22 CFR § 120.41): The primary test for whether a component or part falls under ITAR. An item is specially designed if it was developed, configured, or adapted to provide a critical performance parameter enabling the military capability of a USML end-item.
+
+---
+
+## USML vs CCL Jurisdiction Tips
+
+| Scenario | Likely Jurisdiction |
+|----------|-------------------|
+| Item specifically listed in USML (Cat I–XXI) | ITAR |
+| Item removed from USML via Export Control Reform | EAR (often ECCN 0Yxxx) |
+| Commercial item with no military application | EAR / EAR99 |
+| Ambiguous — file a Commodity Jurisdiction (CJ) request | DDTC determines |
+
+A **Commodity Jurisdiction (CJ)** determination (22 CFR § 120.4) is the official process to obtain DDTC's ruling on whether an item is on the USML. Submit via DDTC's online portal with item description, specifications, and intended use.