arckit-cli 6.1.1__py3-none-any.whl

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/au-e8-posture.md

@@ -0,0 +1,73 @@
+# Australian Essential Eight Maturity Posture Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:au-e8-posture` generates an ASD Essential Eight maturity posture against the Australian Signals Directorate's Essential Eight Maturity Model. It scores each of the eight mitigation strategies (application control, patch applications, configure Microsoft Office macro settings, user application hardening, restrict administrative privileges, patch operating systems, multi-factor authentication, regular backups) against maturity levels ML0–ML3, captures the evidence base, identifies the maturity uplift path, and surfaces the DISP-aligned target (ML2 baseline for DISP Level 2 supplier accreditation).
+
+The Essential Eight is the ASD's prioritised baseline for mitigating cyber security incidents and is the cyber baseline that DISP, federal entities, and most Commonwealth procurements measure against. The artefact this command produces is therefore a foundational input to almost every other Australian Federal security or assurance artefact — run it early.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | Service description, hosting model, user populations |
+| Data model (`ARC-<id>-DMOD-v1.0.md`) | Sensitive data categories that drive control intensity |
+| Stakeholders (`ARC-<id>-STKE-v1.0.md`) | Accountable authority, security operations owner |
+
+---
+
+## Command
+
+```bash
+/arckit:au-e8-posture <project ID or service description>
+```
+
+Output: `projects/<id>/ARC-<id>-AUE8-v1.0.md`
+
+---
+
+## Assessment Structure
+
+| Section | Contents |
+|---------|----------|
+| Document Control | Australian classification (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET / TOP SECRET) |
+| Revision History | Version, date, author, changes, approvals |
+| Executive Summary | Current maturity by strategy, gap to target maturity, headline residual risks |
+| Scope | In-scope systems, business units, environments (production / staging / non-production) |
+| Maturity Assessment per Strategy | For each of the 8: current ML, target ML, evidence cited, gap analysis, planned uplift |
+| Uplift Plan | Sequenced remediation with effort, dependencies, and DISP-attestation deadline alignment |
+| Residual Risk Statement | Risks accepted, treatments in flight, escalation path |
+| Maintenance Cadence | Re-assessment frequency, change triggers, ASD update tracking |
+
+---
+
+## Regulatory Anchors
+
+- **ASD Essential Eight Maturity Model** — eight mitigation strategies, maturity levels ML0–ML3 (the authoritative source for scoring rubric)
+- **ASD Information Security Manual (ISM)** — control-level detail referenced by E8 strategies (cross-reference via `/arckit:au-ism-controls`)
+- **Defence Industry Security Program (DISP) Levels 1–3** — ML2 mandated for DISP Level 2 supplier accreditation
+- **Commonwealth Procurement Rules (November 2025 overhaul)** — cyber maturity questions in standard supplier responses
+
+---
+
+## When to Run
+
+- Early in delivery, immediately after stakeholders and requirements — before HLD or detailed security design
+- Re-run on material change to hosting, identity, or admin access model
+- Refresh annually at minimum; DISP suppliers refresh on the attestation cadence (typically 12 months)
+
+---
+
+## Common Pitfalls
+
+- **Scoping too wide** — assessing the whole organisation when the artefact is service-specific produces a low-confidence score. Tighten scope to the service or DISP-accredited business unit.
+- **Missing evidence date** — every cited evidence item needs a "verified on" date so reviewers can judge currency. Make the date a hard field.
+- **Confusing ML2 with "good enough"** — ML2 is the DISP baseline, not a security ceiling. Where the residual risk justifies it, target ML3 on individual strategies.
+
+---
+
+## Handoff
+
+Foundational input to `/arckit:au-disp-attestation` (DISP Member self-attestation pack consolidates E8 evidence), `/arckit:au-pspf` (PSPF cross-references E8 baselines), and `/arckit:au-ism-controls` (ISM Statement of Applicability draws from the same control evidence).

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/au-energy-compliance.md

@@ -0,0 +1,47 @@
+# AU Energy Compliance Pack
+
+`/arckit:au-energy-compliance` generates an Australian energy compliance pack that integrates AESCSF maturity with energy-market obligations, IT/OT evidence, privacy, notifiable data breach readiness, traceability, diagrams/data flows, data modelling, and ADR decisions.
+
+Use it after the AU federal community baseline is in place. The command depends on `au-aescsf` and can compose optional `au-ot-security` and `au-soci-cirmp` outputs when connected OT or SOCI/CIRMP obligations are in scope.
+
+## Prerequisites
+
+| Artefact | Why it helps |
+|----------|--------------|
+| `/arckit:requirements` | Source for energy-market, customer, resilience, safety, and regulatory obligations |
+| `/arckit:stakeholders` | Identifies responsible entity, operator, market participant, regulator, customer, privacy, OT, and supplier stakeholders |
+| `/arckit:au-pia` (`ARC-<id>-AUPIA-v1.0.md`) | Privacy Act evidence for customer, metering, life-support, DER, and operational data |
+| `/arckit:au-ndb-playbook` (`ARC-<id>-AUNDB-v1.0.md`) | Breach-response and notification evidence |
+| `/arckit:au-ot-security` (`ARC-<id>-AUOT-v1.0.md`) | Optional connected OT and secure-connectivity evidence |
+| `/arckit:au-soci-cirmp` (`ARC-<id>-AUSOCI-v1.0.md`) | Optional SOCI/CIRMP critical-infrastructure evidence |
+| `/arckit:au-aescsf` (`ARC-<id>-AUAESCSF-v1.0.md`) | AESCSF maturity baseline and uplift plan |
+| `/arckit:dfd`, `/arckit:diagram`, and `/arckit:data-model` | Evidence for IT/OT, DER, market, telemetry, customer, and supplier data flows |
+| `/arckit:adr` | Decisions for ring-fencing, AEMO integration, CSIP-AUS, remote access, data sharing, and resilience trade-offs |
+| `/arckit:traceability` | Links energy obligations to requirements, controls, risks, diagrams, data models, and decisions |
+
+## Usage
+
+```text
+/arckit:au-energy-compliance 001
+/arckit:au-energy-compliance "Retailer DER orchestration platform"
+```
+
+Output: `projects/<id>/ARC-<id>-AUENERGY-v1.0.md`
+
+## What It Produces
+
+- Energy-sector scope and obligation profile.
+- AESCSF evidence integration and uplift dependencies.
+- AER ring-fencing, NER/NGR, AEMO, DER, market, and customer-data considerations.
+- IT/OT and vendor connectivity evidence, including data-flow and diagram references.
+- Privacy and Notifiable Data Breach evidence for customer, metering, DER, outage, life-support, and market data.
+- ADR summary for architecturally significant compliance and resilience decisions.
+- Traceability matrix linking obligations, controls, evidence, risks, diagrams, data models, and decisions.
+
+## Source Currency
+
+Verify the current AESCSF package/version, AEMO guidance availability, AER guidance, NER/NGR obligations, and any market-procedure references at run time. The command should record the source version and access date used for the assessment.
+
+## Evaluation Fixtures
+
+The public AU energy fixture corpus under `tests/fixtures/au-energy` is synthetic, including organisations, scenarios, evidence, and personas. It is intended for public evaluation, regression testing, and community improvement.

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

@@ -0,0 +1,199 @@
+# Australian Federal / DISP-supplier Overlay Guide
+
+> **Overlay Origin**: Community-contributed | **Domain co-maintainer**: @royster70 | **ArcKit Version**: [VERSION]
+
+The Australian Federal / DISP-supplier Overlay adds 10 community-contributed commands covering the regulatory anchors that apply to Australian Federal entities, Defence-cleared suppliers (DISP Members), and optional cross-sector critical-infrastructure use cases. It is anchored on ASD Essential Eight + Information Security Manual, ASD operational technology guidance, the Security of Critical Infrastructure Act 2018 / CIRMP, the DTA Digital Service Standard, the Privacy Act 1988 + 13 Australian Privacy Principles, the OAIC Notifiable Data Breach scheme, the Defence Industry Security Program (DISP, Levels 1–3), the Protective Security Policy Framework, the November 2025 Commonwealth Procurement Rules overhaul, the DTA AI Assurance Framework + Responsible AI Policy v2.0, the PGPA Act s16 financial-management duties, and IRAP for cloud-service assessment.
+
+The overlay closes [#424](https://github.com/tractorjuice/arc-kit/issues/424). A sibling sector recipe `au-energy` covering AESCSF, AER ring-fencing, NER/NGR, and AEMO obligations for energy-sector / SOCI-covered critical-asset operators addresses [#440](https://github.com/tractorjuice/arc-kit/issues/440). The general `au-ot-security` and `au-soci-cirmp` commands live here because OT security and SOCI/CIRMP apply beyond energy; `au-energy` consumes them rather than redefining them privately.
+
+> **Follow-up**: after the AU energy PR lands, refresh the main AU community command guidance so `au-e8-posture`, `au-ism-controls`, `au-pia`, `au-ndb-playbook`, `au-ot-security`, and `au-soci-cirmp` explicitly recommend the energy overlay, diagrams, data flows, data modelling, and traceability where relevant.
+
+---
+
+## Purpose
+
+Five jobs in one overlay:
+
+1. **Make ASD's cyber stack a first-class architectural artefact**, not a security-team afterthought — Essential Eight maturity posture and ISM Statement of Applicability sit alongside requirements and HLD.
+2. **Replace UK GDPR / DPA 2018 with Privacy Act 1988**, including the Tranche 1 reforms (December 2024) and the December 2026 AI-decision notification provisions.
+3. **Replace UK GDS Service Standard with DTA Digital Service Standard** as the citizen-service quality gate.
+4. **Make DISP Member self-attestation auditable** — the four DISP security domains (governance, personnel, physical, information & cyber) each get an evidence trail, plus FOCI declaration, supply chain, and annual board attestation.
+5. **Ground AI delivery in DTA AI Assurance Framework v2.0** with explicit AI Accountable Officer designation and Privacy-Act-aligned automated-decision notification.
+6. **Add optional cross-sector critical-infrastructure evidence**, separating ASD OT security and SOCI/CIRMP support so users can apply either or both before a sector overlay such as `au-energy`.
+
+---
+
+## When to Use
+
+Use the overlay if any of the following apply to the project:
+
+- The contracting authority is an **Australian Federal entity** (department, agency, statutory authority) or a Commonwealth-controlled corporate entity.
+- The project handles **personal information** of Australian residents and is in scope of the **Privacy Act 1988** (APP entity threshold: $3M annual turnover or any health-service provider).
+- The project provides services to the **Department of Defence** or its supply chain — **DISP membership** is required for Levels 1–3 supplier accreditation.
+- The system is in scope of **PSPF** (Protective Security Policy Framework) — applies to all non-corporate Commonwealth entities under PGPA Act.
+- The procurement is run under the **November 2025 Commonwealth Procurement Rules** overhaul (AUD 125k SME-only thresholds, AI transparency clauses, ethical conduct in VfM).
+- The project includes AI/ML/LLM in scope and is subject to the **DTA AI Assurance Framework + Responsible AI Policy v2.0** (effective December 2025) and the **NAIC Essential AI Practices ("AI6")** operational guidance.
+- The project includes connected **operational technology** or cyber-physical systems and needs ASD OT guidance alignment. Enable `AU_OT` in the recipe or run `/arckit:au-ot-security`.
+- The project may involve a **SOCI-regulated critical infrastructure asset** and needs CIRMP governance or evidence. Enable `AU_SOCI` in the recipe or run `/arckit:au-soci-cirmp`.
+
+For non-AU projects the overlay is dormant: existing UK, MOD, EU, French, Austrian, UAE, and Canada overlays are unchanged.
+
+---
+
+## Prerequisites
+
+Before running the commands, set the plugin userConfig values:
+
+| userConfig key | Value |
+|---|---|
+| `governance_framework` | `AU Federal` |
+| `classification_scheme` | `PSPF` (UNOFFICIAL → TOP SECRET ladder) |
+| `organisation_name` | the Federal entity name (or the contracting Defence supplier name) |
+| `default_classification` | one of `UNOFFICIAL`, `OFFICIAL`, `OFFICIAL:Sensitive`, `PROTECTED`, `SECRET`, `TOP SECRET` |
+
+> **Note on rendering**: The PSPF classification taxonomy is applied to AU artefacts via a per-command override at the marker-resolution step (mirrors the Canadian-overlay pattern in `ca-pia.md:32`). Each `au-*` command instructs the resolver to swap the standard UK classification line for `UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET`, so the AU artefacts come out with PSPF rendering regardless of these userConfig values. The `governance_framework` and `classification_scheme` settings are still useful as documented intent (project records, downstream tooling, traceability), and a future enhancement (a dedicated `document-control-au.md` partial + extended `RENDERING.md` routing) will make them drive global rendering for **non-AU** artefacts produced inside an AU project too. Until then, set these for clarity but do not rely on them to switch the global Document Control header.
+
+If you are a Defence supplier rather than a Federal entity, set `organisation_name` to your supplier name and use the `au-disp-attestation` command to produce the DISP Member self-attestation pack — the rest of the overlay still applies to the project itself, with the contracting Federal entity treated as the "system owner".
+
+---
+
+## The 10 Commands
+
+### Security baseline
+
+#### `/arckit:au-e8-posture`
+
+Generates an ASD Essential Eight maturity posture assessment covering all 8 mitigation strategies (Application Control, Patch Applications, Configure MS Office Macro Settings, User Application Hardening, Restrict Administrative Privileges, Patch Operating Systems, Multi-factor Authentication, Regular Backups) at maturity levels ML0 through ML3. Anchored on the ASD Essential Eight Maturity Model. Handoffs: `au-ism-controls` (E8 maturity feeds ISM Domain 9 — System Hardening), `au-disp-attestation` (E8 ML2 evidence is primary input to DISP Domain 4 — Information & Cyber Security), and `au-aescsf` in the sibling `au-energy` recipe.
+
+#### `/arckit:au-ism-controls`
+
+Generates an ASD Information Security Manual Statement of Applicability across all 17 control domains (Cyber Security Roles & Responsibilities; Cyber Security Incidents; Outsourced Services; Security Documentation; Personnel Security; Physical Security; Communications Infrastructure; Communications Systems; Enterprise Mobility; Evaluated Products; Information Technology Equipment; Media; System Hardening; System Management; System Monitoring; Software Development; Database Systems & Servers; Network Security; Cryptography; Gateways; Data Transfers). ISM extends E8 — produces the comprehensive control set on top of the mitigation baseline. Handoffs: `risk` (gaps and treatment plan), `au-pspf` (Outcome 2 — information security — instantiated by ISM), `au-disp-attestation` (cross-refs Domain 4).
+
+### Privacy + Incident Response
+
+#### `/arckit:au-pia`
+
+Generates a Privacy Impact Assessment under Privacy Act 1988 s33D (introduced by the Tranche 1 reforms, December 2024) including assessment against all 13 Australian Privacy Principles (APP 1 — Open and transparent management of personal information; APP 2 — Anonymity and pseudonymity; APP 3 — Collection of solicited personal information; APP 4 — Dealing with unsolicited personal information; APP 5 — Notification of collection; APP 6 — Use or disclosure; APP 7 — Direct marketing; APP 8 — Cross-border disclosure; APP 9 — Adoption / use / disclosure of government related identifiers; APP 10 — Quality of personal information; APP 11 — Security of personal information; APP 12 — Access to personal information; APP 13 — Correction of personal information). Replaces the UK `dpia` command for AU projects. Handoffs: `au-ndb-playbook` (NDB depends on PIA — APP 11 + Privacy Officer designation), `au-ai-assurance` (APP 1, 5, 10, 12 cross-refs for AI-decision notification per the December 2026 amendments), `data-model` (per-entity sensitivity), `risk`.
+
+#### `/arckit:au-ndb-playbook`
+
+Generates an OAIC Notifiable Data Breach scheme operational response playbook (Privacy Act Part IIIC). Documents the 30-day notification timeline, the eligible-data-breach assessment criteria, the OAIC reporting workflow, and the affected-individual notification template. Operational artefact — depends on `au-pia` because it requires the designated Privacy Officer (APP 1) and APP 11 control inventory from the PIA. Handoffs: `au-disp-attestation` (DISP incident reporting cross-refs NDB), `risk`.
+
+### Optional critical infrastructure support
+
+#### `/arckit:au-ot-security`
+
+Generates an ASD operational technology cyber security assessment for connected OT, ICS, SCADA, cyber-physical, building-management, field-device, or industrial-control environments. Covers OT architecture visibility, IT/OT segmentation, secure connectivity, remote/vendor access, monitoring, logging, incident response, safety, availability, recovery constraints, and AI-in-OT considerations where relevant. Handoffs: `au-e8-posture` and `au-ism-controls` for baseline cyber evidence, `au-soci-cirmp` where the OT environment supports a critical infrastructure asset, and `risk` for residual OT exposure.
+
+#### `/arckit:au-soci-cirmp`
+
+Generates a SOCI Act / Critical Infrastructure Risk Management Program governance and evidence pack. Covers critical asset and responsible entity context, SOCI applicability, CIRMP governance, cyber and information security hazards, personnel hazards, supply-chain hazards, physical security and natural hazards, protected-information handling, incident reporting, and annual report readiness. It is deliberately separate from `au-ot-security`: some SOCI assets do not include OT, and some OT environments may not trigger SOCI obligations.
+
+### Service + AI compliance
+
+#### `/arckit:au-dss`
+
+Generates a DTA Digital Service Standard conformance assessment against all 13 criteria (1. Understand user needs; 2. Solve a whole problem; 3. Provide a joined-up experience; 4. Make it simple and intuitive; 5. Use ATO/digital-government building blocks; 6. Build a multidisciplinary team; 7. Iterate and improve frequently; 8. Use open standards; 9. Make it accessible and inclusive; 10. Test the service; 11. Measure performance; 12. Provide an unbroken digital service; 13. Use trusted hosting and supplier arrangements). Replaces the UK `tcop` command for AU projects (DTA DSS is the AU equivalent of UK TCoP). Handoffs: `au-e8-posture` (Criterion 13 cross-refs E8/IRAP-assessed hosting), `au-pia` (Criterion 7 cross-refs PIA + privacy notice).
+
+#### `/arckit:au-pspf`
+
+Generates a Protective Security Policy Framework outcomes scorecard against the 4 outcomes (Security Governance; Information Security; Personnel Security; Physical Security) and 16 core requirements. PSPF Outcome 2 (Information Security) is instantiated by `au-ism-controls` — the PSPF scorecard pulls from the ISM Statement of Applicability. Handoffs: `au-disp-attestation` (DISP Domain 1 — Governance — cross-refs PSPF Outcome 1; Domain 3 — Physical — cross-refs PSPF Outcome 4), `risk`.
+
+#### `/arckit:au-ai-assurance`
+
+Generates a DTA AI Assurance Framework baseline aligned to Responsible AI Policy v2.0 (effective December 2025), incorporating ISO 42001 readiness mapping, AI Accountable Officer designation, foundation-model selection and sovereignty, AI-use disclosure requirements, and Privacy Act AI-decision notification provisions (December 2026 commencement). Also covers **AU Essential AI Practices ("AI6")** — the National AI Centre's 6 essential practices for safe and responsible AI adoption (accountability / impact assessment / risk management / information sharing / testing-and-monitoring / human control), with each practice anchored to the canonical [ai.gov.au Foundations](https://www.ai.gov.au/staying-safe-and-responsible/essential-ai-practices/guidance-ai-adoption-foundations) and [Implementation Guidance](https://www.ai.gov.au/staying-safe-and-responsible/essential-ai-practices/guidance-ai-adoption-implementation-guidance) pages. Handoffs: `au-pia` (APP cross-refs for AI-decision notification), `au-e8-posture` (DLP cross-refs), `risk` (AI-specific risks), `adr` (AI/LLM provider decision is architecturally significant).
+
+### DISP attestation (consolidation)
+
+#### `/arckit:au-disp-attestation`
+
+Generates a DISP Member self-attestation pack — the apex artefact for Defence-supplier scope. Consolidates the four DISP security domains (Governance & Personnel; Personnel Security; Physical Security; Information & Cyber Security) plus FOCI (Foreign Ownership, Control and Influence) declaration, supply chain assurance, and the annual board attestation. **Run last in the AU stream** — it pulls evidence from `au-e8-posture` (Domain 4), `au-ism-controls` (Domain 4 + cross-domain), `au-pia` + `au-ndb-playbook` (privacy alignment + incident reporting), and `au-pspf` (Domain 1 + Domain 3 cross-refs). Per the DISP framework, attestation level (1, 2, or 3) determines the rigour expected — Level 2 is the typical Federal-supplier baseline, Level 3 applies to higher-classification work.
+
+---
+
+## Build recipe
+
+Recipe: [`au-federal.yaml`](../../arckit-au/recipes/au-federal.yaml)
+
+37 default targets across the build waves + 3 post-build hooks (`arckit:health`, `arckit:graph-report`, `arckit:pages`), with optional default-off `AIP`, `DATASCOUT`, `AU_OT` and `AU_SOCI` targets for cross-sector critical-infrastructure and procurement use. The recipe swaps three commands from the `uk-saas` baseline (per maintainer guidance on #424):
+
+- `arckit:tcop` → `arckit:au-dss` (DTA DSS replaces UK TCoP)
+- `arckit:secure` → `arckit:au-e8-posture` (E8 ML2 replaces UK Secure-by-Design)
+- `arckit:dpia` → `arckit:au-pia` (Privacy Act 1988 replaces UK GDPR/DPA 2018)
+
+The wave shape mirrors `ca-federal-fitaa` — foundation → research wave + early domain artefacts → mid-domain → late ADRs → flagship → synthesis. `AU_DISP` is the consolidation flagship in W5, depending on `AU_E8`, `AU_ISM`, `AU_PIA`, `AU_NDB`, and `AU_PSPF` having completed in earlier waves.
+
+### Visual and evidence targets
+
+The recipe enables architecture and evidence artefacts by default so compliance findings can cite real structure rather than narrative: `DIAG` (diagrams), `DFD` (data flow diagrams), `DATA_MODEL`, `SNOW` (ServiceNow / CMDB), `TRACEABILITY`, and `MATURITY` (a `MMOD` capability maturity model). The optional `AU_OT` and `AU_SOCI` targets consume these as inputs, and the `arckit:graph-report` post-build hook surfaces coverage across the AU compliance, architecture, risk, traceability, and operations artefacts.
+
+All AU Federal commands and templates apply a **Visual Evidence Decision Rule**: companion visuals are generated only when the evidence has enough structure to identify real nodes and relationships; when evidence is partial but structurally useful, a clearly marked draft visual is produced with `Pending Input` labels; otherwise the artefact records a *Visual Evidence Gap* listing the minimum inputs needed, instead of inventing a diagram from insufficient data.
+
+To add OT and SOCI/CIRMP support to a federal build:
+
+```bash
+/arckit:build <project-name> --recipe au-federal --enable AU_OT --enable AU_SOCI
+```
+
+Use only `--enable AU_OT` for OT environments that are not SOCI-regulated, or only `--enable AU_SOCI` where CIRMP applies without OT. For Australian energy projects, use the `au-energy` recipe after the AU federal baseline; it can compose both optional targets before adding AESCSF and energy-market obligations.
+
+To run:
+
+```bash
+# In a Claude Code session with the ArcKit plugin enabled:
+/arckit:build <project-name> --recipe au-federal --plan      # wave-plan dry run
+/arckit:build <project-name> --recipe au-federal             # full build
+```
+
+Reference test fixture: [`arckit-test-project-v44-australian-gov`](https://github.com/tractorjuice/arckit-test-project-v44-australian-gov) — the Australian Government PoC test repo.
+
+---
+
+## Migration from UK ladder
+
+If you are migrating an existing UK-classified ArcKit project to the AU overlay:
+
+1. Update plugin userConfig: switch `governance_framework` to `AU Federal`, `classification_scheme` to `PSPF`, and pick a `default_classification` from the PSPF taxonomy. (See the *Note on rendering* in Prerequisites — under the current per-command override approach these settings record intent; the AU artefacts get PSPF rendering through their own commands rather than via global routing.)
+2. Re-run `/arckit:health` to validate the Document Control headers in any newly-generated AU artefacts against the PSPF ladder.
+3. Replace UK-specific artefacts where AU equivalents exist:
+   - `ARC-*-DPIA-*.md` → re-generate as `ARC-*-AUPIA-*.md` via `/arckit:au-pia`
+   - `ARC-*-SECD-*.md` (Secure-by-Design) → re-generate as `ARC-*-AUE8-*.md` via `/arckit:au-e8-posture`
+   - `ARC-*-TCOP-*.md` → re-generate as `ARC-*-AUDSS-*.md` via `/arckit:au-dss`
+4. Add the Defence-supplier and Federal-entity-specific artefacts:
+   - `/arckit:au-ism-controls` for ISM SoA
+   - `/arckit:au-pspf` for PSPF outcomes scorecard
+   - `/arckit:au-ndb-playbook` for NDB response
+   - `/arckit:au-ai-assurance` if AI is in scope
+   - `/arckit:au-ot-security` if connected OT or cyber-physical systems are in scope
+   - `/arckit:au-soci-cirmp` if SOCI/CIRMP obligations are in scope
+   - `/arckit:au-disp-attestation` if Defence supply-chain accreditation is in scope
+5. Run `/arckit:traceability` to refresh the cross-reference matrix.
+
+---
+
+## Co-maintenance
+
+The overlay is currently solo-maintained by [@royster70](https://github.com/royster70). An Australian Federal enterprise architect (or DISP-cleared supplier architect) is being recruited as domain co-maintainer before the overlay can be re-evaluated for official-baseline promotion. If you have relevant Federal/DISP 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).
+
+---
+
+## References
+
+- [ASD Essential Eight Maturity Model](https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight/essential-eight-maturity-model)
+- [ASD Information Security Manual](https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism)
+- [ASD Operational Technology environments](https://www.cyber.gov.au/business-government/secure-design/operational-technology-environments)
+- [ASD Principles of operational technology cyber security](https://www.cyber.gov.au/resources-business-and-government/maintaining-devices-and-systems/critical-infrastructure/principles-operational-technology-cybersecurity)
+- [ASD Secure connectivity principles for Operational Technology](https://www.cyber.gov.au/business-government/secure-design/operational-technology-environments/secure-connectivity-principles-for-operational-technology)
+- [Security of Critical Infrastructure Act 2018 (SOCI)](https://www.cisc.gov.au/legislation-regulation-and-compliance/soci-act-2018)
+- [CISC Regulatory obligations](https://www.cisc.gov.au/how-we-support-industry/regulatory-obligations)
+- [DTA Digital Service Standard](https://www.dta.gov.au/help-and-advice/digital-service-standard)
+- [Privacy Act 1988 (Cth)](https://www.legislation.gov.au/Details/C2024C00301)
+- [OAIC Notifiable Data Breach scheme](https://www.oaic.gov.au/privacy/notifiable-data-breaches)
+- [Defence Industry Security Program (DISP)](https://www.defence.gov.au/business-industry/programs/defence-industry-security-program)
+- [Protective Security Policy Framework (PSPF)](https://www.protectivesecurity.gov.au/)
+- [Commonwealth Procurement Rules](https://www.finance.gov.au/government/procurement/commonwealth-procurement-rules) (November 2025 overhaul)
+- [DTA AI Assurance Framework + Responsible AI Policy v2.0](https://www.digital.gov.au/policy/ai/policy)
+- [NAIC Essential AI Practices (AI6) — Foundations](https://www.ai.gov.au/staying-safe-and-responsible/essential-ai-practices/guidance-ai-adoption-foundations)
+- [NAIC Essential AI Practices — Implementation Guidance](https://www.ai.gov.au/staying-safe-and-responsible/essential-ai-practices/guidance-ai-adoption-implementation-guidance)
+- [PGPA Act 2013 s16](https://www.legislation.gov.au/Details/C2024C00310)
+- [Information Security Registered Assessors Program (IRAP)](https://www.cyber.gov.au/about-us/programs-and-services/irap)

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/au-ism-controls.md

@@ -0,0 +1,78 @@
+# Australian ISM Statement of Applicability Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:au-ism-controls` generates a Statement of Applicability against the Australian Signals Directorate's Information Security Manual (ISM). It scopes the system, surveys the 17 ISM control domains for in-scope controls, scores each control's implementation posture with evidence, captures the residual risk, and surfaces the IRAP-assessable posture (Information Security Registered Assessors Program — the Australian government's cloud-inheritance and external-assessment programme).
+
+The ISM is the authoritative control library for Australian Federal entities and DISP suppliers. The SoA is the gate artefact for IRAP assessment, security accreditation, and PSPF Outcome 4 (Information Security).
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | Service description, hosting model, data flows |
+| Data model (`ARC-<id>-DMOD-v1.0.md`) | Sensitivity categories driving control intensity |
+| `/arckit:au-e8-posture` output (`ARC-<id>-AUE8-v1.0.md`) | Cyber baseline that the ISM SoA cross-references |
+| HLD (`ARC-<id>-HLD-v1.0.md`) | Architecture, identity model, key management |
+
+---
+
+## Command
+
+```bash
+/arckit:au-ism-controls <project ID or service description>
+```
+
+Output: `projects/<id>/ARC-<id>-AUISM-v1.0.md`
+
+---
+
+## Assessment Structure
+
+| Section | Contents |
+|---------|----------|
+| Document Control | Australian classification (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET / TOP SECRET) |
+| Revision History | Version, date, author, changes, approvals |
+| Executive Summary | Coverage, gaps, IRAP readiness, accreditation posture |
+| System Scope | Description, owner, classification ceiling, hosting environments |
+| Domain-by-Domain Analysis | All 17 ISM control domains: applicability, implementation posture, evidence, gaps |
+| Control Inheritance | Inherited controls from underlying cloud or platform (cite IRAP assessment letters where relied on) |
+| Residual Risk Statement | Risks accepted, escalation path, treatment commitments |
+| IRAP Posture | Whether the system is IRAP-assessable, target assessment date, scope boundary |
+| Accreditation Strategy | Internal accreditation route or cross-jurisdictional accreditation (Cyber-Hub, etc.) |
+| Maintenance Cadence | Re-assessment frequency, change triggers, ISM update tracking (ASD publishes quarterly) |
+
+---
+
+## Regulatory Anchors
+
+- **ASD Information Security Manual (ISM)** — 17 control domains; quarterly-updated control library
+- **PSPF Outcome 4 (Information Security)** — federal accountability framework that cites the ISM as authoritative
+- **IRAP (Information Security Registered Assessors Program)** — primary external-assessment route, especially for cloud inheritance
+- **Cyber Security Act 2024 (Cth)** — incident reporting obligations relevant to security incidents tracked against ISM controls
+- **PGPA Act 2013 s16** — federal accountable-authority duties
+
+---
+
+## When to Run
+
+- During HLD / detailed design, after the architecture has stabilised enough to enumerate control inheritance
+- Before IRAP assessment kicks off (the SoA is the input to the assessor's scoping)
+- Re-run on material architecture change or quarterly ISM update where control changes affect the system
+- DISP Level 2+ suppliers refresh on the attestation cycle
+
+---
+
+## Common Pitfalls
+
+- **Treating every ISM control as in-scope** — the SoA is about applicability. Mark out-of-scope controls explicitly with rationale; assessors flag thin-scoping faster than thick-scoping.
+- **Claiming inheritance without an IRAP letter** — cloud or platform inheritance requires a current IRAP assessment letter. Without it, the control is not inherited — it's the customer's to implement.
+- **Stale evidence dates** — ISM controls reference fresh evidence (logs, configs, scan output). Mark anything older than the assessment window as stale.
+
+---
+
+## Handoff
+
+Foundational input to `/arckit:au-disp-attestation` (DISP Information & Cyber domain draws heavily from the ISM SoA), `/arckit:au-pspf` (PSPF Outcome 4 cites ISM SoA evidence), and feeds the IRAP assessor scoping package.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/au-ndb-playbook.md

@@ -0,0 +1,80 @@
+# Australian Notifiable Data Breach Response Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:au-ndb-playbook` generates an operational response playbook under the OAIC Notifiable Data Breaches scheme (Privacy Act 1988 Part IIIC). It captures the assessment criteria for an eligible data breach, the 30-day investigation clock, the notification decision logic, the workflow for notifying affected individuals and the OAIC, and the post-incident review obligations including remediation tracking and lessons-learned capture.
+
+The NDB playbook is operational — it is read in the middle of an incident, not at design time. It must be precise about timeframes, roles, and decision criteria. Where the playbook depends on the eligible-data-breach test, the language follows OAIC guidance verbatim.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| `/arckit:au-pia` output (`ARC-<id>-AUPIA-v1.0.md`) | Personal information inventory; eligible-data-breach criteria already drafted |
+| Stakeholders (`ARC-<id>-STKE-v1.0.md`) | Accountable authority, privacy officer, security incident commander |
+| Risk register (`ARC-<id>-RISK-v1.0.md`) | Data-breach risks identified at design time |
+| Runbooks (`ARC-<id>-RBK-v1.0.md`) | Existing incident response procedures the NDB workflow plugs into |
+
+---
+
+## Command
+
+```bash
+/arckit:au-ndb-playbook <project ID or service description>
+```
+
+Output: `projects/<id>/ARC-<id>-AUNDB-v1.0.md`
+
+---
+
+## Playbook Structure
+
+| Section | Contents |
+|---------|----------|
+| Document Control | Australian classification (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET / TOP SECRET) |
+| Revision History | Version, date, author, changes, approvals |
+| Activation Criteria | When to enter the NDB workflow vs treat as general incident |
+| Roles & Responsibilities | Accountable authority, privacy officer, incident commander, comms lead, OAIC liaison |
+| Phase 1 — Containment & Initial Triage | First 24 hours: contain, preserve evidence, initial scoping |
+| Phase 2 — Eligible-Data-Breach Assessment | 30-day clock; serious-harm test against OAIC guidance |
+| Phase 3 — Notification Decisions | Trigger criteria, escalation matrix, individuals vs OAIC vs both |
+| Phase 4 — Notification Execution | Templates, channels, timing, language requirements |
+| Phase 5 — Post-Incident Review | Lessons learned, remediation, public-register updates |
+| Decision Tree | Visual flow from detection through notification or no-notification |
+| Templates | Standard wording for individual notifications, OAIC report, board briefing |
+| External Dependencies | OAIC contact protocol, legal counsel, forensics partner |
+| Quarterly Review | Refresh cadence, regulatory-update tracking |
+
+---
+
+## Regulatory Anchors
+
+- **Privacy Act 1988 (Cth) Part IIIC** — Notifiable Data Breaches scheme (statutory basis)
+- **OAIC Notifiable Data Breach guidance** — authoritative interpretation of "eligible data breach" and "serious harm"
+- **Privacy and Other Legislation Amendment Act 2024** (Tranche 1) — enhanced statutory tort and class-action exposure
+- **Cyber Security Act 2024 (Cth)** — adjacent incident-reporting obligations that may run in parallel to NDB
+
+---
+
+## When to Run
+
+- Author this at service design, not in the middle of an incident
+- Refresh after every actual NDB event (lessons-learned)
+- Refresh on material OAIC guidance change or Privacy Act amendment
+- Refresh on accountable-authority or privacy-officer change
+
+---
+
+## Common Pitfalls
+
+- **Conflating the 30-day clock with the notification clock** — the 30-day clock is for the eligible-data-breach assessment. Once eligibility is confirmed, notification must be as soon as practicable. These are distinct.
+- **No pre-drafted notification text** — incident teams under pressure write poor notifications. Templates with placeholder fields cut time-to-notify significantly.
+- **Missing the OAIC liaison path** — the playbook must name a specific individual responsible for OAIC contact, with backup. "The privacy officer" is not specific enough.
+
+---
+
+## Handoff
+
+Tied tightly to `/arckit:au-pia` (PIA establishes the eligible-data-breach criteria) and the operational runbooks (`/arckit:operationalize`). Cited as evidence in `/arckit:au-disp-attestation` (DISP information protection domain) and `/arckit:au-pspf` (PSPF Outcome 4 incident management).

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/au-ot-security.md

@@ -0,0 +1,39 @@
+# AU OT Security
+
+`/arckit:au-ot-security` generates an ASD-aligned operational technology cyber security assessment for Australian Government, regulated-sector, and critical-infrastructure projects with connected OT, ICS, SCADA, building-management, field-device, or cyber-physical environments.
+
+Use it when OT security matters but you do not necessarily need SOCI/CIRMP coverage. The command complements `au-e8-posture` and `au-ism-controls`: E8 and ISM provide the AU cyber baseline, while this command records OT-specific architecture, connectivity, safety, availability, supplier access, monitoring, and recovery constraints.
+
+## Prerequisites
+
+| Artefact | Why it helps |
+|----------|--------------|
+| `/arckit:requirements` | Source for availability, safety, OT, remote-access, and supplier-access requirements |
+| `/arckit:stakeholders` | Identifies operational owner, safety owner, CISO, suppliers, and managed-service providers |
+| `/arckit:au-e8-posture` (`ARC-<id>-AUE8-v1.0.md`) | Enterprise cyber baseline |
+| `/arckit:au-ism-controls` (`ARC-<id>-AUISM-v1.0.md`) | Broader ASD control evidence for IT and OT systems |
+| `/arckit:risk` | Receives residual OT cyber and safety risks |
+
+## Usage
+
+```text
+/arckit:au-ot-security 001
+/arckit:au-ot-security "Water SCADA Platform"
+```
+
+Output: `projects/<id>/ARC-<id>-AUOT-v1.0.md`
+
+## What It Produces
+
+- OT environment context and safety/availability profile.
+- ASD OT guidance alignment.
+- Definitive OT architecture and asset-view assessment.
+- IT/OT segmentation and trust-boundary assessment.
+- Secure connectivity, remote access, and supplier access review.
+- Monitoring, logging, incident response, and recovery constraints.
+- AI-in-OT considerations where relevant.
+- Cross-reference back to AUE8, AUISM, RISK, and AUSOCI where applicable.
+
+## Notes
+
+This is a general Australian OT security command, not an energy-sector command. The later `au-energy` recipe should consume this artefact before adding AESCSF and energy-market obligations.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/au-pia.md

@@ -0,0 +1,72 @@
+# Australian Privacy Impact Assessment Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:au-pia` generates an Australian Privacy Impact Assessment under the Privacy Act 1988 (Cth) and the 13 Australian Privacy Principles. It captures the entity's APP entity status, scopes the personal information lifecycle, runs an APP-by-APP applicability and compliance analysis, registers privacy risks with mitigations, captures cross-border disclosure flows under APP 8, and surfaces the OAIC notification posture under the Notifiable Data Breaches scheme (Privacy Act Part IIIC).
+
+The PIA is a recognised due diligence artefact for Australian Federal entities and APP entities generally. The Privacy Act Tranche 1 reforms (December 2024) introduced new accountability, consent, and automated-decision-making obligations — the PIA explicitly addresses where these apply. Mark anything dependent on the Tranche 2 reforms as `<PENDING TRANCHE 2>` and revisit when the reforms enter force.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | Service description, decision logic, automated decision-making scope |
+| Data requirements (`ARC-<id>-DR-v1.0.md`) | Per-element personal information inventory and sensitivity flags |
+| Data model (`ARC-<id>-DMOD-v1.0.md`) | Entities and relationships carrying personal information |
+| Stakeholders (`ARC-<id>-STKE-v1.0.md`) | Subject populations, partner agencies, processors, offshore recipients |
+
+---
+
+## Command
+
+```bash
+/arckit:au-pia <project ID or service description>
+```
+
+Output: `projects/<id>/ARC-<id>-AUPIA-v1.0.md`
+
+---
+
+## Assessment Structure
+
+| Section | Contents |
+|---------|----------|
+| Document Control | Australian classification (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET / TOP SECRET) |
+| Revision History | Version, date, author, changes, approvals |
+| Executive Summary | APP entity status, headline privacy risks, OAIC notification posture, Tranche 1 obligations |
+| Programme / System Description | Description, owner, subject populations, lifecycle stage, personal information lifecycle |
+| APP Entity Status | Whether the entity is APP-covered, exemptions claimed, small business operator status |
+| APP-by-APP Analysis | All 13 APPs: applicability, current compliance posture, evidence, gaps |
+| Personal Information Inventory | Per-element: type, sensitivity flag, lawful basis, retention, recipients |
+| Cross-Border Disclosure (APP 8) | Offshore recipients, jurisdictions, enforceability assessment |
+| Automated Decision-Making (Tranche 1) | Where automated decisions affect individuals, notification posture, human-review pathway |
+| Privacy Risk Register | Risks, likelihood, impact, mitigations, residual risk |
+| NDB Posture | Eligible-data-breach assessment criteria, notification decision logic, OAIC reporting workflow |
+| Treatment & Monitoring | Mitigations in flight, review cadence, change triggers |
+
+---
+
+## Regulatory Anchors
+
+- **Privacy Act 1988 (Cth)** — primary statute; 13 APPs in Schedule 1
+- **Privacy and Other Legislation Amendment Act 2024** (Tranche 1 reforms) — children's privacy, statutory tort, automated decisions, transparency
+- **OAIC Notifiable Data Breaches scheme** (Privacy Act Part IIIC) — eligible-data-breach definition, notification timeframes
+- **OAIC Australian Privacy Principles guidelines** — authoritative interpretation
+- **APP 8** — cross-border disclosure accountability; *Australian Privacy Foundation v ALRC* and OAIC guidance
+
+---
+
+## When to Run
+
+- Whenever a new service collects, holds, uses, or discloses personal information
+- On material change to processing activities, recipients, or retention periods
+- Before launch of any service triggering Tranche 1 obligations (notably automated decisions affecting individuals)
+- Refresh annually or on material privacy-incident learnings
+
+---
+
+## Handoff
+
+Foundational input to `/arckit:au-ndb-playbook` (NDB playbook uses the personal information inventory and breach decision criteria), `/arckit:au-disp-attestation` (DISP information protection domain cites PIA evidence), and `/arckit:au-ai-assurance` (AI Assurance cross-references automated decision-making notification posture).