arckit-cli 6.1.1__py3-none-any.whl

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/uk-nhs-dcb0129.md

@@ -0,0 +1,64 @@
+# NHS DCB0129 Manufacturer Clinical Safety Case Guide
+
+> **Command**: `/arckit:uk-nhs-dcb0129` | **Overlay**: [UK NHS Clinical Safety Overlay](uk-nhs-clinical-safety-overlay.md) | **Origin**: Community-contributed
+
+## Purpose
+
+Generates the **manufacturer-side** clinical safety documentation required under NHS DCB0129 for any health IT product being placed on the NHS market. NHS DCB0129 is mandated under the Health and Social Care Act 2012 s250 and applies to *any* health IT system deployed in the NHS, regardless of whether the product is also a medical device.
+
+The output is a 3-file set that follows Dr Marcus Baw's [SAFETY.md spec v2.0.0-draft](https://github.com/pacharanero/SAFETY.md) verbatim — chosen so the documents remain readable by clinicians, NHS England assessors, MHRA inspectors, and Notified Body reviewers without ArcKit-specific tooling.
+
+## What it produces
+
+Three files in `projects/{NNN}-<slug>/clinical-safety/`:
+
+| File | Purpose |
+|---|---|
+| `SAFETY.md` | Front-door anchor: required Marcus-spec fields (product-name, version, CSO, organisation, status, hazard-log-url, last-reviewed) + ArcKit Document Control + Summary |
+| `SAFETY-CASE.md` | Clinical Safety Case Report with 6 GSN-inspired sections: Intended Use, Scope, Safety Argument (G1.1–G1.6 cross-referencing hazards), Evidence, Residual Risk, CSO Sign-off |
+| `HAZARD-LOG.md` | YAML-frontmatter hazard array + controls + rendered Markdown table. 6 starter hazards: wrong-patient identity, stale clinical data, audit-trail gap, authorisation bypass, alert delivery failure, write-integrity loss |
+
+The 3 files together implement the four DCB0129 deliverables — Clinical Risk Management Plan (summarised in `SAFETY.md`), Hazard Log, Clinical Safety Case Report, and Clinical Risk Management File (the repository itself; Git history is the audit trail).
+
+## Risk scoring scales (DCB0129 convention)
+
+- **Severity**: `1` Catastrophic | `2` Major | `3` Considerable | `4` Significant | `5` Minor
+- **Likelihood**: `1` Very High | `2` High | `3` Medium | `4` Low | `5` Very Low
+- **Risk level**: `unacceptable` | `high` | `medium` | `low`
+- **Status**: `open` | `mitigated` | `accepted` | `closed`
+
+> ⚠️ DCB0129 inverts the usual Orange Book convention where 5 = highest. Templates carry the legend prominently.
+
+## When to use
+
+- The system will be deployed in NHS England, Scotland, Wales, or NI as a manufacturer-supplied product
+- The system is software intended to support, inform, or perform clinical functions (decision support, observation capture, prescribing, results display, scheduling for clinical purposes, identity / demographics, etc.)
+- Compare with DCB0160 for **deployer-side** obligations at the deploying NHS organisation
+
+## Prerequisites
+
+Requires the project's REQ, DATA, STKE, RISK artefacts. Will read the project's DPIA if present (privacy hazards may overlap with clinical hazards).
+
+A named, qualified **Clinical Safety Officer** (CSO) with current GMC / NMC / HCPC / GPhC registration MUST be appointed to sign off the case. The command generates the documents in `DRAFT` status with the CSO field left as `[PENDING]`.
+
+## Tiering (Marcus's SAFETY.md spec)
+
+- **Tier 1** (low-risk reference / informational): the CSO may consolidate to a single `SAFETY.md` with embedded hazard table and delete the case + log files
+- **Tier 2** (moderate-risk; the command's default output)
+- **Tier 3** (SaMD; high-risk regulated medical devices): additionally author a `SAFETY-PLAN.md`
+
+## Filename convention
+
+The three filenames deliberately do **not** carry the ArcKit `ARC-` prefix. They pass through the `validate-arc-filename` hook untouched and do not appear in the ArcKit manifest as discrete ARC artefacts. Other documents (DTAC, MDR, project risk register) cross-reference them by relative path.
+
+## Important
+
+This guide and the command's output are **not** clinical, legal, or regulatory advice. The Clinical Safety Case Report MUST be reviewed, materially supplemented, and signed off by a qualified CSO before the product is placed into clinical use.
+
+## Related commands
+
+- `/arckit:uk-nhs-dcb0160` — deployer-side companion (DCB0160)
+- `/arckit:uk-nhs-dtac` — NHS DTAC v3 (consumes the SAFETY-CASE.md content in Section 1)
+- `/arckit:uk-mdr-classification` — if the product is also a medical device, DCB0129 hazards feed the ISO 14971 risk file
+- `/arckit:risk` — project-level risk register cross-references clinical hazards
+- `/arckit:dpia` — privacy hazards may overlap with clinical hazards

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/uk-nhs-dcb0160.md

@@ -0,0 +1,62 @@
+# NHS DCB0160 Deployer Clinical Safety Case Guide
+
+> **Command**: `/arckit:uk-nhs-dcb0160` | **Overlay**: [UK NHS Clinical Safety Overlay](uk-nhs-clinical-safety-overlay.md) | **Origin**: Community-contributed
+
+## Purpose
+
+Generates the **deployer-side** clinical safety documentation required under NHS DCB0160 for an NHS organisation (Trust, ICS, GP federation, mental health Trust, ambulance service) deploying or significantly configuring a health IT product into a specific clinical setting.
+
+DCB0160 sits **alongside** DCB0129 — neither replaces the other. The manufacturer's DCB0129 case argues the product is acceptably safe when used as intended; the deployer's DCB0160 case argues that *this specific deployment*, with this organisation's clinicians, workflows, integrations, training, and business continuity, is acceptably safe in this clinical context.
+
+## What it produces
+
+Three files in `projects/{NNN}-<slug>/clinical-safety/deployment/`, following the same Marcus Baw SAFETY.md spec adapted for deployer use:
+
+| File | Purpose |
+|---|---|
+| `SAFETY.md` | Deployer anchor: product, version-being-deployed, deploying organisation, deploying-organisation CSO, link to manufacturer case |
+| `DEPLOYMENT-SAFETY-CASE.md` | 7 sections: Deployment Context, Scope + Phasing, Manufacturer Case Acceptance, Deployment Safety Argument (G1.1–G1.6 with deployment-specific claims), Local Evidence, Residual Deployment Risk, Deploying-organisation CSO Sign-off |
+| `DEPLOYMENT-HAZARD-LOG.md` | YAML-frontmatter hazard array + controls + rendered Markdown table. 10 starter deployment hazards: inadequate training, workflow integration gap, integration failure, BC failure, parallel-running confusion, data migration error, local configuration error, terminology mismatch, RBAC misalignment, incident-reporting failure |
+
+## When to use
+
+- An NHS organisation is deploying any third-party or in-house health IT product into a clinical setting
+- A deployment involves material local configuration (drug formularies, alert thresholds, role mappings, terminology subsets)
+- A deployment involves significant change to existing clinical workflows
+- Multi-site deployments with material differences in clinical context — run once per site with separate `clinical-safety/deployment/{site-slug}/` subdirectories
+
+## Prerequisites
+
+Requires the project's REQ, DATA, STKE artefacts. If the project also has the manufacturer DCB0129 case (`clinical-safety/SAFETY-CASE.md` and `clinical-safety/HAZARD-LOG.md`), the deployer case directly references those as inputs. If the product is third-party (no in-repo manufacturer case), the manufacturer's externally-supplied case should be linked or attached as a reference.
+
+A named, qualified Clinical Safety Officer at the **deploying organisation** (NOT the product manufacturer's CSO) MUST be appointed to sign off the deployment case.
+
+## Deploying-organisation roles
+
+The template prompts for several NHS-specific governance roles:
+
+- **CSO at the deploying organisation** (GMC / NMC / HCPC / GPhC registered)
+- **Caldicott Guardian** sign-off (information governance)
+- **Senior Information Risk Owner (SIRO)** sign-off
+- Local Implementation Lead and Executive Sponsor at the deploying organisation
+
+## Deployment-specific hazard themes
+
+Beyond the starter set, common deployment-specific hazards to consider in real projects:
+
+- Paediatric vs adult dosing if the local service treats paediatrics — the manufacturer's adult-defaults are a deployment hazard
+- Mental Health Act considerations if the local service is MH
+- Out-of-hours coverage and on-call workflows
+- Interface engine + integration with local PAS / EPR / order-comms / results
+- Local Caldicott / IG positions on data flows the manufacturer assumed were acceptable
+
+## Important
+
+The deployment safety case is a legal obligation of the deploying NHS organisation under DCB0160. A complete DCB0129 manufacturer case does **not** discharge this obligation.
+
+## Related commands
+
+- `/arckit:uk-nhs-dcb0129` — manufacturer-side companion (run first or attach external)
+- `/arckit:uk-nhs-dtac` — DTAC Section 1 may need the deployer case if the deploying NHS organisation is responsible for procurement assurance
+- `/arckit:risk` — deployment-specific risks cross-reference the project risk register
+- `/arckit:operationalize` — runbooks, on-call, incident response feed the deployer hazard-mitigation plan

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/uk-nhs-dtac.md

@@ -0,0 +1,55 @@
+# NHS DTAC v3 Assessment Guide
+
+> **Command**: `/arckit:uk-nhs-dtac` | **Overlay**: [UK NHS Clinical Safety Overlay](uk-nhs-clinical-safety-overlay.md) | **Origin**: Community-contributed
+
+## Purpose
+
+Generates an NHS Digital Technology Assessment Criteria (DTAC) v3 assessment for a digital health product being procured or assured by an NHS organisation. DTAC is the de facto NHS England procurement-assurance baseline used by NHS Trust procurement teams, ICS digital teams, NHS Supply Chain framework buyers, and NHS England innovation pathways.
+
+DTAC overlaps but does not replace MHRA medical-device regulation (run `/arckit:uk-mdr-classification` if the product is a medical device) or the GDS Service Standard (run `/arckit:service-assessment` if the product is also a GDS-assessed service).
+
+## What it produces
+
+Single artefact `projects/{NNN}-<slug>/ARC-{NNN}-NHSDTAC-v1.0.md` covering five sections plus an optional AI annex:
+
+| Section | Coverage | ArcKit cross-references |
+|---|---|---|
+| 1. Clinical Safety | DCB0129 + DCB0160 status, CSO, hazard log open count, highest open risk | `clinical-safety/SAFETY-CASE.md`, `HAZARD-LOG.md` |
+| 2. Data Protection | UK GDPR / DPA 2018 lawful basis, DPIA, DSPT, sub-processors, data-subject rights | `dpia` output |
+| 3. Technical Assurance | Cloud hosting, security certifications (Cyber Essentials, ISO 27001), SDLC, encryption, pen test, BC/DR, vulnerability management | `secure`, `hld`, `dld` |
+| 4. Interoperability | FHIR UK Core, SNOMED CT, dm+d, NHS Number, NHS APIs (PDS, e-RS, GP Connect, NHS App Connect, NHS login, BARS) | `data-model`, `adr` |
+| 5. Usability + Accessibility | NHS Service Standard, WCAG 2.2 AA, screen-reader / keyboard / contrast evidence, plain English | `service-assessment` |
+
+The **AI annex** is required when the product uses AI/ML for any clinically-relevant function — model class, training-data provenance, ATRS publication, fairness assessment, model drift monitoring, human-in-the-loop / human-on-the-loop design, transparency to clinicians and patients, MHRA AIaMD Programme alignment.
+
+## When to use
+
+- The product is being submitted to an NHS Trust, ICS, or national NHS buyer for procurement assurance
+- The product is being onboarded to an NHS framework (e.g. Spark DPS, Health Systems Support Framework)
+- The deploying organisation requires a DTAC pack as part of clinical onboarding
+
+## Prerequisites
+
+The richest output comes when the project already has DPIA, ATRS (if AI), Secure by Design assessment, and DCB0129/0160 cases in place. The DTAC artefact cross-references all of these. The command marks `[PENDING]` for criteria that depend on these missing inputs rather than fabricating compliance.
+
+## DTAC version pinning
+
+DTAC v3 is current as at 2026-05. Verify against <https://transform.england.nhs.uk/key-tools-and-info/digital-technology-assessment-criteria-dtac/> before submission — if NHS England has published a new version, the section structure may have changed. The artefact carries its source-version reference.
+
+## `[PENDING — organisation responsibility]` markers
+
+Many DTAC items depend on activities the deploying NHS organisation must complete (DSPT submission, local Caldicott Guardian sign-off, organisational pen-test of the integrated solution). The artefact uses `[PENDING — organisation responsibility]` explicitly rather than asserting these are complete from product-side evidence alone.
+
+## Important
+
+DTAC pass status does not constitute MHRA medical-device approval, does not constitute DCB0129/0160 compliance, and does not constitute UK GDPR compliance. Each is a separate assurance with its own evidence trail.
+
+## Related commands
+
+- `/arckit:uk-nhs-dcb0129` — manufacturer Clinical Safety Case (Section 1 evidence)
+- `/arckit:uk-nhs-dcb0160` — deployer Clinical Safety Case (Section 1 evidence, deploying-organisation perspective)
+- `/arckit:dpia` — Section 2 evidence
+- `/arckit:atrs` — AI annex evidence
+- `/arckit:secure` — Section 3 evidence
+- `/arckit:service-assessment` — overlapping NHS Service Standard assessment
+- `/arckit:uk-mdr-classification` — for medical-device determination, parallel to DTAC

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/upgrading.md

@@ -0,0 +1,130 @@
+# Upgrading ArcKit
+
+> **Guide Origin**: Official | **ArcKit Version**: [VERSION]
+
+How to upgrade the ArcKit CLI and update your existing projects.
+
+---
+
+## Step 1: Upgrade the CLI
+
+```bash
+# If installed with pip:
+pip install --upgrade git+https://github.com/tractorjuice/arc-kit.git
+
+# If installed with uv:
+uv tool upgrade arckit-cli --from git+https://github.com/tractorjuice/arc-kit.git
+
+# Verify the new version:
+arckit --help
+```
+
+---
+
+## Step 2: Update Your Existing Project
+
+Navigate to your existing ArcKit project directory and re-run init with `--here`:
+
+```bash
+cd /path/to/your-existing-project
+
+# Re-initialize in place (updates commands, templates, scripts)
+arckit init --here --ai codex
+```
+
+### What Gets Updated
+
+| Updated | Preserved |
+|---------|-----------|
+| Skills (`.agents/skills/`) | Project data (`projects/`) |
+| Default templates (`.arckit/templates/`) | Custom templates (`.arckit/templates-custom/`) |
+| Helper scripts (`.arckit/scripts/`) | |
+| Documentation and guides (`docs/`) | |
+| `VERSION`, `CHANGELOG.md` | |
+
+> **Note:** For Claude Code users, commands and agents are provided by the ArcKit plugin and update automatically via the marketplace. No `arckit init` needed.
+
+> **Note:** For Gemini CLI users, use the ArcKit extension (`gemini extensions install https://github.com/tractorjuice/arckit-gemini`). Updates via `gemini extensions update arckit`.
+
+> **Note:** `README.md` will be overwritten. If you've customized it, back it up first:
+>
+> ```bash
+> cp README.md README.md.bak
+> arckit init --here --ai codex
+> mv README.md.bak README.md
+> ```
+
+### Options
+
+| Flag | Description |
+|------|-------------|
+| `--ai codex` | Update Codex CLI commands |
+| `--minimal` | Skip updating docs and guides |
+
+---
+
+## Step 3 (Optional): Migrate Legacy Filenames
+
+If upgrading from **v0.x** to **v1.x**, your project artifacts may use old-style filenames (e.g., `requirements.md`, `stakeholder-drivers.md`). ArcKit v1.x uses standardized Document IDs:
+
+```text
+Old: requirements.md
+New: ARC-001-REQ-v1.0.md
+```
+
+Run the migration script to rename files automatically:
+
+```bash
+# Preview changes first (no files modified)
+.arckit/scripts/bash/migrate-filenames.sh --all --dry-run
+
+# Apply the migration
+.arckit/scripts/bash/migrate-filenames.sh --all
+```
+
+The script:
+
+- Creates timestamped backups before making changes
+- Skips files that are already migrated
+- Handles subdirectories (decisions, diagrams, wardley-maps, etc.)
+- Moves legacy locations (e.g., `.arckit/memory/principles.md` to `projects/000-global/`)
+
+See the [migration guide](migration.md) for the complete filename mapping table and advanced options.
+
+---
+
+## Checking Your Version
+
+```bash
+# Check installed CLI version
+arckit --help
+
+# Check project version (in an ArcKit project directory)
+cat VERSION
+```
+
+---
+
+## Troubleshooting
+
+### "Directory already exists" error
+
+Use `--here` (or `.`) to update an existing project in place:
+
+```bash
+# These are equivalent:
+arckit init --here --ai codex
+arckit init . --ai codex
+```
+
+### Commands not updating
+
+Make sure you upgraded the CLI first (Step 1), then re-ran init (Step 2). The init command copies the latest commands from the installed package.
+
+### Custom templates lost
+
+Custom templates in `.arckit/templates-custom/` are preserved across upgrades. Only default templates in `.arckit/templates/` are refreshed. If you edited files in `.arckit/templates/` directly (instead of `.arckit/templates-custom/`), those edits will be overwritten. Use `/arckit:customize` to set up the override workflow:
+
+```bash
+/arckit:customize requirements   # Copy template for safe customization
+```

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/us-ai-impact.md

@@ -0,0 +1,71 @@
+# US AI Impact Assessment (OMB M-24-10 / M-25-21)
+
+> **Overlay**: USA Federal Civilian Community Overlay | **ArcKit Version**: [VERSION]
+
+`/arckit:us-ai-impact` generates an AI Impact Assessment under OMB M-24-10 (Advancing Governance, Innovation, and Risk Management for Agency Use of AI) and OMB M-25-21 (Accelerating Federal Use of AI through Innovation, Governance, and Public Trust). It determines whether the AI use case is **rights-impacting**, **safety-impacting**, both, or neither; applies the corresponding minimum practices; captures the AI use-case inventory entry for federal.ai.gov; and documents the M-25-21 acquisition clauses where the AI is procured rather than built.
+
+The assessment is the **agency-facing AI governance artefact** — it is what the agency Chief AI Officer (CAIO) reviews, what the public AI use-case inventory cites, and what underpins the disclosures owed to affected individuals. Failing to mark a rights-impacting use case as such (or failing to publish it) is the single biggest M-24-10 finding pattern.
+
+Reviewed by the CAIO, the SAOP for privacy alignment, the System Owner, and the agency procurement / contracts function where M-25-21 acquisition clauses apply.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| AI RMF Assessment (`ARC-<id>-AIRMF-v1.0.md`) | Risk evidence base |
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | AI use case, decision logic, user population |
+| Privacy Impact Assessment (`ARC-<id>-USPIA-v1.0.md`) | PII handling, individual notice posture |
+| Stakeholders (`ARC-<id>-STKE-v1.0.md`) | Affected populations, decision recipients |
+
+---
+
+## Output
+
+- **Doc-type**: `AIIA`
+- **Filename**: `ARC-<PID>-AIIA-v1.0.md` (project root, single-instance)
+
+---
+
+## Process Overview
+
+1. Determine rights-impacting / safety-impacting classification per M-24-10 definitions.
+2. Apply the minimum-practices checklist (impact assessment, real-world testing, monitoring, human review, public notice, opt-out).
+3. Capture the federal.ai.gov use-case inventory record.
+4. Where the AI is procured, build the M-25-21 acquisition clauses into the SOW / contract.
+5. Surface disclosures, opt-out pathways, and feedback channels.
+
+---
+
+## Regulatory Anchors
+
+- **OMB M-24-10** — <https://www.whitehouse.gov/wp-content/uploads/2024/03/M-24-10-Advancing-Governance-Innovation-and-Risk-Management-for-Agency-Use-of-Artificial-Intelligence.pdf>
+- **OMB M-25-21** — <https://www.whitehouse.gov/omb/management/ofcio/>
+- **federal.ai.gov AI use-case inventory** — <https://ai.gov/ai-use-cases/>
+- **NIST AI 600-1 (Generative AI Profile)** — <https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf>
+
+---
+
+## Example Usage
+
+```bash
+/arckit:us-ai-impact 001-claims-triage-llm
+```
+
+---
+
+## Common Pitfalls
+
+- **Failing to mark rights-impacting AI as such.** The definitions in M-24-10 are deliberately broad. If the AI affects access to benefits, employment, housing, healthcare, education, immigration, criminal justice, or civil rights — it is rights-impacting. Treat the default as "yes" and argue otherwise with evidence.
+- **Skipping public disclosure.** M-24-10 requires the AI use case to be entered in the agency's inventory at federal.ai.gov, and rights-impacting AI requires individual notice. Internal-only documentation is non-compliance.
+- **Not building M-25-21 acquisition clauses into vendor contracts.** Procured AI inherits the same M-24-10 minimum practices. Without acquisition clauses, the vendor is not obliged to support the agency in meeting them.
+- **Treating "AI" narrowly.** Rule-based decision aids that drive consequential decisions can be in scope under the M-24-10 definition; not only ML / LLM systems.
+
+---
+
+## Handoffs
+
+- **`us-ai-rmf`** — the AI RMF assessment is the evidence base
+- **`us-privacy-pia`** — privacy notice and AI notice obligations interact
+- **`risk`** — AIIA-surfaced residual risks flow into the project risk register

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/us-ai-rmf.md

@@ -0,0 +1,70 @@
+# US NIST AI RMF Assessment
+
+> **Overlay**: USA Federal Civilian Community Overlay | **ArcKit Version**: [VERSION]
+
+`/arckit:us-ai-rmf` produces a NIST AI Risk Management Framework 1.0 assessment for an AI/ML system, scoring the four core functions (Govern, Map, Measure, Manage) and applying the AI RMF Playbook actions. Where generative AI is in scope, the assessment cross-references **NIST AI 600-1 (Generative AI Profile)** to add GenAI-specific risk categories (confabulation, data privacy leakage, harmful bias, value chain risk, dangerous content, IP infringement, etc.).
+
+This artefact is the **AI risk evidence base** that downstream artefacts (`us-ai-impact`, vendor evaluations, ATO packages) cite. It is voluntary at federal level but functionally required: the M-24-10 / M-25-21 chain expects agencies to demonstrate AI risk management, and the AI RMF is the agreed framework.
+
+Reviewed by the agency Chief AI Officer (CAIO), Senior AI Official (SAO), Senior Agency Official for Privacy (SAOP), the System Owner, and the AI safety / model-evaluation function where one exists.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | AI-related FRs and NFRs, decision logic |
+| Data Model (`ARC-<id>-DMOD-v1.0.md`) | Training data, inference data, PII flags |
+| Architecture Principles (`ARC-<id>-PRIN-v1.0.md`) | Responsible-AI principles |
+
+---
+
+## Output
+
+- **Doc-type**: `AIRMF`
+- **Filename**: `ARC-<PID>-AIRMF-v1.0.md` (project root, single-instance)
+
+---
+
+## Process Overview
+
+1. Apply the four AI RMF functions in turn — Govern, Map, Measure, Manage.
+2. Walk the AI RMF Playbook actions; capture evidence, gaps, owners.
+3. Where GenAI is in scope, apply the NIST AI 600-1 cross-reference for GenAI risk categories.
+4. Score each function (qualitative + evidence-backed) and document the measurement plan.
+5. Surface high-residual-risk items for the impact assessment and the risk register.
+
+---
+
+## Regulatory Anchors
+
+- **NIST AI RMF 1.0** — <https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf>
+- **NIST AI RMF Playbook** — <https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook>
+- **NIST AI 600-1 (Generative AI Profile)** — <https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf>
+
+---
+
+## Example Usage
+
+```bash
+/arckit:us-ai-rmf 001-claims-triage-llm
+```
+
+---
+
+## Common Pitfalls
+
+- **Scoring all four functions equally without evidence.** Govern is usually mature, Measure is usually weakest. Equal scoring across the board is a tell that the assessment was theoretical.
+- **Ignoring GenAI-specific risks when LLMs are involved.** If the system uses LLMs / foundation models, the AI 600-1 profile is not optional — confabulation and value-chain risk in particular need explicit treatment.
+- **No measurement plan.** Risk that cannot be measured cannot be managed. Each high-residual risk needs a metric, a threshold, and a data source.
+- **Treating AI RMF as a one-shot.** Models drift, training data rotates, user populations evolve — refresh the assessment on each retrain or material change.
+
+---
+
+## Handoffs
+
+- **`us-ai-impact`** — AI RMF feeds the OMB M-24-10 / M-25-21 impact assessment
+- **`us-privacy-pia`** — AI-decision logic and training-data PII feed the PIA
+- **`risk`** — high-residual AI risks flow into the project risk register
+- **`adr`** — foundation-model selection, fine-tuning vs. RAG, sovereignty calls warrant ADRs

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/us-federal-overlay.md

@@ -0,0 +1,111 @@
+# USA Federal Civilian Overlay — Maintenance & Citation Register
+
+> **Overlay Origin**: Community-contributed | **Domain co-maintainer**: [recruiting — open call] | **ArcKit Version**: [VERSION]
+
+## Purpose
+
+The USA Federal Civilian Overlay adds 10 community-contributed commands that ground architecture artefacts in the federal civilian regulatory stack — FIPS 199 categorization, NIST SP 800-53 Rev 5 tailoring, FedRAMP authorization (SSP + RAR), CISA Zero Trust Maturity Model v2.0, ICAM under M-19-17, the NIST AI RMF + the OMB M-24-10 / M-25-21 chain, the E-Government Act §208 PIA, and EO 14028 secure-software attestation + SBOM.
+
+The target audience is federal civilian agencies building or procuring information systems, and the vendors who serve them (FedRAMP-pursuing CSPs, system integrators, AI / ML providers). The overlay is positioned for agency System Owners, ISSOs, Authorizing Officials, CAIOs, SAOPs, and the architects supporting them.
+
+The overlay is shipped as **`[COMMUNITY]`** tier rather than official baseline. Federal civilian statutory currency moves faster than a single maintainer can verify with confidence — EO 14110 was issued in October 2023 and revoked in January 2025; M-25-21 superseded the prior acquisition guidance in 2025; FedRAMP Rev 5 completed transition in 2024. A community tier signals: "the regulatory anchors here are the ones the maintainer has verified on the date stamped in the citation register; you must re-verify before relying on them for go-live decisions."
+
+---
+
+## When to Use the Overlay
+
+- The contracting authority is a **federal civilian agency** (department, independent agency, executive branch entity outside DoD / IC).
+- The system handles federal data under **FISMA boundary** (44 U.S.C. §3551 et seq.).
+- An **AI use case** is in scope under **OMB M-24-10** (use of AI) or **M-25-21** (acquisition of AI).
+- The vendor is **pursuing FedRAMP authorization** (Low / Moderate / High / LI-SaaS) for federal customer adoption.
+- The agency **Senior AI Official** or **SAOP** needs artefacts for the federal.ai.gov AI use-case inventory or for the §208 PIA register.
+
+---
+
+## Out of Scope
+
+- **Federal defense (DoD, IC).** CMMC, RMF for DoD IT, DISA-STIGs, JSIG, NIST SP 800-171 for CUI in non-federal systems — covered by a future `arckit-us-dod` overlay, not this one.
+- **State governments.** StateRAMP, TX-RAMP, AZ-RAMP, CJIS Security Policy — sibling state overlays where they exist.
+- **Sector-specific regimes.** HIPAA (HHS / HIPAA-covered entities), GLBA (financial), SOX (publicly traded), PCI-DSS (payment card) — these layer on top and need their own assessments.
+- **Section 508 accessibility.** Deferred to v5.2. Until then, use agency-specific Section 508 guidance and the GSA accessibility resources directly.
+
+---
+
+## Citation Register
+
+Every regulatory anchor used across the overlay's commands, with verification timestamps. Verification is repeated quarterly — next scheduled review **2026-08-23**.
+
+| Anchor | URL | Verified | Last Checked | Notes |
+|---|---|---|---|---|
+| FIPS Publication 199 | <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf> | 2026-05-23 | 2026-05-23 | Stable since 2004; CIA + impact-level definitions |
+| NIST SP 800-60 Vol 2 Rev 1 | <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-60v2r1.pdf> | 2026-05-23 | 2026-05-23 | Information-type catalogue |
+| NIST SP 800-53 Rev 5 | <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf> | 2026-05-23 | 2026-05-23 | Active baseline; Rev 5 transition complete |
+| NIST SP 800-53B | <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53B.pdf> | 2026-05-23 | 2026-05-23 | Control baselines (Low / Moderate / High / Privacy) |
+| NIST SP 800-37 Rev 2 | <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf> | 2026-05-23 | 2026-05-23 | RMF for Information Systems and Organizations |
+| NIST SP 800-63-3 (A / B / C) | <https://pages.nist.gov/800-63-3/> | 2026-05-23 | 2026-05-23 | Digital Identity Guidelines; IAL / AAL / FAL |
+| NIST SP 800-207 | <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf> | 2026-05-23 | 2026-05-23 | Zero Trust Architecture |
+| NIST SP 800-218 (SSDF) | <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf> | 2026-05-23 | 2026-05-23 | Secure Software Development Framework v1.1 |
+| NIST SP 800-122 (PII Protection) | <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-122.pdf> | 2026-05-23 | 2026-05-23 | Guide to Protecting the Confidentiality of PII |
+| NIST AI RMF 1.0 | <https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf> | 2026-05-23 | 2026-05-23 | Four functions: Govern, Map, Measure, Manage |
+| NIST AI 600-1 (Generative AI Profile) | <https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf> | 2026-05-23 | 2026-05-23 | GenAI cross-cutting risks |
+| FIPS 201-3 | <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.201-3.pdf> | 2026-05-23 | 2026-05-23 | PIV for federal employees and contractors |
+| FedRAMP Rev 5 Baselines | <https://www.fedramp.gov/rev5/baselines/> | 2026-05-23 | 2026-05-23 | Low / Moderate / High / LI-SaaS |
+| FedRAMP SSP Template Rev 5 | <https://www.fedramp.gov/documents-templates/> | 2026-05-23 | 2026-05-23 | Current template revision |
+| FedRAMP RAR Template | <https://www.fedramp.gov/documents-templates/> | 2026-05-23 | 2026-05-23 | 3PAO readiness assessment |
+| FedRAMP Authorization Boundary Guidance | <https://www.fedramp.gov/assets/resources/documents/CSP_A_FedRAMP_Authorization_Boundary_Guidance.pdf> | 2026-05-23 | 2026-05-23 | Boundary heuristics |
+| CISA ZTMM v2.0 | <https://www.cisa.gov/zero-trust-maturity-model> | 2026-05-23 | 2026-05-23 | 5 pillars + 3 cross-cuts, 4 stages |
+| CISA Secure Software Development Attestation Form | <https://www.cisa.gov/secure-software-attestation-form> | 2026-05-23 | 2026-05-23 | EO 14028 attestation vehicle |
+| OMB M-03-22 (E-Gov PIA guidance) | <https://www.whitehouse.gov/wp-content/uploads/2017/11/203-M-03-22-OMB-Guidance-for-Implementing-the-Privacy-Provisions-of-the-E-Government-Act-of-2002-1.pdf> | 2026-05-23 | 2026-05-23 | Implementing guidance for §208 |
+| OMB M-19-17 (ICAM) | <https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf> | 2026-05-23 | 2026-05-23 | ICAM policy for federal agencies |
+| OMB M-22-09 (Federal Zero Trust) | <https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf> | 2026-05-23 | 2026-05-23 | Federal zero-trust strategy |
+| OMB M-22-18 (Secure Software / SBOM) | <https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf> | 2026-05-23 | 2026-05-23 | EO 14028 implementation |
+| OMB M-23-16 (M-22-18 Update) | <https://www.whitehouse.gov/wp-content/uploads/2023/06/M-23-16-Update-to-M-22-18-Enhancing-Software-Security-.pdf> | 2026-05-23 | 2026-05-23 | Timeline + scope clarification |
+| OMB M-24-10 (Agency Use of AI) | <https://www.whitehouse.gov/wp-content/uploads/2024/03/M-24-10-Advancing-Governance-Innovation-and-Risk-Management-for-Agency-Use-of-Artificial-Intelligence.pdf> | 2026-05-23 | 2026-05-23 | Active; replaced EO 14110 requirements |
+| OMB M-25-21 (AI Acquisition) | <https://www.whitehouse.gov/omb/management/ofcio/> | 2026-05-23 | 2026-05-23 | AI acquisition clauses |
+| EO 14028 (Improving the Nation's Cybersecurity) | <https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity> | 2026-05-23 | 2026-05-23 | Secure-software supply chain anchor |
+| E-Government Act 2002 §208 | <https://www.justice.gov/opcl/e-government-act-2002> | 2026-05-23 | 2026-05-23 | PIA statutory authority |
+| Privacy Act of 1974 (5 U.S.C. §552a) | <https://www.justice.gov/opcl/privacy-act-1974> | 2026-05-23 | 2026-05-23 | SoR / SORN statutory authority |
+| FISMA Modernization Act of 2014 | <https://www.congress.gov/bill/113th-congress/senate-bill/2521> | 2026-05-23 | 2026-05-23 | 44 U.S.C. §3551 et seq. |
+| login.gov developer documentation | <https://developers.login.gov/> | 2026-05-23 | 2026-05-23 | GSA shared identity service for the public |
+
+---
+
+## Quarterly Review Cadence
+
+The citation register above is re-verified every quarter. **Next scheduled review: 2026-08-23.** The maintainer walks each URL in turn; if a URL 404s or the document has been superseded, the row is updated and the Notes column records the move (including a wayback-machine snapshot URL — `https://web.archive.org/web/<timestamp>/<original-url>` — where the original is gone). Material changes to a regulatory anchor (revision, supersession, revocation) trigger a corresponding update to the affected `us-*` command files within 14 days, plus a CHANGELOG entry.
+
+---
+
+## Known Limitations
+
+- **Section 508 accessibility is not covered.** Deferred to ArcKit v5.2; until then, use the GSA Section 508 resources and agency-specific accessibility guidance directly.
+- **CUI / Confidential / Secret / Top Secret marking is not covered in v1.** The overlay focuses on civilian unclassified information; classified-system architecture sits with the future `arckit-us-dod` overlay.
+- **State-level regimes are not covered.** StateRAMP, TX-RAMP, AZ-RAMP, CJIS Security Policy — sibling overlays where they exist; sector-specific overlays where they don't.
+- **Sector-specific regimes are not covered.** HIPAA, GLBA, SOX, PCI-DSS layer on top; if any apply, treat them as additional artefacts, not as parts of this overlay.
+- **No live A&A test against a real FedRAMP package.** The templates are based on the published FedRAMP SSP and RAR template structures; they have not been put in front of a 3PAO or the FedRAMP PMO for a real authorization decision. Treat as a strong starting point, not a guaranteed-pass package.
+
+---
+
+## Statutory Currency Anchor
+
+- **EO 14110 was revoked in January 2025.** The successor anchors for federal AI governance are **OMB M-24-10** (agency use of AI) and **OMB M-25-21** (AI acquisition). The overlay tracks the M-24-10 / M-25-21 chain, not EO 14110.
+- **FedRAMP completed the Rev 5 transition in 2024.** Rev 4 is retired for new authorisations; the overlay anchors on Rev 5 throughout.
+- **OMB M-22-18 / M-23-16 secure-software attestation has been active since 2024.** Agencies have been collecting CISA attestation forms since common-form-availability in March 2024.
+
+If any of these change materially before the next quarterly review, the maintainer will issue an out-of-band CHANGELOG update.
+
+---
+
+## Domain Co-maintainer — Open Call
+
+The overlay is currently solo-maintained. For reference, the Australian overlay maintainer is [@royster70](https://github.com/royster70) and the Canadian overlay is anonymous-community. The USA overlay is seeking a federal-civilian SME co-maintainer — backgrounds welcome from agency CISO offices, Senior Agency Officials for Privacy (SAOPs), FedRAMP PMO / 3PAO practitioners, agency Chief AI Officers, or federal architecture leads with direct ATO experience.
+
+If you have relevant federal-civilian architecture experience and are interested in co-maintaining, [open an issue](https://github.com/tractorjuice/arc-kit/issues) or DM [@tractorjuice](https://github.com/tractorjuice).
+
+Co-maintainer recruitment is a precondition for re-evaluating the overlay for official-baseline promotion.
+
+---
+
+## Changelog Reference
+
+Per-release changes are recorded in [`plugins/arckit-us/CHANGELOG.md`](../../plugins/arckit-us/CHANGELOG.md). Citation-register verifications are also reflected there with the quarterly date and the rows touched.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/us-fedramp-readiness.md

@@ -0,0 +1,69 @@
+# US FedRAMP Readiness Assessment Report
+
+> **Overlay**: USA Federal Civilian Community Overlay | **ArcKit Version**: [VERSION]
+
+`/arckit:us-fedramp-readiness` generates a FedRAMP Readiness Assessment Report (RAR) — the 3PAO-led capability-and-evidence assessment that determines whether a CSP is ready to enter a full FedRAMP authorization. The RAR scores the CSP's technical capability, documentation maturity, and the presence of the foundational evidence (architecture, ICAM, encryption, audit, ConMon, IR) demanded by the JAB or sponsoring Agency.
+
+A "FedRAMP Ready" designation, published on the FedRAMP Marketplace, is the public signal that a CSP can credibly pursue authorization. RAR findings shape the POA&M, surface the gating gaps, and feed the JAB prioritisation discussion. Optimistic POA&M dates are the single most common reason a Ready package is bounced back to the CSP.
+
+Reviewed by the 3PAO (lead assessor signature required), the CSP's CISO, and FedRAMP PMO during marketplace review. Independent re-review every 12 months while the designation is active.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| FedRAMP SSP (`ARC-<id>-FRSSP-v1.0.md`) | System Security Plan being assessed for readiness |
+| Tailored Control Set (`ARC-<id>-NIST-v1.0.md`) | Control selection underpinning the SSP |
+| All supporting evidence artefacts | ICAM, encryption inventory, audit catalogue, IR plan, ConMon strategy |
+
+---
+
+## Output
+
+- **Doc-type**: `FRRR`
+- **Filename**: `ARC-<PID>-FRRR-v1.0.md` (project root, single-instance)
+
+---
+
+## Process Overview
+
+1. Confirm the SSP scope and authorisation boundary are stable.
+2. Walk the FedRAMP RAR Template sections (capability statement, architecture, ICAM, encryption, audit, ConMon, IR, supply chain).
+3. Score each section: Met / Partially Met / Not Met, with evidence citations.
+4. Build the POA&M for Partially Met / Not Met items with realistic dates and owners.
+5. Capture the Customer Responsibility Matrix (CRM) and shared-responsibility narrative.
+
+---
+
+## Regulatory Anchors
+
+- **FedRAMP RAR Template** — <https://www.fedramp.gov/documents-templates/>
+- **FedRAMP Agency Authorization Playbook** — <https://www.fedramp.gov/agency-authorization/>
+- **FedRAMP JAB Prioritization Criteria** — <https://www.fedramp.gov/jab-prioritization/>
+
+---
+
+## Example Usage
+
+```bash
+/arckit:us-fedramp-readiness 001-citizen-benefits-portal
+```
+
+---
+
+## Common Pitfalls
+
+- **Optimistic POA&M dates.** A POA&M full of "30-day" dates that quietly slip undermines confidence. Set defensible dates tied to engineering capacity, not best-case.
+- **Missing penetration-test evidence.** A current independent pentest report is a hard requirement; many CSPs skimp here and bounce back from PMO review.
+- **Not articulating the CRM.** The Customer Responsibility Matrix must enumerate every customer-side control. "Customer is responsible for managing accounts" is too vague.
+- **Treating Ready as the destination.** Ready is a milestone, not authorization. Plan the post-Ready 3PAO assessment and JAB / Agency engagement on the same timeline.
+
+---
+
+## Handoffs
+
+- **`service-assessment`** — RAR readiness feeds the broader service assessment posture
+- **`roadmap`** — POA&M dates shape the authorization roadmap
+- **`risk`** — Not Met items flow into the risk register as authorisation-blocking risks