.md` partial, extend RENDERING.md routing, extend `plugin.json` userConfig to accept the regime governance framework value.
@@ -82,10 +82,10 @@ grep -L "classification scheme\|UK line in the header" arckit-claude/commands/-*.md | grep -v "\|{P}"
+grep -n "generate-document-id.sh" arckit-/commands/-*.md | grep -v "\|{P}"
```
-**Working precedent:** `arckit-claude/commands/ca-pia.md:32`:
+**Working precedent:** `arckit-ca/commands/ca-pia.md:32`:
> `scripts/bash/generate-document-id.sh PIA --filename`
**Note:** `uae-*` commands share this bug. Worth fixing in the same sweep.
@@ -161,7 +161,7 @@ For each new `xx-*` command file:
```python
import yaml, glob, pathlib
cmds = {pathlib.Path(p).stem for p in glob.glob('arckit-claude/commands/*.md')}
- for f in glob.glob('arckit-claude/commands/-*.md'):
+ for f in glob.glob('arckit-/commands/-*.md'):
fm = yaml.safe_load(open(f).read().split('---')[1])
for h in (fm or {}).get('handoffs', []):
if h['command'] not in cmds: print(f, '→', h['command'])
@@ -175,7 +175,7 @@ For each new `xx-*` command file:
For non-UK overlays, grep for unintended UK terminology:
```bash
-grep -rE '\b(NCSC|ICO|Cyber Essentials|GovS|UK GDPR|GDS|Cabinet Office|DPA 2018|DPIA)\b' arckit-claude/commands/-*.md arckit-claude/templates/-*.md
+grep -rE '\b(NCSC|ICO|Cyber Essentials|GovS|UK GDPR|GDS|Cabinet Office|DPA 2018|DPIA)\b' arckit-/commands/-*.md arckit-claude/templates/-*.md
```
A small number of intentional comparison references is fine (PR #441 had 2 in `au-dss.md` + `au-pia.md`) — author should call them out in the PR body. Anything else is leakage.
@@ -199,10 +199,10 @@ for f in arckit-claude/templates/*-template.md; do
done | grep -E "-"
# B2: missing classification override
-grep -L "classification scheme\|UK line in the header" arckit-claude/commands/-*.md
+grep -L "classification scheme\|UK line in the header" arckit-/commands/-*.md
# B3: generate-document-id.sh mis-invocation
-grep -n "generate-document-id.sh [A-Z]\+ --filename" arckit-claude/commands/-*.md
+grep -n "generate-document-id.sh [A-Z]\+ --filename" arckit-/commands/-*.md
# B4: converter drift
python scripts/converter.py && git status --porcelain | grep -v "memory/"
diff --git a/.github/workflows/lint-markdown.yml b/.github/workflows/lint-markdown.yml
index 8b0ea4b2..d6c440d0 100644
--- a/.github/workflows/lint-markdown.yml
+++ b/.github/workflows/lint-markdown.yml
@@ -8,6 +8,11 @@ on:
- ".markdownlint-cli2.jsonc"
- ".github/workflows/lint-markdown.yml"
- "scripts/check_references.py"
+ - "scripts/check_recipes.py"
+ - "scripts/check_doctype_collisions.py"
+ - "arckit-*/recipes/**"
+ - "arckit-claude/skills/arckit-build/recipes/**"
+ - "arckit-claude/config/doc-types.mjs"
- "arckit-claude/.claude-plugin/plugin.json"
pull_request:
paths:
@@ -15,6 +20,11 @@ on:
- ".markdownlint-cli2.jsonc"
- ".github/workflows/lint-markdown.yml"
- "scripts/check_references.py"
+ - "scripts/check_recipes.py"
+ - "scripts/check_doctype_collisions.py"
+ - "arckit-*/recipes/**"
+ - "arckit-claude/skills/arckit-build/recipes/**"
+ - "arckit-claude/config/doc-types.mjs"
- "arckit-claude/.claude-plugin/plugin.json"
jobs:
@@ -37,6 +47,12 @@ jobs:
- name: Cross-reference linter
run: python3 scripts/check_references.py
+ - name: Recipe sanity linter
+ run: python3 scripts/check_recipes.py
+
+ - name: Doc-type collision check
+ run: python3 scripts/check_doctype_collisions.py
+
- uses: actions/setup-node@v4
with:
node-version: "20"
diff --git a/CHANGELOG.md b/CHANGELOG.md
index d7486b1b..fa4b25d5 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -7,6 +7,40 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
## [Unreleased]
+## [5.0.0] - 2026-XX-XX
+
+### BREAKING
+
+- **Community overlays moved to separate plugins**. The monolithic `arckit` plugin shipped 117 commands (71 core + 46 community). v5.0.0 splits community commands into six per-jurisdiction marketplace plugins: `arckit-uae` (12 commands + 2 recipes), `arckit-fr` (12), `arckit-ca` (12 + 1 recipe), `arckit-eu` (7), `arckit-at` (3), and `arckit-au` (8 + 1 recipe — new in v5.0.0). Users now install only the jurisdictions they need. Total surface: 125 commands across 7 plugins.
+ - **Migration:** after upgrading, install the community plugins you previously used. A one-shot SessionStart banner reads `.arckit/manifest.json` and prints the exact `claude plugin install ...` command for your project. Acknowledge with `touch .arckit/v5-migration-acked`.
+ - **Token savings:** UK-only users save ~5K tokens per SessionStart system reminder (estimate — to be replaced with measured figures in Task 16).
+ - **No functional change** for users who install all 6 plugins — the full 117-command surface is intact, just spread across plugins.
+
+### Added
+
+- `scripts/check_recipes.py` — CI gate validating every recipe's structure and dep references.
+- `scripts/check_doctype_collisions.py` — CI gate asserting every doc-type code in `arckit-claude/config/doc-types.mjs` is unique.
+- `scripts/tag-plugins.sh` — creates native `--vX.Y.Z` tags per release (idempotent).
+- `arckit-claude/hooks/v5-migration-banner.mjs` — one-shot SessionStart hook suggesting per-jurisdiction installs based on prior project artefacts.
+- 6 new plugin directories: `arckit-uae/`, `arckit-fr/`, `arckit-ca/`, `arckit-eu/`, `arckit-at/`, `arckit-au/`, each with their own `plugin.json`, `README.md`, `VERSION`, `commands/`, `templates/`, and (where applicable) `recipes/`.
+- **`arckit-au`** Australian Federal / DISP-supplier overlay — 8 commands (`au-e8-posture`, `au-pia`, `au-dss`, `au-ism-controls`, `au-ndb-playbook`, `au-pspf`, `au-ai-assurance`, `au-disp-attestation`), 8 templates, and the `au-federal` recipe (35 targets, 9 waves). 8 new doc-type codes registered in `arckit-claude/config/doc-types.mjs` (`AUE8`, `AUISM`, `AUPIA`, `AUNDB`, `AUDSS`, `AUPSPF`, `AUAIA`, `AUDISP`). Adds `AU` regime; also adds `CA` retroactively (CA shipped doc-types in v4.15.0 but was missing from `REGIMES`). Domain co-maintainer: @royster70. Supersedes #441.
+
+### Changed
+
+- `arckit-build` skill: new three-tier recipe lookup precedence — project override → core plugin → sibling community plugins via glob.
+- `scripts/converter.py` walks all 6 plugin source dirs and merges into one extension output per non-Claude format. Non-Claude extensions stay monolithic per the v5 design.
+- `scripts/bump-version.sh` updates 6 plugin manifests + `marketplace.json` (all `.plugins[]` entries) instead of just one.
+- `docs/RELEASING.md` updated with multi-plugin release flow.
+- `CONTRIBUTING.md` adds a two-part PR rule for new doc-types (command in community plugin, doc-type registration in core).
+
+### Note on doc-types
+
+All doc-type codes remain in `arckit-claude/config/doc-types.mjs` — community plugins ship commands and recipes only. This keeps `validate-arc-filename.mjs` single-sourced.
+
+### Note on plugin dependencies (Claude Code v2.1.110+)
+
+All 6 community plugins (`arckit-uae`, `arckit-fr`, `arckit-ca`, `arckit-eu`, `arckit-at`, `arckit-au`) declare an exact (`=`) dependency on the `arckit` core plugin. Installing any community plugin auto-installs core; uninstalling with `--prune` cleans it up. The exact pin keeps the 6 plugins shipping as a coherent set — `scripts/bump-version.sh` updates `.version` and `.dependencies[arckit].version` in lockstep on every release.
+
## [4.22.0] - 2026-05-17
### Added
diff --git a/CLAUDE.md b/CLAUDE.md
index 3a93a1e0..43b812d5 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -9,7 +9,7 @@ ArcKit is an **Enterprise Architecture Governance & Vendor Procurement Toolkit**
**Six distribution formats** exist side-by-side in this repo:
1. **CLI package** (`src/arckit_cli/`) — Python CLI installed via `pip`/`uv`, runs `arckit init` to scaffold projects for Codex CLI or OpenCode CLI
-2. **Claude Code plugin** (`arckit-claude/`) — installed via marketplace (`/plugin marketplace add tractorjuice/arc-kit`)
+2. **Claude Code plugins** (`arckit-claude/`, `arckit-uae/`, `arckit-fr/`, `arckit-ca/`, `arckit-eu/`, `arckit-at/`, `arckit-au/`) — installed via marketplace (`/plugin marketplace add tractorjuice/arc-kit`). Core `arckit` ships 71 commands + all hooks/MCP/doc-types config. Six community overlays ship per-jurisdiction commands and recipes. Install only what you need; community plugins require the `arckit` core plugin.
3. **Gemini CLI extension** (`arckit-gemini/`) — published as `tractorjuice/arckit-gemini`, installed via `gemini extensions install`
4. **OpenCode CLI extension** (`arckit-opencode/`) — scaffolded via `arckit init --ai opencode`
5. **Codex CLI extension** (`arckit-codex/`) — published as `tractorjuice/arckit-codex`
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 6a5dcd73..94644d58 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -223,6 +223,19 @@ All contributions must align with:
- **GDS Service Standard**: 14 points for government services
- **Digital Marketplace**: DOS and G-Cloud procurement frameworks
+## Adding a new doc-type code (v5.0.0+)
+
+Doc-type codes live in `arckit-claude/config/doc-types.mjs` regardless of which plugin the emitting command lives in. This keeps `validate-arc-filename.mjs` single-sourced and the collision check in one file.
+
+A new community command that emits a new doc type therefore requires a **two-part PR**:
+
+1. The command in `arckit-{jurisdiction}/commands/{slug}.md` (e.g. `arckit-uae/commands/uae-newthing.md`).
+2. The new code in `arckit-claude/config/doc-types.mjs` with `regime: 'UAE'` (or `FR`, `CA`, `EU`, `AT`).
+
+Reviewers check that the new code doesn't collide with existing codes — `scripts/check_doctype_collisions.py` catches duplicates automatically in CI.
+
+If the new code is the **first** of its regime, also register the regime in the `REGIMES` array and `REGIME_LABELS` object at the bottom of `doc-types.mjs`. Order convention: officially-maintained first, then community alphabetical.
+
## Command Naming Conventions
- Use lowercase with hyphens: `/arckit.data-model`
diff --git a/README.md b/README.md
index d1cc4569..44e6ab12 100644
--- a/README.md
+++ b/README.md
@@ -63,7 +63,20 @@ Then in Claude Code:
/plugin marketplace add tractorjuice/arc-kit
```
-Then install from the Discover tab.
+Then install from the Discover tab. As of v5.0.0 the marketplace ships **6 plugins** — install only the jurisdictions you need:
+
+```bash
+# Core (71 commands — UK Government civilian + generic enterprise)
+claude plugin install arckit
+
+# UK + UAE federal
+claude plugin install arckit arckit-uae
+
+# Everything (125 commands across UK + UAE + FR + CA + EU + AT + AU)
+claude plugin install arckit arckit-{uae,fr,ca,eu,at,au}
+```
+
+All 7 plugins come from the same `tractorjuice/arc-kit` marketplace. Community plugins (`arckit-uae`, `arckit-fr`, `arckit-ca`, `arckit-eu`, `arckit-at`, `arckit-au`) require the `arckit` core plugin.
> **Tip: lighter marketplace clone.** The command above clones the full arc-kit monorepo (~100 MB) because it hosts five other AI-assistant distributions, 147 vendored Wardley maps, and research docs you don't need. To fetch just the plugin's directories, add the marketplace via the CLI with `--sparse`:
>
@@ -71,7 +84,7 @@ Then install from the Discover tab.
> claude plugin marketplace add tractorjuice/arc-kit --sparse .claude-plugin arckit-claude
> ```
>
-> This uses `git sparse-checkout` to limit the clone to `.claude-plugin/` (the marketplace catalog) and `arckit-claude/` (the plugin itself). Works with Claude Code's documented marketplace sparse flag. Claude Code is the **primary development platform** for ArcKit and provides the most complete experience: all 70 official commands (plus 46 community-contributed), 10 autonomous research agents, 5 automation hooks (session init, project context injection, filename enforcement, output validation, impact scan), bundled MCP servers (AWS Knowledge, Microsoft Learn, Google Developer Knowledge, govreposcrape), and automatic updates via the marketplace. See [Why Claude Code?](#why-claude-code) below.
+> This uses `git sparse-checkout` to limit the clone to `.claude-plugin/` (the marketplace catalog) and `arckit-claude/` (the plugin itself). Works with Claude Code's documented marketplace sparse flag. Claude Code is the **primary development platform** for ArcKit and provides the most complete experience: all 71 official commands (plus 54 community-contributed), 10 autonomous research agents, 5 automation hooks (session init, project context injection, filename enforcement, output validation, impact scan), bundled MCP servers (AWS Knowledge, Microsoft Learn, Google Developer Knowledge, govreposcrape), and automatic updates via the marketplace. See [Why Claude Code?](#why-claude-code) below.
> **Why v2.1.139?** Claude Code v2.1.139 added the hook `args: string[]` exec form — ArcKit's 16 registered hooks now use this form so the harness execs `node ` directly instead of parsing a shell-quoted command string. This eliminates a whole class of quoting / metacharacter bugs in the `${CLAUDE_PLUGIN_ROOT}`-substituted paths. The same release also fixed subagents not discovering project / user / plugin skills (affects ArcKit's 13 agents) and made `/mcp` reconnect pick up `.mcp.json` edits without a restart. Builds on v2.1.136 (fix: env vars from SessionStart hooks going stale — relevant to the `inject-arckit-context` pattern; fix: MCP servers from `.mcp.json` disappearing after `/clear`), v2.1.133 (subagent skill discovery fix, hooks receive `effort.level`), and v2.1.129 (plugin manifest's `monitors`/`themes` moved under a top-level `experimental` block — ArcKit's `stale-artifact-scan` background monitor which warns when `projects/` artefacts are past their `Next Review Date` or stuck in `DRAFT` for 14+ days is declared via that key and will not load on older clients; `ENABLE_PROMPT_CACHING_1H` regression fix). Carries forward the v2.1.121 unlocks: MCP `alwaysLoad` eager-loads AWS Knowledge and Microsoft Learn tools at session start (skips a discovery round-trip on `/arckit:aws-research` and `/arckit:azure-research`), and PostToolUse `hookSpecificOutput.updatedToolOutput` so provenance-stamp and manifest hooks surface their effects to the model in-band; the v2.1.118–119 release-flow unlocks: `claude plugin tag --dry-run` validates plugin/marketplace version agreement, and the session-telemetry hook records `duration_ms` on every tool call; the v2.1.117 unlocks: Opus 4.7 `/context` correctly sized to 1M instead of 200K (long research sessions no longer autocompact early) and agent frontmatter `mcpServers` loading for `--agent` sessions; the v2.1.111+ unlocks: Opus 4.7 `xhigh` effort tier, Auto mode without `--enable-auto-mode`, read-only bash glob patterns without permission prompts; and the v2.1.97 fixes: `claude plugin update` correctly detects new commits for git-based plugins (critical for ArcKit distribution), MCP HTTP/SSE memory leak fix (~50 MB/hr, affects ArcKit's 5 bundled servers), proper 429 exponential backoff (benefits 10 research agents), Stop/SubagentStop hooks no longer fail on long sessions (affects session-learner), and subagent working directory leak fix.
@@ -1120,7 +1133,7 @@ Claude Code is the **primary development platform** for ArcKit and provides capa
| Feature | Claude Code | Gemini CLI | Copilot | Codex / OpenCode |
|---------|:-----------:|:----------:|:-------:|:----------------:|
-| 70 cross-AI slash commands (plus 46 community-contributed) | ✅ | ✅ | ✅ | ✅ |
+| 71 cross-AI slash commands (plus 54 community-contributed) | ✅ | ✅ | ✅ | ✅ |
| `/arckit:build` parallel build harness (Claude-only — depends on parallel `Agent` dispatch) | ✅ | — | — | — |
| Templates & scripts | ✅ | ✅ | ✅ | ✅ |
| Bundled MCP servers (AWS, Azure, GCP, DataCommons, govreposcrape) | ✅ | ✅ (3 servers) | — | Manual setup |
diff --git a/arckit-at/.claude-plugin/plugin.json b/arckit-at/.claude-plugin/plugin.json
new file mode 100644
index 00000000..e40d9271
--- /dev/null
+++ b/arckit-at/.claude-plugin/plugin.json
@@ -0,0 +1,25 @@
+{
+ "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
+ "name": "arckit-at",
+ "version": "5.0.0-alpha.9",
+ "description": "Austrian Overlay for ArcKit — 3 commands for DSG/DSGVO, NISG, and Bundesvergabegesetz public procurement. Requires arckit core plugin.",
+ "author": {
+ "name": "TractorJuice",
+ "url": "https://github.com/tractorjuice"
+ },
+ "homepage": "https://arckit.org",
+ "repository": "https://github.com/tractorjuice/arc-kit",
+ "license": "MIT",
+ "keywords": [
+ "architecture",
+ "governance",
+ "austria",
+ "compliance"
+ ],
+ "dependencies": [
+ {
+ "name": "arckit",
+ "version": "=5.0.0-alpha.8"
+ }
+ ]
+}
diff --git a/arckit-at/README.md b/arckit-at/README.md
new file mode 100644
index 00000000..a2473f92
--- /dev/null
+++ b/arckit-at/README.md
@@ -0,0 +1,22 @@
+# ArcKit — Austrian Overlay
+
+3 slash commands covering Austrian regulatory compliance:
+
+- `/arckit:at-bvergg` — Austrian public procurement (Bundesvergabegesetz 2018, ANKÖ, BVwG)
+- `/arckit:at-dsgvo` — Austrian DSG / DSGVO obligations (Datenschutzbehörde, §§12–13 DSG)
+- `/arckit:at-nisg` — Austrian NISG obligations (BGBl. I Nr. 94/2025, BKA/BMI reporting)
+
+Recipes: No recipes ship in this overlay yet.
+
+## Requires arckit core plugin
+
+```bash
+claude plugin install arckit@arc-kit
+claude plugin install arckit-at@arc-kit
+```
+
+Without `arckit` (core), recipes won't resolve their foundation commands (`arckit:principles`, `arckit:requirements`, etc.) and `validate-arc-filename` won't recognise AT doc-type codes.
+
+## Maintainer
+
+Currently maintained by @tractorjuice. Recruiting an Austrian domain co-maintainer — see [CONTRIBUTING.md](https://github.com/tractorjuice/arc-kit/blob/main/CONTRIBUTING.md).
diff --git a/arckit-at/VERSION b/arckit-at/VERSION
new file mode 100644
index 00000000..d012d7bc
--- /dev/null
+++ b/arckit-at/VERSION
@@ -0,0 +1 @@
+5.0.0-alpha.9
diff --git a/arckit-claude/commands/at-bvergg.md b/arckit-at/commands/at-bvergg.md
similarity index 100%
rename from arckit-claude/commands/at-bvergg.md
rename to arckit-at/commands/at-bvergg.md
diff --git a/arckit-claude/commands/at-dsgvo.md b/arckit-at/commands/at-dsgvo.md
similarity index 100%
rename from arckit-claude/commands/at-dsgvo.md
rename to arckit-at/commands/at-dsgvo.md
diff --git a/arckit-claude/commands/at-nisg.md b/arckit-at/commands/at-nisg.md
similarity index 100%
rename from arckit-claude/commands/at-nisg.md
rename to arckit-at/commands/at-nisg.md
diff --git a/arckit-claude/templates/at-bvergg-template.md b/arckit-at/templates/at-bvergg-template.md
similarity index 100%
rename from arckit-claude/templates/at-bvergg-template.md
rename to arckit-at/templates/at-bvergg-template.md
diff --git a/arckit-claude/templates/at-dsgvo-template.md b/arckit-at/templates/at-dsgvo-template.md
similarity index 100%
rename from arckit-claude/templates/at-dsgvo-template.md
rename to arckit-at/templates/at-dsgvo-template.md
diff --git a/arckit-claude/templates/at-nisg-template.md b/arckit-at/templates/at-nisg-template.md
similarity index 100%
rename from arckit-claude/templates/at-nisg-template.md
rename to arckit-at/templates/at-nisg-template.md
diff --git a/arckit-au/.claude-plugin/plugin.json b/arckit-au/.claude-plugin/plugin.json
new file mode 100644
index 00000000..ccf7e244
--- /dev/null
+++ b/arckit-au/.claude-plugin/plugin.json
@@ -0,0 +1,26 @@
+{
+ "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
+ "name": "arckit-au",
+ "version": "5.0.0-alpha.9",
+ "description": "Australian Federal Overlay for ArcKit — 8 commands for ASD Essential Eight, ISM, DTA Digital Service Standard, Privacy Act 1988 PIA, OAIC Notifiable Data Breach, PSPF, DTA AI Assurance, and DISP supplier attestation. Recipe: au-federal. Requires arckit core plugin.",
+ "author": {
+ "name": "TractorJuice",
+ "url": "https://github.com/tractorjuice"
+ },
+ "homepage": "https://arckit.org",
+ "repository": "https://github.com/tractorjuice/arc-kit",
+ "license": "MIT",
+ "keywords": [
+ "architecture",
+ "governance",
+ "australia",
+ "compliance",
+ "disp"
+ ],
+ "dependencies": [
+ {
+ "name": "arckit",
+ "version": "=5.0.0-alpha.8"
+ }
+ ]
+}
diff --git a/arckit-au/CHANGELOG.md b/arckit-au/CHANGELOG.md
new file mode 100644
index 00000000..f3f16cab
--- /dev/null
+++ b/arckit-au/CHANGELOG.md
@@ -0,0 +1,33 @@
+# Changelog — arckit-au
+
+All notable changes to the `arckit-au` plugin will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+## [5.0.0] - 2026-XX-XX
+
+### Added
+
+Initial release of `arckit-au` — Australian Federal Government / DISP-supplier compliance overlay. Supersedes PR #441 (au-federal-recipe by @royster70) by restructuring the same content into the v5.0.0 per-jurisdiction layout.
+
+**8 community-overlay commands** (validated end-to-end against a real Australian SMB engagement; DISP-track, OFFICIAL:Sensitive):
+
+- `au-e8-posture` — ASD Essential Eight ML0–ML3 maturity assessment
+- `au-pia` — Privacy Act 1988 s33D Privacy Impact Assessment (13 APPs)
+- `au-dss` — DTA Digital Service Standard (13 criteria)
+- `au-ism-controls` — ASD ISM Statement of Applicability (17 control domains)
+- `au-ndb-playbook` — OAIC Notifiable Data Breach response playbook
+- `au-pspf` — Protective Security Policy Framework (4 outcomes / 16 core requirements)
+- `au-ai-assurance` — DTA AI Assurance Framework + Responsible AI Policy v2.0 baseline
+- `au-disp-attestation` — DISP Member self-attestation pack (consolidates E8 + ISM + PIA + NDB + PSPF)
+
+**Recipe:** `au-federal` (35 targets across 9 build waves).
+
+**8 doc-type codes** registered in `arckit-claude/config/doc-types.mjs` (per the v5.0.0 spec, doc-types stay in core): `AUE8`, `AUISM`, `AUPIA`, `AUNDB`, `AUDSS`, `AUPSPF`, `AUAIA`, `AUDISP`. Regime `AU` added to `REGIMES` and `REGIME_LABELS`.
+
+**Validation evidence** preserved from PR #441: 25/25 evaluation scorecard pass, 220 AU framework references in validation artefacts, 0 UK framework leakage. See `docs/au-federal-validation-scorecard.md`.
+
+**Domain co-maintainer:** @royster70.
diff --git a/arckit-au/README.md b/arckit-au/README.md
new file mode 100644
index 00000000..ca78bd99
--- /dev/null
+++ b/arckit-au/README.md
@@ -0,0 +1,34 @@
+# ArcKit — Australian Federal Overlay
+
+8 slash commands and the `au-federal` build recipe covering Australian Federal Government and DISP-supplier compliance:
+
+- `/arckit:au-e8-posture` — ASD Essential Eight ML0–ML3 maturity assessment (8 mitigation strategies)
+- `/arckit:au-pia` — Privacy Act 1988 s33D Privacy Impact Assessment (13 APPs)
+- `/arckit:au-dss` — DTA Digital Service Standard (13 criteria) compliance assessment
+- `/arckit:au-ism-controls` — ASD Information Security Manual Statement of Applicability (17 control domains)
+- `/arckit:au-ndb-playbook` — OAIC Notifiable Data Breach response playbook (Privacy Act 1988 Part IIIC)
+- `/arckit:au-pspf` — Protective Security Policy Framework (4 outcomes / 16 core requirements)
+- `/arckit:au-ai-assurance` — DTA AI Assurance Framework + Responsible AI Policy v2.0 baseline
+- `/arckit:au-disp-attestation` — DISP Member self-attestation pack (consolidates E8, ISM, PIA, NDB, PSPF)
+
+Recipe: `au-federal` (35 targets across 9 build waves).
+
+## Requires arckit core plugin
+
+```bash
+claude plugin install arckit arckit-au
+```
+
+Without `arckit` (core), recipes won't resolve their foundation commands (`arckit:principles`, `arckit:requirements`, etc.) and `validate-arc-filename` won't recognise AU doc-type codes (`AUE8`, `AUISM`, `AUPIA`, `AUNDB`, `AUDSS`, `AUPSPF`, `AUAIA`, `AUDISP`).
+
+## Validation
+
+End-to-end validated against a real Australian SMB engagement (DISP-track, OFFICIAL:Sensitive). 25/25 evaluation scorecard pass at Run 3, 0 UK framework leakage, 220 AU framework references. See [`docs/au-federal-validation-scorecard.md`](https://github.com/tractorjuice/arc-kit/blob/main/docs/au-federal-validation-scorecard.md).
+
+## Regulatory anchors
+
+ASD Essential Eight Maturity Model · ASD Information Security Manual · DTA Digital Service Standard · Privacy Act 1988 (Cth) including Tranche 1 reforms (Dec 2024) · Defence Industry Security Program (DISP) · Protective Security Policy Framework · Commonwealth Procurement Rules (November 2025 overhaul) · DTA AI Assurance Framework + Responsible AI Policy v2.0 · PGPA Act 2013 s16 · IRAP.
+
+## Maintainer
+
+Domain co-maintainer: @royster70. Originally contributed via PR #441 (au-federal-recipe).
diff --git a/arckit-au/VERSION b/arckit-au/VERSION
new file mode 100644
index 00000000..d012d7bc
--- /dev/null
+++ b/arckit-au/VERSION
@@ -0,0 +1 @@
+5.0.0-alpha.9
diff --git a/arckit-au/commands/au-ai-assurance.md b/arckit-au/commands/au-ai-assurance.md
new file mode 100644
index 00000000..b2a9199b
--- /dev/null
+++ b/arckit-au/commands/au-ai-assurance.md
@@ -0,0 +1,127 @@
+---
+description: "[COMMUNITY] Generate an AI assurance assessment for Australian Government / regulated-sector AI systems covering DTA AI Policy v2.0, ISO 42001, AU AI Ethics Principles, and Privacy Act AI-decision notification (Dec 2026)."
+argument-hint: ""
+effort: high
+handoffs:
+ - command: au-pia
+ description: AI fairness + automated decision-making findings feed APP 6 + APP 11 in the PIA.
+ - command: au-dss
+ description: AI assurance feeds DSS Criterion 7 (privacy) + Criterion 5 (security of training/inference data).
+ - command: au-ism-controls
+ description: AI training / inference data security cites ISM Domain 9 (System Hardening) + Domain 12 (Cryptography).
+ - command: risk
+ description: AI-specific risks (bias, drift, prompt injection, training-data exposure) feed the project risk register.
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified AI ethics specialist, Privacy Officer, or DTA-aligned AI assurance assessor before reliance. DTA AI Policy v2.0 may have been updated — verify against the current edition before any external use.
+
+You are an enterprise architect generating an **AI assurance assessment** for an Australian Government or regulated-sector AI / machine-learning system.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+Australia's AI assurance landscape combines several frameworks that together govern AI deployment in government and regulated industry:
+
+- **DTA Responsible AI Policy v2.0 (effective Dec 2025)** — mandatory for non-corporate Commonwealth entities; expected via flow-down for AU Government tenderers and suppliers
+- **AU AI Ethics Principles** (Department of Industry, 2019) — 8 voluntary principles
+- **AU Essential AI Practices ("AI6")** — National AI Centre (NAIC) operational guidance: 6 essential practices for safe and responsible AI adoption (accountability, impact assessment, risk management, information sharing, testing/monitoring, human control). Foundations + Implementation Guidance issued via ai.gov.au.
+- **ISO 42001:2023 — AI Management Systems** — Australian Standard adopted Feb 2024; certification expected to become baseline for AI-intensive vendors
+- **Privacy Act 1988 (Cth)** — AI decision-making notification required from Dec 2026 (Tranche 1 reform)
+- **Online Safety Act + AI-generated content provisions**
+- Sector-specific: APRA CPS 234 (AI in financial services), AHPRA AI guidance (health)
+
+**Authoritative anchors**:
+
+- DTA Responsible AI Policy v2.0 —
+- AU AI Ethics Principles —
+- AU Essential AI Practices (AI6) — Guidance for AI Adoption: Foundations —
+- AU Essential AI Practices — Implementation Guidance —
+- Privacy Act 1988 (Cth) —
+
+## Process
+
+1. Read prerequisites:
+ - Project's PIA artefact (`ARC-{P}-AUPIA-v*`) — APP 6 + APP 11 cross-reference
+ - Project's DATA artefact — for training/inference data classification
+ - Project's REQ artefact — extract AI-specific requirements
+ - Project's RISK artefact — existing AI risks
+ - `${CLAUDE_PLUGIN_ROOT}/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-ai-assurance-template.md`
+ - Then: `.arckit/templates/au-ai-assurance-template.md`
+ - Fallback: `${CLAUDE_PLUGIN_ROOT}/templates/au-ai-assurance-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUAIA --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **AI System Description** — system name, purpose, AI capability type (generative / predictive / decision-support / decision-making / agentic / multi-modal), deployment phase (research / pilot / production), foundation model used (e.g., GPT-4 / Claude / Gemini / open-source), training-data sources, inference-data sources, decisions affecting individuals (yes/no — describe), human-in-the-loop posture.
+
+ - **DTA Responsible AI Policy v2.0 Compliance** — assessment against the policy's six accountabilities:
+ 1. **Accountability** — designated AI accountable officer
+ 2. **Transparency** — public AI use disclosure
+ 3. **Risk-based approach** — AI risk assessment performed
+ 4. **Quality data + design integrity** — data lineage, model documentation
+ 5. **Privacy + security** — cross-reference PIA + ISM + E8
+ 6. **Human oversight + redress** — human review mechanism, individual appeal pathway
+
+ - **AU AI Ethics Principles Alignment** — assess against the 8 principles:
+ 1. Human, societal and environmental wellbeing
+ 2. Human-centred values
+ 3. Fairness
+ 4. Privacy protection and security
+ 5. Reliability and safety
+ 6. Transparency and explainability
+ 7. Contestability
+ 8. Accountability
+
+ For each principle: status (Aligned / Partial / Not Aligned), evidence, gap, mitigation.
+
+ - **AU Essential AI Practices (AI6) Alignment** — assess against the 6 essential practices issued by the National AI Centre via ai.gov.au:
+ 1. Decide who is accountable
+ 2. Understand impacts and plan accordingly
+ 3. Measure and manage risks
+ 4. Share essential information
+ 5. Test and monitor
+ 6. Maintain human control
+
+ For each practice: status (Implemented / Partial / Not Implemented / Not Applicable), evidence (artefact references where possible), gap, action. Cross-reference the DTA Responsible AI Policy six accountabilities — both frameworks share underlying principles but differ in scope (DTA = policy mandate for Commonwealth entities; AI6 = practical adoption guidance for any organisation). The AI6 *Implementation Guidance* on ai.gov.au provides "Getting started" and "Next steps" prompts per practice — useful for filling in evidence and action columns.
+
+ - **ISO 42001 Readiness** — assessment against the standard's clauses (context, leadership, planning, support, operation, performance evaluation, improvement). Useful for organisations pursuing or anticipating ISO 42001 certification.
+
+ - **Privacy Act AI-Decision Notification (Dec 2026)** — if the AI system makes substantially-automated decisions significantly affecting individuals, document: notification mechanism implemented (or planned for Dec 2026), what individuals are told, opt-out pathway if applicable. Cross-reference AUPIA APP 6 + APP 11.
+
+ - **Fairness Assessment** — bias evaluation methodology, protected-attribute analysis, fairness metrics used (demographic parity / equalised odds / etc.), test results across population segments, residual fairness risks.
+
+ - **Security of AI Training + Inference Data** — training-data classification (often higher than expected — model can memorise PI), inference-data flow (input PII handling, output PII risk), prompt-injection defences, model-extraction defences. Cross-reference E8 posture + ISM applicability.
+
+ - **Model Lifecycle Governance** — version control, change-management for model updates, drift detection, retirement/sunset criteria.
+
+ - **Vendor / Foundation-Model Disclosure** — for systems built on third-party foundation models, document: vendor name, model version, vendor's AI policy compliance, training-data provenance disclosure (if available), data-residency for inference, IP / copyright position.
+
+ - **Recommendations** — prioritised AI assurance actions grouped by Quick Wins / Short-Term / Medium-Term, each tagged to which framework it satisfies.
+
+7. Populate the External References section per `${CLAUDE_PLUGIN_ROOT}/references/citation-instructions.md`. DTA AI Policy v2.0, AU AI Ethics Principles, AU Essential AI Practices (AI6) — Foundations + Implementation Guidance, ISO 42001 (Australian Standard), and Privacy Act 1988 MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the DTA + Ethics Principles compliance summary table).
+
+## Important Notes
+
+- DTA AI Policy v2.0 applies to **non-corporate Commonwealth entities** directly. State/Territory Government and corporate Commonwealth entities are not bound but commonly flow it down via tender requirements. Suppliers to those entities should track for contractual flow-down.
+- The **December 2026 Privacy Act AI-decision notification** is a deadline. Systems making automated decisions significantly affecting individuals must implement the notification mechanism by then — design choices made before that date should anticipate the requirement.
+- Foundation-model use is a supply-chain concern. Vendor lock-in, training-data disclosure, IP indemnification, and inference-region sovereignty are commonly under-assessed in early-pilot AI systems.
+- Bias / fairness assessment is methodology-dependent. Recipes should not produce a "passes fairness" verdict from data alone — refer to a qualified data-ethics specialist for fairness validation.
+- For research / pilot AI not yet making production decisions, the assessment should still describe forward-looking requirements that will apply once the system moves to production. This avoids "we'll add it later" technical debt.
+- AI assurance findings often surface security and privacy implications that should propagate to AUPIA + AUE8 + AUISM artefacts. Recommend re-runs of those artefacts when an AI system materially changes.
diff --git a/arckit-au/commands/au-disp-attestation.md b/arckit-au/commands/au-disp-attestation.md
new file mode 100644
index 00000000..ed7d65ff
--- /dev/null
+++ b/arckit-au/commands/au-disp-attestation.md
@@ -0,0 +1,112 @@
+---
+description: "[COMMUNITY] Generate a DISP (Defence Industry Security Program) Member self-attestation pack covering E8 ML2, ISM applicability, governance, personnel security, and incident reporting — supports DISP Levels 1, 2, 3."
+argument-hint: ""
+effort: high
+handoffs:
+ - command: au-e8-posture
+ description: E8 ML2 evidence per strategy is a primary input to the DISP attestation pack.
+ - command: au-ism-controls
+ description: ISM applicability statement is a primary input — controls beyond E8 mandated by DISP level.
+ - command: au-pia
+ description: Privacy Act + APP 11 alignment cited in attestation pack.
+ - command: au-ndb-playbook
+ description: Notifiable Data Breach response is the operational complement to DISP incident reporting.
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified DISP-experienced security officer or DISP advisor before submission to Defence. DISP requirements may be updated — verify against the current DISP Membership Pack before any external use.
+
+You are an enterprise architect generating a **DISP (Defence Industry Security Program) Member self-attestation pack** for an Australian organisation supplying products or services to Defence.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Defence Industry Security Program (DISP) is the security accreditation framework for Australian organisations supplying Defence. DISP Membership has three levels (Levels 1, 2, 3 — formerly Entry, Level 1, Level 2 in earlier guidance) with progressively-deeper governance, personnel, ICT, physical, and supply-chain security obligations. Essential Eight ML2 has been the minimum cyber baseline for DISP members since 2025; ISM applicability scales with the level. The attestation pack is the supplier's self-evidence document referenced during DISP application, audit, and renewal.
+
+**Authoritative anchor**: Defence Industry Security Program —
+
+**Key references**:
+
+- DISP Membership Pack (current edition) — application form + evidence requirements
+- ASD Essential Eight Maturity Model (ML2 minimum for DISP) —
+- ASD Information Security Manual —
+- Protective Security Policy Framework (PSPF)
+- Defence Security Principles Framework (DSPF) — referenced sections only
+- Privacy Act 1988 (Cth) — APP 11 alignment
+
+## Process
+
+1. Read prerequisites:
+ - The project's E8 posture artefact (`ARC-{P}-AUE8-v*`) — primary input
+ - The project's ISM applicability statement (`ARC-{P}-AUISM-v*`) — primary input
+ - The project's PIA (`ARC-{P}-AUPIA-v*`) — APP 11 cross-reference
+ - The project's PSPF assessment (`ARC-{P}-AUPSPF-v*`) — physical / personnel / information security evidence
+ - The project's RISK artefact — for SecRisk register integration
+ - `${CLAUDE_PLUGIN_ROOT}/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-disp-attestation-template.md` (user override)
+ - Then: `.arckit/templates/au-disp-attestation-template.md`
+ - Fallback: `${CLAUDE_PLUGIN_ROOT}/templates/au-disp-attestation-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if needed.
+
+4. Use `scripts/bash/generate-document-id.sh AUDISP --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Organisation Profile** — entity name, ABN, primary business activity, Defence contracts in scope, headcount, sites, foreign ownership / control / influence (FOCI) declaration.
+
+ - **DISP Level Sought** — Level 1 / Level 2 / Level 3, regulatory driver (specific contract requirement, panel mandate, anticipated tender pipeline), justification of level chosen.
+
+ - **Security Officer Designation** — Chief Security Officer (CSO) name + role + authority, deputy / backup CSO, contact details, vetting status. **DISP requires a named, suitably-cleared CSO with authority across the four security domains.**
+
+ - **Four Security Domains Coverage** — DISP requires evidence across four domains:
+ 1. **Governance** — security policy, risk management, audit, incident management, change control
+ 2. **Personnel Security** — security clearances appropriate to work, security awareness training, separation of duties, off-boarding
+ 3. **Physical Security** — facility security, ICT equipment security, equipment lifecycle (cloud-only systems may inherit much of this from cloud provider's IRAP)
+ 4. **Information & Cyber Security** — Essential Eight ML2 minimum, ISM applicability, cryptography, gateway, monitoring, BCP
+
+ For each domain, document:
+ - Current implementation state (cite E8 posture, ISM applicability, supporting policies)
+ - Evidence references (artefact IDs + document register)
+ - Gap description
+ - Remediation plan with target dates
+ - Sign-off statement by accountable officer
+
+ - **Essential Eight ML2 Evidence Per Strategy** — for each of the 8 E8 strategies, summarise the current ML position and evidence supporting ML2 attestation. Cite the AUE8 artefact directly.
+
+ - **ISM Applicability Highlights** — beyond E8, summarise which ISM domains apply, current implementation summary, and identify any ISM gaps that materially affect DISP attestation. Cite the AUISM artefact.
+
+ - **Foreign Ownership, Control or Influence (FOCI) Declaration** — disclose any foreign ownership > 5%, foreign-board-member arrangements, foreign-supply-chain dependencies, foreign-personnel access. DISP Level 2 + 3 require FOCI mitigation plans where applicable.
+
+ - **Supply Chain Security** — disclose Tier 1 suppliers (MSPs, SaaS, cloud), supply-chain attestations held (SOC 2 / ISO 27001 / IRAP), supply-chain risk management process.
+
+ - **Incident Response & Reporting** — incident response plan summary, 24-hour rapid notification capability for Defence-relevant incidents, OAIC NDB scheme integration, evidence of last incident response exercise. Cite NDB playbook (`ARC-{P}-AUNDB-v*`) if available.
+
+ - **Security Awareness Training** — DISP-mandated security awareness training programme, completion rate, refresher cadence, security-clearance-holder additional briefings (pre/post-leave for cleared personnel).
+
+ - **Annual Self-Audit Plan** — DISP requires annual self-audit; describe scope, methodology, evidence retention.
+
+ - **Attestation Statement** — formal CSO + Director sign-off statement attesting to the accuracy of the pack, with signature blocks, date, and re-attestation cadence.
+
+7. Populate the External References section per `${CLAUDE_PLUGIN_ROOT}/references/citation-instructions.md`. The DISP Membership Pack (with edition) MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the Four Security Domains coverage table).
+
+## Important Notes
+
+- The pack is a **self-attestation**, not a third-party assurance. Defence reserves the right to audit. Artefact tone should be evidence-based and conservative — do not claim controls not yet implemented.
+- The CSO designation is a hard requirement. If no CSO is named in the source artefacts, the pack must explicitly flag this as an outstanding action — it cannot be filled in by the recipe.
+- For Level 2 + 3 members supplying classified Defence work, security clearances of personnel handling that work must be evidenced. Records of clearance levels held may be sensitive — reference by clearance level (Baseline / NV1 / NV2 / PV) not by individual name.
+- Cloud-only systems that inherit Physical Security from an IRAP-assessed cloud provider should explicitly cite the cloud provider's IRAP scope statement, not generic marketing.
+- The pack should integrate with the project's risk register — material residual risks should appear both in the risk register and in the DISP pack's gap descriptions.
+- For DISP renewal cycles, the artefact should produce a redline-friendly format so year-on-year changes are easy to track.
diff --git a/arckit-au/commands/au-dss.md b/arckit-au/commands/au-dss.md
new file mode 100644
index 00000000..5869faf7
--- /dev/null
+++ b/arckit-au/commands/au-dss.md
@@ -0,0 +1,103 @@
+---
+description: "[COMMUNITY] Generate a DTA Digital Service Standard compliance assessment for Australian Government digital services against all 13 criteria."
+argument-hint: ""
+effort: high
+handoffs:
+ - command: au-e8-posture
+ description: DSS Criterion 5 (Make it secure) feeds into the E8 maturity posture assessment.
+ - command: au-pia
+ description: DSS Criterion 7 (Protect users' privacy) feeds into the Privacy Impact Assessment.
+ - command: risk
+ description: DSS gaps surface as delivery and compliance risks for the risk register.
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified DTA assessor or digital delivery lead before reliance. The DTA Digital Service Standard was refreshed in July 2025 — verify criteria against the current published version.
+
+You are an enterprise architect generating a **DTA Digital Service Standard compliance assessment** for an Australian Government digital service.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Digital Transformation Agency (DTA) Digital Service Standard sets the mandatory criteria that Australian Government digital services must meet. Services subject to the Standard must demonstrate compliance at key assessment points. The Standard replaced the earlier Digital Service Standard (2016) with a refreshed version in July 2025.
+
+**Authoritative anchor**: DTA Digital Service Standard —
+
+**Key Australian Digital Service References**:
+
+- DTA Digital Service Standard (July 2025 refresh)
+- DTA Service Design and Delivery Process
+- Digital Government Strategy
+- Web Content Accessibility Guidelines (WCAG) 2.2 Level AA
+- Style Manual for Australian Government (style.gov.au)
+- DTA Content Guide
+- Whole of Government Digital and ICT Investment Oversight Framework
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract user-facing requirements, accessibility requirements, technology choices
+ - The project's STKE artefact — extract user research, stakeholder engagement evidence
+ - `${CLAUDE_PLUGIN_ROOT}/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - **First**, check `.arckit/templates-custom/au-dss-template.md` (user override)
+ - **Then**, `.arckit/templates/au-dss-template.md`
+ - **Fallback**, `${CLAUDE_PLUGIN_ROOT}/templates/au-dss-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUDSS --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Service Context** — service name, owning agency/department, service phase (Discovery / Alpha / Beta / Live), user base (public-facing / internal / both), annual transaction volume (if known).
+
+ - **13-Criterion Assessment** — one assessment block per Digital Service Standard criterion:
+ 1. **Understand user needs** — research conducted with real users, needs documented
+ 2. **Have a multidisciplinary team** — team composition, capability coverage, DDaT roles
+ 3. **Agile and user-centred process** — delivery methodology, iteration cadence, user feedback loops
+ 4. **Understand tools and systems** — technology landscape mapped, legacy dependencies identified
+ 5. **Make it secure** — security posture, E8 alignment, threat assessment, incident response
+ 6. **Consistent and responsive design** — design system usage, responsive breakpoints, device testing
+ 7. **Protect users' privacy** — PIA completed, APP compliance, data minimisation, consent
+ 8. **Make source code open** — open-source strategy, code repository, licence
+ 9. **Make it accessible** — WCAG 2.2 AA compliance, assistive technology testing, accessibility statement
+ 10. **Test the service** — testing strategy (unit, integration, UAT, accessibility, performance, security)
+ 11. **Measure performance** — KPIs defined (completion rate, user satisfaction, cost per transaction, digital take-up)
+ 12. **Don't forget the non-digital experience** — assisted digital, phone, in-person channel design
+ 13. **Encourage everyone to use the digital service** — channel shift strategy, take-up targets
+
+ For each criterion, document:
+ - Assessment status: ✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A
+ - Evidence summary (what demonstrates compliance)
+ - Gap description (what is missing)
+ - Remediation actions with owner and target date
+
+ - **Compliance Summary** — table: Criterion # | Criterion Name | Status | Gap Count
+
+ - **Assessment Readiness** — for services approaching Alpha/Beta/Live assessment, identify the top 3 risks to passing and recommended mitigations.
+
+ - **Recommendations** — prioritised list of actions to improve compliance posture, grouped by criterion priority.
+
+7. Populate the External References section per `${CLAUDE_PLUGIN_ROOT}/references/citation-instructions.md`. The DTA Digital Service Standard MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the compliance summary table showing status per criterion).
+
+## Important Notes
+
+- The DTA Digital Service Standard applies to **all new and redesigned Australian Government digital services**. Existing services may be assessed when undergoing significant change.
+- Criterion 5 (Make it secure) should cross-reference the ASD Essential Eight assessment (`/arckit:au-e8-posture`) if one exists.
+- Criterion 7 (Protect users' privacy) should cross-reference the Privacy Impact Assessment (`/arckit:au-pia`) if one exists.
+- Criterion 9 (Make it accessible) requires WCAG 2.2 Level AA as the minimum standard for Australian Government services.
+- The Standard is assessed at Alpha, Beta, and Live phases — the depth of evidence expected increases at each gate.
+- This assessment is analogous to the UK GDS Service Standard assessment (`/arckit:service-assessment`) but uses Australian criteria and governance structures.
diff --git a/arckit-au/commands/au-e8-posture.md b/arckit-au/commands/au-e8-posture.md
new file mode 100644
index 00000000..52204fd9
--- /dev/null
+++ b/arckit-au/commands/au-e8-posture.md
@@ -0,0 +1,97 @@
+---
+description: "[COMMUNITY] Generate an ASD Essential Eight maturity posture assessment for Australian Government projects against all eight mitigation strategies at ML0–ML3."
+argument-hint: ""
+effort: high
+handoffs:
+ - command: au-ism-controls
+ description: E8 posture feeds the ISM control applicability statement — target ML drives which ISM controls are mandatory.
+ - command: risk
+ description: E8 gaps surface as security risks for the project risk register.
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified CISO or security assessor before reliance. Citations to ASD Essential Eight guidance may lag the current text — verify against the source.
+
+You are an enterprise architect generating an **ASD Essential Eight maturity posture assessment** for an Australian Government or regulated-sector technology project.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Australian Signals Directorate (ASD) Essential Eight is the baseline cyber-security mitigation framework for Australian Government entities. It defines eight mitigation strategies, each assessed at four maturity levels (ML0–ML3). Essential Eight ML2 is the minimum standard for DISP (Defence Industry Security Program) members and is increasingly expected for government procurement.
+
+**Authoritative anchor**: ASD Essential Eight Maturity Model —
+
+**Key Australian Security References**:
+
+- ASD Essential Eight Maturity Model (current edition)
+- ASD Information Security Manual (ISM) —
+- Protective Security Policy Framework (PSPF) —
+- Australian Cyber Security Strategy 2023–2030
+- DISP Essential Eight ML2 mandate (effective 2025)
+- Privacy Act 1988 (Cth) — security of personal information (APP 11)
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract NFR-SEC requirements, data classification, compliance obligations
+ - The project's RISK artefact — extract existing security risks and mitigations
+ - `${CLAUDE_PLUGIN_ROOT}/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - **First**, check `.arckit/templates-custom/au-e8-posture-template.md` (user override)
+ - **Then**, `.arckit/templates/au-e8-posture-template.md`
+ - **Fallback**, `${CLAUDE_PLUGIN_ROOT}/templates/au-e8-posture-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUE8 --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **System Context** — system name, classification level (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET), deployment model (cloud / on-premise / hybrid), IRAP assessment status, data sovereignty position.
+
+ - **Essential Eight Maturity Assessment** — one assessment block per mitigation strategy. For each of the eight strategies:
+ 1. **Application Control** — only approved applications execute on systems
+ 2. **Patch Applications** — security patches for applications applied within timeframes
+ 3. **Configure Microsoft Office Macro Settings** — macros blocked or restricted per policy
+ 4. **User Application Hardening** — web browsers, email clients, Office configured to block untrusted content
+ 5. **Restrict Administrative Privileges** — admin access validated, separated, and time-limited
+ 6. **Patch Operating Systems** — OS patches applied within timeframes, unsupported OS replaced
+ 7. **Multi-Factor Authentication** — MFA on all remote access, privileged access, and data repositories
+ 8. **Regular Backups** — backups performed, tested, and stored securely per retention schedule
+
+ For each strategy, document:
+ - Current maturity level (ML0 / ML1 / ML2 / ML3) with evidence
+ - Target maturity level with rationale (regulatory driver or risk appetite)
+ - Gap description (specific controls not yet implemented)
+ - Remediation actions with owner and target date
+ - Residual risk if gap persists
+
+ - **Maturity Summary Matrix** — 8-row table: Strategy | Current ML | Target ML | Gap Count | Priority (Critical / High / Medium / Low)
+
+ - **DISP Compliance Position** — if the entity is a DISP member, assess whether current posture meets ML2 minimum across all eight strategies. Flag any strategy below ML2 as a DISP non-compliance risk.
+
+ - **Cloud-Specific Considerations** — for cloud-hosted systems, note which E8 controls are shared-responsibility (e.g., OS patching on PaaS vs IaaS), which are vendor-managed (e.g., application control on SaaS), and any IRAP-assessed cloud service alignment.
+
+ - **Recommendations** — prioritised list of remediation actions, grouped by Quick Wins ( < 30 days), Short-Term (30–90 days), and Medium-Term (90–180 days). Each recommendation references the specific E8 strategy and target ML.
+
+7. Populate the External References section per `${CLAUDE_PLUGIN_ROOT}/references/citation-instructions.md`. The ASD Essential Eight Maturity Model MUST appear in the Document Register with its primary URL and verification date.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the maturity summary matrix showing current ML vs target ML per strategy).
+
+## Important Notes
+
+- ML0 means the strategy is **not implemented** — it does not mean "assessed and found satisfactory at a low level." Explicitly state this distinction.
+- Each maturity level has specific sub-controls defined by ASD. Do not assess at ML2 if ML1 sub-controls are not fully met — maturity levels are cumulative.
+- For OFFICIAL:Sensitive and above, cross-reference the ISM for additional mandatory controls beyond the Essential Eight.
+- The Essential Eight is a **mitigation** framework, not a comprehensive security standard. Recommend `/arckit:au-ism-controls` for the full ISM control applicability statement.
+- For energy-sector projects, recommend `/arckit:au-aescsf` as the AESCSF capability domains build on and extend the E8 baseline.
diff --git a/arckit-au/commands/au-ism-controls.md b/arckit-au/commands/au-ism-controls.md
new file mode 100644
index 00000000..b854d29f
--- /dev/null
+++ b/arckit-au/commands/au-ism-controls.md
@@ -0,0 +1,115 @@
+---
+description: "[COMMUNITY] Generate an ASD Information Security Manual (ISM) control applicability statement for Australian Government projects, scoped to the system's classification and supporting DISP attestation."
+argument-hint: ""
+effort: high
+handoffs:
+ - command: au-disp-attestation
+ description: ISM applicability is a primary input to the DISP Member self-attestation pack.
+ - command: au-pspf
+ description: ISM is the technical-controls instantiation of PSPF Information Security outcome — feeds the PSPF assessment.
+ - command: au-e8-posture
+ description: E8 is a mitigation subset of ISM. The ISM applicability statement extends beyond E8 to cover personnel security, physical security, and information governance controls.
+ - command: risk
+ description: ISM control gaps surface as security risks for the project risk register.
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified IRAP Assessor or CISO before reliance. ISM is updated quarterly — verify control identifiers against the current edition before any external use.
+
+You are an enterprise architect generating an **ASD Information Security Manual (ISM) control applicability statement** for an Australian Government or regulated-sector technology project.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Australian Signals Directorate (ASD) Information Security Manual (ISM) is the comprehensive set of cyber-security controls for Australian Government information systems. Where the Essential Eight is a mitigation framework targeting attack-vector defence, the ISM is the comprehensive control set covering governance, personnel, physical, communications, ICT system, networking, cryptography, gateway, data-transfer, evaluation, working-off-site, and incident-response domains. ISM compliance is the core technical-controls evidence for PSPF Information Security outcome and a primary input to DISP attestation.
+
+**Authoritative anchor**: ASD Information Security Manual —
+
+**Key Australian Security References**:
+
+- ASD Information Security Manual (current edition; updated quarterly)
+- Protective Security Policy Framework (PSPF) —
+- ASD Essential Eight Maturity Model (mitigation subset of ISM)
+- Defence Industry Security Program (DISP) requirements
+- IRAP (Information Security Registered Assessors Program) — control assurance methodology
+- Privacy Act 1988 (Cth) — APP 11 alignment
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract NFR-SEC requirements, data classification, compliance obligations
+ - The project's RISK artefact — extract existing security risks
+ - The project's E8 posture artefact (`ARC-{P}-AUE8-v*`) if available — provides E8 sub-control evidence
+ - The project's DATA artefact — for classification-driven control scoping
+ - `${CLAUDE_PLUGIN_ROOT}/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-ism-controls-template.md` (user override)
+ - Then: `.arckit/templates/au-ism-controls-template.md`
+ - Fallback: `${CLAUDE_PLUGIN_ROOT}/templates/au-ism-controls-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist.
+
+4. Use `scripts/bash/generate-document-id.sh AUISM --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **System Context** — system name, classification level (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET), deployment model, IRAP assessment status, sovereignty position. Classification drives applicability — controls applicable at OFFICIAL:Sensitive are a subset of those at PROTECTED.
+
+ - **Control Domain Applicability Matrix** — table covering all 17 ISM control areas (15 ASD ISM chapter domains plus 2 cross-cutting areas — Cloud/IaaS and Working-Off-Site), marking applicability per system classification:
+ 1. **Cyber Security Governance** — security risk management, security documentation, change management
+ 2. **Cyber Security Incidents** — detection, reporting, response, business continuity
+ 3. **Outsourced Services** — managed service providers, cloud, supply chain
+ 4. **Security Documentation** — system security plans, security risk management plans
+ 5. **Personnel Security** — clearance levels, awareness training, separation of duties
+ 6. **Physical Security** — facilities, equipment, ICT equipment lifecycle
+ 7. **Communications Infrastructure** — fibre, cabling, telephony
+ 8. **ICT Equipment Security** — hardware lifecycle, media, sanitisation
+ 9. **System Hardening** — operating systems, applications, authentication, network
+ 10. **System Management** — administration, monitoring, maintenance, vulnerability mgmt
+ 11. **System Monitoring** — event logging, audit, security metrics
+ 12. **Cryptography** — cryptographic fundamentals, ASD-approved algorithms, key management
+ 13. **Gateway Security** — gateway architecture, content filtering, DLP
+ 14. **Data Transfer** — between domains, between systems, data import/export
+ 15. **Cloud and IaaS Considerations** — IRAP assessment status, sovereign cloud, shared responsibility
+ 16. **Working-Off-Site Security** — remote work, mobile devices, BYOD
+ 17. **Evaluation Activities** — Common Criteria, FIPS, vendor product testing
+
+ - **Per-Domain Control Applicability Assessment** — for each in-scope domain, document:
+ - Applicability rationale (which controls apply at the system's classification level)
+ - Current implementation status: ✅ Implemented / ⚠️ Partial / ❌ Not Implemented / N/A
+ - Evidence supporting the status (cite E8 posture artefact, IRAP report, vendor attestations)
+ - Gap description with specific ISM control IDs not yet met
+ - Remediation actions with owner and target date
+ - Compensating controls if applicable
+
+ - **ISM-to-E8 Cross-Reference** — show which E8 strategies map to which ISM domains. Reinforces the E8-as-mitigation-subset framing for governance audiences.
+
+ - **Compliance Summary** — table summarising domain-by-domain compliance posture; overall ISM applicability score (controls implemented / controls applicable).
+
+ - **IRAP Assessment Position** — if the system holds or pursues IRAP assessment, note the IRAP scope, assessment date, residual risks accepted, and re-assessment cadence. For systems integrating with IRAP-assessed cloud services, note the inherited control posture.
+
+ - **Recommendations** — prioritised remediation actions grouped by Quick Wins ( < 30 days), Short-Term (30–90 days), Medium-Term (90–180 days). Each recommendation references the specific ISM control ID(s).
+
+7. Populate the External References section per `${CLAUDE_PLUGIN_ROOT}/references/citation-instructions.md`. The ASD ISM (with edition / publication date) MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the Compliance Summary table showing per-domain status).
+
+## Important Notes
+
+- ISM controls are tagged with applicability flags (ALL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET / TOP SECRET). The applicability statement must select controls appropriate to the *highest classification of information processed*, not the *lowest*.
+- ISM is updated quarterly — control IDs and wording can change. The artefact should record the ISM edition / publication date used as a verification anchor.
+- For systems integrating with IRAP-assessed cloud services, note explicit shared-responsibility — many ISM controls inherit from the cloud provider's IRAP attestation. Cite the IRAP scope statement, not the cloud provider's marketing.
+- Cross-reference the E8 posture artefact wherever an ISM control maps to an E8 sub-control — avoids duplication and keeps the two artefacts consistent.
+- For DISP members or systems supporting Defence work, scope the Personnel Security and Physical Security domains carefully — these are commonly under-assessed in cloud-only environments.
+- The Cyber Security Incidents domain should reference the project's NDB playbook (`/arckit:au-ndb-playbook`) for personal-information breach scenarios.
+- The Outsourced Services domain must include MSP-held admin role boundaries, contractual security-control flow-down, and supply-chain attestation review.
diff --git a/arckit-au/commands/au-ndb-playbook.md b/arckit-au/commands/au-ndb-playbook.md
new file mode 100644
index 00000000..37d35bda
--- /dev/null
+++ b/arckit-au/commands/au-ndb-playbook.md
@@ -0,0 +1,113 @@
+---
+description: "[COMMUNITY] Generate a Notifiable Data Breach (NDB) scheme response playbook under Privacy Act 1988 Part IIIC — eligible-data-breach test, 30-day OAIC notification timeline, individual notification, containment, and lessons-learned framework."
+argument-hint: ""
+effort: medium
+handoffs:
+ - command: au-pia
+ description: NDB playbook is the operational complement to AUPIA APP 11 mitigation; APP 11 references NDB.
+ - command: au-disp-attestation
+ description: DISP attestation pack cites NDB capability evidence.
+ - command: risk
+ description: NDB-relevant risks tagged into the project risk register.
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a Privacy Officer and legal counsel before adoption. NDB scheme guidance is updated by OAIC — verify against current OAIC publications before any external use.
+
+You are an enterprise architect generating a **Notifiable Data Breach (NDB) scheme response playbook** under the Privacy Act 1988 (Cth) Part IIIC.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Notifiable Data Breach (NDB) scheme under Privacy Act 1988 (Cth) Part IIIC requires APP entities (Australian Government agencies + private organisations subject to the Privacy Act) to notify the **OAIC and affected individuals** when an "eligible data breach" of personal information occurs and is likely to result in serious harm.
+
+The NDB scheme has three statutory tests:
+
+1. **Unauthorised access to / disclosure of, or loss of, personal information**
+2. **Likely to result in serious harm** to one or more individuals
+3. **Cannot be remediated through reasonable steps** to prevent the serious harm
+
+The notification clock is **30 days** to OAIC + affected individuals from the time the entity has reasonable grounds to believe an eligible data breach has occurred. Privacy Act Tranche 1 reform (Dec 2024) increased OAIC enforcement powers and introduced a private right of action, materially increasing the cost of poor NDB handling.
+
+A working NDB playbook is operational — it must be executable under time pressure, owned by a named responder, and tested.
+
+**Authoritative anchors**:
+
+- Privacy Act 1988 (Cth) Part IIIC —
+- OAIC NDB scheme guidance —
+
+## Process
+
+1. Read prerequisites:
+ - The project's PIA (`ARC-{P}-AUPIA-v*`) — APP 11 cross-reference
+ - The project's E8 posture (`ARC-{P}-AUE8-v*`) — security baseline
+ - The project's ISM applicability (`ARC-{P}-AUISM-v*`) — Domain 2 (Cyber Security Incidents)
+ - The project's RISK artefact
+ - `${CLAUDE_PLUGIN_ROOT}/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-ndb-playbook-template.md`
+ - Then: `.arckit/templates/au-ndb-playbook-template.md`
+ - Fallback: `${CLAUDE_PLUGIN_ROOT}/templates/au-ndb-playbook-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUNDB --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Entity Profile** — APP entity status, Privacy Officer designation, accountable officer for NDB response, business hours + after-hours contact details, key incident-team roles.
+
+ - **NDB Eligibility Test** — explicit decision tree:
+ 1. Has there been unauthorised access to / disclosure of, or loss of, personal information?
+ 2. Is serious harm likely to result?
+ 3. Can the entity remediate through reasonable steps to prevent the serious harm?
+
+ If 1 + 2 = Yes and 3 = No → eligible data breach → notify within 30 days.
+
+ - **30-Day Timeline Plan** — day-by-day milestones from Day 0 (becoming aware of suspected breach) through Day 30 (OAIC + individual notification deadline):
+ - Day 0–1: Detect, contain, assess + activate playbook
+ - Day 1–7: Investigate, scope, classify
+ - Day 7–14: Eligibility assessment, draft notifications
+ - Day 14–21: Legal review, executive sign-off, finalise notifications
+ - Day 21–30: OAIC notification, individual notifications, public statement (if required)
+
+ - **Roles & Responsibilities (RACI)** — Privacy Officer, Security Officer, CISO, Legal, Communications, accountable executive — clear responsibility matrix.
+
+ - **Detection + Containment Procedures** — how breaches become known to the playbook owner (SIEM alerts, customer reports, vendor disclosure, insider report); immediate containment steps; evidence preservation.
+
+ - **Assessment Procedure** — how to determine eligibility under the three statutory tests; serious-harm assessment criteria (financial loss, identity theft, emotional distress, physical safety, reputational harm); reasonable-steps mitigation to remove eligibility.
+
+ - **OAIC Notification Form Content** — what OAIC requires per the statutory form: nature of breach, kind of information involved, recommendations for affected individuals, contact details. Template language for use in the OAIC form.
+
+ - **Individual Notification Approach** — direct vs publication-based notification options, content requirements, channel decisions, language and accessibility considerations.
+
+ - **Communications Plan** — internal, external, media, regulator-coordinated. Pre-written holding statements + escalation triggers.
+
+ - **Post-Incident Review** — root cause analysis, lessons learned, control updates feeding back into AUE8 + AUISM + AUPIA artefacts.
+
+ - **Coordination With Other Reporting Obligations** — SOCI Act 12hr / 72hr (where applicable), DISP incident reporting, sectoral reporting (APRA, AHPRA, etc.). Single incident may trigger multiple obligations on different timelines.
+
+ - **Tabletop Exercise Plan** — annual tabletop scenario, evidence retention, lessons-learned cycle.
+
+7. Populate the External References section per `${CLAUDE_PLUGIN_ROOT}/references/citation-instructions.md`. Privacy Act 1988 + OAIC NDB scheme guidance MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the 30-day timeline summary).
+
+## Important Notes
+
+- The 30-day notification clock starts from "reasonable grounds to believe" an eligible breach has occurred — **not** from the breach itself, and **not** from confirmation. This is the most commonly misread part of the scheme. The recipe should make this distinction unambiguous.
+- The "reasonable steps to remediate" test is the off-ramp from notification — if the entity can prevent serious harm through containment / mitigation actions, no notification is required. But this needs to be assessed conservatively; OAIC will second-guess hindsight optimism.
+- For multi-jurisdictional incidents (e.g., breach affecting AU + NZ + EU residents), the 30-day clock is not the only timeline. EU GDPR is 72 hours; NZ Privacy Act is "as soon as practicable". The playbook should flag this for legal-counsel coordination.
+- "Serious harm" is a broad threshold including financial loss, identity theft, **emotional distress** (including humiliation), and **reputational harm**. It is materially broader than "real prospect of significant harm" some practitioners assume.
+- For SOCI-covered entities, the NDB 30-day clock runs in parallel with SOCI 12hr / 72hr cyber incident reporting. The playbook should explicitly coordinate both timelines so the 12hr SOCI report doesn't pre-commit positions before the NDB assessment is complete.
+- Pre-written holding statements and notification templates dramatically reduce time-to-notify under pressure. Recipes producing this artefact should include template language wherever possible.
+- The playbook is operational. It should be **tested** at least annually via tabletop exercise; the recipe should output an exercise scenario template as part of the deliverable.
diff --git a/arckit-au/commands/au-pia.md b/arckit-au/commands/au-pia.md
new file mode 100644
index 00000000..4c168f27
--- /dev/null
+++ b/arckit-au/commands/au-pia.md
@@ -0,0 +1,111 @@
+---
+description: "[COMMUNITY] Generate a Privacy Impact Assessment (PIA) for Australian Government entities under Privacy Act 1988 s33D, assessing compliance with all 13 Australian Privacy Principles (APPs)."
+argument-hint: ""
+effort: high
+handoffs:
+ - command: au-dss
+ description: PIA findings feed DSS Criterion 7 (Protect users' privacy).
+ - command: au-e8-posture
+ description: APP 11 (security of personal information) informs E8 target maturity level.
+ - command: risk
+ description: Privacy risks surface in the project risk register.
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified Privacy Officer, DPO, or legal counsel before reliance. Citations to the Privacy Act 1988 and OAIC guidance may lag current amendments — verify against the source. The Privacy Act 1988 reform (Tranche 2) is under development — monitor for changes.
+
+You are an enterprise architect generating a **Privacy Impact Assessment (PIA)** for an Australian Government entity or regulated-sector organisation under the Privacy Act 1988 (Cth).
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+Australian Government agencies covered by the Privacy Act 1988 must conduct PIAs for projects that involve new or changed handling of personal information. Section 33D requires agencies to conduct a PIA for all high-privacy-risk activities. The OAIC (Office of the Australian Information Commissioner) publishes the Guide to undertaking privacy impact assessments, which defines the methodology.
+
+**Authoritative anchors**:
+
+- Privacy Act 1988 (Cth) —
+- OAIC Guide to undertaking privacy impact assessments —
+- Australian Privacy Principles (APPs) — Schedule 1 of the Privacy Act 1988
+- Privacy (Australian Government Agencies — Governance) APP Code 2017
+- OAIC Privacy regulatory action policy
+
+**Key Privacy Act 1988 Reform Context**:
+
+- Tranche 1 effective December 2024 — enhanced enforcement powers, tiered penalties, private right of action
+- AI decision-making notification required from December 2026
+- Tranche 2 under development — ~93 remaining proposals from Attorney-General's review
+- Small business exemption changes from 1 July 2026
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract data requirements (DR-*), NFR-SEC requirements, integration requirements (INT-*)
+ - The project's DATA artefact — extract entity model, PII fields, data flows
+ - The project's STKE artefact — extract data subjects, stakeholder privacy expectations
+ - `${CLAUDE_PLUGIN_ROOT}/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - **First**, check `.arckit/templates-custom/au-pia-template.md` (user override)
+ - **Then**, `.arckit/templates/au-pia-template.md`
+ - **Fallback**, `${CLAUDE_PLUGIN_ROOT}/templates/au-pia-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUPIA --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Project Description** — what the project does, what personal information is involved, why it is needed, who the data subjects are, estimated data volumes.
+
+ - **Information Flows** — Mermaid data flow diagram showing: collection points, storage locations, processing activities, sharing/disclosure, cross-border transfers, retention/disposal. Mark each flow with the APP that governs it.
+
+ - **13 APP Compliance Assessment** — one assessment block per Australian Privacy Principle:
+ 1. **APP 1** — Open and transparent management of personal information
+ 2. **APP 2** — Anonymity and pseudonymity
+ 3. **APP 3** — Collection of solicited personal information
+ 4. **APP 4** — Dealing with unsolicited personal information
+ 5. **APP 5** — Notification of the collection of personal information
+ 6. **APP 6** — Use or disclosure of personal information
+ 7. **APP 7** — Direct marketing
+ 8. **APP 8** — Cross-border disclosure of personal information
+ 9. **APP 9** — Adoption, use or disclosure of government related identifiers
+ 10. **APP 10** — Quality of personal information
+ 11. **APP 11** — Security of personal information
+ 12. **APP 12** — Access to personal information
+ 13. **APP 13** — Correction of personal information
+
+ For each APP, document:
+ - Applicability: Applies / Does Not Apply (with rationale)
+ - Compliance status: ✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant
+ - Evidence of compliance measures
+ - Privacy risk if non-compliant (likelihood × impact)
+ - Mitigation actions with owner and target date
+
+ - **Privacy Risk Register** — risks identified during APP assessment, scored by likelihood and impact, with mitigations and residual risk.
+
+ - **Sensitive Information Assessment** — identify whether any sensitive information (as defined in s 6 of the Privacy Act) is processed: racial or ethnic origin, political opinions, religious beliefs, sexual orientation, criminal record, health information, genetic information, biometric information, trade union membership. If yes, note the additional consent requirements under APP 3.3.
+
+ - **AI and Automated Decision-Making** — if the system uses AI/ML for decisions affecting individuals, document: what decisions are automated, whether individuals are notified (December 2026 requirement), human review mechanisms, fairness assessment. Cross-reference `/arckit:au-ai-assurance` if applicable.
+
+ - **Recommendations** — prioritised list of privacy-enhancing measures.
+
+7. Populate the External References section per `${CLAUDE_PLUGIN_ROOT}/references/citation-instructions.md`. The Privacy Act 1988 and OAIC PIA Guide MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the APP compliance summary table).
+
+## Important Notes
+
+- This is the **Australian** PIA, not the UK DPIA. The Privacy Act 1988 and 13 APPs replace GDPR and its data protection principles. Do not reference GDPR, ICO, or UK data protection law.
+- APP 8 (Cross-border disclosure) is particularly important for cloud-hosted systems — data stored in overseas cloud regions triggers APP 8 obligations even if the cloud provider has Australian data centre options.
+- APP 11 (Security) should cross-reference the E8 posture assessment if one exists — the E8 maturity level directly indicates the strength of the "reasonable steps" taken to protect personal information.
+- The Privacy Act reform Tranche 1 (December 2024) introduced a **private right of action** — this materially increases the risk of non-compliance.
+- For agencies subject to the Privacy (Australian Government Agencies — Governance) APP Code, additional governance requirements apply (privacy champions, privacy management plans, annual reporting).
diff --git a/arckit-au/commands/au-pspf.md b/arckit-au/commands/au-pspf.md
new file mode 100644
index 00000000..79658450
--- /dev/null
+++ b/arckit-au/commands/au-pspf.md
@@ -0,0 +1,120 @@
+---
+description: "[COMMUNITY] Generate a Protective Security Policy Framework (PSPF) compliance assessment for Australian Government entities and contractors against the four security outcomes and 16 core requirements."
+argument-hint: ""
+effort: high
+handoffs:
+ - command: au-ism-controls
+ description: ISM is the technical-controls instantiation of PSPF Information Security outcome — primary input to PSPF Outcome 2.
+ - command: au-e8-posture
+ description: E8 supports PSPF Information Security outcome.
+ - command: au-pia
+ description: APP 11 + PSPF Personnel Security overlap; PIA cross-reference.
+ - command: au-disp-attestation
+ description: DISP attestation pack draws on PSPF compliance evidence.
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a PSPF-experienced security officer or government accreditation specialist. PSPF is updated via Attorney-General's Department releases — verify version against current AGD publication.
+
+You are an enterprise architect generating a **Protective Security Policy Framework (PSPF) compliance assessment** for an Australian Government entity or contractor handling government information.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Protective Security Policy Framework (PSPF) is the Australian Government's overarching security policy framework administered by the Attorney-General's Department. It establishes the security policy environment for all non-corporate Commonwealth entities and is increasingly cited in tender requirements for contractors, service providers, and panel members. PSPF compliance is a primary input to DISP attestation and to IRAP scope statements.
+
+PSPF is structured around **four security outcomes** with **16 core requirements**:
+
+- **Outcome 1: Security Governance** (4 core requirements)
+- **Outcome 2: Information Security** (4 core requirements — ISM is the technical instantiation)
+- **Outcome 3: Personnel Security** (4 core requirements)
+- **Outcome 4: Physical Security** (4 core requirements)
+
+**Authoritative anchor**: Protective Security Policy Framework —
+
+**Key references**:
+
+- PSPF (current edition) — Attorney-General's Department
+- ASD Information Security Manual (ISM) — instantiates Outcome 2
+- ASD Essential Eight — minimum cyber baseline supporting Outcome 2
+- DISP (Defence Industry Security Program) — adjacent framework
+
+## Process
+
+1. Read prerequisites:
+ - The project's E8 posture (`ARC-{P}-AUE8-v*`)
+ - The project's ISM applicability (`ARC-{P}-AUISM-v*`) — primary input
+ - The project's PIA (`ARC-{P}-AUPIA-v*`)
+ - The project's RISK artefact
+ - `${CLAUDE_PLUGIN_ROOT}/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-pspf-template.md`
+ - Then: `.arckit/templates/au-pspf-template.md`
+ - Fallback: `${CLAUDE_PLUGIN_ROOT}/templates/au-pspf-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUPSPF --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Entity Profile** — entity name, type (non-corporate Commonwealth / corporate Commonwealth / contractor / panel member / state-government with PSPF flow-down), PSPF applicability driver (direct / contractual flow-down), Chief Security Officer (CSO) designation, security maturity self-assessment level.
+
+ - **Outcome 1: Security Governance** — assessment of the 4 core requirements:
+ 1. CR1: Role of accountable authority (security governance leadership)
+ 2. CR2: Management structures and responsibilities (CSO, security committee, executives)
+ 3. CR3: Security planning and risk management
+ 4. CR4: Security maturity monitoring (Annual Self-Assessment + reporting to AGD)
+
+ - **Outcome 2: Information Security** — assessment of 4 core requirements (ISM is the primary instantiation here):
+ 1. CR5: Sensitive and classified information (information classification, marking, handling)
+ 2. CR6: Access to information (need-to-know, security clearances)
+ 3. CR7: Safeguarding information from cyber threats (E8 + ISM)
+ 4. CR8: Sensitive and classified discussions and communications
+
+ - **Outcome 3: Personnel Security** — assessment of 4 core requirements:
+ 1. CR9: Eligibility and suitability (vetting + AGSVA clearance process)
+ 2. CR10: Ongoing assessment (continuous suitability)
+ 3. CR11: Separation of personnel (off-boarding clearance debrief)
+ 4. CR12: Insider threat
+
+ - **Outcome 4: Physical Security** — assessment of 4 core requirements:
+ 1. CR13: Entity facilities (physical security zones)
+ 2. CR14: Working off-site (remote work + travel)
+ 3. CR15: Physical security risk
+ 4. CR16: Supporting services (cleaning, maintenance, contractor access)
+
+ For each Core Requirement document:
+ - Compliance status: ✅ Fully Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant / N/A
+ - Evidence supporting status (cite ARC-{P}-AUISM, AUE8, AUPIA, AUDISP where applicable)
+ - Specific gap description
+ - Remediation actions with owner and target date
+ - PSPF Self-Assessment Level achieved (if relevant — Compliant / Substantially Compliant / Partly Compliant / Not Compliant)
+
+ - **PSPF Annual Self-Assessment** — for non-corporate Commonwealth entities, document Annual Self-Assessment Report status, last submission to AGD, current self-assessed maturity level, gaps.
+
+ - **Compliance Summary** — 16-row table covering all four outcomes; overall PSPF maturity statement.
+
+ - **Recommendations** — prioritised remediations by Quick Wins / Short-Term / Medium-Term, each tagged to specific Core Requirement.
+
+7. Populate the External References section per `${CLAUDE_PLUGIN_ROOT}/references/citation-instructions.md`. PSPF (with edition) MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the four-outcome compliance summary table).
+
+## Important Notes
+
+- PSPF directly applies to **non-corporate Commonwealth entities**. Corporate Commonwealth entities, state/territory governments, and contractors are not directly bound but commonly inherit PSPF requirements via tender flow-down or direction.
+- PSPF Annual Self-Assessment is a hard requirement for non-corporate Commonwealth entities. Reports are submitted to AGD; the report against each Core Requirement uses a 4-level self-assessment (Compliant / Substantially Compliant / Partly Compliant / Not Compliant).
+- **ISM is the technical instantiation of Outcome 2 Information Security.** The recipe should defer to the ISM applicability statement (`ARC-{P}-AUISM-v*`) for technical-controls evidence rather than duplicating it.
+- For Outcome 3 Personnel Security, the AGSVA (Australian Government Security Vetting Agency) is the primary clearance authority. Cleared personnel records reference clearance levels (Baseline / NV1 / NV2 / PV) not individual identities.
+- For pure-cloud systems and contractors with no physical facilities, Outcome 4 Physical Security largely inherits from cloud provider IRAP attestations + host-organisation facilities. Document the inheritance explicitly.
+- For contractors handling Defence-related work, the PSPF assessment dovetails with DISP attestation — cite the DISP pack where it exists rather than re-evidencing.
diff --git a/arckit-au/recipes/au-federal.yaml b/arckit-au/recipes/au-federal.yaml
new file mode 100644
index 00000000..e35d3deb
--- /dev/null
+++ b/arckit-au/recipes/au-federal.yaml
@@ -0,0 +1,369 @@
+# ArcKit build recipe — Australian Federal Government / DISP-supplier compliance
+#
+# Scope: Federal Australian digital services and Defence-supplier engagements
+# subject to the multi-anchor compliance stack — ASD Essential Eight, ASD ISM,
+# DTA Digital Service Standard, Privacy Act 1988 + 13 APPs, OAIC Notifiable Data
+# Breach scheme, Defence Industry Security Program (DISP), Protective Security
+# Policy Framework, DTA AI Assurance Framework + Responsible AI Policy v2.0,
+# Commonwealth Procurement Rules (November 2025), PGPA Act s16, and IRAP.
+#
+# Produces every artefact a Federal/DISP build needs: E8 maturity posture, ISM
+# Statement of Applicability, DTA DSS conformance, Privacy Act PIA, NDB scheme
+# playbook, PSPF outcome scorecard, DTA AI assurance baseline, and a DISP
+# self-attestation pack — plus the core ArcKit governance suite tailored for
+# Australian Federal entities and Defence-cleared suppliers.
+#
+# Differences from uk-saas / uk-mod-sovereign / uae-federal-ai / ca-federal-fitaa
+#
+# Eight au-* community commands all included (Phase 1 + Phase 2 bundled per
+# maintainer's "one PR" recommendation matching UAE/Canada precedent):
+# au-e8-posture ASD Essential Eight ML0-ML3 maturity
+# au-ism-controls ASD ISM 17-domain Statement of Applicability
+# au-pia Privacy Act 1988 s33D + 13 APPs assessment
+# au-ndb-playbook OAIC Notifiable Data Breach response
+# au-dss DTA Digital Service Standard 13 criteria
+# au-pspf PSPF 4 outcomes + 16 core requirements
+# au-ai-assurance DTA AI Assurance Framework + AI Policy v2.0
+# au-disp-attestation DISP Member self-attestation (4 domains)
+#
+# Command swaps from the uk-saas baseline (per #424):
+# arckit:tcop → arckit:au-dss (DTA DSS replaces UK TCoP)
+# arckit:secure → arckit:au-e8-posture (E8 ML2 replaces UK SBD)
+# arckit:dpia → arckit:au-pia (Privacy Act replaces UK GDPR)
+#
+# Sector overlays out of scope for this recipe (separate au-energy PR #440):
+# au-aescsf Australian Energy Sector Cyber Security Framework
+# au-soci-cirmp Security of Critical Infrastructure Act CIRMP
+#
+# Cloud research wave (IRAP-aligned; Australia regions)
+# arckit:research Federal/DISP procurement landscape
+# arckit:aws-research AWS Asia Pacific Sydney + IRAP PROTECTED
+# arckit:azure-research Azure Australia East/Southeast/Central + IRAP
+# arckit:gcp-research Google Cloud australia-southeast1 (Sydney)
+# arckit:datascout data.gov.au, AusTender, federal open data
+
+recipe: au-federal
+schema_version: 1
+flagship: AU_DISP
+description: >
+ Australian Federal Government / DISP-supplier compliance — full
+ compliance suite covering eleven regulatory anchors (ASD Essential Eight,
+ ASD ISM, DTA Digital Service Standard, Privacy Act 1988 + 13 APPs, OAIC
+ NDB scheme, DISP, PSPF, Commonwealth Procurement Rules Nov 2025, DTA AI
+ Assurance Framework + Responsible AI Policy v2.0, PGPA Act s16, IRAP).
+ Includes all 8 au-* community commands (E8 posture, ISM controls, PIA,
+ NDB playbook, DSS, PSPF, AI assurance, DISP attestation) plus the core
+ ArcKit governance suite tailored for Australian Federal entities and
+ Defence-cleared suppliers.
+
+defaults:
+ version: "1.0"
+
+# Optional targets are skipped unless explicitly enabled.
+# - default: true → built unless excluded with --exclude {ID}
+# - default: false (or absent) → built only with --enable {ID}
+optional_targets:
+ AIP:
+ description: AI Playbook (UK reference framework, useful cross-jurisdiction when AI is in scope; au-ai-assurance is the AU-specific equivalent)
+ default: false
+ ORG_RESEARCH:
+ description: Target federal entity research — strategy, mandate, structure, existing systems. Output to projects/000-global/research/ so the entity context is shared across every Australian Federal project in the repo. Runs first (no deps) ahead of all other research.
+ default: true
+ RESEARCH:
+ description: Australian Federal/DISP procurement landscape, build-vs-buy, comparable jurisdictions
+ default: true
+ AWS_RESEARCH:
+ description: AWS Asia Pacific Sydney + Melbourne — IRAP-assessed services, sovereign options (skip if Azure/GCP-only)
+ default: true
+ AZURE_RESEARCH:
+ description: Azure Australia East / Australia Southeast / Australia Central — IRAP PROTECTED, sovereign cloud (skip if AWS/GCP-only)
+ default: true
+ GCP_RESEARCH:
+ description: Google Cloud australia-southeast1 (Sydney) — IRAP-assessed services (skip if AWS/Azure-only)
+ default: true
+ DATASCOUT:
+ description: Australian federal open-data discovery — data.gov.au, AusTender, OAIC, ACSC publications
+ default: false
+ DATA_MODEL:
+ description: Data model with entity relationships and Privacy-Act-aligned governance (recommended for systems handling APP-defined personal information)
+ default: true
+ TRACEABILITY:
+ description: Requirements traceability matrix (recommended for DISP-supplier governance audit and PSPF reporting)
+ default: true
+
+post_build_hooks:
+ - skill: arckit:health
+ args: ""
+ - skill: arckit:pages
+ args: ""
+
+# ---------------------------------------------------------------------------
+# Targets
+# ---------------------------------------------------------------------------
+# Each target is one ArcKit artefact. The orchestrator topo-sorts by `deps`
+# and dispatches one worker subagent per target per wave.
+# ---------------------------------------------------------------------------
+
+targets:
+
+ # --- Foundation --------------------------------------------------------
+ - id: PRIN
+ skill: arckit:principles
+ args: ""
+ output: { project: "000-global", type: PRIN }
+ deps: []
+
+ - id: GLOSSARY
+ skill: arckit:glossary
+ args: "{P}"
+ output: { project: "000-global", type: GLO }
+ deps: [PRIN]
+
+ - id: REQ
+ skill: arckit:requirements
+ args: "{NAME}"
+ output: { project: "{P}-{NAME}", type: REQ }
+ deps: [PRIN]
+
+ - id: STKE
+ skill: arckit:stakeholders
+ args: "{NAME}"
+ output: { project: "{P}-{NAME}", type: STKE }
+ deps: [PRIN]
+
+ # --- Research wave (parallel, before ADRs) -----------------------------
+ # Org research runs first (no deps) and writes to projects/000-global/research/
+ # so the federal-entity context (Defence, Home Affairs, Services Australia,
+ # ATO, etc.) is shared across every Australian Federal project in the repo.
+ # Per-project research targets all depend on ORG_RESEARCH so context flows
+ # organisation -> project.
+ - id: ORG_RESEARCH
+ skill: arckit:research
+ topic: "Target federal entity — Defence / Home Affairs / Services Australia / ATO / DTA strategy, mandate, structure, existing systems, current digital posture"
+ args: "{NAME} target-federal-entity strategy structure existing-systems"
+ output: { project: "000-global", type: RSCH, subfolder: research, multi_instance: true }
+ deps: []
+
+ - id: RESEARCH
+ skill: arckit:research
+ topic: "Australian Federal Government and DISP-supplier procurement landscape — vendors, build vs buy, AusTender / Digital Marketplace panels, comparable jurisdictions"
+ args: "{P} federal-disp-procurement"
+ output: { project: "{P}-{NAME}", type: RSCH, subfolder: research, multi_instance: true }
+ deps: [REQ, ORG_RESEARCH]
+
+ - id: AWS_RESEARCH
+ skill: arckit:aws-research
+ topic: "AWS Asia Pacific Sydney + Melbourne — services, IRAP-assessed services, PROTECTED options, sovereign hosting"
+ args: "{P} ap-southeast-2 ap-southeast-4"
+ output: { project: "{P}-{NAME}", type: AWRS, subfolder: research, multi_instance: true }
+ deps: [REQ, ORG_RESEARCH]
+
+ - id: AZURE_RESEARCH
+ skill: arckit:azure-research
+ topic: "Azure Australia East / Australia Southeast / Australia Central — services, IRAP PROTECTED, Microsoft Cloud for Sovereignty"
+ args: "{P} australia-east australia-southeast australia-central"
+ output: { project: "{P}-{NAME}", type: AZRS, subfolder: research, multi_instance: true }
+ deps: [REQ, ORG_RESEARCH]
+
+ - id: GCP_RESEARCH
+ skill: arckit:gcp-research
+ topic: "Google Cloud australia-southeast1 (Sydney) — services, IRAP-assessed offerings, residency"
+ args: "{P} australia-southeast1"
+ output: { project: "{P}-{NAME}", type: GCRS, subfolder: research, multi_instance: true }
+ deps: [REQ, ORG_RESEARCH]
+
+ - id: DATASCOUT
+ skill: arckit:datascout
+ topic: "Australian federal open-data — data.gov.au, AusTender, OAIC, ACSC publications, federal-entity APIs"
+ args: "{P}"
+ output: { project: "{P}-{NAME}", type: DSCT, subfolder: research, multi_instance: true }
+ deps: [REQ, ORG_RESEARCH]
+
+ # --- Security baseline (E8 → ISM) --------------------------------------
+ # E8 is the AU equivalent of UK Secure-by-Design (replaces arckit:secure
+ # in the uk-saas baseline). ISM extends E8 — produces the comprehensive
+ # 17-domain control set on top of the 8 mitigation strategies.
+ - id: AU_E8
+ skill: arckit:au-e8-posture
+ args: "{P}"
+ output: { project: "{P}-{NAME}", type: AUE8 }
+ deps: [REQ, STKE]
+
+ - id: AU_ISM
+ skill: arckit:au-ism-controls
+ args: "{P}"
+ output: { project: "{P}-{NAME}", type: AUISM }
+ deps: [REQ, AU_E8]
+
+ # --- Privacy + incident response (PIA → NDB) ---------------------------
+ # PIA is the AU equivalent of UK GDPR DPIA (replaces arckit:dpia in the
+ # uk-saas baseline). NDB is the operational incident-response playbook —
+ # depends on PIA because it requires the designated Privacy Officer and
+ # APP 11 control inventory from the PIA.
+ - id: AU_PIA
+ skill: arckit:au-pia
+ args: "{P}"
+ output: { project: "{P}-{NAME}", type: AUPIA }
+ deps: [REQ, STKE]
+
+ - id: AU_NDB
+ skill: arckit:au-ndb-playbook
+ args: "{P}"
+ output: { project: "{P}-{NAME}", type: AUNDB }
+ deps: [REQ, AU_PIA]
+
+ # --- Service + AI compliance (DSS, PSPF, AI assurance) -----------------
+ # DSS is the AU equivalent of UK TCoP (replaces arckit:tcop in the uk-saas
+ # baseline). PSPF Outcome 2 (information security) is instantiated by
+ # AU_ISM. AI assurance cross-references PIA (APP) and E8 (DLP).
+ - id: AU_DSS
+ skill: arckit:au-dss
+ args: "{P}"
+ output: { project: "{P}-{NAME}", type: AUDSS }
+ deps: [REQ, AU_E8, AU_PIA]
+
+ - id: AU_PSPF
+ skill: arckit:au-pspf
+ args: "{P}"
+ output: { project: "{P}-{NAME}", type: AUPSPF }
+ deps: [REQ, AU_ISM]
+
+ - id: AU_AI
+ skill: arckit:au-ai-assurance
+ args: "{P}"
+ output: { project: "{P}-{NAME}", type: AUAIA }
+ deps: [REQ, AU_PIA, AU_E8]
+
+ # --- DISP attestation (consolidation; depends on all prior AU artefacts)
+ # DISP self-attestation is the apex artefact for Defence-supplier scope.
+ # Consolidates the four DISP security domains (governance, personnel,
+ # physical, information & cyber) plus FOCI declaration plus supply chain
+ # plus annual board attestation — pulls evidence from E8, ISM, PIA, NDB,
+ # and PSPF. Run last in the AU-* stream.
+ - id: AU_DISP
+ skill: arckit:au-disp-attestation
+ args: "{P}"
+ output: { project: "{P}-{NAME}", type: AUDISP }
+ deps: [REQ, AU_E8, AU_ISM, AU_PIA, AU_NDB, AU_PSPF]
+
+ # --- ADRs (8 typical decision points per #424 design) ------------------
+ - id: ADR-001
+ skill: arckit:adr
+ topic: "Cloud platform and IRAP-assessed sovereign hosting (AWS ap-southeast-2 / Azure Australia / GCP australia-southeast1)"
+ args: "{P} {TOPIC}"
+ output: { project: "{P}-{NAME}", type: ADR, subfolder: decisions, multi_instance: true }
+ deps: [PRIN, REQ, AWS_RESEARCH, AZURE_RESEARCH, GCP_RESEARCH]
+
+ - id: ADR-002
+ skill: arckit:adr
+ topic: "Identity and access — myGovID / AGDIS (citizen + agency) vs Microsoft Entra ID (commercial)"
+ args: "{P} {TOPIC}"
+ output: { project: "{P}-{NAME}", type: ADR, subfolder: decisions, multi_instance: true }
+ deps: [PRIN, REQ]
+
+ - id: ADR-003
+ skill: arckit:adr
+ topic: "Data classification per PSPF taxonomy (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET / TOP SECRET) and ISM control applicability"
+ args: "{P} {TOPIC}"
+ output: { project: "{P}-{NAME}", type: ADR, subfolder: decisions, multi_instance: true }
+ deps: [PRIN, REQ, AU_ISM]
+
+ - id: ADR-004
+ skill: arckit:adr
+ topic: "AI / LLM provider — DTA AI Assurance Framework alignment, AI Accountable Officer designation, foundation-model selection and sovereignty"
+ args: "{P} {TOPIC}"
+ output: { project: "{P}-{NAME}", type: ADR, subfolder: decisions, multi_instance: true }
+ deps: [PRIN, REQ, AU_AI, AU_PIA]
+
+ - id: ADR-005
+ skill: arckit:adr
+ topic: "Logging and audit — ISM Domain 11 event logging, audit retention windows, SIEM/Sentinel integration, privileged-event monitoring"
+ args: "{P} {TOPIC}"
+ output: { project: "{P}-{NAME}", type: ADR, subfolder: decisions, multi_instance: true }
+ deps: [PRIN, REQ, AU_ISM]
+
+ - id: ADR-006
+ skill: arckit:adr
+ topic: "Deployment topology — PSPF physical-security zones, SOCI critical-asset scope (where applicable; see au-energy recipe in #440), cross-zone data flow controls"
+ args: "{P} {TOPIC}"
+ output: { project: "{P}-{NAME}", type: ADR, subfolder: decisions, multi_instance: true }
+ deps: [PRIN, REQ, AU_PSPF]
+
+ - id: ADR-007
+ skill: arckit:adr
+ topic: "Build vs buy — AusTender + Digital Marketplace, DTA panels (MAS, People, DTA), CPR Nov 2025 SME-only thresholds, IRAP-assessed-vendor preference"
+ args: "{P} {TOPIC}"
+ output: { project: "{P}-{NAME}", type: ADR, subfolder: decisions, multi_instance: true }
+ deps: [PRIN, REQ, RESEARCH]
+
+ - id: ADR-008
+ skill: arckit:adr
+ topic: "Open-source policy — supply-chain security obligations, export-control implications for Defence-relevant code, IP indemnification under CPR"
+ args: "{P} {TOPIC}"
+ output: { project: "{P}-{NAME}", type: ADR, subfolder: decisions, multi_instance: true }
+ deps: [PRIN, REQ]
+
+ # --- Cross-cutting + design --------------------------------------------
+ - id: DATA_MODEL
+ skill: arckit:data-model
+ args: "{P}"
+ output: { project: "{P}-{NAME}", type: DATA }
+ deps: [REQ, AU_PIA]
+
+ - id: HLD
+ skill: arckit:hld-review
+ args: "{P}"
+ output: { project: "{P}-{NAME}", type: HLDR }
+ deps: [REQ, "ADR-*", PRIN]
+
+ - id: RISK
+ skill: arckit:risk
+ args: "{P}"
+ output: { project: "{P}-{NAME}", type: RISK }
+ deps: [REQ, STKE, "ADR-*", PRIN, AU_E8, AU_PIA]
+
+ # --- Strategic outputs --------------------------------------------------
+ - id: STRATEGY
+ skill: arckit:strategy
+ args: ""
+ output: { project: "000-global", type: STRAT }
+ deps: [PRIN, STKE]
+
+ - id: WARDLEY
+ skill: arckit:wardley
+ args: "{NAME}"
+ output: { project: "000-global", type: WARD }
+ deps: [PRIN, REQ]
+
+ - id: SOBC
+ skill: arckit:sobc
+ args: "{P}"
+ output: { project: "{P}-{NAME}", type: SOBC }
+ deps: [REQ, STKE, RISK]
+
+ # --- Optional AI reference (UK Playbook cross-jurisdiction reference) --
+ - id: AIP
+ skill: arckit:ai-playbook
+ args: "{P} ai-mode=auto-detect-from-REQ-FRs"
+ output: { project: "{P}-{NAME}", type: AIPB }
+ deps: [REQ, AU_AI, AU_PIA, ADR-004]
+
+ # --- Synthesis (executive view of all AU-* artefacts) -----------------
+ - id: FRAMEWORK
+ skill: arckit:framework
+ args: "{P}"
+ output: { project: "{P}-{NAME}", type: FWRK }
+ deps:
+ [SOBC, RISK,
+ AU_E8, AU_ISM, AU_PIA, AU_NDB,
+ AU_DSS, AU_PSPF, AU_AI, AU_DISP]
+
+ # --- Cross-cutting traceability ---------------------------------------
+ - id: TRACEABILITY
+ skill: arckit:traceability
+ args: "{P}"
+ output: { project: "{P}-{NAME}", type: TRAC }
+ deps:
+ [REQ, STKE, "ADR-*", RISK, HLD,
+ AU_E8, AU_ISM, AU_PIA, AU_NDB,
+ AU_DSS, AU_PSPF, AU_AI, AU_DISP]
diff --git a/arckit-au/templates/au-ai-assurance-template.md b/arckit-au/templates/au-ai-assurance-template.md
new file mode 100644
index 00000000..b913706e
--- /dev/null
+++ b/arckit-au/templates/au-ai-assurance-template.md
@@ -0,0 +1,226 @@
+# AI Assurance Assessment
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:au-ai-assurance`
+
+## Document Control
+
+
+
+
+
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:au-ai-assurance` command | PENDING | PENDING |
+
+---
+
+## Executive Summary
+
+[Two to three paragraphs: AI system, deployment phase, regulatory frameworks in scope, overall assurance posture, key gaps.]
+
+---
+
+## 1. AI System Description
+
+| Field | Value |
+|-------|-------|
+| **System Name** | [System name] |
+| **Purpose** | [What the AI does and for whom] |
+| **AI Capability Type** | [Generative / Predictive / Decision-Support / Decision-Making / Agentic / Multi-Modal] |
+| **Deployment Phase** | [Research / Pilot / Production] |
+| **Foundation Model** | [Model + version + vendor — e.g., Claude Opus 4 / GPT-4 / Gemini 2.0 / open-source Llama 3] |
+| **Training-Data Sources** | [Public / proprietary / mixed; classification level] |
+| **Inference-Data Sources** | [User input / database / API / mixed] |
+| **Decisions Affecting Individuals** | [Yes — describe / No / Decision-support only] |
+| **Human-in-the-Loop Posture** | [Always / Threshold-triggered / None] |
+| **Population Affected** | [Internal users / customers / public / regulated cohort] |
+| **Assessment Date** | [YYYY-MM-DD] |
+| **AI Accountable Officer** | [Name + role] |
+
+---
+
+## 2. DTA Responsible AI Policy v2.0 Compliance
+
+| Accountability | Status | Evidence | Gap | Mitigation |
+|----------------|--------|----------|-----|------------|
+| 1. Accountability — designated AI accountable officer | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 2. Transparency — public AI use disclosure | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 3. Risk-based approach — AI risk assessment performed | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 4. Quality data + design integrity | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 5. Privacy + security (cross-ref PIA + ISM + E8) | [✅/⚠️/❌] | [Cite ARC-{P}-AUPIA, AUISM, AUE8] | [Gap] | [Action] |
+| 6. Human oversight + redress | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+
+---
+
+## 3. AU AI Ethics Principles Alignment
+
+| Principle | Status | Evidence | Gap | Mitigation |
+|-----------|--------|----------|-----|------------|
+| 1. Human, societal and environmental wellbeing | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 2. Human-centred values | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 3. Fairness | [✅/⚠️/❌] | [Cite Fairness Assessment §6] | [Gap] | [Action] |
+| 4. Privacy protection and security | [✅/⚠️/❌] | [Cite PIA + E8 + ISM] | [Gap] | [Action] |
+| 5. Reliability and safety | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 6. Transparency and explainability | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 7. Contestability | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 8. Accountability | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+
+---
+
+## 4. AU Essential AI Practices (AI6) Alignment
+
+National AI Centre (NAIC) operational practices for safe and responsible AI adoption — see [Guidance for AI Adoption: Foundations](https://www.ai.gov.au/staying-safe-and-responsible/essential-ai-practices/guidance-ai-adoption-foundations) and the deeper [Implementation Guidance](https://www.ai.gov.au/staying-safe-and-responsible/essential-ai-practices/guidance-ai-adoption-implementation-guidance) (each practice has Getting started + Next steps prompts on the source).
+
+| # | Practice | Status | Evidence | Gap | Action |
+|---|----------|--------|----------|-----|--------|
+| 1 | Decide who is accountable | [✅/⚠️/❌/N/A] | [Cite accountable AI officer designation; cross-ref DTA Responsible AI Policy section 2] | [Gap] | [Action] |
+| 2 | Understand impacts and plan accordingly | [✅/⚠️/❌/N/A] | [Cite impact assessment / PIA / DPIA where relevant] | [Gap] | [Action] |
+| 3 | Measure and manage risks | [✅/⚠️/❌/N/A] | [Cite RISK register entries; AI-specific risk methodology] | [Gap] | [Action] |
+| 4 | Share essential information | [✅/⚠️/❌/N/A] | [Cite transparency artefacts; AI use disclosure; user-facing notices] | [Gap] | [Action] |
+| 5 | Test and monitor | [✅/⚠️/❌/N/A] | [Cite testing methodology; monitoring dashboards; drift detection] | [Gap] | [Action] |
+| 6 | Maintain human control | [✅/⚠️/❌/N/A] | [Cite human-in-the-loop posture; intervention pathways; redress mechanism] | [Gap] | [Action] |
+
+**Cross-framework note**: AI6 practices align closely with the DTA Responsible AI Policy v2.0 six accountabilities (section 2 of this assessment) but are framed as adoption *practices* rather than policy *accountabilities*. Use both lenses; the differences in framing surface different evidence gaps.
+
+---
+
+## 5. ISO 42001 Readiness
+
+| Clause | Topic | Readiness | Notes |
+|--------|-------|-----------|-------|
+| 4 | Context of the organisation | [✅/⚠️/❌] | [Notes] |
+| 5 | Leadership | [✅/⚠️/❌] | [Notes] |
+| 6 | Planning | [✅/⚠️/❌] | [Notes] |
+| 7 | Support | [✅/⚠️/❌] | [Notes] |
+| 8 | Operation | [✅/⚠️/❌] | [Notes] |
+| 9 | Performance evaluation | [✅/⚠️/❌] | [Notes] |
+| 10 | Improvement | [✅/⚠️/❌] | [Notes] |
+
+**Certification position**: [Targeting certification / Internal alignment only / Not pursuing]
+
+---
+
+## 6. Privacy Act AI-Decision Notification (Dec 2026)
+
+| Aspect | Detail |
+|--------|--------|
+| **Substantially-automated decisions affecting individuals** | [Yes / No] |
+| **Notification mechanism** | [Implemented / Planned for Dec 2026 / Not applicable] |
+| **What individuals are told** | [Description of notification content] |
+| **Opt-out pathway** | [Yes — describe / Not applicable] |
+| **Cross-reference** | [ARC-{P}-AUPIA-v* APP 6 + APP 11] |
+
+---
+
+## 7. Fairness Assessment
+
+| Aspect | Detail |
+|--------|--------|
+| **Methodology** | [E.g., demographic parity, equalised odds, predictive parity] |
+| **Protected Attributes Tested** | [List — race, ethnicity, gender, age, disability, geographic, socioeconomic] |
+| **Test Population Segments** | [Description] |
+| **Fairness Metrics + Results** | [Metric: result, threshold, pass/fail per segment] |
+| **Residual Fairness Risks** | [Description] |
+| **Validated by** | [Internal / External fairness specialist] |
+
+---
+
+## 8. Security of AI Training + Inference Data
+
+| Aspect | Detail |
+|--------|--------|
+| **Training-Data Classification** | [UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED — note model can memorise PII] |
+| **Inference-Data Classification** | [Same scale; consider input + output PII risk] |
+| **Prompt-Injection Defences** | [Implemented / Planned] |
+| **Model-Extraction Defences** | [Implemented / Planned] |
+| **Training-Data Sanitisation** | [Process description] |
+| **E8 Cross-Reference** | [ARC-{P}-AUE8-v* — Strategies 1, 4, 11 most relevant] |
+| **ISM Cross-Reference** | [ARC-{P}-AUISM-v* Domain 9 + 12] |
+
+---
+
+## 9. Model Lifecycle Governance
+
+| Aspect | Detail |
+|--------|--------|
+| **Version Control** | [Tooling + cadence] |
+| **Change Management** | [Process for model updates] |
+| **Drift Detection** | [Metrics + alerting] |
+| **Retraining Cadence** | [Trigger conditions] |
+| **Retirement / Sunset Criteria** | [Description] |
+| **Audit Trail** | [Inference logs retention + scope] |
+
+---
+
+## 10. Vendor / Foundation-Model Disclosure
+
+| Aspect | Detail |
+|--------|--------|
+| **Vendor Name** | [E.g., Anthropic / OpenAI / Google] |
+| **Model + Version** | [E.g., Claude Opus 4.7] |
+| **Vendor AI Policy Compliance** | [Vendor's published AI policy alignment] |
+| **Training-Data Provenance** | [Disclosed / Partially disclosed / Not disclosed] |
+| **Inference Region** | [AU / US / EU / global] |
+| **IP / Copyright Position** | [Vendor indemnification stance; user-content rights] |
+| **Data-Use Policy** | [Whether prompts/completions used for vendor training] |
+
+---
+
+## 11. Recommendations
+
+### Quick Wins ( < 30 days)
+
+| # | Recommendation | Framework | Effort |
+|---|---------------|-----------|--------|
+| 1 | [Recommendation] | [DTA / AIEP / ISO42001 / PrivacyAct] | [Low/Medium] |
+
+### Short-Term (30–90 days)
+
+| # | Recommendation | Framework | Effort |
+|---|---------------|-----------|--------|
+| 1 | [Recommendation] | [Framework] | [Medium/High] |
+
+### Medium-Term (90–180 days)
+
+| # | Recommendation | Framework | Effort |
+|---|---------------|-----------|--------|
+| 1 | [Recommendation] | [Framework] | [High] |
+
+---
+
+## 12. External References
+
+### Document Register
+
+| Doc ID | Filename | Type | Source | Description |
+|--------|----------|------|--------|-------------|
+| DTAAI | DTA Responsible AI Policy v2.0 | Policy | digital.gov.au | Effective Dec 2025 |
+| AUAIEP | AU AI Ethics Principles | Framework | industry.gov.au | 8 voluntary principles |
+| AI6F | AU Essential AI Practices — Foundations | Operational Guidance | ai.gov.au (NAIC) | 6 essential practices for safe and responsible AI adoption |
+| AI6IG | AU Essential AI Practices — Implementation Guidance | Operational Guidance | ai.gov.au (NAIC) | Per-practice Getting started + Next steps prompts |
+| ISO42001 | ISO 42001:2023 (AS adopted Feb 2024) | Standard | standards.org.au | AI Management Systems |
+| PA88 | Privacy Act 1988 (Cth) | Legislation | legislation.gov.au | AI-decision notification Dec 2026 |
+| AUPIA | ARC-{P}-AUPIA-v* | ArcKit Artefact | projects/ | APP 6 + APP 11 cross-ref |
+| AUE8 | ARC-{P}-AUE8-v* | ArcKit Artefact | projects/ | E8 cross-ref |
+| AUISM | ARC-{P}-AUISM-v* | ArcKit Artefact | projects/ | ISM cross-ref |
+
+### Verification
+
+| Standard | URL | Verification Date |
+|----------|-----|-------------------|
+| DTA Responsible AI Policy | https://www.digital.gov.au/policy/ai/policy | [YYYY-MM-DD] |
+| AU AI Ethics Principles | https://www.industry.gov.au/publications/australias-artificial-intelligence-ethics-framework/australias-ai-ethics-principles | [YYYY-MM-DD] |
+| AU Essential AI Practices (AI6) — Foundations | https://www.ai.gov.au/staying-safe-and-responsible/essential-ai-practices/guidance-ai-adoption-foundations | [YYYY-MM-DD] |
+| AU Essential AI Practices — Implementation Guidance | https://www.ai.gov.au/staying-safe-and-responsible/essential-ai-practices/guidance-ai-adoption-implementation-guidance | [YYYY-MM-DD] |
+| Privacy Act 1988 | https://www.legislation.gov.au/Details/C2024C00301 | [YYYY-MM-DD] |
+
+---
+
+**Generated by**: ArcKit `/arckit:au-ai-assurance` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
diff --git a/arckit-au/templates/au-disp-attestation-template.md b/arckit-au/templates/au-disp-attestation-template.md
new file mode 100644
index 00000000..9bd1c0ee
--- /dev/null
+++ b/arckit-au/templates/au-disp-attestation-template.md
@@ -0,0 +1,283 @@
+# DISP Member Self-Attestation Pack
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:au-disp-attestation`
+
+## Document Control
+
+
+
+
+
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:au-disp-attestation` command | PENDING | PENDING |
+
+---
+
+## Executive Summary
+
+[Two to three paragraphs: organisation, DISP level sought, current attestation readiness, key gaps, target attestation date.]
+
+---
+
+## 1. Organisation Profile
+
+| Field | Value |
+|-------|-------|
+| **Legal Entity** | [Full name + ABN] |
+| **Trading Names** | [If applicable] |
+| **Primary Business Activity** | [e.g., Infrastructure Advisory] |
+| **Headcount** | [Total + by site] |
+| **Sites** | [Office locations + cloud-tenant region] |
+| **Defence Contracts in Scope** | [Active / pipeline contracts requiring DISP] |
+| **DISP Level Sought** | [Level 1 / 2 / 3] |
+| **Target Attestation Date** | [YYYY-MM-DD] |
+
+---
+
+## 2. DISP Level Sought
+
+| Aspect | Detail |
+|--------|--------|
+| **Level** | [Level 1 / 2 / 3] |
+| **Regulatory Driver** | [Specific contract / panel mandate / pipeline anticipation] |
+| **Justification** | [Why this level — types of Defence work, classified content handling] |
+| **Anticipated Defence Work** | [UNCLASSIFIED / OFFICIAL / OFFICIAL:Sensitive / PROTECTED — content categories handled] |
+
+---
+
+## 3. Security Officer Designation
+
+| Aspect | Detail |
+|--------|--------|
+| **Chief Security Officer (CSO)** | [Name + role title] |
+| **CSO Authority** | [Reporting line, signing authority, budget authority across the four security domains] |
+| **CSO Clearance Level** | [Baseline / NV1 / NV2 / PV] |
+| **Deputy CSO / Backup** | [Name + role + clearance] |
+| **CSO Contact** | [Email / phone for Defence engagement] |
+| **Vetting Status Verified** | [Yes / In progress / Not yet] |
+
+---
+
+## 4. Four Security Domains Coverage
+
+### Domain 1: Governance
+
+| Aspect | Detail |
+|--------|--------|
+| **Implementation Status** | [✅ / ⚠️ / ❌] |
+
+**Evidence**: [Security policy framework, risk management plan, audit cadence, incident management process, change control. Cite ISM applicability statement [ARC-{P}-AUISM] Domain 1 + 4]
+
+**Gaps**: [List]
+
+**Remediation**: [Actions, owners, target dates]
+
+**Sign-off**: [Accountable officer + date]
+
+---
+
+### Domain 2: Personnel Security
+
+| Aspect | Detail |
+|--------|--------|
+| **Implementation Status** | [✅ / ⚠️ / ❌] |
+| **Cleared Personnel Count** | [By clearance level — Baseline: n, NV1: n, NV2: n, PV: n] |
+| **Vetting Workflow** | [In-house / outsourced; turnaround time] |
+
+**Evidence**: [Clearance verification process, security awareness training programme, separation of duties model, off-boarding clearance debrief procedure, pre/post-leave briefing for cleared personnel. Cite ISM Domain 5]
+
+**Gaps**: [List]
+
+**Remediation**: [Actions, owners, target dates]
+
+**Sign-off**: [Accountable officer + date]
+
+---
+
+### Domain 3: Physical Security
+
+| Aspect | Detail |
+|--------|--------|
+| **Implementation Status** | [✅ / ⚠️ / ❌ / Inherited from IRAP cloud provider] |
+
+**Evidence**: [Facility access controls, ICT equipment lifecycle, secure media handling, equipment disposal. For cloud-only systems, cite cloud provider IRAP scope statement (Microsoft IRAP PROTECTED date / AWS IRAP date / GCP IRAP date) + customer-side responsibility implementation]
+
+**Gaps**: [Specific cloud-shared-responsibility gaps]
+
+**Remediation**: [Actions, owners, target dates]
+
+**Sign-off**: [Accountable officer + date]
+
+---
+
+### Domain 4: Information & Cyber Security
+
+| Aspect | Detail |
+|--------|--------|
+| **Implementation Status** | [✅ / ⚠️ / ❌] |
+| **E8 Posture Reference** | [ARC-{P}-AUE8-v*] |
+| **ISM Applicability Reference** | [ARC-{P}-AUISM-v*] |
+
+**Evidence**: [Defer to E8 posture artefact for E8 ML2 evidence; ISM applicability for additional controls. Specifically address: cryptography (Domain 12), gateway security (Domain 13), monitoring (Domain 11), BCP (cross-references E8 Strategy 8)]
+
+**Gaps**: [Beyond E8 ML2, list ISM-domain-specific gaps]
+
+**Remediation**: [Actions, owners, target dates]
+
+**Sign-off**: [Accountable officer + date]
+
+---
+
+## 5. Essential Eight ML2 Evidence Per Strategy
+
+(Summarised from `ARC-{P}-AUE8-v*` — refer to that artefact for evidence detail.)
+
+| # | Strategy | Current ML | ML2 Evidence | Gap to ML2 | Sign-off |
+|---|----------|-----------|--------------|------------|----------|
+| 1 | Application Control | [ML0–3] | [Evidence summary] | [Gap] | [Officer + date] |
+| 2 | Patch Applications | [ML0–3] | [Evidence summary] | [Gap] | [Officer + date] |
+| 3 | Configure MS Office Macros | [ML0–3] | [Evidence summary] | [Gap] | [Officer + date] |
+| 4 | User Application Hardening | [ML0–3] | [Evidence summary] | [Gap] | [Officer + date] |
+| 5 | Restrict Admin Privileges | [ML0–3] | [Evidence summary] | [Gap] | [Officer + date] |
+| 6 | Patch Operating Systems | [ML0–3] | [Evidence summary] | [Gap] | [Officer + date] |
+| 7 | Multi-Factor Authentication | [ML0–3] | [Evidence summary] | [Gap] | [Officer + date] |
+| 8 | Regular Backups | [ML0–3] | [Evidence summary] | [Gap] | [Officer + date] |
+
+---
+
+## 6. ISM Applicability Highlights
+
+(Summarised from `ARC-{P}-AUISM-v*`.)
+
+| ISM Domain | Material to DISP | Implementation | Gap |
+|------------|-------------------|----------------|-----|
+| 1. Cyber Security Governance | High | [✅/⚠️/❌] | [Gap] |
+| 3. Outsourced Services (MSP boundary) | High | [✅/⚠️/❌] | [Gap] |
+| 4. Security Documentation (SSP, SRMP) | High | [✅/⚠️/❌] | [Gap] |
+| 5. Personnel Security | High (DISP-specific) | [✅/⚠️/❌] | [Gap] |
+| 10. System Management (privileged access) | High | [✅/⚠️/❌] | [Gap] |
+| 11. System Monitoring (audit retention) | High | [✅/⚠️/❌] | [Gap] |
+| 12. Cryptography | Medium | [✅/⚠️/❌] | [Gap] |
+| 15. Cloud and IaaS Considerations | High (if cloud-only) | [✅/⚠️/❌ / Inherited] | [Gap] |
+
+---
+
+## 7. Foreign Ownership, Control or Influence (FOCI) Declaration
+
+| Aspect | Detail |
+|--------|--------|
+| **Foreign Ownership > 5%** | [Yes / No — if Yes: nation, percentage, entity] |
+| **Foreign Board Members** | [Number, nationalities, role authority] |
+| **Foreign Personnel with System Access** | [Number, nationalities, access scope] |
+| **Foreign Supply-Chain Dependencies** | [Description] |
+| **FOCI Mitigation Plan** | [If applicable, summary; cite supporting documentation] |
+
+---
+
+## 8. Supply Chain Security
+
+| Tier 1 Supplier | Service | Attestation Held | Last Reviewed | Cleared for DISP Level |
+|-----------------|---------|------------------|---------------|------------------------|
+| [MSP name] | M365 admin | [SOC 2 / ISO 27001 / IRAP] | [YYYY-MM-DD] | [Level 1/2/3] |
+| [Cloud Provider] | IaaS/PaaS | [IRAP PROTECTED date] | [YYYY-MM-DD] | [Level 1/2/3] |
+| [SaaS Provider] | [Service] | [Attestation] | [YYYY-MM-DD] | [Level 1/2/3] |
+
+**Supply-Chain Risk Management Process**: [Describe vendor onboarding, ongoing review, exit procedures]
+
+---
+
+## 9. Incident Response & Reporting
+
+| Aspect | Detail |
+|--------|--------|
+| **Incident Response Plan** | [Document reference] |
+| **24-Hour Defence Notification Capability** | [✅ / ⚠️ / ❌] |
+| **OAIC NDB Scheme Integration** | [✅ / ⚠️ / ❌; cite NDB playbook ARC-{P}-AUNDB-v* if available] |
+| **Last Tabletop / Live Exercise** | [YYYY-MM-DD] |
+| **Lessons Learned Process** | [Description] |
+
+---
+
+## 10. Security Awareness Training
+
+| Aspect | Detail |
+|--------|--------|
+| **Programme Name** | [E.g., DISP-aligned cyber awareness in ELMO] |
+| **Modules** | [Mandatory / role-specific / clearance-holder additional briefings] |
+| **Completion Rate (last 12mo)** | [%] |
+| **Refresher Cadence** | [Annual / event-driven] |
+| **Cleared-Personnel Briefings** | [Pre-leave / post-leave / change-of-role] |
+
+---
+
+## 11. Annual Self-Audit Plan
+
+| Aspect | Detail |
+|--------|--------|
+| **Scope** | [Four domains coverage; specific control sample] |
+| **Methodology** | [Self-assessment + evidence review + sample testing] |
+| **Frequency** | [Annual minimum; on-major-change additional] |
+| **Evidence Retention** | [Years] |
+| **Last Audit Date** | [YYYY-MM-DD] |
+| **Next Scheduled** | [YYYY-MM-DD] |
+
+---
+
+## 12. Attestation Statement
+
+I/we attest that the information in this pack is accurate to the best of my/our knowledge as at the date below. We commit to maintaining the security posture described, completing the listed remediation actions by their target dates, and notifying Defence promptly of any material change to the four security domains.
+
+| Role | Name | Signature | Date |
+|------|------|-----------|------|
+| Chief Security Officer | | | |
+| Director / Managing Director | | | |
+| Date of Attestation | | | [YYYY-MM-DD] |
+| Re-Attestation Due | | | [YYYY-MM-DD] |
+
+---
+
+## 13. External References
+
+### Upstream ArcKit Evidence
+
+| Artefact | Doc-ID | Cross-Reference |
+|----------|--------|-----------------|
+| ASD Essential Eight Posture | `ARC-{P}-AUE8-v*` | E8 maturity evidence per Strategy in section 6 |
+| ASD ISM Applicability | `ARC-{P}-AUISM-v*` | ISM control coverage per domain in section 6 |
+| Privacy Impact Assessment | `ARC-{P}-AUPIA-v*` | APP 11 personal-information protection evidence |
+| Notifiable Data Breach Playbook | `ARC-{P}-AUNDB-v*` | Incident-response capability evidence |
+| PSPF Compliance Assessment | `ARC-{P}-AUPSPF-v*` | Physical / personnel / governance security evidence |
+| DTA Digital Service Standard | `ARC-{P}-AUDSS-v*` | Service-design assurance evidence (where applicable) |
+| AI Assurance Assessment | `ARC-{P}-AUAIA-v*` | AI-system risk-control evidence (where applicable) |
+
+### Document Register
+
+| Doc ID | Filename | Type | Source | Description |
+|--------|----------|------|--------|-------------|
+| DISP | DISP Membership Pack | Standard | defence.gov.au | DISP application + evidence framework — edition [DATE] |
+| AUE8 | ARC-{P}-AUE8-v* | ArcKit Artefact | projects/ | Essential Eight evidence |
+| AUISM | ARC-{P}-AUISM-v* | ArcKit Artefact | projects/ | ISM applicability evidence |
+| AUPIA | ARC-{P}-AUPIA-v* | ArcKit Artefact | projects/ | Privacy Act + APP 11 evidence |
+| AUNDB | ARC-{P}-AUNDB-v* | ArcKit Artefact | projects/ | NDB playbook evidence (if available) |
+| ASDISM | ASD Information Security Manual | Standard | cyber.gov.au | Underlying control framework |
+| E8MM | ASD Essential Eight Maturity Model | Standard | cyber.gov.au | E8 ML2 minimum reference |
+
+### Verification
+
+| Standard | URL | Verification Date |
+|----------|-----|-------------------|
+| DISP | https://www.defence.gov.au/business-industry/programs/defence-industry-security-program | [YYYY-MM-DD] |
+| ASD ISM | https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism | [YYYY-MM-DD] |
+| ASD E8 | https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight/essential-eight-maturity-model | [YYYY-MM-DD] |
+
+---
+
+**Generated by**: ArcKit `/arckit:au-disp-attestation` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
diff --git a/arckit-au/templates/au-dss-template.md b/arckit-au/templates/au-dss-template.md
new file mode 100644
index 00000000..488b9eb2
--- /dev/null
+++ b/arckit-au/templates/au-dss-template.md
@@ -0,0 +1,283 @@
+# DTA Digital Service Standard Compliance Assessment
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:au-dss`
+
+## Document Control
+
+
+
+
+
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:au-dss` command | PENDING | PENDING |
+
+---
+
+## Executive Summary
+
+[Two to three paragraphs: service under assessment, current compliance posture against the 13 criteria, key gaps, and assessment readiness for the current phase.]
+
+---
+
+## Service Context
+
+| Field | Value |
+|-------|-------|
+| **Service Name** | [Service name] |
+| **Owning Agency** | [Department / Agency] |
+| **Service Phase** | [Discovery / Alpha / Beta / Live] |
+| **User Base** | [Public-facing / Internal / Both] |
+| **Annual Transactions** | [Volume or estimate] |
+| **Assessment Date** | [YYYY-MM-DD] |
+| **Assessor** | [Name and role] |
+
+---
+
+## Digital Service Standard Assessment
+
+### Criterion 1: Understand User Needs
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [User research conducted, methods used, findings documented, personas created]
+
+**Gaps**: [Missing research, unvalidated assumptions, user groups not covered]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 2: Have a Multidisciplinary Team
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [Team composition, DDaT roles covered, decision-making authority]
+
+**Gaps**: [Missing roles, capability gaps, external dependencies]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 3: Agile and User-Centred Process
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [Delivery methodology, sprint cadence, user feedback integration, iteration evidence]
+
+**Gaps**: [Waterfall dependencies, missing feedback loops]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 4: Understand Tools and Systems
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [Technology landscape mapped, integration points, legacy dependencies, vendor dependencies]
+
+**Gaps**: [Unmapped systems, undocumented integrations]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 5: Make It Secure
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+| **E8 Posture Reference** | [ARC-{P}-AUE8-v{V} if available] |
+
+**Evidence**: [E8 maturity level, ISM controls, threat assessment, incident response plan, IRAP status]
+
+**Gaps**: [E8 strategies below target, missing controls, untested DR]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 6: Consistent and Responsive Design
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [Design system used, responsive breakpoints, device testing coverage, brand compliance]
+
+**Gaps**: [Missing breakpoints, untested devices, inconsistent components]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 7: Protect Users' Privacy
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+| **PIA Reference** | [ARC-{P}-AUPIA-v{V} if available] |
+
+**Evidence**: [PIA completed, APP compliance, data minimisation, consent mechanisms, OAIC notification]
+
+**Gaps**: [Missing PIA, non-compliant data handling, consent gaps]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 8: Make Source Code Open
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [Code repository, licence, open-source strategy, exemption justification if not open]
+
+**Gaps**: [Proprietary dependencies, missing licence, no public repo]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 9: Make It Accessible
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+| **WCAG Level** | [2.2 AA / 2.1 AA / Below AA] |
+
+**Evidence**: [Accessibility testing, assistive technology coverage, accessibility statement, audit results]
+
+**Gaps**: [WCAG failures, untested assistive technologies, missing accessibility statement]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 10: Test the Service
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [Test strategy, test types (unit, integration, UAT, accessibility, performance, security), coverage metrics]
+
+**Gaps**: [Missing test types, low coverage, no performance testing]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 11: Measure Performance
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [KPIs defined, measurement tools, reporting cadence, baseline metrics]
+
+**Gaps**: [Missing KPIs, no measurement tooling, no baseline]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 12: Don't Forget the Non-Digital Experience
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [Assisted digital channel, phone support, in-person options, channel integration]
+
+**Gaps**: [No assisted digital, missing channels, disconnected experience]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 13: Encourage Everyone to Use the Digital Service
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [Channel shift strategy, take-up targets, migration plan from legacy channels]
+
+**Gaps**: [No channel shift plan, no take-up measurement]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+## Compliance Summary
+
+| # | Criterion | Status | Gap Count |
+|---|----------|--------|-----------|
+| 1 | Understand user needs | [✅/⚠️/❌/N/A] | [n] |
+| 2 | Have a multidisciplinary team | [✅/⚠️/❌/N/A] | [n] |
+| 3 | Agile and user-centred process | [✅/⚠️/❌/N/A] | [n] |
+| 4 | Understand tools and systems | [✅/⚠️/❌/N/A] | [n] |
+| 5 | Make it secure | [✅/⚠️/❌/N/A] | [n] |
+| 6 | Consistent and responsive design | [✅/⚠️/❌/N/A] | [n] |
+| 7 | Protect users' privacy | [✅/⚠️/❌/N/A] | [n] |
+| 8 | Make source code open | [✅/⚠️/❌/N/A] | [n] |
+| 9 | Make it accessible | [✅/⚠️/❌/N/A] | [n] |
+| 10 | Test the service | [✅/⚠️/❌/N/A] | [n] |
+| 11 | Measure performance | [✅/⚠️/❌/N/A] | [n] |
+| 12 | Non-digital experience | [✅/⚠️/❌/N/A] | [n] |
+| 13 | Encourage digital use | [✅/⚠️/❌/N/A] | [n] |
+
+**Overall**: [n] Met | [n] Partially Met | [n] Not Met | [n] N/A
+
+---
+
+## Assessment Readiness
+
+| Risk | Criterion | Impact | Mitigation |
+|------|----------|--------|-----------|
+| [Risk description] | [#] | [High/Medium/Low] | [Mitigation action] |
+
+---
+
+## External References
+
+### Document Register
+
+| Doc ID | Filename | Type | Source Location | Description |
+|--------|----------|------|-----------------|-------------|
+| DSS | DTA Digital Service Standard | Standard | dta.gov.au | Primary assessment framework |
+
+### Citations
+
+| Citation ID | Doc ID | Page/Section | Category | Quoted Passage |
+|-------------|--------|--------------|----------|----------------|
+| — | — | — | — | — |
+
+### Unreferenced Documents
+
+| Filename | Source Location | Reason |
+|----------|-----------------|--------|
+| — | — | — |
+
+---
+
+**Generated by**: ArcKit `/arckit:au-dss` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
diff --git a/arckit-au/templates/au-e8-posture-template.md b/arckit-au/templates/au-e8-posture-template.md
new file mode 100644
index 00000000..3466381e
--- /dev/null
+++ b/arckit-au/templates/au-e8-posture-template.md
@@ -0,0 +1,362 @@
+# ASD Essential Eight Maturity Posture Assessment
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:au-e8-posture`
+
+## Document Control
+
+
+
+
+
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:au-e8-posture` command | PENDING | PENDING |
+
+---
+
+## Executive Summary
+
+[Two to three paragraphs: system under assessment, current overall E8 maturity posture, highest-priority gaps, and DISP compliance position if applicable.]
+
+---
+
+## System Context
+
+| Field | Value |
+|-------|-------|
+| **System Name** | [System name] |
+| **Classification** | [UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET] |
+| **Deployment Model** | [Cloud (SaaS/PaaS/IaaS) / On-Premise / Hybrid] |
+| **IRAP Assessment Status** | [Assessed / In Progress / Not Required / Not Started] |
+| **Cloud Provider(s)** | [AWS / Azure / GCP / Other — with IRAP status] |
+| **Data Sovereignty** | [All data in AU / Some offshore / Sovereign cloud] |
+| **DISP Member** | [Yes (Level 1/2/3) / No / Not Applicable] |
+| **Assessment Date** | [YYYY-MM-DD] |
+| **Assessor** | [Name and role] |
+
+---
+
+## Essential Eight Maturity Assessment
+
+### 1. Application Control
+
+| Aspect | Detail |
+|--------|--------|
+| **Current Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Target Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Regulatory Driver** | [DISP ML2 / PSPF / Contractual / Risk appetite] |
+
+**Evidence of Current State**:
+
+[Description of current application control measures — whitelisting tools, policy enforcement, coverage scope.]
+
+**Gap Analysis**:
+
+| ML Level | Sub-Control | Status | Gap Description |
+|----------|------------|--------|-----------------|
+| ML1 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML2 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML3 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+
+**Remediation Actions**:
+
+| Action | Owner | Target Date | Priority |
+|--------|-------|-------------|----------|
+| [Action description] | [Role/Name] | [YYYY-MM-DD] | [Critical / High / Medium / Low] |
+
+---
+
+### 2. Patch Applications
+
+| Aspect | Detail |
+|--------|--------|
+| **Current Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Target Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Regulatory Driver** | [DISP ML2 / PSPF / Contractual / Risk appetite] |
+
+**Evidence of Current State**:
+
+[Description of patching process — tools, SLAs, coverage, internet-facing vs internal.]
+
+**Gap Analysis**:
+
+| ML Level | Sub-Control | Status | Gap Description |
+|----------|------------|--------|-----------------|
+| ML1 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML2 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML3 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+
+**Remediation Actions**:
+
+| Action | Owner | Target Date | Priority |
+|--------|-------|-------------|----------|
+| [Action description] | [Role/Name] | [YYYY-MM-DD] | [Critical / High / Medium / Low] |
+
+---
+
+### 3. Configure Microsoft Office Macro Settings
+
+| Aspect | Detail |
+|--------|--------|
+| **Current Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Target Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Regulatory Driver** | [DISP ML2 / PSPF / Contractual / Risk appetite] |
+
+**Evidence of Current State**:
+
+[Description of macro policy — Group Policy settings, trusted locations, signing requirements.]
+
+**Gap Analysis**:
+
+| ML Level | Sub-Control | Status | Gap Description |
+|----------|------------|--------|-----------------|
+| ML1 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML2 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML3 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+
+**Remediation Actions**:
+
+| Action | Owner | Target Date | Priority |
+|--------|-------|-------------|----------|
+| [Action description] | [Role/Name] | [YYYY-MM-DD] | [Critical / High / Medium / Low] |
+
+---
+
+### 4. User Application Hardening
+
+| Aspect | Detail |
+|--------|--------|
+| **Current Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Target Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Regulatory Driver** | [DISP ML2 / PSPF / Contractual / Risk appetite] |
+
+**Evidence of Current State**:
+
+[Description of browser hardening, email client configuration, Office settings, ad-blocking, Java/Flash removal.]
+
+**Gap Analysis**:
+
+| ML Level | Sub-Control | Status | Gap Description |
+|----------|------------|--------|-----------------|
+| ML1 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML2 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML3 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+
+**Remediation Actions**:
+
+| Action | Owner | Target Date | Priority |
+|--------|-------|-------------|----------|
+| [Action description] | [Role/Name] | [YYYY-MM-DD] | [Critical / High / Medium / Low] |
+
+---
+
+### 5. Restrict Administrative Privileges
+
+| Aspect | Detail |
+|--------|--------|
+| **Current Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Target Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Regulatory Driver** | [DISP ML2 / PSPF / Contractual / Risk appetite] |
+
+**Evidence of Current State**:
+
+[Description of admin account management — PAM tools, JIT access, separation of duties, regular review cadence.]
+
+**Gap Analysis**:
+
+| ML Level | Sub-Control | Status | Gap Description |
+|----------|------------|--------|-----------------|
+| ML1 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML2 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML3 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+
+**Remediation Actions**:
+
+| Action | Owner | Target Date | Priority |
+|--------|-------|-------------|----------|
+| [Action description] | [Role/Name] | [YYYY-MM-DD] | [Critical / High / Medium / Low] |
+
+---
+
+### 6. Patch Operating Systems
+
+| Aspect | Detail |
+|--------|--------|
+| **Current Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Target Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Regulatory Driver** | [DISP ML2 / PSPF / Contractual / Risk appetite] |
+
+**Evidence of Current State**:
+
+[Description of OS patching — WSUS/SCCM/Intune, Linux patching, patching SLAs, unsupported OS inventory.]
+
+**Gap Analysis**:
+
+| ML Level | Sub-Control | Status | Gap Description |
+|----------|------------|--------|-----------------|
+| ML1 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML2 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML3 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+
+**Remediation Actions**:
+
+| Action | Owner | Target Date | Priority |
+|--------|-------|-------------|----------|
+| [Action description] | [Role/Name] | [YYYY-MM-DD] | [Critical / High / Medium / Low] |
+
+---
+
+### 7. Multi-Factor Authentication
+
+| Aspect | Detail |
+|--------|--------|
+| **Current Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Target Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Regulatory Driver** | [DISP ML2 / PSPF / Contractual / Risk appetite] |
+
+**Evidence of Current State**:
+
+[Description of MFA coverage — identity provider, MFA methods (FIDO2, authenticator app, SMS), coverage scope (VPN, email, admin portals, cloud services).]
+
+**Gap Analysis**:
+
+| ML Level | Sub-Control | Status | Gap Description |
+|----------|------------|--------|-----------------|
+| ML1 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML2 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML3 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+
+**Remediation Actions**:
+
+| Action | Owner | Target Date | Priority |
+|--------|-------|-------------|----------|
+| [Action description] | [Role/Name] | [YYYY-MM-DD] | [Critical / High / Medium / Low] |
+
+---
+
+### 8. Regular Backups
+
+| Aspect | Detail |
+|--------|--------|
+| **Current Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Target Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Regulatory Driver** | [DISP ML2 / PSPF / Contractual / Risk appetite] |
+
+**Evidence of Current State**:
+
+[Description of backup strategy — RPO/RTO, backup scope, offline/immutable copies, restore testing cadence.]
+
+**Gap Analysis**:
+
+| ML Level | Sub-Control | Status | Gap Description |
+|----------|------------|--------|-----------------|
+| ML1 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML2 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML3 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+
+**Remediation Actions**:
+
+| Action | Owner | Target Date | Priority |
+|--------|-------|-------------|----------|
+| [Action description] | [Role/Name] | [YYYY-MM-DD] | [Critical / High / Medium / Low] |
+
+---
+
+## Maturity Summary Matrix
+
+| # | Mitigation Strategy | Current ML | Target ML | Gap Count | Priority |
+|---|-------------------|-----------|-----------|-----------|----------|
+| 1 | Application Control | [ML0–3] | [ML0–3] | [n] | [Critical/High/Medium/Low] |
+| 2 | Patch Applications | [ML0–3] | [ML0–3] | [n] | [Critical/High/Medium/Low] |
+| 3 | Configure MS Office Macros | [ML0–3] | [ML0–3] | [n] | [Critical/High/Medium/Low] |
+| 4 | User Application Hardening | [ML0–3] | [ML0–3] | [n] | [Critical/High/Medium/Low] |
+| 5 | Restrict Admin Privileges | [ML0–3] | [ML0–3] | [n] | [Critical/High/Medium/Low] |
+| 6 | Patch Operating Systems | [ML0–3] | [ML0–3] | [n] | [Critical/High/Medium/Low] |
+| 7 | Multi-Factor Authentication | [ML0–3] | [ML0–3] | [n] | [Critical/High/Medium/Low] |
+| 8 | Regular Backups | [ML0–3] | [ML0–3] | [n] | [Critical/High/Medium/Low] |
+
+**Overall Posture**: [ML0 / ML1 / ML2 / ML3] (lowest common level across all eight strategies)
+
+---
+
+## DISP Compliance Position
+
+| Assessment | Result |
+|-----------|--------|
+| **DISP Member** | [Yes / No / Not Applicable] |
+| **Required Level** | ML2 (all eight strategies) |
+| **Current Compliance** | [Compliant / Non-Compliant — n strategies below ML2] |
+| **Strategies Below ML2** | [List strategies and current ML] |
+| **Estimated Remediation Timeline** | [Timeframe to achieve ML2 compliance] |
+
+---
+
+## Cloud-Specific Considerations
+
+| E8 Strategy | Shared Responsibility Model | Notes |
+|------------|---------------------------|-------|
+| Application Control | [Customer / Shared / Provider] | [Cloud-specific notes] |
+| Patch Applications | [Customer / Shared / Provider] | [Cloud-specific notes] |
+| Configure MS Office Macros | [Customer / Shared / Provider] | [Cloud-specific notes] |
+| User Application Hardening | [Customer / Shared / Provider] | [Cloud-specific notes] |
+| Restrict Admin Privileges | [Customer / Shared / Provider] | [Cloud-specific notes] |
+| Patch Operating Systems | [Customer / Shared / Provider] | [Cloud-specific notes] |
+| Multi-Factor Authentication | [Customer / Shared / Provider] | [Cloud-specific notes] |
+| Regular Backups | [Customer / Shared / Provider] | [Cloud-specific notes] |
+
+---
+
+## Recommendations
+
+### Quick Wins ( < 30 days)
+
+| # | Recommendation | E8 Strategy | Target ML | Effort |
+|---|---------------|------------|-----------|--------|
+| 1 | [Recommendation] | [Strategy] | [ML] | [Low/Medium] |
+
+### Short-Term (30–90 days)
+
+| # | Recommendation | E8 Strategy | Target ML | Effort |
+|---|---------------|------------|-----------|--------|
+| 1 | [Recommendation] | [Strategy] | [ML] | [Medium/High] |
+
+### Medium-Term (90–180 days)
+
+| # | Recommendation | E8 Strategy | Target ML | Effort |
+|---|---------------|------------|-----------|--------|
+| 1 | [Recommendation] | [Strategy] | [ML] | [High] |
+
+---
+
+## External References
+
+> This section provides traceability from generated content back to source documents.
+
+### Document Register
+
+| Doc ID | Filename | Type | Source Location | Description |
+|--------|----------|------|-----------------|-------------|
+| E8MM | ASD Essential Eight Maturity Model | Standard | cyber.gov.au | Primary assessment framework |
+
+### Citations
+
+| Citation ID | Doc ID | Page/Section | Category | Quoted Passage |
+|-------------|--------|--------------|----------|----------------|
+| — | — | — | — | — |
+
+### Unreferenced Documents
+
+| Filename | Source Location | Reason |
+|----------|-----------------|--------|
+| — | — | — |
+
+---
+
+**Generated by**: ArcKit `/arckit:au-e8-posture` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
diff --git a/arckit-au/templates/au-ism-controls-template.md b/arckit-au/templates/au-ism-controls-template.md
new file mode 100644
index 00000000..90731838
--- /dev/null
+++ b/arckit-au/templates/au-ism-controls-template.md
@@ -0,0 +1,443 @@
+# ASD Information Security Manual (ISM) Control Applicability Statement
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:au-ism-controls`
+
+## Document Control
+
+
+
+
+
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:au-ism-controls` command | PENDING | PENDING |
+
+---
+
+## Executive Summary
+
+[Two to three paragraphs: system under assessment, classification, ISM edition used, overall control applicability posture, key gaps, and IRAP / DISP cross-reference position.]
+
+---
+
+## System Context
+
+| Field | Value |
+|-------|-------|
+| **System Name** | [System name] |
+| **Classification** | [UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET] |
+| **Deployment Model** | [Cloud (SaaS/PaaS/IaaS) / On-Premise / Hybrid] |
+| **IRAP Assessment Status** | [Assessed (date) / In Progress / Not Required / Not Started] |
+| **IRAP Scope** | [What's in scope / Cloud provider's IRAP boundary referenced] |
+| **DISP Member** | [Yes (Level 1/2/3) / In Progress / No] |
+| **ISM Edition Used** | [e.g., March 2026 — verification date] |
+| **Sovereignty** | [All data in AU / Some offshore / Sovereign cloud] |
+| **Assessment Date** | [YYYY-MM-DD] |
+| **Assessor** | [Name and role] |
+
+---
+
+## Control Domain Applicability Matrix
+
+ISM controls are organised into 17 domains. Applicability depends on the system's classification — controls flagged for the system's *highest classification of processed information* apply.
+
+| # | Domain | Applies | Implementation | Notes |
+|---|--------|---------|----------------|-------|
+| 1 | Cyber Security Governance | [Y/N] | [✅/⚠️/❌] | [Notes] |
+| 2 | Cyber Security Incidents | [Y/N] | [✅/⚠️/❌] | [Cross-ref NDB playbook] |
+| 3 | Outsourced Services | [Y/N] | [✅/⚠️/❌] | [MSP boundary, supply chain] |
+| 4 | Security Documentation | [Y/N] | [✅/⚠️/❌] | [SSP, SRMP] |
+| 5 | Personnel Security | [Y/N] | [✅/⚠️/❌] | [Clearance levels] |
+| 6 | Physical Security | [Y/N] | [✅/⚠️/❌] | [Cloud-only systems may N/A this in part] |
+| 7 | Communications Infrastructure | [Y/N] | [✅/⚠️/❌] | [Often N/A for pure-cloud] |
+| 8 | ICT Equipment Security | [Y/N] | [✅/⚠️/❌] | [Endpoint lifecycle] |
+| 9 | System Hardening | [Y/N] | [✅/⚠️/❌] | [Cross-ref E8] |
+| 10 | System Management | [Y/N] | [✅/⚠️/❌] | [Admin governance, vuln mgmt] |
+| 11 | System Monitoring | [Y/N] | [✅/⚠️/❌] | [SIEM, audit retention] |
+| 12 | Cryptography | [Y/N] | [✅/⚠️/❌] | [ASD-approved algorithms, key mgmt] |
+| 13 | Gateway Security | [Y/N] | [✅/⚠️/❌] | [Content filtering, DLP] |
+| 14 | Data Transfer | [Y/N] | [✅/⚠️/❌] | [Cross-domain, cross-system] |
+| 15 | Cloud and IaaS Considerations | [Y/N] | [✅/⚠️/❌] | [Inherit from IRAP cloud provider where applicable] |
+| 16 | Working-Off-Site Security | [Y/N] | [✅/⚠️/❌] | [Remote work, mobile, BYOD] |
+| 17 | Evaluation Activities | [Y/N] | [✅/⚠️/❌] | [Common Criteria, FIPS] |
+
+---
+
+## Per-Domain Control Applicability Assessment
+
+### Domain 1: Cyber Security Governance
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List ISM control identifiers — e.g., ISM-0027, ISM-0714, ISM-1567] |
+
+**Evidence**: [Security risk management plan, security documentation, change management process, accountable security officer]
+
+**Gaps**: [Specific control IDs not implemented + gap description]
+
+**Remediation**: [Actions, owners, target dates]
+
+**Compensating Controls**: [If any]
+
+---
+
+### Domain 2: Cyber Security Incidents
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List ISM control identifiers] |
+
+**Evidence**: [Incident response plan, NDB playbook reference (`ARC-{P}-AUNDB-v*`), 24/7 monitoring posture]
+
+**Gaps**: [Specific control IDs not implemented]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 3: Outsourced Services
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes — MSP / cloud providers in scope] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+
+**Evidence**: [MSP contractual security flow-down, supply-chain attestation review, IRAP-assessed cloud service inheritance, MSP-held admin role inventory]
+
+**Gaps**: [Specific control IDs not implemented]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 4: Security Documentation
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+
+**Evidence**: [System Security Plan (SSP), Security Risk Management Plan (SRMP), Continuous Monitoring Plan, Incident Response Plan]
+
+**Gaps**: [Specific control IDs not implemented]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 5: Personnel Security
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List — varies by classification + DISP membership] |
+
+**Evidence**: [Security clearance verification process, security awareness training, separation of duties, foreign national handling]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 6: Physical Security
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / Partial — cloud-only systems may inherit from cloud provider's IRAP] |
+| **Implementation** | [✅ / ⚠️ / ❌ / Inherited from IRAP cloud provider] |
+
+**Evidence**: [Facility access controls, ICT equipment lifecycle, media handling]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 7: Communications Infrastructure
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Often N/A for pure-cloud systems] |
+| **Implementation** | [Inherited / N/A] |
+
+**Notes**: For pure-cloud systems (SaaS/PaaS/IaaS), this domain typically inherits from the cloud provider's IRAP attestation.
+
+---
+
+### Domain 8: ICT Equipment Security
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes for endpoint estate] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+
+**Evidence**: [Endpoint hardening, secure media handling, sanitisation procedures, equipment disposal]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 9: System Hardening
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+| **E8 Cross-Reference** | [ARC-{P}-AUE8-v*] |
+
+**Evidence**: [Operating system hardening, application hardening, authentication mechanisms, network security] — **defer to E8 posture artefact for E8-mapped controls**.
+
+**Gaps**: [Beyond-E8 ISM control gaps]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 10: System Management
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+
+**Evidence**: [Privileged access management, vulnerability management, change management, configuration management]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 11: System Monitoring
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+
+**Evidence**: [Event logging, audit retention (typically 7 years for OFFICIAL+), SIEM integration, security metrics]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 12: Cryptography
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes for any encrypted data] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+
+**Evidence**: [ASD-Approved Cryptographic Algorithms (AACA) used; ASD-Approved Cryptographic Protocols (AACP) used; key lifecycle management; HSM use]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 13: Gateway Security
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes for systems with internet boundary] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+
+**Evidence**: [Gateway architecture, content filtering, DLP, certificate management]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 14: Data Transfer
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes if cross-domain or cross-system data movement] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+
+**Evidence**: [Cross-domain solutions, secure file transfer, data import/export controls, sanitisation at boundary]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 15: Cloud and IaaS Considerations
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes for any cloud-hosted system] |
+| **Implementation** | [✅ / ⚠️ / ❌ / Inherited from IRAP cloud provider] |
+| **Applicable Controls** | [List] |
+| **IRAP Cloud Provider Inheritance** | [Microsoft Azure (IRAP PROTECTED date), AWS (IRAP date), GCP (IRAP date) — list applicable] |
+
+**Evidence**: [Cloud provider IRAP scope statements, customer-side responsibility implementation, sovereignty configuration]
+
+**Gaps**: [Specific control IDs not satisfied by inheritance]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 16: Working-Off-Site Security
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes if remote work supported] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+
+**Evidence**: [Remote work policy, BYOD posture, mobile device management, secure remote access]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 17: Evaluation Activities
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes if Common Criteria / FIPS-evaluated products in scope] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+
+**Evidence**: [Common Criteria / FIPS 140-2 product use, evaluated configurations]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+## ISM-to-E8 Cross-Reference
+
+| E8 Strategy | Primary ISM Domain(s) | Notes |
+|-------------|-----------------------|-------|
+| Application Control | 9 (System Hardening), 13 (Gateway Security) | App allowlist + boundary control |
+| Patch Applications | 9, 10 (System Management) | Vulnerability + patch management |
+| Configure MS Office Macro Settings | 9 | Application hardening sub-control |
+| User Application Hardening | 9 | Endpoint application configuration |
+| Restrict Administrative Privileges | 5 (Personnel), 10 (System Management) | Privileged access mgmt |
+| Patch Operating Systems | 9, 10 | OS-level patching |
+| Multi-Factor Authentication | 9, 12 (Cryptography) | Authentication mechanism |
+| Regular Backups | 4 (Security Documentation), 11 (System Monitoring), 17 (Working-Off-Site security for offline backups) | BCP + restore testing |
+
+---
+
+## Compliance Summary
+
+| Domain | Applies | Status | Applicable Controls | Implemented | Gap Count |
+|--------|---------|--------|---------------------|-------------|-----------|
+| 1. Cyber Security Governance | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 2. Cyber Security Incidents | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 3. Outsourced Services | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 4. Security Documentation | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 5. Personnel Security | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 6. Physical Security | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 7. Communications Infrastructure | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 8. ICT Equipment Security | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 9. System Hardening | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 10. System Management | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 11. System Monitoring | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 12. Cryptography | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 13. Gateway Security | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 14. Data Transfer | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 15. Cloud and IaaS Considerations | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 16. Working-Off-Site Security | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 17. Evaluation Activities | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+
+**Overall**: [n] Implemented / [n] Applicable = [n]% applicability score.
+
+---
+
+## IRAP Assessment Position
+
+| Item | Detail |
+|------|--------|
+| **IRAP Assessment Status** | [Assessed (date) / In Progress / Not Required / Not Started] |
+| **IRAP Scope** | [Description of system boundary assessed] |
+| **Residual Risks Accepted** | [List residual risks accepted by Authorising Officer] |
+| **Re-Assessment Cadence** | [Annual / On-major-change] |
+| **Cloud Provider Inheritance** | [Microsoft Azure / AWS / GCP — IRAP scope citation] |
+
+---
+
+## Recommendations
+
+### Quick Wins ( < 30 days)
+
+| # | Recommendation | ISM Control(s) | Domain | Effort |
+|---|---------------|----------------|--------|--------|
+| 1 | [Recommendation] | [Control IDs] | [#] | [Low/Medium] |
+
+### Short-Term (30–90 days)
+
+| # | Recommendation | ISM Control(s) | Domain | Effort |
+|---|---------------|----------------|--------|--------|
+| 1 | [Recommendation] | [Control IDs] | [#] | [Medium/High] |
+
+### Medium-Term (90–180 days)
+
+| # | Recommendation | ISM Control(s) | Domain | Effort |
+|---|---------------|----------------|--------|--------|
+| 1 | [Recommendation] | [Control IDs] | [#] | [High] |
+
+---
+
+## External References
+
+### Document Register
+
+| Doc ID | Filename | Type | Source | Description |
+|--------|----------|------|--------|-------------|
+| ASDISM | ASD Information Security Manual | Standard | cyber.gov.au | Primary control framework — edition [DATE] |
+| AUE8 | ARC-{P}-AUE8-v* | ArcKit Artefact | projects/ | E8 posture cross-reference (Domain 9) |
+
+### Citations
+
+| Citation ID | Doc ID | Section | Category | Quoted Passage |
+|-------------|--------|---------|----------|----------------|
+| — | — | — | — | — |
+
+### Verification
+
+| Standard | URL | Verification Date |
+|----------|-----|-------------------|
+| ASD Information Security Manual | https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism | [YYYY-MM-DD] |
+| Protective Security Policy Framework | https://www.protectivesecurity.gov.au/ | [YYYY-MM-DD] |
+| IRAP | https://www.cyber.gov.au/about-us/programs-and-services/irap | [YYYY-MM-DD] |
+
+---
+
+**Generated by**: ArcKit `/arckit:au-ism-controls` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
diff --git a/arckit-au/templates/au-ndb-playbook-template.md b/arckit-au/templates/au-ndb-playbook-template.md
new file mode 100644
index 00000000..f620835d
--- /dev/null
+++ b/arckit-au/templates/au-ndb-playbook-template.md
@@ -0,0 +1,271 @@
+# Notifiable Data Breach (NDB) Response Playbook
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:au-ndb-playbook`
+
+## Document Control
+
+
+
+
+
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:au-ndb-playbook` command | PENDING | PENDING |
+
+---
+
+## Executive Summary
+
+[One to two paragraphs: APP entity status, NDB scheme applicability, playbook readiness, last test date, key risks.]
+
+---
+
+## 1. Entity Profile
+
+| Field | Value |
+|-------|-------|
+| **APP Entity Status** | [Australian Government agency / APP organisation per s 6C / s 6D] |
+| **Privacy Officer** | [Name + role + contact] |
+| **Accountable Officer for NDB Response** | [Name + role; named single accountable officer] |
+| **Business Hours Response Team Lead** | [Name + role + contact] |
+| **After-Hours Response Team Lead** | [Name + role + 24/7 contact] |
+| **External Legal Counsel** | [Firm name + contact] |
+| **Communications Lead** | [Name + role] |
+| **CISO / Security Officer** | [Name + role; cross-ref ARC-{P}-AUE8 governance] |
+| **Last Tabletop Exercise** | [YYYY-MM-DD] |
+| **Last Live Incident** | [YYYY-MM-DD or N/A] |
+
+---
+
+## 2. NDB Eligibility Test (Decision Tree)
+
+```text
+Step 1: Has there been unauthorised access to,
+ unauthorised disclosure of, or loss of
+ personal information?
+ │
+ ├── No → Not an eligible data breach. Document as
+ │ "incident — not eligible". STOP.
+ │
+ └── Yes
+ │
+ ▼
+Step 2: Is serious harm likely to result to one
+ or more individuals?
+ (Financial loss, identity theft, emotional
+ distress, physical safety, reputational harm)
+ │
+ ├── No (assessed conservatively) → Not eligible. Document. STOP.
+ │
+ └── Yes
+ │
+ ▼
+Step 3: Can the entity remediate through reasonable
+ steps to prevent the serious harm?
+ │
+ ├── Yes → Take reasonable steps. If steps successful, NOT eligible
+ │ for notification (document the reasonable-steps action).
+ │ If steps fail or cannot be applied in time, return to
+ │ Step 2.
+ │
+ └── No → ELIGIBLE DATA BREACH.
+ 30-day notification clock starts from when reasonable
+ grounds to believe were established (typically Day 0).
+ Notify OAIC + affected individuals.
+```
+
+---
+
+## 3. 30-Day Timeline Plan
+
+| Day | Milestone | Owner | Output |
+|-----|-----------|-------|--------|
+| **Day 0** | Detect → Contain → Activate playbook → Notify Privacy Officer + accountable officer | SOC / detector | Incident ticket, containment evidence |
+| **Day 0–1** | Initial scoping → preliminary eligibility assessment → set 30-day clock | Privacy Officer | Eligibility memo (preliminary) |
+| **Day 1–3** | Forensic investigation → identify affected individuals + types of personal information involved | Security Officer + Privacy Officer | Scope statement |
+| **Day 3–7** | Serious-harm assessment per individual cohort → identify reasonable-steps mitigations | Privacy Officer + Legal | Harm assessment + mitigation list |
+| **Day 7–10** | Reasonable-steps execution → re-test eligibility | Security Officer | Mitigation evidence |
+| **Day 10–14** | Final eligibility decision → if eligible, draft OAIC notification + individual notifications | Privacy Officer + Legal + Comms | Draft notifications |
+| **Day 14–21** | Legal review → executive sign-off → finalise OAIC form + individual notification | Legal + accountable officer | Approved notifications |
+| **Day 21–25** | Submit OAIC notification → execute individual notifications | Privacy Officer + Comms | OAIC submission receipt; individual notification log |
+| **Day 25–30** | Public statement if required → media response → regulator follow-up | Comms + accountable officer | Public statement; media log |
+| **Day 30** | Notification deadline → all required notifications complete | Privacy Officer | Compliance evidence pack |
+| **Day 30+** | Post-incident review (within 90 days) → lessons-learned → AUE8/AUISM/AUPIA artefact updates | Privacy Officer + Security Officer | Post-incident review document |
+
+---
+
+## 4. Roles & Responsibilities (RACI)
+
+| Role | Detect | Contain | Assess Eligibility | Notify OAIC | Notify Individuals | Public Statement | Lessons Learned |
+|------|--------|---------|---------------------|-------------|--------------------|--------------------|-----------------|
+| Privacy Officer | I | I | **R+A** | **R** | **R** | C | **R+A** |
+| Security Officer / CISO | I | **R+A** | C | I | I | I | C |
+| SOC / Detection team | **R** | C | I | I | I | I | I |
+| Accountable Officer (Director / CEO) | I | I | A | A | A | **R+A** | A |
+| Legal Counsel | I | C | C | C | C | **R+A** | C |
+| Communications | I | I | I | I | C | **R+A** | C |
+| Affected business owner | I | C | C | I | I | I | C |
+
+R = Responsible · A = Accountable · C = Consulted · I = Informed
+
+---
+
+## 5. Detection + Containment Procedures
+
+### Detection sources
+
+- SIEM alerts (cross-ref ARC-{P}-AUE8 + ARC-{P}-AUISM Domain 11)
+- Customer / data-subject reports (front-line intake to Privacy Officer)
+- Vendor / supply-chain notification (cross-ref AUDISP supply-chain provisions)
+- Insider report
+- Regulator notification
+- Media discovery
+
+### Immediate containment
+
+- Isolate affected systems (cross-ref ARC-{P}-AUE8 incident response capability)
+- Preserve evidence (logs, system images) per ISM Domain 11 retention
+- Engage forensic capability (internal SOC + external IR retainer)
+- **Do not** publicly comment until eligibility assessment complete
+
+---
+
+## 6. Assessment Procedure
+
+### Three statutory tests
+
+1. Unauthorised access / disclosure / loss
+2. Likely serious harm
+3. No reasonable-steps remediation
+
+### Serious-harm criteria (broadly read)
+
+- **Financial harm**: identity theft, financial loss, fraud
+- **Emotional / psychological harm**: humiliation, anxiety, stress
+- **Physical safety**: violence, intimidation, stalking
+- **Reputational harm**: defamation, social impact
+- **Discrimination harm**: protected attributes exposure
+- **Loss of opportunity**: employment, services, insurance
+
+### Reasonable-steps test
+
+- Encryption recovery (e.g., breach is of encrypted data + key not compromised)
+- Wiping recovered devices
+- Rapid password reset + MFA enforcement
+- Data deletion at recipient (with verification)
+- Court order / contractual return of data
+
+If reasonable steps **successful**, document and treat as a non-eligible incident. If **unsuccessful or unavailable**, eligible breach — proceed to notification.
+
+---
+
+## 7. OAIC Notification Form Content
+
+Required fields per OAIC NDB form:
+
+- Entity name + contact details
+- Description of the breach (concise factual summary)
+- Kind of information involved (PII categories)
+- Likely consequences for individuals (serious-harm assessment)
+- Recommendations for affected individuals (e.g., change passwords, monitor accounts, contact IDCare)
+- Steps the entity has taken / will take to remediate
+
+### Sample notification text (placeholder — adapt per incident)
+
+> [Entity name] regrets to advise that a data breach occurred on [DATE] affecting [INDIVIDUAL COHORT — number + type]. The breach involved [INFORMATION CATEGORY]. The breach is believed to have been caused by [CAUSE]. We have taken the following steps to contain the breach: [STEPS]. Affected individuals are advised to: [RECOMMENDATIONS]. Please contact our Privacy Officer at [CONTACT] with any questions.
+
+---
+
+## 8. Individual Notification Approach
+
+| Aspect | Detail |
+|--------|--------|
+| **Direct or publication-based** | [Direct preferred where contactable; publication where direct not practicable] |
+| **Channel** | [Email primary; SMS / postal mail backup; published notice if required] |
+| **Language + accessibility** | [Plain-English; alternative formats on request] |
+| **Content** | [What happened, what info, what consequences, what to do, who to contact] |
+| **Cohort segmentation** | [Tailor notification by data-subject category if appropriate] |
+
+---
+
+## 9. Communications Plan
+
+| Audience | Channel | Pre-Approved Holding Statement |
+|----------|---------|---------------------------------|
+| Internal staff | All-staff email + leadership briefing | [Holding statement] |
+| Affected individuals | Direct (email/SMS/post) | [Per §8] |
+| OAIC | OAIC NDB form | [Per §7] |
+| Media | Statement + spokesperson | [Pre-written holding statement] |
+| Sector regulator (if applicable — APRA / AHPRA / etc.) | Sector reporting channel | [Per sector requirement] |
+
+---
+
+## 10. Post-Incident Review
+
+Conducted within 90 days of incident closure.
+
+| Aspect | Detail |
+|--------|--------|
+| **Root cause analysis** | [5-whys methodology] |
+| **Control effectiveness review** | [What worked, what didn't] |
+| **Artefact updates triggered** | [AUE8 strategy refresh / AUISM domain refresh / AUPIA APP refresh] |
+| **Lessons learned cycle** | [Action register; review at next risk forum] |
+| **Tabletop exercise refresh** | [Update annual exercise scenario based on incident pattern] |
+
+---
+
+## 11. Coordination With Other Reporting Obligations
+
+| Obligation | Trigger | Timeline | Coordination Note |
+|------------|---------|----------|-------------------|
+| SOCI cyber incident (if SOCI-covered entity) | Significant operational impact | 12 hours | Runs parallel to NDB; coordinate so 12hr report doesn't pre-commit eligibility position |
+| SOCI cyber incident (relevant impact) | Relevant impact | 72 hours | As above |
+| DISP-relevant incident | Defence-classified content involvement | 24 hours | Cross-ref ARC-{P}-AUDISP-v* incident reporting |
+| Sector regulator (e.g., APRA CPS 234) | Material information security incident | 72 hours | Sector-specific |
+| EU GDPR (if EU residents affected) | Personal data breach | 72 hours | Concurrent jurisdiction — legal counsel coordinate |
+| NZ Privacy Act (if NZ residents) | Notifiable privacy breach | "As soon as practicable" | Trans-Tasman coordination |
+
+---
+
+## 12. Tabletop Exercise Plan
+
+| Aspect | Detail |
+|--------|--------|
+| **Cadence** | [Annual minimum; semi-annual recommended] |
+| **Last Exercise** | [YYYY-MM-DD] |
+| **Next Scheduled** | [YYYY-MM-DD] |
+| **Scenario Theme (next exercise)** | [E.g., ransomware on payroll system; insider exfiltration; vendor compromise] |
+| **Participants** | [Privacy Officer, Security Officer, Legal, Comms, accountable officer] |
+| **Evidence Retention** | [Years; storage location] |
+
+---
+
+## 13. External References
+
+### Document Register
+
+| Doc ID | Filename | Type | Source | Description |
+|--------|----------|------|--------|-------------|
+| PA88 | Privacy Act 1988 (Cth) Part IIIC | Legislation | legislation.gov.au | NDB scheme statute |
+| OAIC-NDB | OAIC NDB scheme guidance | Guidance | oaic.gov.au | Operational guidance |
+| AUPIA | ARC-{P}-AUPIA-v* | ArcKit Artefact | projects/ | APP 11 cross-ref |
+| AUE8 | ARC-{P}-AUE8-v* | ArcKit Artefact | projects/ | Security baseline |
+| AUISM | ARC-{P}-AUISM-v* | ArcKit Artefact | projects/ | Domain 2 (incidents) cross-ref |
+
+### Verification
+
+| Standard | URL | Verification Date |
+|----------|-----|-------------------|
+| Privacy Act 1988 (Cth) | https://www.legislation.gov.au/Details/C2024C00301 | [YYYY-MM-DD] |
+| OAIC NDB Scheme | https://www.oaic.gov.au/privacy/notifiable-data-breaches | [YYYY-MM-DD] |
+
+---
+
+**Generated by**: ArcKit `/arckit:au-ndb-playbook` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
diff --git a/arckit-au/templates/au-pia-template.md b/arckit-au/templates/au-pia-template.md
new file mode 100644
index 00000000..950cf7cd
--- /dev/null
+++ b/arckit-au/templates/au-pia-template.md
@@ -0,0 +1,378 @@
+# Privacy Impact Assessment (Privacy Act 1988)
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:au-pia`
+
+## Document Control
+
+
+
+
+
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:au-pia` command | PENDING | PENDING |
+
+---
+
+## Executive Summary
+
+[Two to three paragraphs: project under assessment, personal information involved, overall privacy risk posture, key findings and recommendations.]
+
+---
+
+## Project Description
+
+| Field | Value |
+|-------|-------|
+| **Project Name** | [Project name] |
+| **Owning Agency** | [Department / Agency] |
+| **Project Phase** | [Discovery / Alpha / Beta / Live] |
+| **Data Subjects** | [Citizens / Employees / Contractors / Business entities] |
+| **Personal Information Types** | [Contact details / Identity / Financial / Health / Criminal / Biometric] |
+| **Sensitive Information** | [Yes — categories / No] |
+| **Estimated Data Volume** | [Number of records / data subjects] |
+| **AI/Automated Decisions** | [Yes — describe / No] |
+| **Assessment Date** | [YYYY-MM-DD] |
+| **Privacy Officer** | [Name and role] |
+
+---
+
+## Information Flows
+
+```mermaid
+graph LR
+ subgraph Collection
+ C1[Web Form]
+ C2[API Integration]
+ C3[Manual Entry]
+ end
+
+ subgraph Processing
+ P1[Application Server]
+ P2[Analytics Engine]
+ end
+
+ subgraph Storage
+ S1[Primary Database
AU Region]
+ S2[Backup
AU Region]
+ end
+
+ subgraph Disclosure
+ D1[Reporting Dashboard]
+ D2[Partner Agency]
+ end
+
+ C1 -->|APP 3| P1
+ C2 -->|APP 3| P1
+ C3 -->|APP 3| P1
+ P1 -->|APP 6| S1
+ P1 -->|APP 6| P2
+ S1 -->|APP 11| S2
+ P2 -->|APP 6| D1
+ P1 -->|APP 6| D2
+```
+
+[Replace with actual information flows for the project. Annotate each flow with the governing APP.]
+
+---
+
+## APP Compliance Assessment
+
+### APP 1 — Open and Transparent Management
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Privacy policy published, privacy management plan, complaints process, staff training]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 2 — Anonymity and Pseudonymity
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Option to transact anonymously/pseudonymously, exceptions documented]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 3 — Collection of Solicited Personal Information
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Collection limited to necessary information, lawful basis, consent for sensitive information (APP 3.3)]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 4 — Dealing with Unsolicited Personal Information
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Process for unsolicited information — assess, retain or destroy]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 5 — Notification of Collection
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Collection notices, privacy statements at point of collection, matters covered in notice]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 6 — Use or Disclosure
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Use limited to primary purpose, secondary use exceptions documented, disclosure register]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 7 — Direct Marketing
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant / N/A] |
+
+**Evidence**: [Direct marketing controls, opt-out mechanism, consent records]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 8 — Cross-Border Disclosure
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Data residency, cloud hosting regions, offshore processing, reasonable steps to ensure APP compliance by overseas recipient]
+
+**Overseas Recipients**:
+
+| Recipient | Country | Purpose | APP Compliance Mechanism |
+|-----------|---------|---------|-------------------------|
+| [Name] | [Country] | [Purpose] | [Contract / Consent / Substantially similar laws] |
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 9 — Government Related Identifiers
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Government identifiers used (TFN, Medicare, myGovID), adoption restrictions, disclosure controls]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 10 — Quality of Personal Information
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Data quality processes, validation at collection, update mechanisms, accuracy checks]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 11 — Security of Personal Information
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+| **E8 Posture Reference** | [ARC-{P}-AUE8-v{V} if available] |
+
+**Evidence**: [Security controls — encryption, access controls, E8 maturity level, destruction/de-identification procedures]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 12 — Access to Personal Information
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Access request process, response timeframes, FOI integration, exceptions documented]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 13 — Correction of Personal Information
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Correction request process, notification of corrections to third parties]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+## APP Compliance Summary
+
+| APP | Principle | Applies | Status | Risk Level |
+|-----|----------|---------|--------|-----------|
+| 1 | Open and transparent management | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 2 | Anonymity and pseudonymity | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 3 | Collection of solicited information | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 4 | Unsolicited personal information | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 5 | Notification of collection | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 6 | Use or disclosure | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 7 | Direct marketing | [Y/N] | [✅/⚠️/❌/N/A] | [H/M/L] |
+| 8 | Cross-border disclosure | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 9 | Government related identifiers | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 10 | Quality of personal information | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 11 | Security of personal information | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 12 | Access to personal information | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 13 | Correction of personal information | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+
+---
+
+## Privacy Risk Register
+
+| Risk ID | APP | Risk Description | Likelihood | Impact | Risk Level | Mitigation | Residual Risk |
+|---------|-----|-----------------|-----------|--------|-----------|-----------|---------------|
+| PR-001 | [#] | [Description] | [1-5] | [1-5] | [H/M/L] | [Action] | [H/M/L] |
+
+---
+
+## Sensitive Information Assessment
+
+| Category (Privacy Act s 6) | Processed | Consent Mechanism | Notes |
+|---------------------------|-----------|-------------------|-------|
+| Racial or ethnic origin | [Y/N] | [Mechanism] | |
+| Political opinions | [Y/N] | [Mechanism] | |
+| Religious beliefs | [Y/N] | [Mechanism] | |
+| Sexual orientation | [Y/N] | [Mechanism] | |
+| Criminal record | [Y/N] | [Mechanism] | |
+| Health information | [Y/N] | [Mechanism] | |
+| Genetic information | [Y/N] | [Mechanism] | |
+| Biometric information | [Y/N] | [Mechanism] | |
+| Trade union membership | [Y/N] | [Mechanism] | |
+
+---
+
+## AI and Automated Decision-Making
+
+| Aspect | Detail |
+|--------|--------|
+| **Uses AI/ML** | [Yes / No] |
+| **Automated decisions affecting individuals** | [Yes — describe / No] |
+| **Individual notification** | [Implemented / Planned for Dec 2026 / Not applicable] |
+| **Human review mechanism** | [Describe] |
+| **Fairness assessment** | [Completed / In progress / Not started] |
+| **AU AI Assurance Reference** | [ARC-{P}-AUAIA-v{V} if available] |
+
+---
+
+## Recommendations
+
+| # | Recommendation | APP | Priority | Owner | Target Date |
+|---|---------------|-----|----------|-------|-------------|
+| 1 | [Recommendation] | [#] | [Critical/High/Medium/Low] | [Role] | [Date] |
+
+---
+
+## External References
+
+### Document Register
+
+| Doc ID | Filename | Type | Source Location | Description |
+|--------|----------|------|-----------------|-------------|
+| PA88 | Privacy Act 1988 (Cth) | Legislation | legislation.gov.au | Primary privacy legislation |
+| OAIC-PIA | OAIC Guide to undertaking PIAs | Guidance | oaic.gov.au | PIA methodology guide |
+
+### Citations
+
+| Citation ID | Doc ID | Page/Section | Category | Quoted Passage |
+|-------------|--------|--------------|----------|----------------|
+| — | — | — | — | — |
+
+### Unreferenced Documents
+
+| Filename | Source Location | Reason |
+|----------|-----------------|--------|
+| — | — | — |
+
+---
+
+**Generated by**: ArcKit `/arckit:au-pia` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
diff --git a/arckit-au/templates/au-pspf-template.md b/arckit-au/templates/au-pspf-template.md
new file mode 100644
index 00000000..16c287a9
--- /dev/null
+++ b/arckit-au/templates/au-pspf-template.md
@@ -0,0 +1,362 @@
+# PSPF Compliance Assessment
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:au-pspf`
+
+## Document Control
+
+
+
+
+
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:au-pspf` command | PENDING | PENDING |
+
+---
+
+## Executive Summary
+
+[Two to three paragraphs: entity, PSPF applicability, current self-assessment posture, key gaps, AGD reporting status.]
+
+---
+
+## Entity Profile
+
+| Field | Value |
+|-------|-------|
+| **Entity Name** | [Entity name] |
+| **Entity Type** | [Non-corporate Commonwealth / Corporate Commonwealth / Contractor / Panel Member / State Govt with flow-down] |
+| **PSPF Applicability Driver** | [Direct / Contractual flow-down — cite source] |
+| **Chief Security Officer (CSO)** | [Name + role + clearance] |
+| **CSO Authority** | [Reporting line, signing authority] |
+| **PSPF Edition Used** | [E.g., PSPF 2024 release] |
+| **Last AGD Self-Assessment Submission** | [YYYY-MM-DD] |
+| **Self-Assessed Maturity Level** | [Compliant / Substantially Compliant / Partly Compliant / Not Compliant] |
+| **Assessment Date** | [YYYY-MM-DD] |
+| **Assessor** | [Name + role] |
+
+---
+
+## Outcome 1: Security Governance
+
+### CR1: Role of accountable authority
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Compliant / ⚠️ Substantially Compliant / ⚠️ Partly Compliant / ❌ Not Compliant] |
+
+**Evidence**: [Accountable authority designated, security leadership, governance documents]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR2: Management structures and responsibilities
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [CSO designated, security committee, executive structures]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR3: Security planning and risk management
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Security plan, risk-management plan; cross-ref ARC-{P}-AUISM Domain 1]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR4: Security maturity monitoring
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Annual self-assessment process; AGD reporting submission]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+## Outcome 2: Information Security
+
+### CR5: Sensitive and classified information
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Classification policy, marking + handling procedures, classification training]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR6: Access to information
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Need-to-know enforcement; security-clearance verification at point of access]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR7: Safeguarding information from cyber threats
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+| **E8 Cross-Reference** | [ARC-{P}-AUE8-v*] |
+| **ISM Cross-Reference** | [ARC-{P}-AUISM-v*] |
+
+**Evidence**: [Defer to ISM applicability statement + E8 posture]
+
+**Gap**: [Beyond-E8 gaps]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR8: Sensitive and classified discussions and communications
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Approved communications channels for classified content; meeting room ratings; encrypted comms]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+## Outcome 3: Personnel Security
+
+### CR9: Eligibility and suitability
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [AGSVA clearance process; vetting workflow; cleared-personnel inventory]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR10: Ongoing assessment
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Continuous suitability programme, periodic reviews, change-of-circumstance reporting]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR11: Separation of personnel
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Off-boarding clearance debrief, access revocation cadence, return of equipment]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR12: Insider threat
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Insider threat programme, detection capability, role-based controls]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+## Outcome 4: Physical Security
+
+### CR13: Entity facilities
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌ / Inherited from cloud provider IRAP] |
+
+**Evidence**: [Physical security zones, facility ratings, access controls]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR14: Working off-site
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Remote work policy, travel security, mobile device management]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR15: Physical security risk
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Physical risk assessment, treatment plan, incident response]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR16: Supporting services
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Cleaning, maintenance, contractor access governance, escort policy]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+## PSPF Annual Self-Assessment
+
+| Aspect | Detail |
+|--------|--------|
+| **Self-Assessment Cycle** | [Annual; deadline 31 October] |
+| **Last Submission Date** | [YYYY-MM-DD] |
+| **Self-Assessed Levels** | [List per Core Requirement] |
+| **AGD Feedback** | [Notes from last submission] |
+| **Material Improvements Since Last** | [Description] |
+| **Identified Issues for Next Cycle** | [Description] |
+
+---
+
+## Compliance Summary
+
+| Outcome | CR | Title | Status | Gap Count |
+|---------|----|-------|--------|-----------|
+| 1. Governance | CR1 | Role of accountable authority | [✅/⚠️/❌] | [n] |
+| 1. Governance | CR2 | Management structures | [✅/⚠️/❌] | [n] |
+| 1. Governance | CR3 | Security planning + risk | [✅/⚠️/❌] | [n] |
+| 1. Governance | CR4 | Security maturity monitoring | [✅/⚠️/❌] | [n] |
+| 2. Information | CR5 | Sensitive/classified information | [✅/⚠️/❌] | [n] |
+| 2. Information | CR6 | Access to information | [✅/⚠️/❌] | [n] |
+| 2. Information | CR7 | Safeguarding from cyber threats | [✅/⚠️/❌] | [n] |
+| 2. Information | CR8 | Discussions + communications | [✅/⚠️/❌] | [n] |
+| 3. Personnel | CR9 | Eligibility + suitability | [✅/⚠️/❌] | [n] |
+| 3. Personnel | CR10 | Ongoing assessment | [✅/⚠️/❌] | [n] |
+| 3. Personnel | CR11 | Separation of personnel | [✅/⚠️/❌] | [n] |
+| 3. Personnel | CR12 | Insider threat | [✅/⚠️/❌] | [n] |
+| 4. Physical | CR13 | Entity facilities | [✅/⚠️/❌] | [n] |
+| 4. Physical | CR14 | Working off-site | [✅/⚠️/❌] | [n] |
+| 4. Physical | CR15 | Physical security risk | [✅/⚠️/❌] | [n] |
+| 4. Physical | CR16 | Supporting services | [✅/⚠️/❌] | [n] |
+
+**Overall PSPF Maturity**: [Compliant / Substantially Compliant / Partly Compliant / Not Compliant]
+
+---
+
+## Recommendations
+
+### Quick Wins ( < 30 days)
+
+| # | Recommendation | Outcome / CR | Effort |
+|---|---------------|--------------|--------|
+| 1 | [Recommendation] | [Outcome.CR] | [Low/Medium] |
+
+### Short-Term (30–90 days)
+
+| # | Recommendation | Outcome / CR | Effort |
+|---|---------------|--------------|--------|
+| 1 | [Recommendation] | [Outcome.CR] | [Medium/High] |
+
+### Medium-Term (90–180 days)
+
+| # | Recommendation | Outcome / CR | Effort |
+|---|---------------|--------------|--------|
+| 1 | [Recommendation] | [Outcome.CR] | [High] |
+
+---
+
+## External References
+
+### Document Register
+
+| Doc ID | Filename | Type | Source | Description |
+|--------|----------|------|--------|-------------|
+| PSPF | Protective Security Policy Framework | Standard | protectivesecurity.gov.au | Primary framework |
+| AUE8 | ARC-{P}-AUE8-v* | ArcKit Artefact | projects/ | E8 cross-ref (Outcome 2) |
+| AUISM | ARC-{P}-AUISM-v* | ArcKit Artefact | projects/ | ISM cross-ref (Outcome 2) |
+| AUPIA | ARC-{P}-AUPIA-v* | ArcKit Artefact | projects/ | PIA cross-ref (Outcomes 2 + 3) |
+| AUDISP | ARC-{P}-AUDISP-v* | ArcKit Artefact | projects/ | DISP cross-ref where applicable |
+
+### Verification
+
+| Standard | URL | Verification Date |
+|----------|-----|-------------------|
+| PSPF | https://www.protectivesecurity.gov.au/ | [YYYY-MM-DD] |
+| ASD ISM | https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism | [YYYY-MM-DD] |
+
+---
+
+**Generated by**: ArcKit `/arckit:au-pspf` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
diff --git a/arckit-ca/.claude-plugin/plugin.json b/arckit-ca/.claude-plugin/plugin.json
new file mode 100644
index 00000000..9c6c5023
--- /dev/null
+++ b/arckit-ca/.claude-plugin/plugin.json
@@ -0,0 +1,26 @@
+{
+ "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
+ "name": "arckit-ca",
+ "version": "5.0.0-alpha.9",
+ "description": "Canadian Federal Overlay for ArcKit — 12 commands for AIA, ATIP, ITSG-33, GC Digital Standards, OCAP, OLA, and federal cloud residency. Requires arckit core plugin.",
+ "author": {
+ "name": "TractorJuice",
+ "url": "https://github.com/tractorjuice"
+ },
+ "homepage": "https://arckit.org",
+ "repository": "https://github.com/tractorjuice/arc-kit",
+ "license": "MIT",
+ "keywords": [
+ "architecture",
+ "governance",
+ "canada",
+ "federal",
+ "compliance"
+ ],
+ "dependencies": [
+ {
+ "name": "arckit",
+ "version": "=5.0.0-alpha.8"
+ }
+ ]
+}
diff --git a/arckit-ca/README.md b/arckit-ca/README.md
new file mode 100644
index 00000000..decd05a1
--- /dev/null
+++ b/arckit-ca/README.md
@@ -0,0 +1,31 @@
+# ArcKit — Canadian Federal Overlay
+
+12 slash commands covering Canadian federal compliance:
+
+- `/arckit:ca-aia` — Algorithmic Impact Assessment (TBS Directive on Automated Decision-Making)
+- `/arckit:ca-atip` — ATIP reconciliation (Access to Information Act / Privacy Act)
+- `/arckit:ca-charter` — Charter rights design review (Oakes proportionality framing)
+- `/arckit:ca-cloud-residency` — Sovereign cloud residency (GC Cloud Adoption Strategy, Protected B+)
+- `/arckit:ca-fitaa` — Foreign Influence Transparency and Accountability Act compliance
+- `/arckit:ca-gc-digital-standards` — Government of Canada Digital Standards conformance scorecard
+- `/arckit:ca-itsg-33` — ITSG-33 Statement of Applicability with TBS security categorization
+- `/arckit:ca-ocap` — First Nations OCAP® sovereignty assessment (FNIGC pre-engagement)
+- `/arckit:ca-ola` — Official Languages Act review (Parts IV, V, VI)
+- `/arckit:ca-pia` — Privacy Impact Assessment (Privacy Act and TBS Directive on PIA)
+- `/arckit:ca-pspc` — Federal procurement strategy (PSPC Supply Manual, PSAB 5%)
+- `/arckit:ca-soia` — Security of Information Act handling plan
+
+Recipes: `ca-federal-fitaa`.
+
+## Requires arckit core plugin
+
+```bash
+claude plugin install arckit@arc-kit
+claude plugin install arckit-ca@arc-kit
+```
+
+Without `arckit` (core), recipes won't resolve their foundation commands (`arckit:principles`, `arckit:requirements`, etc.) and `validate-arc-filename` won't recognise CA doc-type codes.
+
+## Maintainer
+
+Currently maintained by @tractorjuice. Recruiting a Canadian federal domain co-maintainer — see [CONTRIBUTING.md](https://github.com/tractorjuice/arc-kit/blob/main/CONTRIBUTING.md).
diff --git a/arckit-ca/VERSION b/arckit-ca/VERSION
new file mode 100644
index 00000000..d012d7bc
--- /dev/null
+++ b/arckit-ca/VERSION
@@ -0,0 +1 @@
+5.0.0-alpha.9
diff --git a/arckit-claude/commands/ca-aia.md b/arckit-ca/commands/ca-aia.md
similarity index 100%
rename from arckit-claude/commands/ca-aia.md
rename to arckit-ca/commands/ca-aia.md
diff --git a/arckit-claude/commands/ca-atip.md b/arckit-ca/commands/ca-atip.md
similarity index 100%
rename from arckit-claude/commands/ca-atip.md
rename to arckit-ca/commands/ca-atip.md
diff --git a/arckit-claude/commands/ca-charter.md b/arckit-ca/commands/ca-charter.md
similarity index 100%
rename from arckit-claude/commands/ca-charter.md
rename to arckit-ca/commands/ca-charter.md
diff --git a/arckit-claude/commands/ca-cloud-residency.md b/arckit-ca/commands/ca-cloud-residency.md
similarity index 100%
rename from arckit-claude/commands/ca-cloud-residency.md
rename to arckit-ca/commands/ca-cloud-residency.md
diff --git a/arckit-claude/commands/ca-fitaa.md b/arckit-ca/commands/ca-fitaa.md
similarity index 100%
rename from arckit-claude/commands/ca-fitaa.md
rename to arckit-ca/commands/ca-fitaa.md
diff --git a/arckit-claude/commands/ca-gc-digital-standards.md b/arckit-ca/commands/ca-gc-digital-standards.md
similarity index 100%
rename from arckit-claude/commands/ca-gc-digital-standards.md
rename to arckit-ca/commands/ca-gc-digital-standards.md
diff --git a/arckit-claude/commands/ca-itsg-33.md b/arckit-ca/commands/ca-itsg-33.md
similarity index 100%
rename from arckit-claude/commands/ca-itsg-33.md
rename to arckit-ca/commands/ca-itsg-33.md
diff --git a/arckit-claude/commands/ca-ocap.md b/arckit-ca/commands/ca-ocap.md
similarity index 100%
rename from arckit-claude/commands/ca-ocap.md
rename to arckit-ca/commands/ca-ocap.md
diff --git a/arckit-claude/commands/ca-ola.md b/arckit-ca/commands/ca-ola.md
similarity index 100%
rename from arckit-claude/commands/ca-ola.md
rename to arckit-ca/commands/ca-ola.md
diff --git a/arckit-claude/commands/ca-pia.md b/arckit-ca/commands/ca-pia.md
similarity index 100%
rename from arckit-claude/commands/ca-pia.md
rename to arckit-ca/commands/ca-pia.md
diff --git a/arckit-claude/commands/ca-pspc.md b/arckit-ca/commands/ca-pspc.md
similarity index 100%
rename from arckit-claude/commands/ca-pspc.md
rename to arckit-ca/commands/ca-pspc.md
diff --git a/arckit-claude/commands/ca-soia.md b/arckit-ca/commands/ca-soia.md
similarity index 100%
rename from arckit-claude/commands/ca-soia.md
rename to arckit-ca/commands/ca-soia.md
diff --git a/arckit-claude/skills/arckit-build/recipes/ca-federal-fitaa.yaml b/arckit-ca/recipes/ca-federal-fitaa.yaml
similarity index 100%
rename from arckit-claude/skills/arckit-build/recipes/ca-federal-fitaa.yaml
rename to arckit-ca/recipes/ca-federal-fitaa.yaml
diff --git a/arckit-claude/templates/ca-aia-template.md b/arckit-ca/templates/ca-aia-template.md
similarity index 100%
rename from arckit-claude/templates/ca-aia-template.md
rename to arckit-ca/templates/ca-aia-template.md
diff --git a/arckit-claude/templates/ca-atip-template.md b/arckit-ca/templates/ca-atip-template.md
similarity index 100%
rename from arckit-claude/templates/ca-atip-template.md
rename to arckit-ca/templates/ca-atip-template.md
diff --git a/arckit-claude/templates/ca-charter-template.md b/arckit-ca/templates/ca-charter-template.md
similarity index 100%
rename from arckit-claude/templates/ca-charter-template.md
rename to arckit-ca/templates/ca-charter-template.md
diff --git a/arckit-claude/templates/ca-cloud-residency-template.md b/arckit-ca/templates/ca-cloud-residency-template.md
similarity index 100%
rename from arckit-claude/templates/ca-cloud-residency-template.md
rename to arckit-ca/templates/ca-cloud-residency-template.md
diff --git a/arckit-claude/templates/ca-fitaa-template.md b/arckit-ca/templates/ca-fitaa-template.md
similarity index 100%
rename from arckit-claude/templates/ca-fitaa-template.md
rename to arckit-ca/templates/ca-fitaa-template.md
diff --git a/arckit-claude/templates/ca-gc-digital-standards-template.md b/arckit-ca/templates/ca-gc-digital-standards-template.md
similarity index 100%
rename from arckit-claude/templates/ca-gc-digital-standards-template.md
rename to arckit-ca/templates/ca-gc-digital-standards-template.md
diff --git a/arckit-claude/templates/ca-itsg-33-template.md b/arckit-ca/templates/ca-itsg-33-template.md
similarity index 100%
rename from arckit-claude/templates/ca-itsg-33-template.md
rename to arckit-ca/templates/ca-itsg-33-template.md
diff --git a/arckit-claude/templates/ca-ocap-template.md b/arckit-ca/templates/ca-ocap-template.md
similarity index 100%
rename from arckit-claude/templates/ca-ocap-template.md
rename to arckit-ca/templates/ca-ocap-template.md
diff --git a/arckit-claude/templates/ca-ola-template.md b/arckit-ca/templates/ca-ola-template.md
similarity index 100%
rename from arckit-claude/templates/ca-ola-template.md
rename to arckit-ca/templates/ca-ola-template.md
diff --git a/arckit-claude/templates/ca-pia-template.md b/arckit-ca/templates/ca-pia-template.md
similarity index 100%
rename from arckit-claude/templates/ca-pia-template.md
rename to arckit-ca/templates/ca-pia-template.md
diff --git a/arckit-claude/templates/ca-pspc-template.md b/arckit-ca/templates/ca-pspc-template.md
similarity index 100%
rename from arckit-claude/templates/ca-pspc-template.md
rename to arckit-ca/templates/ca-pspc-template.md
diff --git a/arckit-claude/templates/ca-soia-template.md b/arckit-ca/templates/ca-soia-template.md
similarity index 100%
rename from arckit-claude/templates/ca-soia-template.md
rename to arckit-ca/templates/ca-soia-template.md
diff --git a/arckit-claude/.claude-plugin/plugin.json b/arckit-claude/.claude-plugin/plugin.json
index 303faa3f..8d91180f 100644
--- a/arckit-claude/.claude-plugin/plugin.json
+++ b/arckit-claude/.claude-plugin/plugin.json
@@ -1,7 +1,7 @@
{
"$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
"name": "arckit",
- "version": "4.22.0",
+ "version": "5.0.0-alpha.8",
"description": "Enterprise Architecture Governance & Vendor Procurement Toolkit - 70 slash commands for generating architecture artifacts",
"author": {
"name": "TractorJuice",
diff --git a/arckit-claude/CHANGELOG.md b/arckit-claude/CHANGELOG.md
index 9106ece0..75cf22c7 100644
--- a/arckit-claude/CHANGELOG.md
+++ b/arckit-claude/CHANGELOG.md
@@ -7,6 +7,22 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
## [Unreleased]
+## [5.0.0] - 2026-XX-XX
+
+### BREAKING
+
+- **Plugin split**: the `arckit` core plugin now ships only the 71 official-baseline commands. 46 community-overlay commands move to five new marketplace plugins: `arckit-uae` (12), `arckit-fr` (12), `arckit-ca` (12), `arckit-eu` (7), `arckit-at` (3). Install them alongside `arckit` to restore the previous full surface. See root `CHANGELOG.md` for the migration story.
+
+### Added
+
+- `hooks/v5-migration-banner.mjs` — one-shot SessionStart hook that reads `.arckit/manifest.json` and prints install suggestions for the jurisdictions a project previously used.
+
+### Changed
+
+- `skills/arckit-build/SKILL.md` — three-tier recipe lookup (project → core → sibling community plugins). Built-in recipes table gains a Plugin column and adds `ca-federal-fitaa` (previously missing despite shipping in v4.15.0).
+- `config/doc-types.mjs` — single source of truth for ALL doc-type codes, including codes used by community-plugin commands. Adding a community command that emits a new code requires a two-part PR (see root `CONTRIBUTING.md`).
+- All `uae-*`, `fr-*`, `ca-*`, `eu-*`, `at-*` commands, templates, and recipes are no longer shipped by the core plugin — moved to their respective community plugins.
+
## [4.22.0] - 2026-05-17
### Added
diff --git a/arckit-claude/VERSION b/arckit-claude/VERSION
index d7638f37..82f9aa98 100644
--- a/arckit-claude/VERSION
+++ b/arckit-claude/VERSION
@@ -1 +1 @@
-4.22.0
+5.0.0-alpha.8
diff --git a/arckit-claude/commands/pages.md b/arckit-claude/commands/pages.md
index 808d4a55..3c30849d 100644
--- a/arckit-claude/commands/pages.md
+++ b/arckit-claude/commands/pages.md
@@ -334,6 +334,16 @@ Only include these known artifact types. Match by type code pattern `ARC-{PID}-{
| | OCAP | `ARC-*-OCAP-*.md` | Canada First Nations OCAP Sovereignty Assessment |
| **Procurement (Community-contributed — Canada Federal Overlay)** | | | |
| | PROC | `ARC-*-PROC-*.md` | Canada Federal Procurement Strategy |
+| **Compliance (Community-contributed — Australian Federal / DISP-supplier Overlay)** | | | |
+| | AUE8 | `ARC-*-AUE8-*.md` | AU Essential Eight Maturity Posture |
+| | AUISM | `ARC-*-AUISM-*.md` | AU ISM Statement of Applicability |
+| | AUPIA | `ARC-*-AUPIA-*.md` | AU Privacy Impact Assessment (Privacy Act 1988) |
+| | AUNDB | `ARC-*-AUNDB-*.md` | AU Notifiable Data Breach Response Playbook |
+| | AUAIA | `ARC-*-AUAIA-*.md` | AU AI Assurance Baseline (DTA AI Policy v2.0) |
+| | AUDISP | `ARC-*-AUDISP-*.md` | AU DISP Member Self-Attestation Pack |
+| **Governance (Community-contributed — Australian Federal / DISP-supplier Overlay)** | | | |
+| | AUDSS | `ARC-*-AUDSS-*.md` | AU DTA Digital Service Standard Conformance |
+| | AUPSPF | `ARC-*-AUPSPF-*.md` | AU Protective Security Policy Framework Scorecard |
> **Single source of truth**: this table mirrors [`arckit-claude/config/doc-types.mjs`](../config/doc-types.mjs). When adding new commands, register the type code in `doc-types.mjs` first (so the hook resolves category + display name) and then add the row here so `/arckit.pages` includes the artifact in the dashboard.
diff --git a/arckit-claude/config/doc-types.mjs b/arckit-claude/config/doc-types.mjs
index 00d58bee..611ed971 100644
--- a/arckit-claude/config/doc-types.mjs
+++ b/arckit-claude/config/doc-types.mjs
@@ -152,18 +152,32 @@ export const DOC_TYPES = {
'OLA': { name: 'Canada Official Languages Act Review', category: 'Compliance', regime: 'CA' },
'PROC': { name: 'Canada Federal Procurement Strategy', category: 'Procurement', regime: 'CA' },
'OCAP': { name: 'Canada First Nations OCAP Sovereignty Assessment', category: 'Governance', regime: 'CA' },
+ // Australian Federal Overlay (Community-contributed, maintained by @royster70) — ASD Essential Eight, ISM, DTA DSS, Privacy Act 1988 PIA,
+ // OAIC NDB scheme, DISP, PSPF, DTA AI Assurance Framework + Responsible AI Policy v2.0
+ 'AUE8': { name: 'AU Essential Eight Maturity Posture', category: 'Compliance', regime: 'AU', severity: 'HIGH' },
+ 'AUISM': { name: 'AU ISM Statement of Applicability', category: 'Compliance', regime: 'AU', severity: 'HIGH' },
+ 'AUPIA': { name: 'AU Privacy Impact Assessment (Privacy Act 1988)', category: 'Compliance', regime: 'AU', severity: 'HIGH' },
+ 'AUNDB': { name: 'AU Notifiable Data Breach Response Playbook', category: 'Compliance', regime: 'AU' },
+ 'AUDSS': { name: 'AU DTA Digital Service Standard Conformance', category: 'Governance', regime: 'AU', severity: 'HIGH' },
+ 'AUPSPF': { name: 'AU Protective Security Policy Framework Scorecard', category: 'Governance', regime: 'AU', severity: 'HIGH' },
+ 'AUAIA': { name: 'AU AI Assurance Baseline (DTA AI Policy v2.0)', category: 'Compliance', regime: 'AU', severity: 'HIGH' },
+ 'AUDISP': { name: 'AU DISP Member Self-Attestation Pack', category: 'Compliance', regime: 'AU', severity: 'HIGH' },
};
// Derived: regimes in canonical order (officially-maintained first, then community alphabetical)
-export const REGIMES = ['UK', 'MOD', 'EU', 'FR', 'AT', 'UAE'];
+// CA + AU added retroactively — both shipped doc-types without REGIMES registration
+// (CA since v4.15.0, AU in v5.0.0). REGIME_LABELS ordering matches.
+export const REGIMES = ['UK', 'MOD', 'AT', 'AU', 'CA', 'EU', 'FR', 'UAE'];
// Human-readable regime labels
export const REGIME_LABELS = {
UK: 'UK Gov',
MOD: 'MOD',
+ AT: 'Austria',
+ AU: 'Australia',
+ CA: 'Canada',
EU: 'EU',
FR: 'France',
- AT: 'Austria',
UAE: 'UAE',
};
diff --git a/arckit-claude/hooks/hooks.json b/arckit-claude/hooks/hooks.json
index 75648e05..01790ca3 100644
--- a/arckit-claude/hooks/hooks.json
+++ b/arckit-claude/hooks/hooks.json
@@ -42,6 +42,12 @@
"command": "node",
"args": ["${CLAUDE_PLUGIN_ROOT}/hooks/version-check.mjs"],
"timeout": 5
+ },
+ {
+ "type": "command",
+ "command": "node",
+ "args": ["${CLAUDE_PLUGIN_ROOT}/hooks/v5-migration-banner.mjs"],
+ "timeout": 5
}
]
}
diff --git a/arckit-claude/hooks/v5-migration-banner.mjs b/arckit-claude/hooks/v5-migration-banner.mjs
new file mode 100644
index 00000000..48c2c9fe
--- /dev/null
+++ b/arckit-claude/hooks/v5-migration-banner.mjs
@@ -0,0 +1,49 @@
+#!/usr/bin/env node
+/**
+ * v5-migration-banner.mjs — one-shot SessionStart hook for the v4→v5 plugin split.
+ *
+ * Prints install suggestions for the per-jurisdiction community plugins the
+ * user previously used in this project. Reads .arckit/manifest.json to detect
+ * prior usage. Stops firing once .arckit/v5-migration-acked exists.
+ *
+ * Exit codes: always 0. Output goes to stdout for the SessionStart context.
+ */
+import { readFileSync, existsSync } from 'node:fs';
+import { join } from 'node:path';
+
+const cwd = process.env.CLAUDE_PROJECT_DIR || process.cwd();
+const manifestPath = join(cwd, '.arckit/manifest.json');
+const ackPath = join(cwd, '.arckit/v5-migration-acked');
+
+if (existsSync(ackPath)) process.exit(0);
+if (!existsSync(manifestPath)) process.exit(0);
+
+let manifest;
+try {
+ manifest = JSON.parse(readFileSync(manifestPath, 'utf-8'));
+} catch {
+ process.exit(0);
+}
+
+const JURISDICTION_RE = /^arckit:(uae|fr|ca|eu|at)-/;
+const used = new Set();
+for (const entry of manifest.artefacts || []) {
+ const m = entry.command?.match(JURISDICTION_RE);
+ if (m) used.add(m[1]);
+}
+
+if (used.size === 0) process.exit(0);
+
+const sorted = [...used].sort();
+const plugins = sorted.map((j) => `arckit-${j}`).join(' ');
+console.log(`
+ArcKit v5.0.0 — community overlays now ship as separate plugins.
+
+This project previously used: ${sorted.map((j) => `arckit:${j}-*`).join(', ')}
+
+Install the matching plugins to keep those commands available:
+ claude plugin install ${plugins}
+
+Acknowledge (suppresses this banner):
+ touch .arckit/v5-migration-acked
+`);
diff --git a/arckit-claude/skills/arckit-build/SKILL.md b/arckit-claude/skills/arckit-build/SKILL.md
index 849e5d0d..5510cde2 100644
--- a/arckit-claude/skills/arckit-build/SKILL.md
+++ b/arckit-claude/skills/arckit-build/SKILL.md
@@ -40,24 +40,29 @@ You are running the ArcKit build harness. Your job is **orchestration only** —
Recipes are external YAML files. Lookup precedence for `--recipe NAME` (first hit wins):
-1. **Project override**: `.arckit/recipes/{NAME}.yaml` — user customizations preserved across plugin updates
-2. **Plugin default**: `${CLAUDE_PLUGIN_ROOT}/skills/arckit-build/recipes/{NAME}.yaml` — ships with the ArcKit plugin
+1. **Project override**: `.arckit/recipes/{NAME}.yaml` — user customizations preserved across plugin updates.
+2. **Core plugin**: `${CLAUDE_PLUGIN_ROOT}/skills/arckit-build/recipes/{NAME}.yaml` — recipes shipped with the `arckit` core plugin (`uk-saas`, `uk-mod-sovereign`).
+3. **Sibling community plugins**: `${CLAUDE_PLUGIN_ROOT}/../arckit-*/recipes/{NAME}.yaml` — recipes shipped with installed community plugins (e.g. `arckit-uae/recipes/uae-federal-ai.yaml`, `arckit-ca/recipes/ca-federal-fitaa.yaml`).
-Default recipe is `uk-saas`. To customize, copy the plugin default to `.arckit/recipes/uk-saas.yaml` and edit there:
+Resolution: glob the parent directory of `${CLAUDE_PLUGIN_ROOT}` for `arckit-*/recipes/{NAME}.yaml` and take the first match. The glob works in both layouts — marketplace-installed plugins land as siblings under the same marketplace-source cache directory, and the dev-mode same-repo layout has them as sibling directories in the repo root.
+
+Default recipe is `uk-saas`. To customize, copy the core default to `.arckit/recipes/uk-saas.yaml` and edit there:
```bash
mkdir -p .arckit/recipes
cp "${CLAUDE_PLUGIN_ROOT}/skills/arckit-build/recipes/uk-saas.yaml" .arckit/recipes/uk-saas.yaml
```
-**Built-in recipes** (shipped with the plugin):
+**Built-in recipes**:
-| Recipe | Use case |
-|--------|----------|
-| `uk-saas` | UK Government managed multi-tenant SaaS — civilian departments |
-| `uk-mod-sovereign` | UK MOD / sovereign / air-gapped — `mod-secure` + `jsp-936`, no SVCASS, sealed-media distribution |
-| `uae-federal-ai` | UAE Federal AI — full Cabinet agentic AI decree compliance with all 12 UAE community commands, integrated research wave (general AI + AWS / Azure UAE region availability), plus core ArcKit governance |
-| `uae-agentic-transformation` | UAE Federal Agentic AI Transformation — focused 24-month playbook for the 23 April 2026 Cabinet framework's 50%-of-services-by-April-2028 target; ADRs reshaped around agentic architecture (orchestration, human-in-the-loop, observability, kill-switch); PLAN + ROADMAP timeboxed to the 24-month window |
+| Recipe | Plugin | Use case |
+|--------|--------|----------|
+| `uk-saas` | `arckit` (core) | UK Government managed multi-tenant SaaS — civilian departments |
+| `uk-mod-sovereign` | `arckit` (core) | UK MOD / sovereign / air-gapped — `mod-secure` + `jsp-936`, no SVCASS, sealed-media distribution |
+| `uae-federal-ai` | `arckit-uae` | UAE Federal AI — full Cabinet agentic AI decree compliance with all 12 UAE community commands, integrated research wave (general AI + AWS / Azure UAE region availability), plus core ArcKit governance |
+| `uae-agentic-transformation` | `arckit-uae` | UAE Federal Agentic AI Transformation — focused 24-month playbook for the 23 April 2026 Cabinet framework's 50%-of-services-by-April-2028 target; ADRs reshaped around agentic architecture (orchestration, human-in-the-loop, observability, kill-switch); PLAN + ROADMAP timeboxed to the 24-month window |
+| `ca-federal-fitaa` | `arckit-ca` | Canadian Federal — FITAA, ITSG-33, GC Digital Standards |
+| `au-federal` | `arckit-au` | Australian Federal / DISP-supplier — ASD Essential Eight, ISM, DTA DSS, Privacy Act 1988, OAIC NDB, PSPF, AI Assurance, DISP attestation (35 targets, 9 waves) |
### Recipe schema (v1)
@@ -390,7 +395,7 @@ State written by older versions (`state_format_version: "0.3"`) is read-compatib
## Failure modes to watch for
- **Subagent doesn't have access to `arckit:*` skills** — detected by the smoke-test in step 6 of the run order; halts the build before any wave dispatches. Workaround if smoke-test fails: load the skill prompt in main context once, pass as plain text to agent (deferred to v0.4+).
-- **Recipe file missing or malformed** — halt at step 3 with the exact YAML parse error and the precedence list of paths checked.
+- **Recipe file missing or malformed** — halt at step 3 with the exact YAML parse error and the precedence list of paths checked. If a community recipe is requested but the corresponding community plugin isn't installed, surface a concrete install command: `"Recipe 'uae-federal-ai' not found. It ships in the arckit-uae community plugin. Install with: claude plugin install arckit-uae"`. The orchestrator maps recipe name to expected plugin via the built-in recipes table; recipes the table doesn't know about fall back to the generic precedence-list error.
- **Skill expects interactive Q&A** — the worker prompt's defaults table covers this. The recipe's `args` field should be specific enough to skip interaction in the first place.
- **Output path collision** — two targets writing to same path. Recipe must have unique `(output.project, output.type, output.subfolder, multi_instance)` tuples for non-multi-instance targets, and unique `id`s for multi-instance ones.
- **State drift** — user manually deletes/edits artefacts after build. Deletions are caught by `test -f`. Edits are caught by the SHA-256 hash check (§ "Input-hash change detection") — the edited artefact's downstream targets are marked stale and rebuilt in dep order. Use `--skip-hash-check` to bypass.
diff --git a/arckit-codex/.codex-plugin/plugin.json b/arckit-codex/.codex-plugin/plugin.json
index 894554c9..12617db2 100644
--- a/arckit-codex/.codex-plugin/plugin.json
+++ b/arckit-codex/.codex-plugin/plugin.json
@@ -1,6 +1,6 @@
{
"name": "arckit-codex",
- "version": "4.21.0",
+ "version": "4.22.0",
"description": "Enterprise architecture governance, procurement, research, and delivery workflows for Codex.",
"author": {
"name": "ArcKit",
diff --git a/arckit-codex/commands/arckit.au-ai-assurance.md b/arckit-codex/commands/arckit.au-ai-assurance.md
new file mode 100644
index 00000000..ea74b2d5
--- /dev/null
+++ b/arckit-codex/commands/arckit.au-ai-assurance.md
@@ -0,0 +1,125 @@
+---
+description: "[COMMUNITY] Generate an AI assurance assessment for Australian Government / regulated-sector AI systems covering DTA AI Policy v2.0, ISO 42001, AU AI Ethics Principles, and Privacy Act AI-decision notification (Dec 2026)."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified AI ethics specialist, Privacy Officer, or DTA-aligned AI assurance assessor before reliance. DTA AI Policy v2.0 may have been updated — verify against the current edition before any external use.
+
+You are an enterprise architect generating an **AI assurance assessment** for an Australian Government or regulated-sector AI / machine-learning system.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+Australia's AI assurance landscape combines several frameworks that together govern AI deployment in government and regulated industry:
+
+- **DTA Responsible AI Policy v2.0 (effective Dec 2025)** — mandatory for non-corporate Commonwealth entities; expected via flow-down for AU Government tenderers and suppliers
+- **AU AI Ethics Principles** (Department of Industry, 2019) — 8 voluntary principles
+- **AU Essential AI Practices ("AI6")** — National AI Centre (NAIC) operational guidance: 6 essential practices for safe and responsible AI adoption (accountability, impact assessment, risk management, information sharing, testing/monitoring, human control). Foundations + Implementation Guidance issued via ai.gov.au.
+- **ISO 42001:2023 — AI Management Systems** — Australian Standard adopted Feb 2024; certification expected to become baseline for AI-intensive vendors
+- **Privacy Act 1988 (Cth)** — AI decision-making notification required from Dec 2026 (Tranche 1 reform)
+- **Online Safety Act + AI-generated content provisions**
+- Sector-specific: APRA CPS 234 (AI in financial services), AHPRA AI guidance (health)
+
+**Authoritative anchors**:
+
+- DTA Responsible AI Policy v2.0 —
+- AU AI Ethics Principles —
+- AU Essential AI Practices (AI6) — Guidance for AI Adoption: Foundations —
+- AU Essential AI Practices — Implementation Guidance —
+- Privacy Act 1988 (Cth) —
+
+## Process
+
+1. Read prerequisites:
+ - Project's PIA artefact (`ARC-{P}-AUPIA-v*`) — APP 6 + APP 11 cross-reference
+ - Project's DATA artefact — for training/inference data classification
+ - Project's REQ artefact — extract AI-specific requirements
+ - Project's RISK artefact — existing AI risks
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-ai-assurance-template.md`
+ - Then: `.arckit/templates-custom/au-ai-assurance-template.md`
+ - Fallback: `.arckit/templates/au-ai-assurance-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUAIA --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **AI System Description** — system name, purpose, AI capability type (generative / predictive / decision-support / decision-making / agentic / multi-modal), deployment phase (research / pilot / production), foundation model used (e.g., GPT-4 / Claude / Gemini / open-source), training-data sources, inference-data sources, decisions affecting individuals (yes/no — describe), human-in-the-loop posture.
+
+ - **DTA Responsible AI Policy v2.0 Compliance** — assessment against the policy's six accountabilities:
+ 1. **Accountability** — designated AI accountable officer
+ 2. **Transparency** — public AI use disclosure
+ 3. **Risk-based approach** — AI risk assessment performed
+ 4. **Quality data + design integrity** — data lineage, model documentation
+ 5. **Privacy + security** — cross-reference PIA + ISM + E8
+ 6. **Human oversight + redress** — human review mechanism, individual appeal pathway
+
+ - **AU AI Ethics Principles Alignment** — assess against the 8 principles:
+ 1. Human, societal and environmental wellbeing
+ 2. Human-centred values
+ 3. Fairness
+ 4. Privacy protection and security
+ 5. Reliability and safety
+ 6. Transparency and explainability
+ 7. Contestability
+ 8. Accountability
+
+ For each principle: status (Aligned / Partial / Not Aligned), evidence, gap, mitigation.
+
+ - **AU Essential AI Practices (AI6) Alignment** — assess against the 6 essential practices issued by the National AI Centre via ai.gov.au:
+ 1. Decide who is accountable
+ 2. Understand impacts and plan accordingly
+ 3. Measure and manage risks
+ 4. Share essential information
+ 5. Test and monitor
+ 6. Maintain human control
+
+ For each practice: status (Implemented / Partial / Not Implemented / Not Applicable), evidence (artefact references where possible), gap, action. Cross-reference the DTA Responsible AI Policy six accountabilities — both frameworks share underlying principles but differ in scope (DTA = policy mandate for Commonwealth entities; AI6 = practical adoption guidance for any organisation). The AI6 *Implementation Guidance* on ai.gov.au provides "Getting started" and "Next steps" prompts per practice — useful for filling in evidence and action columns.
+
+ - **ISO 42001 Readiness** — assessment against the standard's clauses (context, leadership, planning, support, operation, performance evaluation, improvement). Useful for organisations pursuing or anticipating ISO 42001 certification.
+
+ - **Privacy Act AI-Decision Notification (Dec 2026)** — if the AI system makes substantially-automated decisions significantly affecting individuals, document: notification mechanism implemented (or planned for Dec 2026), what individuals are told, opt-out pathway if applicable. Cross-reference AUPIA APP 6 + APP 11.
+
+ - **Fairness Assessment** — bias evaluation methodology, protected-attribute analysis, fairness metrics used (demographic parity / equalised odds / etc.), test results across population segments, residual fairness risks.
+
+ - **Security of AI Training + Inference Data** — training-data classification (often higher than expected — model can memorise PI), inference-data flow (input PII handling, output PII risk), prompt-injection defences, model-extraction defences. Cross-reference E8 posture + ISM applicability.
+
+ - **Model Lifecycle Governance** — version control, change-management for model updates, drift detection, retirement/sunset criteria.
+
+ - **Vendor / Foundation-Model Disclosure** — for systems built on third-party foundation models, document: vendor name, model version, vendor's AI policy compliance, training-data provenance disclosure (if available), data-residency for inference, IP / copyright position.
+
+ - **Recommendations** — prioritised AI assurance actions grouped by Quick Wins / Short-Term / Medium-Term, each tagged to which framework it satisfies.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. DTA AI Policy v2.0, AU AI Ethics Principles, AU Essential AI Practices (AI6) — Foundations + Implementation Guidance, ISO 42001 (Australian Standard), and Privacy Act 1988 MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the DTA + Ethics Principles compliance summary table).
+
+## Important Notes
+
+- DTA AI Policy v2.0 applies to **non-corporate Commonwealth entities** directly. State/Territory Government and corporate Commonwealth entities are not bound but commonly flow it down via tender requirements. Suppliers to those entities should track for contractual flow-down.
+- The **December 2026 Privacy Act AI-decision notification** is a deadline. Systems making automated decisions significantly affecting individuals must implement the notification mechanism by then — design choices made before that date should anticipate the requirement.
+- Foundation-model use is a supply-chain concern. Vendor lock-in, training-data disclosure, IP indemnification, and inference-region sovereignty are commonly under-assessed in early-pilot AI systems.
+- Bias / fairness assessment is methodology-dependent. Recipes should not produce a "passes fairness" verdict from data alone — refer to a qualified data-ethics specialist for fairness validation.
+- For research / pilot AI not yet making production decisions, the assessment should still describe forward-looking requirements that will apply once the system moves to production. This avoids "we'll add it later" technical debt.
+- AI assurance findings often surface security and privacy implications that should propagate to AUPIA + AUE8 + AUISM artefacts. Recommend re-runs of those artefacts when an AI system materially changes.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit:au-pia` -- AI fairness + automated decision-making findings feed APP 6 + APP 11 in the PIA.
+- `/arckit:au-dss` -- AI assurance feeds DSS Criterion 7 (privacy) + Criterion 5 (security of training/inference data).
+- `/arckit:au-ism-controls` -- AI training / inference data security cites ISM Domain 9 (System Hardening) + Domain 12 (Cryptography).
+- `/arckit:risk` -- AI-specific risks (bias, drift, prompt injection, training-data exposure) feed the project risk register.
diff --git a/arckit-codex/commands/arckit.au-disp-attestation.md b/arckit-codex/commands/arckit.au-disp-attestation.md
new file mode 100644
index 00000000..64aebf3e
--- /dev/null
+++ b/arckit-codex/commands/arckit.au-disp-attestation.md
@@ -0,0 +1,110 @@
+---
+description: "[COMMUNITY] Generate a DISP (Defence Industry Security Program) Member self-attestation pack covering E8 ML2, ISM applicability, governance, personnel security, and incident reporting — supports DISP Levels 1, 2, 3."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified DISP-experienced security officer or DISP advisor before submission to Defence. DISP requirements may be updated — verify against the current DISP Membership Pack before any external use.
+
+You are an enterprise architect generating a **DISP (Defence Industry Security Program) Member self-attestation pack** for an Australian organisation supplying products or services to Defence.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Defence Industry Security Program (DISP) is the security accreditation framework for Australian organisations supplying Defence. DISP Membership has three levels (Levels 1, 2, 3 — formerly Entry, Level 1, Level 2 in earlier guidance) with progressively-deeper governance, personnel, ICT, physical, and supply-chain security obligations. Essential Eight ML2 has been the minimum cyber baseline for DISP members since 2025; ISM applicability scales with the level. The attestation pack is the supplier's self-evidence document referenced during DISP application, audit, and renewal.
+
+**Authoritative anchor**: Defence Industry Security Program —
+
+**Key references**:
+
+- DISP Membership Pack (current edition) — application form + evidence requirements
+- ASD Essential Eight Maturity Model (ML2 minimum for DISP) —
+- ASD Information Security Manual —
+- Protective Security Policy Framework (PSPF)
+- Defence Security Principles Framework (DSPF) — referenced sections only
+- Privacy Act 1988 (Cth) — APP 11 alignment
+
+## Process
+
+1. Read prerequisites:
+ - The project's E8 posture artefact (`ARC-{P}-AUE8-v*`) — primary input
+ - The project's ISM applicability statement (`ARC-{P}-AUISM-v*`) — primary input
+ - The project's PIA (`ARC-{P}-AUPIA-v*`) — APP 11 cross-reference
+ - The project's PSPF assessment (`ARC-{P}-AUPSPF-v*`) — physical / personnel / information security evidence
+ - The project's RISK artefact — for SecRisk register integration
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-disp-attestation-template.md` (user override)
+ - Then: `.arckit/templates-custom/au-disp-attestation-template.md`
+ - Fallback: `.arckit/templates/au-disp-attestation-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if needed.
+
+4. Use `scripts/bash/generate-document-id.sh AUDISP --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Organisation Profile** — entity name, ABN, primary business activity, Defence contracts in scope, headcount, sites, foreign ownership / control / influence (FOCI) declaration.
+
+ - **DISP Level Sought** — Level 1 / Level 2 / Level 3, regulatory driver (specific contract requirement, panel mandate, anticipated tender pipeline), justification of level chosen.
+
+ - **Security Officer Designation** — Chief Security Officer (CSO) name + role + authority, deputy / backup CSO, contact details, vetting status. **DISP requires a named, suitably-cleared CSO with authority across the four security domains.**
+
+ - **Four Security Domains Coverage** — DISP requires evidence across four domains:
+ 1. **Governance** — security policy, risk management, audit, incident management, change control
+ 2. **Personnel Security** — security clearances appropriate to work, security awareness training, separation of duties, off-boarding
+ 3. **Physical Security** — facility security, ICT equipment security, equipment lifecycle (cloud-only systems may inherit much of this from cloud provider's IRAP)
+ 4. **Information & Cyber Security** — Essential Eight ML2 minimum, ISM applicability, cryptography, gateway, monitoring, BCP
+
+ For each domain, document:
+ - Current implementation state (cite E8 posture, ISM applicability, supporting policies)
+ - Evidence references (artefact IDs + document register)
+ - Gap description
+ - Remediation plan with target dates
+ - Sign-off statement by accountable officer
+
+ - **Essential Eight ML2 Evidence Per Strategy** — for each of the 8 E8 strategies, summarise the current ML position and evidence supporting ML2 attestation. Cite the AUE8 artefact directly.
+
+ - **ISM Applicability Highlights** — beyond E8, summarise which ISM domains apply, current implementation summary, and identify any ISM gaps that materially affect DISP attestation. Cite the AUISM artefact.
+
+ - **Foreign Ownership, Control or Influence (FOCI) Declaration** — disclose any foreign ownership > 5%, foreign-board-member arrangements, foreign-supply-chain dependencies, foreign-personnel access. DISP Level 2 + 3 require FOCI mitigation plans where applicable.
+
+ - **Supply Chain Security** — disclose Tier 1 suppliers (MSPs, SaaS, cloud), supply-chain attestations held (SOC 2 / ISO 27001 / IRAP), supply-chain risk management process.
+
+ - **Incident Response & Reporting** — incident response plan summary, 24-hour rapid notification capability for Defence-relevant incidents, OAIC NDB scheme integration, evidence of last incident response exercise. Cite NDB playbook (`ARC-{P}-AUNDB-v*`) if available.
+
+ - **Security Awareness Training** — DISP-mandated security awareness training programme, completion rate, refresher cadence, security-clearance-holder additional briefings (pre/post-leave for cleared personnel).
+
+ - **Annual Self-Audit Plan** — DISP requires annual self-audit; describe scope, methodology, evidence retention.
+
+ - **Attestation Statement** — formal CSO + Director sign-off statement attesting to the accuracy of the pack, with signature blocks, date, and re-attestation cadence.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The DISP Membership Pack (with edition) MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the Four Security Domains coverage table).
+
+## Important Notes
+
+- The pack is a **self-attestation**, not a third-party assurance. Defence reserves the right to audit. Artefact tone should be evidence-based and conservative — do not claim controls not yet implemented.
+- The CSO designation is a hard requirement. If no CSO is named in the source artefacts, the pack must explicitly flag this as an outstanding action — it cannot be filled in by the recipe.
+- For Level 2 + 3 members supplying classified Defence work, security clearances of personnel handling that work must be evidenced. Records of clearance levels held may be sensitive — reference by clearance level (Baseline / NV1 / NV2 / PV) not by individual name.
+- Cloud-only systems that inherit Physical Security from an IRAP-assessed cloud provider should explicitly cite the cloud provider's IRAP scope statement, not generic marketing.
+- The pack should integrate with the project's risk register — material residual risks should appear both in the risk register and in the DISP pack's gap descriptions.
+- For DISP renewal cycles, the artefact should produce a redline-friendly format so year-on-year changes are easy to track.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit:au-e8-posture` -- E8 ML2 evidence per strategy is a primary input to the DISP attestation pack.
+- `/arckit:au-ism-controls` -- ISM applicability statement is a primary input — controls beyond E8 mandated by DISP level.
+- `/arckit:au-pia` -- Privacy Act + APP 11 alignment cited in attestation pack.
+- `/arckit:au-ndb-playbook` -- Notifiable Data Breach response is the operational complement to DISP incident reporting.
diff --git a/arckit-codex/commands/arckit.au-dss.md b/arckit-codex/commands/arckit.au-dss.md
new file mode 100644
index 00000000..2b131062
--- /dev/null
+++ b/arckit-codex/commands/arckit.au-dss.md
@@ -0,0 +1,102 @@
+---
+description: "[COMMUNITY] Generate a DTA Digital Service Standard compliance assessment for Australian Government digital services against all 13 criteria."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified DTA assessor or digital delivery lead before reliance. The DTA Digital Service Standard was refreshed in July 2025 — verify criteria against the current published version.
+
+You are an enterprise architect generating a **DTA Digital Service Standard compliance assessment** for an Australian Government digital service.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Digital Transformation Agency (DTA) Digital Service Standard sets the mandatory criteria that Australian Government digital services must meet. Services subject to the Standard must demonstrate compliance at key assessment points. The Standard replaced the earlier Digital Service Standard (2016) with a refreshed version in July 2025.
+
+**Authoritative anchor**: DTA Digital Service Standard —
+
+**Key Australian Digital Service References**:
+
+- DTA Digital Service Standard (July 2025 refresh)
+- DTA Service Design and Delivery Process
+- Digital Government Strategy
+- Web Content Accessibility Guidelines (WCAG) 2.2 Level AA
+- Style Manual for Australian Government (style.gov.au)
+- DTA Content Guide
+- Whole of Government Digital and ICT Investment Oversight Framework
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract user-facing requirements, accessibility requirements, technology choices
+ - The project's STKE artefact — extract user research, stakeholder engagement evidence
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - **First**, check `.arckit/templates-custom/au-dss-template.md` (user override)
+ - **Then**, `.arckit/templates-custom/au-dss-template.md`
+ - **Fallback**, `.arckit/templates/au-dss-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUDSS --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Service Context** — service name, owning agency/department, service phase (Discovery / Alpha / Beta / Live), user base (public-facing / internal / both), annual transaction volume (if known).
+
+ - **13-Criterion Assessment** — one assessment block per Digital Service Standard criterion:
+ 1. **Understand user needs** — research conducted with real users, needs documented
+ 2. **Have a multidisciplinary team** — team composition, capability coverage, DDaT roles
+ 3. **Agile and user-centred process** — delivery methodology, iteration cadence, user feedback loops
+ 4. **Understand tools and systems** — technology landscape mapped, legacy dependencies identified
+ 5. **Make it secure** — security posture, E8 alignment, threat assessment, incident response
+ 6. **Consistent and responsive design** — design system usage, responsive breakpoints, device testing
+ 7. **Protect users' privacy** — PIA completed, APP compliance, data minimisation, consent
+ 8. **Make source code open** — open-source strategy, code repository, licence
+ 9. **Make it accessible** — WCAG 2.2 AA compliance, assistive technology testing, accessibility statement
+ 10. **Test the service** — testing strategy (unit, integration, UAT, accessibility, performance, security)
+ 11. **Measure performance** — KPIs defined (completion rate, user satisfaction, cost per transaction, digital take-up)
+ 12. **Don't forget the non-digital experience** — assisted digital, phone, in-person channel design
+ 13. **Encourage everyone to use the digital service** — channel shift strategy, take-up targets
+
+ For each criterion, document:
+ - Assessment status: ✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A
+ - Evidence summary (what demonstrates compliance)
+ - Gap description (what is missing)
+ - Remediation actions with owner and target date
+
+ - **Compliance Summary** — table: Criterion # | Criterion Name | Status | Gap Count
+
+ - **Assessment Readiness** — for services approaching Alpha/Beta/Live assessment, identify the top 3 risks to passing and recommended mitigations.
+
+ - **Recommendations** — prioritised list of actions to improve compliance posture, grouped by criterion priority.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The DTA Digital Service Standard MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the compliance summary table showing status per criterion).
+
+## Important Notes
+
+- The DTA Digital Service Standard applies to **all new and redesigned Australian Government digital services**. Existing services may be assessed when undergoing significant change.
+- Criterion 5 (Make it secure) should cross-reference the ASD Essential Eight assessment (`/arckit:au-e8-posture`) if one exists.
+- Criterion 7 (Protect users' privacy) should cross-reference the Privacy Impact Assessment (`/arckit:au-pia`) if one exists.
+- Criterion 9 (Make it accessible) requires WCAG 2.2 Level AA as the minimum standard for Australian Government services.
+- The Standard is assessed at Alpha, Beta, and Live phases — the depth of evidence expected increases at each gate.
+- This assessment is analogous to the UK GDS Service Standard assessment (`/arckit:service-assessment`) but uses Australian criteria and governance structures.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit:au-e8-posture` -- DSS Criterion 5 (Make it secure) feeds into the E8 maturity posture assessment.
+- `/arckit:au-pia` -- DSS Criterion 7 (Protect users' privacy) feeds into the Privacy Impact Assessment.
+- `/arckit:risk` -- DSS gaps surface as delivery and compliance risks for the risk register.
diff --git a/arckit-codex/commands/arckit.au-e8-posture.md b/arckit-codex/commands/arckit.au-e8-posture.md
new file mode 100644
index 00000000..79886554
--- /dev/null
+++ b/arckit-codex/commands/arckit.au-e8-posture.md
@@ -0,0 +1,97 @@
+---
+description: "[COMMUNITY] Generate an ASD Essential Eight maturity posture assessment for Australian Government projects against all eight mitigation strategies at ML0–ML3."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified CISO or security assessor before reliance. Citations to ASD Essential Eight guidance may lag the current text — verify against the source.
+
+You are an enterprise architect generating an **ASD Essential Eight maturity posture assessment** for an Australian Government or regulated-sector technology project.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Australian Signals Directorate (ASD) Essential Eight is the baseline cyber-security mitigation framework for Australian Government entities. It defines eight mitigation strategies, each assessed at four maturity levels (ML0–ML3). Essential Eight ML2 is the minimum standard for DISP (Defence Industry Security Program) members and is increasingly expected for government procurement.
+
+**Authoritative anchor**: ASD Essential Eight Maturity Model —
+
+**Key Australian Security References**:
+
+- ASD Essential Eight Maturity Model (current edition)
+- ASD Information Security Manual (ISM) —
+- Protective Security Policy Framework (PSPF) —
+- Australian Cyber Security Strategy 2023–2030
+- DISP Essential Eight ML2 mandate (effective 2025)
+- Privacy Act 1988 (Cth) — security of personal information (APP 11)
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract NFR-SEC requirements, data classification, compliance obligations
+ - The project's RISK artefact — extract existing security risks and mitigations
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - **First**, check `.arckit/templates-custom/au-e8-posture-template.md` (user override)
+ - **Then**, `.arckit/templates-custom/au-e8-posture-template.md`
+ - **Fallback**, `.arckit/templates/au-e8-posture-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUE8 --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **System Context** — system name, classification level (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET), deployment model (cloud / on-premise / hybrid), IRAP assessment status, data sovereignty position.
+
+ - **Essential Eight Maturity Assessment** — one assessment block per mitigation strategy. For each of the eight strategies:
+ 1. **Application Control** — only approved applications execute on systems
+ 2. **Patch Applications** — security patches for applications applied within timeframes
+ 3. **Configure Microsoft Office Macro Settings** — macros blocked or restricted per policy
+ 4. **User Application Hardening** — web browsers, email clients, Office configured to block untrusted content
+ 5. **Restrict Administrative Privileges** — admin access validated, separated, and time-limited
+ 6. **Patch Operating Systems** — OS patches applied within timeframes, unsupported OS replaced
+ 7. **Multi-Factor Authentication** — MFA on all remote access, privileged access, and data repositories
+ 8. **Regular Backups** — backups performed, tested, and stored securely per retention schedule
+
+ For each strategy, document:
+ - Current maturity level (ML0 / ML1 / ML2 / ML3) with evidence
+ - Target maturity level with rationale (regulatory driver or risk appetite)
+ - Gap description (specific controls not yet implemented)
+ - Remediation actions with owner and target date
+ - Residual risk if gap persists
+
+ - **Maturity Summary Matrix** — 8-row table: Strategy | Current ML | Target ML | Gap Count | Priority (Critical / High / Medium / Low)
+
+ - **DISP Compliance Position** — if the entity is a DISP member, assess whether current posture meets ML2 minimum across all eight strategies. Flag any strategy below ML2 as a DISP non-compliance risk.
+
+ - **Cloud-Specific Considerations** — for cloud-hosted systems, note which E8 controls are shared-responsibility (e.g., OS patching on PaaS vs IaaS), which are vendor-managed (e.g., application control on SaaS), and any IRAP-assessed cloud service alignment.
+
+ - **Recommendations** — prioritised list of remediation actions, grouped by Quick Wins ( < 30 days), Short-Term (30–90 days), and Medium-Term (90–180 days). Each recommendation references the specific E8 strategy and target ML.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The ASD Essential Eight Maturity Model MUST appear in the Document Register with its primary URL and verification date.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the maturity summary matrix showing current ML vs target ML per strategy).
+
+## Important Notes
+
+- ML0 means the strategy is **not implemented** — it does not mean "assessed and found satisfactory at a low level." Explicitly state this distinction.
+- Each maturity level has specific sub-controls defined by ASD. Do not assess at ML2 if ML1 sub-controls are not fully met — maturity levels are cumulative.
+- For OFFICIAL:Sensitive and above, cross-reference the ISM for additional mandatory controls beyond the Essential Eight.
+- The Essential Eight is a **mitigation** framework, not a comprehensive security standard. Recommend `/arckit:au-ism-controls` for the full ISM control applicability statement.
+- For energy-sector projects, recommend `/arckit:au-aescsf` as the AESCSF capability domains build on and extend the E8 baseline.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit:au-ism-controls` -- E8 posture feeds the ISM control applicability statement — target ML drives which ISM controls are mandatory.
+- `/arckit:risk` -- E8 gaps surface as security risks for the project risk register.
diff --git a/arckit-codex/commands/arckit.au-ism-controls.md b/arckit-codex/commands/arckit.au-ism-controls.md
new file mode 100644
index 00000000..83bea368
--- /dev/null
+++ b/arckit-codex/commands/arckit.au-ism-controls.md
@@ -0,0 +1,113 @@
+---
+description: "[COMMUNITY] Generate an ASD Information Security Manual (ISM) control applicability statement for Australian Government projects, scoped to the system's classification and supporting DISP attestation."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified IRAP Assessor or CISO before reliance. ISM is updated quarterly — verify control identifiers against the current edition before any external use.
+
+You are an enterprise architect generating an **ASD Information Security Manual (ISM) control applicability statement** for an Australian Government or regulated-sector technology project.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Australian Signals Directorate (ASD) Information Security Manual (ISM) is the comprehensive set of cyber-security controls for Australian Government information systems. Where the Essential Eight is a mitigation framework targeting attack-vector defence, the ISM is the comprehensive control set covering governance, personnel, physical, communications, ICT system, networking, cryptography, gateway, data-transfer, evaluation, working-off-site, and incident-response domains. ISM compliance is the core technical-controls evidence for PSPF Information Security outcome and a primary input to DISP attestation.
+
+**Authoritative anchor**: ASD Information Security Manual —
+
+**Key Australian Security References**:
+
+- ASD Information Security Manual (current edition; updated quarterly)
+- Protective Security Policy Framework (PSPF) —
+- ASD Essential Eight Maturity Model (mitigation subset of ISM)
+- Defence Industry Security Program (DISP) requirements
+- IRAP (Information Security Registered Assessors Program) — control assurance methodology
+- Privacy Act 1988 (Cth) — APP 11 alignment
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract NFR-SEC requirements, data classification, compliance obligations
+ - The project's RISK artefact — extract existing security risks
+ - The project's E8 posture artefact (`ARC-{P}-AUE8-v*`) if available — provides E8 sub-control evidence
+ - The project's DATA artefact — for classification-driven control scoping
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-ism-controls-template.md` (user override)
+ - Then: `.arckit/templates-custom/au-ism-controls-template.md`
+ - Fallback: `.arckit/templates/au-ism-controls-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist.
+
+4. Use `scripts/bash/generate-document-id.sh AUISM --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **System Context** — system name, classification level (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET), deployment model, IRAP assessment status, sovereignty position. Classification drives applicability — controls applicable at OFFICIAL:Sensitive are a subset of those at PROTECTED.
+
+ - **Control Domain Applicability Matrix** — table covering all 17 ISM control areas (15 ASD ISM chapter domains plus 2 cross-cutting areas — Cloud/IaaS and Working-Off-Site), marking applicability per system classification:
+ 1. **Cyber Security Governance** — security risk management, security documentation, change management
+ 2. **Cyber Security Incidents** — detection, reporting, response, business continuity
+ 3. **Outsourced Services** — managed service providers, cloud, supply chain
+ 4. **Security Documentation** — system security plans, security risk management plans
+ 5. **Personnel Security** — clearance levels, awareness training, separation of duties
+ 6. **Physical Security** — facilities, equipment, ICT equipment lifecycle
+ 7. **Communications Infrastructure** — fibre, cabling, telephony
+ 8. **ICT Equipment Security** — hardware lifecycle, media, sanitisation
+ 9. **System Hardening** — operating systems, applications, authentication, network
+ 10. **System Management** — administration, monitoring, maintenance, vulnerability mgmt
+ 11. **System Monitoring** — event logging, audit, security metrics
+ 12. **Cryptography** — cryptographic fundamentals, ASD-approved algorithms, key management
+ 13. **Gateway Security** — gateway architecture, content filtering, DLP
+ 14. **Data Transfer** — between domains, between systems, data import/export
+ 15. **Cloud and IaaS Considerations** — IRAP assessment status, sovereign cloud, shared responsibility
+ 16. **Working-Off-Site Security** — remote work, mobile devices, BYOD
+ 17. **Evaluation Activities** — Common Criteria, FIPS, vendor product testing
+
+ - **Per-Domain Control Applicability Assessment** — for each in-scope domain, document:
+ - Applicability rationale (which controls apply at the system's classification level)
+ - Current implementation status: ✅ Implemented / ⚠️ Partial / ❌ Not Implemented / N/A
+ - Evidence supporting the status (cite E8 posture artefact, IRAP report, vendor attestations)
+ - Gap description with specific ISM control IDs not yet met
+ - Remediation actions with owner and target date
+ - Compensating controls if applicable
+
+ - **ISM-to-E8 Cross-Reference** — show which E8 strategies map to which ISM domains. Reinforces the E8-as-mitigation-subset framing for governance audiences.
+
+ - **Compliance Summary** — table summarising domain-by-domain compliance posture; overall ISM applicability score (controls implemented / controls applicable).
+
+ - **IRAP Assessment Position** — if the system holds or pursues IRAP assessment, note the IRAP scope, assessment date, residual risks accepted, and re-assessment cadence. For systems integrating with IRAP-assessed cloud services, note the inherited control posture.
+
+ - **Recommendations** — prioritised remediation actions grouped by Quick Wins ( < 30 days), Short-Term (30–90 days), Medium-Term (90–180 days). Each recommendation references the specific ISM control ID(s).
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The ASD ISM (with edition / publication date) MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the Compliance Summary table showing per-domain status).
+
+## Important Notes
+
+- ISM controls are tagged with applicability flags (ALL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET / TOP SECRET). The applicability statement must select controls appropriate to the *highest classification of information processed*, not the *lowest*.
+- ISM is updated quarterly — control IDs and wording can change. The artefact should record the ISM edition / publication date used as a verification anchor.
+- For systems integrating with IRAP-assessed cloud services, note explicit shared-responsibility — many ISM controls inherit from the cloud provider's IRAP attestation. Cite the IRAP scope statement, not the cloud provider's marketing.
+- Cross-reference the E8 posture artefact wherever an ISM control maps to an E8 sub-control — avoids duplication and keeps the two artefacts consistent.
+- For DISP members or systems supporting Defence work, scope the Personnel Security and Physical Security domains carefully — these are commonly under-assessed in cloud-only environments.
+- The Cyber Security Incidents domain should reference the project's NDB playbook (`/arckit:au-ndb-playbook`) for personal-information breach scenarios.
+- The Outsourced Services domain must include MSP-held admin role boundaries, contractual security-control flow-down, and supply-chain attestation review.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit:au-disp-attestation` -- ISM applicability is a primary input to the DISP Member self-attestation pack.
+- `/arckit:au-pspf` -- ISM is the technical-controls instantiation of PSPF Information Security outcome — feeds the PSPF assessment.
+- `/arckit:au-e8-posture` -- E8 is a mitigation subset of ISM. The ISM applicability statement extends beyond E8 to cover personnel security, physical security, and information governance controls.
+- `/arckit:risk` -- ISM control gaps surface as security risks for the project risk register.
diff --git a/arckit-codex/commands/arckit.au-ndb-playbook.md b/arckit-codex/commands/arckit.au-ndb-playbook.md
new file mode 100644
index 00000000..ef1d246a
--- /dev/null
+++ b/arckit-codex/commands/arckit.au-ndb-playbook.md
@@ -0,0 +1,112 @@
+---
+description: "[COMMUNITY] Generate a Notifiable Data Breach (NDB) scheme response playbook under Privacy Act 1988 Part IIIC — eligible-data-breach test, 30-day OAIC notification timeline, individual notification, containment, and lessons-learned framework."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a Privacy Officer and legal counsel before adoption. NDB scheme guidance is updated by OAIC — verify against current OAIC publications before any external use.
+
+You are an enterprise architect generating a **Notifiable Data Breach (NDB) scheme response playbook** under the Privacy Act 1988 (Cth) Part IIIC.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Notifiable Data Breach (NDB) scheme under Privacy Act 1988 (Cth) Part IIIC requires APP entities (Australian Government agencies + private organisations subject to the Privacy Act) to notify the **OAIC and affected individuals** when an "eligible data breach" of personal information occurs and is likely to result in serious harm.
+
+The NDB scheme has three statutory tests:
+
+1. **Unauthorised access to / disclosure of, or loss of, personal information**
+2. **Likely to result in serious harm** to one or more individuals
+3. **Cannot be remediated through reasonable steps** to prevent the serious harm
+
+The notification clock is **30 days** to OAIC + affected individuals from the time the entity has reasonable grounds to believe an eligible data breach has occurred. Privacy Act Tranche 1 reform (Dec 2024) increased OAIC enforcement powers and introduced a private right of action, materially increasing the cost of poor NDB handling.
+
+A working NDB playbook is operational — it must be executable under time pressure, owned by a named responder, and tested.
+
+**Authoritative anchors**:
+
+- Privacy Act 1988 (Cth) Part IIIC —
+- OAIC NDB scheme guidance —
+
+## Process
+
+1. Read prerequisites:
+ - The project's PIA (`ARC-{P}-AUPIA-v*`) — APP 11 cross-reference
+ - The project's E8 posture (`ARC-{P}-AUE8-v*`) — security baseline
+ - The project's ISM applicability (`ARC-{P}-AUISM-v*`) — Domain 2 (Cyber Security Incidents)
+ - The project's RISK artefact
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-ndb-playbook-template.md`
+ - Then: `.arckit/templates-custom/au-ndb-playbook-template.md`
+ - Fallback: `.arckit/templates/au-ndb-playbook-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUNDB --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Entity Profile** — APP entity status, Privacy Officer designation, accountable officer for NDB response, business hours + after-hours contact details, key incident-team roles.
+
+ - **NDB Eligibility Test** — explicit decision tree:
+ 1. Has there been unauthorised access to / disclosure of, or loss of, personal information?
+ 2. Is serious harm likely to result?
+ 3. Can the entity remediate through reasonable steps to prevent the serious harm?
+
+ If 1 + 2 = Yes and 3 = No → eligible data breach → notify within 30 days.
+
+ - **30-Day Timeline Plan** — day-by-day milestones from Day 0 (becoming aware of suspected breach) through Day 30 (OAIC + individual notification deadline):
+ - Day 0–1: Detect, contain, assess + activate playbook
+ - Day 1–7: Investigate, scope, classify
+ - Day 7–14: Eligibility assessment, draft notifications
+ - Day 14–21: Legal review, executive sign-off, finalise notifications
+ - Day 21–30: OAIC notification, individual notifications, public statement (if required)
+
+ - **Roles & Responsibilities (RACI)** — Privacy Officer, Security Officer, CISO, Legal, Communications, accountable executive — clear responsibility matrix.
+
+ - **Detection + Containment Procedures** — how breaches become known to the playbook owner (SIEM alerts, customer reports, vendor disclosure, insider report); immediate containment steps; evidence preservation.
+
+ - **Assessment Procedure** — how to determine eligibility under the three statutory tests; serious-harm assessment criteria (financial loss, identity theft, emotional distress, physical safety, reputational harm); reasonable-steps mitigation to remove eligibility.
+
+ - **OAIC Notification Form Content** — what OAIC requires per the statutory form: nature of breach, kind of information involved, recommendations for affected individuals, contact details. Template language for use in the OAIC form.
+
+ - **Individual Notification Approach** — direct vs publication-based notification options, content requirements, channel decisions, language and accessibility considerations.
+
+ - **Communications Plan** — internal, external, media, regulator-coordinated. Pre-written holding statements + escalation triggers.
+
+ - **Post-Incident Review** — root cause analysis, lessons learned, control updates feeding back into AUE8 + AUISM + AUPIA artefacts.
+
+ - **Coordination With Other Reporting Obligations** — SOCI Act 12hr / 72hr (where applicable), DISP incident reporting, sectoral reporting (APRA, AHPRA, etc.). Single incident may trigger multiple obligations on different timelines.
+
+ - **Tabletop Exercise Plan** — annual tabletop scenario, evidence retention, lessons-learned cycle.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. Privacy Act 1988 + OAIC NDB scheme guidance MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the 30-day timeline summary).
+
+## Important Notes
+
+- The 30-day notification clock starts from "reasonable grounds to believe" an eligible breach has occurred — **not** from the breach itself, and **not** from confirmation. This is the most commonly misread part of the scheme. The recipe should make this distinction unambiguous.
+- The "reasonable steps to remediate" test is the off-ramp from notification — if the entity can prevent serious harm through containment / mitigation actions, no notification is required. But this needs to be assessed conservatively; OAIC will second-guess hindsight optimism.
+- For multi-jurisdictional incidents (e.g., breach affecting AU + NZ + EU residents), the 30-day clock is not the only timeline. EU GDPR is 72 hours; NZ Privacy Act is "as soon as practicable". The playbook should flag this for legal-counsel coordination.
+- "Serious harm" is a broad threshold including financial loss, identity theft, **emotional distress** (including humiliation), and **reputational harm**. It is materially broader than "real prospect of significant harm" some practitioners assume.
+- For SOCI-covered entities, the NDB 30-day clock runs in parallel with SOCI 12hr / 72hr cyber incident reporting. The playbook should explicitly coordinate both timelines so the 12hr SOCI report doesn't pre-commit positions before the NDB assessment is complete.
+- Pre-written holding statements and notification templates dramatically reduce time-to-notify under pressure. Recipes producing this artefact should include template language wherever possible.
+- The playbook is operational. It should be **tested** at least annually via tabletop exercise; the recipe should output an exercise scenario template as part of the deliverable.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit:au-pia` -- NDB playbook is the operational complement to AUPIA APP 11 mitigation; APP 11 references NDB.
+- `/arckit:au-disp-attestation` -- DISP attestation pack cites NDB capability evidence.
+- `/arckit:risk` -- NDB-relevant risks tagged into the project risk register.
diff --git a/arckit-codex/commands/arckit.au-pia.md b/arckit-codex/commands/arckit.au-pia.md
new file mode 100644
index 00000000..36fda142
--- /dev/null
+++ b/arckit-codex/commands/arckit.au-pia.md
@@ -0,0 +1,110 @@
+---
+description: "[COMMUNITY] Generate a Privacy Impact Assessment (PIA) for Australian Government entities under Privacy Act 1988 s33D, assessing compliance with all 13 Australian Privacy Principles (APPs)."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified Privacy Officer, DPO, or legal counsel before reliance. Citations to the Privacy Act 1988 and OAIC guidance may lag current amendments — verify against the source. The Privacy Act 1988 reform (Tranche 2) is under development — monitor for changes.
+
+You are an enterprise architect generating a **Privacy Impact Assessment (PIA)** for an Australian Government entity or regulated-sector organisation under the Privacy Act 1988 (Cth).
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+Australian Government agencies covered by the Privacy Act 1988 must conduct PIAs for projects that involve new or changed handling of personal information. Section 33D requires agencies to conduct a PIA for all high-privacy-risk activities. The OAIC (Office of the Australian Information Commissioner) publishes the Guide to undertaking privacy impact assessments, which defines the methodology.
+
+**Authoritative anchors**:
+
+- Privacy Act 1988 (Cth) —
+- OAIC Guide to undertaking privacy impact assessments —
+- Australian Privacy Principles (APPs) — Schedule 1 of the Privacy Act 1988
+- Privacy (Australian Government Agencies — Governance) APP Code 2017
+- OAIC Privacy regulatory action policy
+
+**Key Privacy Act 1988 Reform Context**:
+
+- Tranche 1 effective December 2024 — enhanced enforcement powers, tiered penalties, private right of action
+- AI decision-making notification required from December 2026
+- Tranche 2 under development — ~93 remaining proposals from Attorney-General's review
+- Small business exemption changes from 1 July 2026
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract data requirements (DR-*), NFR-SEC requirements, integration requirements (INT-*)
+ - The project's DATA artefact — extract entity model, PII fields, data flows
+ - The project's STKE artefact — extract data subjects, stakeholder privacy expectations
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - **First**, check `.arckit/templates-custom/au-pia-template.md` (user override)
+ - **Then**, `.arckit/templates-custom/au-pia-template.md`
+ - **Fallback**, `.arckit/templates/au-pia-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUPIA --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Project Description** — what the project does, what personal information is involved, why it is needed, who the data subjects are, estimated data volumes.
+
+ - **Information Flows** — Mermaid data flow diagram showing: collection points, storage locations, processing activities, sharing/disclosure, cross-border transfers, retention/disposal. Mark each flow with the APP that governs it.
+
+ - **13 APP Compliance Assessment** — one assessment block per Australian Privacy Principle:
+ 1. **APP 1** — Open and transparent management of personal information
+ 2. **APP 2** — Anonymity and pseudonymity
+ 3. **APP 3** — Collection of solicited personal information
+ 4. **APP 4** — Dealing with unsolicited personal information
+ 5. **APP 5** — Notification of the collection of personal information
+ 6. **APP 6** — Use or disclosure of personal information
+ 7. **APP 7** — Direct marketing
+ 8. **APP 8** — Cross-border disclosure of personal information
+ 9. **APP 9** — Adoption, use or disclosure of government related identifiers
+ 10. **APP 10** — Quality of personal information
+ 11. **APP 11** — Security of personal information
+ 12. **APP 12** — Access to personal information
+ 13. **APP 13** — Correction of personal information
+
+ For each APP, document:
+ - Applicability: Applies / Does Not Apply (with rationale)
+ - Compliance status: ✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant
+ - Evidence of compliance measures
+ - Privacy risk if non-compliant (likelihood × impact)
+ - Mitigation actions with owner and target date
+
+ - **Privacy Risk Register** — risks identified during APP assessment, scored by likelihood and impact, with mitigations and residual risk.
+
+ - **Sensitive Information Assessment** — identify whether any sensitive information (as defined in s 6 of the Privacy Act) is processed: racial or ethnic origin, political opinions, religious beliefs, sexual orientation, criminal record, health information, genetic information, biometric information, trade union membership. If yes, note the additional consent requirements under APP 3.3.
+
+ - **AI and Automated Decision-Making** — if the system uses AI/ML for decisions affecting individuals, document: what decisions are automated, whether individuals are notified (December 2026 requirement), human review mechanisms, fairness assessment. Cross-reference `/arckit:au-ai-assurance` if applicable.
+
+ - **Recommendations** — prioritised list of privacy-enhancing measures.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The Privacy Act 1988 and OAIC PIA Guide MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the APP compliance summary table).
+
+## Important Notes
+
+- This is the **Australian** PIA, not the UK DPIA. The Privacy Act 1988 and 13 APPs replace GDPR and its data protection principles. Do not reference GDPR, ICO, or UK data protection law.
+- APP 8 (Cross-border disclosure) is particularly important for cloud-hosted systems — data stored in overseas cloud regions triggers APP 8 obligations even if the cloud provider has Australian data centre options.
+- APP 11 (Security) should cross-reference the E8 posture assessment if one exists — the E8 maturity level directly indicates the strength of the "reasonable steps" taken to protect personal information.
+- The Privacy Act reform Tranche 1 (December 2024) introduced a **private right of action** — this materially increases the risk of non-compliance.
+- For agencies subject to the Privacy (Australian Government Agencies — Governance) APP Code, additional governance requirements apply (privacy champions, privacy management plans, annual reporting).
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit:au-dss` -- PIA findings feed DSS Criterion 7 (Protect users' privacy).
+- `/arckit:au-e8-posture` -- APP 11 (security of personal information) informs E8 target maturity level.
+- `/arckit:risk` -- Privacy risks surface in the project risk register.
diff --git a/arckit-codex/commands/arckit.au-pspf.md b/arckit-codex/commands/arckit.au-pspf.md
new file mode 100644
index 00000000..c43ed1cf
--- /dev/null
+++ b/arckit-codex/commands/arckit.au-pspf.md
@@ -0,0 +1,118 @@
+---
+description: "[COMMUNITY] Generate a Protective Security Policy Framework (PSPF) compliance assessment for Australian Government entities and contractors against the four security outcomes and 16 core requirements."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a PSPF-experienced security officer or government accreditation specialist. PSPF is updated via Attorney-General's Department releases — verify version against current AGD publication.
+
+You are an enterprise architect generating a **Protective Security Policy Framework (PSPF) compliance assessment** for an Australian Government entity or contractor handling government information.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Protective Security Policy Framework (PSPF) is the Australian Government's overarching security policy framework administered by the Attorney-General's Department. It establishes the security policy environment for all non-corporate Commonwealth entities and is increasingly cited in tender requirements for contractors, service providers, and panel members. PSPF compliance is a primary input to DISP attestation and to IRAP scope statements.
+
+PSPF is structured around **four security outcomes** with **16 core requirements**:
+
+- **Outcome 1: Security Governance** (4 core requirements)
+- **Outcome 2: Information Security** (4 core requirements — ISM is the technical instantiation)
+- **Outcome 3: Personnel Security** (4 core requirements)
+- **Outcome 4: Physical Security** (4 core requirements)
+
+**Authoritative anchor**: Protective Security Policy Framework —
+
+**Key references**:
+
+- PSPF (current edition) — Attorney-General's Department
+- ASD Information Security Manual (ISM) — instantiates Outcome 2
+- ASD Essential Eight — minimum cyber baseline supporting Outcome 2
+- DISP (Defence Industry Security Program) — adjacent framework
+
+## Process
+
+1. Read prerequisites:
+ - The project's E8 posture (`ARC-{P}-AUE8-v*`)
+ - The project's ISM applicability (`ARC-{P}-AUISM-v*`) — primary input
+ - The project's PIA (`ARC-{P}-AUPIA-v*`)
+ - The project's RISK artefact
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-pspf-template.md`
+ - Then: `.arckit/templates-custom/au-pspf-template.md`
+ - Fallback: `.arckit/templates/au-pspf-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUPSPF --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Entity Profile** — entity name, type (non-corporate Commonwealth / corporate Commonwealth / contractor / panel member / state-government with PSPF flow-down), PSPF applicability driver (direct / contractual flow-down), Chief Security Officer (CSO) designation, security maturity self-assessment level.
+
+ - **Outcome 1: Security Governance** — assessment of the 4 core requirements:
+ 1. CR1: Role of accountable authority (security governance leadership)
+ 2. CR2: Management structures and responsibilities (CSO, security committee, executives)
+ 3. CR3: Security planning and risk management
+ 4. CR4: Security maturity monitoring (Annual Self-Assessment + reporting to AGD)
+
+ - **Outcome 2: Information Security** — assessment of 4 core requirements (ISM is the primary instantiation here):
+ 1. CR5: Sensitive and classified information (information classification, marking, handling)
+ 2. CR6: Access to information (need-to-know, security clearances)
+ 3. CR7: Safeguarding information from cyber threats (E8 + ISM)
+ 4. CR8: Sensitive and classified discussions and communications
+
+ - **Outcome 3: Personnel Security** — assessment of 4 core requirements:
+ 1. CR9: Eligibility and suitability (vetting + AGSVA clearance process)
+ 2. CR10: Ongoing assessment (continuous suitability)
+ 3. CR11: Separation of personnel (off-boarding clearance debrief)
+ 4. CR12: Insider threat
+
+ - **Outcome 4: Physical Security** — assessment of 4 core requirements:
+ 1. CR13: Entity facilities (physical security zones)
+ 2. CR14: Working off-site (remote work + travel)
+ 3. CR15: Physical security risk
+ 4. CR16: Supporting services (cleaning, maintenance, contractor access)
+
+ For each Core Requirement document:
+ - Compliance status: ✅ Fully Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant / N/A
+ - Evidence supporting status (cite ARC-{P}-AUISM, AUE8, AUPIA, AUDISP where applicable)
+ - Specific gap description
+ - Remediation actions with owner and target date
+ - PSPF Self-Assessment Level achieved (if relevant — Compliant / Substantially Compliant / Partly Compliant / Not Compliant)
+
+ - **PSPF Annual Self-Assessment** — for non-corporate Commonwealth entities, document Annual Self-Assessment Report status, last submission to AGD, current self-assessed maturity level, gaps.
+
+ - **Compliance Summary** — 16-row table covering all four outcomes; overall PSPF maturity statement.
+
+ - **Recommendations** — prioritised remediations by Quick Wins / Short-Term / Medium-Term, each tagged to specific Core Requirement.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. PSPF (with edition) MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the four-outcome compliance summary table).
+
+## Important Notes
+
+- PSPF directly applies to **non-corporate Commonwealth entities**. Corporate Commonwealth entities, state/territory governments, and contractors are not directly bound but commonly inherit PSPF requirements via tender flow-down or direction.
+- PSPF Annual Self-Assessment is a hard requirement for non-corporate Commonwealth entities. Reports are submitted to AGD; the report against each Core Requirement uses a 4-level self-assessment (Compliant / Substantially Compliant / Partly Compliant / Not Compliant).
+- **ISM is the technical instantiation of Outcome 2 Information Security.** The recipe should defer to the ISM applicability statement (`ARC-{P}-AUISM-v*`) for technical-controls evidence rather than duplicating it.
+- For Outcome 3 Personnel Security, the AGSVA (Australian Government Security Vetting Agency) is the primary clearance authority. Cleared personnel records reference clearance levels (Baseline / NV1 / NV2 / PV) not individual identities.
+- For pure-cloud systems and contractors with no physical facilities, Outcome 4 Physical Security largely inherits from cloud provider IRAP attestations + host-organisation facilities. Document the inheritance explicitly.
+- For contractors handling Defence-related work, the PSPF assessment dovetails with DISP attestation — cite the DISP pack where it exists rather than re-evidencing.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit:au-ism-controls` -- ISM is the technical-controls instantiation of PSPF Information Security outcome — primary input to PSPF Outcome 2.
+- `/arckit:au-e8-posture` -- E8 supports PSPF Information Security outcome.
+- `/arckit:au-pia` -- APP 11 + PSPF Personnel Security overlap; PIA cross-reference.
+- `/arckit:au-disp-attestation` -- DISP attestation pack draws on PSPF compliance evidence.
diff --git a/arckit-codex/config/doc-types.mjs b/arckit-codex/config/doc-types.mjs
index 00d58bee..611ed971 100644
--- a/arckit-codex/config/doc-types.mjs
+++ b/arckit-codex/config/doc-types.mjs
@@ -152,18 +152,32 @@ export const DOC_TYPES = {
'OLA': { name: 'Canada Official Languages Act Review', category: 'Compliance', regime: 'CA' },
'PROC': { name: 'Canada Federal Procurement Strategy', category: 'Procurement', regime: 'CA' },
'OCAP': { name: 'Canada First Nations OCAP Sovereignty Assessment', category: 'Governance', regime: 'CA' },
+ // Australian Federal Overlay (Community-contributed, maintained by @royster70) — ASD Essential Eight, ISM, DTA DSS, Privacy Act 1988 PIA,
+ // OAIC NDB scheme, DISP, PSPF, DTA AI Assurance Framework + Responsible AI Policy v2.0
+ 'AUE8': { name: 'AU Essential Eight Maturity Posture', category: 'Compliance', regime: 'AU', severity: 'HIGH' },
+ 'AUISM': { name: 'AU ISM Statement of Applicability', category: 'Compliance', regime: 'AU', severity: 'HIGH' },
+ 'AUPIA': { name: 'AU Privacy Impact Assessment (Privacy Act 1988)', category: 'Compliance', regime: 'AU', severity: 'HIGH' },
+ 'AUNDB': { name: 'AU Notifiable Data Breach Response Playbook', category: 'Compliance', regime: 'AU' },
+ 'AUDSS': { name: 'AU DTA Digital Service Standard Conformance', category: 'Governance', regime: 'AU', severity: 'HIGH' },
+ 'AUPSPF': { name: 'AU Protective Security Policy Framework Scorecard', category: 'Governance', regime: 'AU', severity: 'HIGH' },
+ 'AUAIA': { name: 'AU AI Assurance Baseline (DTA AI Policy v2.0)', category: 'Compliance', regime: 'AU', severity: 'HIGH' },
+ 'AUDISP': { name: 'AU DISP Member Self-Attestation Pack', category: 'Compliance', regime: 'AU', severity: 'HIGH' },
};
// Derived: regimes in canonical order (officially-maintained first, then community alphabetical)
-export const REGIMES = ['UK', 'MOD', 'EU', 'FR', 'AT', 'UAE'];
+// CA + AU added retroactively — both shipped doc-types without REGIMES registration
+// (CA since v4.15.0, AU in v5.0.0). REGIME_LABELS ordering matches.
+export const REGIMES = ['UK', 'MOD', 'AT', 'AU', 'CA', 'EU', 'FR', 'UAE'];
// Human-readable regime labels
export const REGIME_LABELS = {
UK: 'UK Gov',
MOD: 'MOD',
+ AT: 'Austria',
+ AU: 'Australia',
+ CA: 'Canada',
EU: 'EU',
FR: 'France',
- AT: 'Austria',
UAE: 'UAE',
};
diff --git a/arckit-codex/prompts/arckit.au-ai-assurance.md b/arckit-codex/prompts/arckit.au-ai-assurance.md
new file mode 100644
index 00000000..ea74b2d5
--- /dev/null
+++ b/arckit-codex/prompts/arckit.au-ai-assurance.md
@@ -0,0 +1,125 @@
+---
+description: "[COMMUNITY] Generate an AI assurance assessment for Australian Government / regulated-sector AI systems covering DTA AI Policy v2.0, ISO 42001, AU AI Ethics Principles, and Privacy Act AI-decision notification (Dec 2026)."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified AI ethics specialist, Privacy Officer, or DTA-aligned AI assurance assessor before reliance. DTA AI Policy v2.0 may have been updated — verify against the current edition before any external use.
+
+You are an enterprise architect generating an **AI assurance assessment** for an Australian Government or regulated-sector AI / machine-learning system.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+Australia's AI assurance landscape combines several frameworks that together govern AI deployment in government and regulated industry:
+
+- **DTA Responsible AI Policy v2.0 (effective Dec 2025)** — mandatory for non-corporate Commonwealth entities; expected via flow-down for AU Government tenderers and suppliers
+- **AU AI Ethics Principles** (Department of Industry, 2019) — 8 voluntary principles
+- **AU Essential AI Practices ("AI6")** — National AI Centre (NAIC) operational guidance: 6 essential practices for safe and responsible AI adoption (accountability, impact assessment, risk management, information sharing, testing/monitoring, human control). Foundations + Implementation Guidance issued via ai.gov.au.
+- **ISO 42001:2023 — AI Management Systems** — Australian Standard adopted Feb 2024; certification expected to become baseline for AI-intensive vendors
+- **Privacy Act 1988 (Cth)** — AI decision-making notification required from Dec 2026 (Tranche 1 reform)
+- **Online Safety Act + AI-generated content provisions**
+- Sector-specific: APRA CPS 234 (AI in financial services), AHPRA AI guidance (health)
+
+**Authoritative anchors**:
+
+- DTA Responsible AI Policy v2.0 —
+- AU AI Ethics Principles —
+- AU Essential AI Practices (AI6) — Guidance for AI Adoption: Foundations —
+- AU Essential AI Practices — Implementation Guidance —
+- Privacy Act 1988 (Cth) —
+
+## Process
+
+1. Read prerequisites:
+ - Project's PIA artefact (`ARC-{P}-AUPIA-v*`) — APP 6 + APP 11 cross-reference
+ - Project's DATA artefact — for training/inference data classification
+ - Project's REQ artefact — extract AI-specific requirements
+ - Project's RISK artefact — existing AI risks
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-ai-assurance-template.md`
+ - Then: `.arckit/templates-custom/au-ai-assurance-template.md`
+ - Fallback: `.arckit/templates/au-ai-assurance-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUAIA --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **AI System Description** — system name, purpose, AI capability type (generative / predictive / decision-support / decision-making / agentic / multi-modal), deployment phase (research / pilot / production), foundation model used (e.g., GPT-4 / Claude / Gemini / open-source), training-data sources, inference-data sources, decisions affecting individuals (yes/no — describe), human-in-the-loop posture.
+
+ - **DTA Responsible AI Policy v2.0 Compliance** — assessment against the policy's six accountabilities:
+ 1. **Accountability** — designated AI accountable officer
+ 2. **Transparency** — public AI use disclosure
+ 3. **Risk-based approach** — AI risk assessment performed
+ 4. **Quality data + design integrity** — data lineage, model documentation
+ 5. **Privacy + security** — cross-reference PIA + ISM + E8
+ 6. **Human oversight + redress** — human review mechanism, individual appeal pathway
+
+ - **AU AI Ethics Principles Alignment** — assess against the 8 principles:
+ 1. Human, societal and environmental wellbeing
+ 2. Human-centred values
+ 3. Fairness
+ 4. Privacy protection and security
+ 5. Reliability and safety
+ 6. Transparency and explainability
+ 7. Contestability
+ 8. Accountability
+
+ For each principle: status (Aligned / Partial / Not Aligned), evidence, gap, mitigation.
+
+ - **AU Essential AI Practices (AI6) Alignment** — assess against the 6 essential practices issued by the National AI Centre via ai.gov.au:
+ 1. Decide who is accountable
+ 2. Understand impacts and plan accordingly
+ 3. Measure and manage risks
+ 4. Share essential information
+ 5. Test and monitor
+ 6. Maintain human control
+
+ For each practice: status (Implemented / Partial / Not Implemented / Not Applicable), evidence (artefact references where possible), gap, action. Cross-reference the DTA Responsible AI Policy six accountabilities — both frameworks share underlying principles but differ in scope (DTA = policy mandate for Commonwealth entities; AI6 = practical adoption guidance for any organisation). The AI6 *Implementation Guidance* on ai.gov.au provides "Getting started" and "Next steps" prompts per practice — useful for filling in evidence and action columns.
+
+ - **ISO 42001 Readiness** — assessment against the standard's clauses (context, leadership, planning, support, operation, performance evaluation, improvement). Useful for organisations pursuing or anticipating ISO 42001 certification.
+
+ - **Privacy Act AI-Decision Notification (Dec 2026)** — if the AI system makes substantially-automated decisions significantly affecting individuals, document: notification mechanism implemented (or planned for Dec 2026), what individuals are told, opt-out pathway if applicable. Cross-reference AUPIA APP 6 + APP 11.
+
+ - **Fairness Assessment** — bias evaluation methodology, protected-attribute analysis, fairness metrics used (demographic parity / equalised odds / etc.), test results across population segments, residual fairness risks.
+
+ - **Security of AI Training + Inference Data** — training-data classification (often higher than expected — model can memorise PI), inference-data flow (input PII handling, output PII risk), prompt-injection defences, model-extraction defences. Cross-reference E8 posture + ISM applicability.
+
+ - **Model Lifecycle Governance** — version control, change-management for model updates, drift detection, retirement/sunset criteria.
+
+ - **Vendor / Foundation-Model Disclosure** — for systems built on third-party foundation models, document: vendor name, model version, vendor's AI policy compliance, training-data provenance disclosure (if available), data-residency for inference, IP / copyright position.
+
+ - **Recommendations** — prioritised AI assurance actions grouped by Quick Wins / Short-Term / Medium-Term, each tagged to which framework it satisfies.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. DTA AI Policy v2.0, AU AI Ethics Principles, AU Essential AI Practices (AI6) — Foundations + Implementation Guidance, ISO 42001 (Australian Standard), and Privacy Act 1988 MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the DTA + Ethics Principles compliance summary table).
+
+## Important Notes
+
+- DTA AI Policy v2.0 applies to **non-corporate Commonwealth entities** directly. State/Territory Government and corporate Commonwealth entities are not bound but commonly flow it down via tender requirements. Suppliers to those entities should track for contractual flow-down.
+- The **December 2026 Privacy Act AI-decision notification** is a deadline. Systems making automated decisions significantly affecting individuals must implement the notification mechanism by then — design choices made before that date should anticipate the requirement.
+- Foundation-model use is a supply-chain concern. Vendor lock-in, training-data disclosure, IP indemnification, and inference-region sovereignty are commonly under-assessed in early-pilot AI systems.
+- Bias / fairness assessment is methodology-dependent. Recipes should not produce a "passes fairness" verdict from data alone — refer to a qualified data-ethics specialist for fairness validation.
+- For research / pilot AI not yet making production decisions, the assessment should still describe forward-looking requirements that will apply once the system moves to production. This avoids "we'll add it later" technical debt.
+- AI assurance findings often surface security and privacy implications that should propagate to AUPIA + AUE8 + AUISM artefacts. Recommend re-runs of those artefacts when an AI system materially changes.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit:au-pia` -- AI fairness + automated decision-making findings feed APP 6 + APP 11 in the PIA.
+- `/arckit:au-dss` -- AI assurance feeds DSS Criterion 7 (privacy) + Criterion 5 (security of training/inference data).
+- `/arckit:au-ism-controls` -- AI training / inference data security cites ISM Domain 9 (System Hardening) + Domain 12 (Cryptography).
+- `/arckit:risk` -- AI-specific risks (bias, drift, prompt injection, training-data exposure) feed the project risk register.
diff --git a/arckit-codex/prompts/arckit.au-disp-attestation.md b/arckit-codex/prompts/arckit.au-disp-attestation.md
new file mode 100644
index 00000000..64aebf3e
--- /dev/null
+++ b/arckit-codex/prompts/arckit.au-disp-attestation.md
@@ -0,0 +1,110 @@
+---
+description: "[COMMUNITY] Generate a DISP (Defence Industry Security Program) Member self-attestation pack covering E8 ML2, ISM applicability, governance, personnel security, and incident reporting — supports DISP Levels 1, 2, 3."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified DISP-experienced security officer or DISP advisor before submission to Defence. DISP requirements may be updated — verify against the current DISP Membership Pack before any external use.
+
+You are an enterprise architect generating a **DISP (Defence Industry Security Program) Member self-attestation pack** for an Australian organisation supplying products or services to Defence.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Defence Industry Security Program (DISP) is the security accreditation framework for Australian organisations supplying Defence. DISP Membership has three levels (Levels 1, 2, 3 — formerly Entry, Level 1, Level 2 in earlier guidance) with progressively-deeper governance, personnel, ICT, physical, and supply-chain security obligations. Essential Eight ML2 has been the minimum cyber baseline for DISP members since 2025; ISM applicability scales with the level. The attestation pack is the supplier's self-evidence document referenced during DISP application, audit, and renewal.
+
+**Authoritative anchor**: Defence Industry Security Program —
+
+**Key references**:
+
+- DISP Membership Pack (current edition) — application form + evidence requirements
+- ASD Essential Eight Maturity Model (ML2 minimum for DISP) —
+- ASD Information Security Manual —
+- Protective Security Policy Framework (PSPF)
+- Defence Security Principles Framework (DSPF) — referenced sections only
+- Privacy Act 1988 (Cth) — APP 11 alignment
+
+## Process
+
+1. Read prerequisites:
+ - The project's E8 posture artefact (`ARC-{P}-AUE8-v*`) — primary input
+ - The project's ISM applicability statement (`ARC-{P}-AUISM-v*`) — primary input
+ - The project's PIA (`ARC-{P}-AUPIA-v*`) — APP 11 cross-reference
+ - The project's PSPF assessment (`ARC-{P}-AUPSPF-v*`) — physical / personnel / information security evidence
+ - The project's RISK artefact — for SecRisk register integration
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-disp-attestation-template.md` (user override)
+ - Then: `.arckit/templates-custom/au-disp-attestation-template.md`
+ - Fallback: `.arckit/templates/au-disp-attestation-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if needed.
+
+4. Use `scripts/bash/generate-document-id.sh AUDISP --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Organisation Profile** — entity name, ABN, primary business activity, Defence contracts in scope, headcount, sites, foreign ownership / control / influence (FOCI) declaration.
+
+ - **DISP Level Sought** — Level 1 / Level 2 / Level 3, regulatory driver (specific contract requirement, panel mandate, anticipated tender pipeline), justification of level chosen.
+
+ - **Security Officer Designation** — Chief Security Officer (CSO) name + role + authority, deputy / backup CSO, contact details, vetting status. **DISP requires a named, suitably-cleared CSO with authority across the four security domains.**
+
+ - **Four Security Domains Coverage** — DISP requires evidence across four domains:
+ 1. **Governance** — security policy, risk management, audit, incident management, change control
+ 2. **Personnel Security** — security clearances appropriate to work, security awareness training, separation of duties, off-boarding
+ 3. **Physical Security** — facility security, ICT equipment security, equipment lifecycle (cloud-only systems may inherit much of this from cloud provider's IRAP)
+ 4. **Information & Cyber Security** — Essential Eight ML2 minimum, ISM applicability, cryptography, gateway, monitoring, BCP
+
+ For each domain, document:
+ - Current implementation state (cite E8 posture, ISM applicability, supporting policies)
+ - Evidence references (artefact IDs + document register)
+ - Gap description
+ - Remediation plan with target dates
+ - Sign-off statement by accountable officer
+
+ - **Essential Eight ML2 Evidence Per Strategy** — for each of the 8 E8 strategies, summarise the current ML position and evidence supporting ML2 attestation. Cite the AUE8 artefact directly.
+
+ - **ISM Applicability Highlights** — beyond E8, summarise which ISM domains apply, current implementation summary, and identify any ISM gaps that materially affect DISP attestation. Cite the AUISM artefact.
+
+ - **Foreign Ownership, Control or Influence (FOCI) Declaration** — disclose any foreign ownership > 5%, foreign-board-member arrangements, foreign-supply-chain dependencies, foreign-personnel access. DISP Level 2 + 3 require FOCI mitigation plans where applicable.
+
+ - **Supply Chain Security** — disclose Tier 1 suppliers (MSPs, SaaS, cloud), supply-chain attestations held (SOC 2 / ISO 27001 / IRAP), supply-chain risk management process.
+
+ - **Incident Response & Reporting** — incident response plan summary, 24-hour rapid notification capability for Defence-relevant incidents, OAIC NDB scheme integration, evidence of last incident response exercise. Cite NDB playbook (`ARC-{P}-AUNDB-v*`) if available.
+
+ - **Security Awareness Training** — DISP-mandated security awareness training programme, completion rate, refresher cadence, security-clearance-holder additional briefings (pre/post-leave for cleared personnel).
+
+ - **Annual Self-Audit Plan** — DISP requires annual self-audit; describe scope, methodology, evidence retention.
+
+ - **Attestation Statement** — formal CSO + Director sign-off statement attesting to the accuracy of the pack, with signature blocks, date, and re-attestation cadence.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The DISP Membership Pack (with edition) MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the Four Security Domains coverage table).
+
+## Important Notes
+
+- The pack is a **self-attestation**, not a third-party assurance. Defence reserves the right to audit. Artefact tone should be evidence-based and conservative — do not claim controls not yet implemented.
+- The CSO designation is a hard requirement. If no CSO is named in the source artefacts, the pack must explicitly flag this as an outstanding action — it cannot be filled in by the recipe.
+- For Level 2 + 3 members supplying classified Defence work, security clearances of personnel handling that work must be evidenced. Records of clearance levels held may be sensitive — reference by clearance level (Baseline / NV1 / NV2 / PV) not by individual name.
+- Cloud-only systems that inherit Physical Security from an IRAP-assessed cloud provider should explicitly cite the cloud provider's IRAP scope statement, not generic marketing.
+- The pack should integrate with the project's risk register — material residual risks should appear both in the risk register and in the DISP pack's gap descriptions.
+- For DISP renewal cycles, the artefact should produce a redline-friendly format so year-on-year changes are easy to track.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit:au-e8-posture` -- E8 ML2 evidence per strategy is a primary input to the DISP attestation pack.
+- `/arckit:au-ism-controls` -- ISM applicability statement is a primary input — controls beyond E8 mandated by DISP level.
+- `/arckit:au-pia` -- Privacy Act + APP 11 alignment cited in attestation pack.
+- `/arckit:au-ndb-playbook` -- Notifiable Data Breach response is the operational complement to DISP incident reporting.
diff --git a/arckit-codex/prompts/arckit.au-dss.md b/arckit-codex/prompts/arckit.au-dss.md
new file mode 100644
index 00000000..2b131062
--- /dev/null
+++ b/arckit-codex/prompts/arckit.au-dss.md
@@ -0,0 +1,102 @@
+---
+description: "[COMMUNITY] Generate a DTA Digital Service Standard compliance assessment for Australian Government digital services against all 13 criteria."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified DTA assessor or digital delivery lead before reliance. The DTA Digital Service Standard was refreshed in July 2025 — verify criteria against the current published version.
+
+You are an enterprise architect generating a **DTA Digital Service Standard compliance assessment** for an Australian Government digital service.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Digital Transformation Agency (DTA) Digital Service Standard sets the mandatory criteria that Australian Government digital services must meet. Services subject to the Standard must demonstrate compliance at key assessment points. The Standard replaced the earlier Digital Service Standard (2016) with a refreshed version in July 2025.
+
+**Authoritative anchor**: DTA Digital Service Standard —
+
+**Key Australian Digital Service References**:
+
+- DTA Digital Service Standard (July 2025 refresh)
+- DTA Service Design and Delivery Process
+- Digital Government Strategy
+- Web Content Accessibility Guidelines (WCAG) 2.2 Level AA
+- Style Manual for Australian Government (style.gov.au)
+- DTA Content Guide
+- Whole of Government Digital and ICT Investment Oversight Framework
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract user-facing requirements, accessibility requirements, technology choices
+ - The project's STKE artefact — extract user research, stakeholder engagement evidence
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - **First**, check `.arckit/templates-custom/au-dss-template.md` (user override)
+ - **Then**, `.arckit/templates-custom/au-dss-template.md`
+ - **Fallback**, `.arckit/templates/au-dss-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUDSS --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Service Context** — service name, owning agency/department, service phase (Discovery / Alpha / Beta / Live), user base (public-facing / internal / both), annual transaction volume (if known).
+
+ - **13-Criterion Assessment** — one assessment block per Digital Service Standard criterion:
+ 1. **Understand user needs** — research conducted with real users, needs documented
+ 2. **Have a multidisciplinary team** — team composition, capability coverage, DDaT roles
+ 3. **Agile and user-centred process** — delivery methodology, iteration cadence, user feedback loops
+ 4. **Understand tools and systems** — technology landscape mapped, legacy dependencies identified
+ 5. **Make it secure** — security posture, E8 alignment, threat assessment, incident response
+ 6. **Consistent and responsive design** — design system usage, responsive breakpoints, device testing
+ 7. **Protect users' privacy** — PIA completed, APP compliance, data minimisation, consent
+ 8. **Make source code open** — open-source strategy, code repository, licence
+ 9. **Make it accessible** — WCAG 2.2 AA compliance, assistive technology testing, accessibility statement
+ 10. **Test the service** — testing strategy (unit, integration, UAT, accessibility, performance, security)
+ 11. **Measure performance** — KPIs defined (completion rate, user satisfaction, cost per transaction, digital take-up)
+ 12. **Don't forget the non-digital experience** — assisted digital, phone, in-person channel design
+ 13. **Encourage everyone to use the digital service** — channel shift strategy, take-up targets
+
+ For each criterion, document:
+ - Assessment status: ✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A
+ - Evidence summary (what demonstrates compliance)
+ - Gap description (what is missing)
+ - Remediation actions with owner and target date
+
+ - **Compliance Summary** — table: Criterion # | Criterion Name | Status | Gap Count
+
+ - **Assessment Readiness** — for services approaching Alpha/Beta/Live assessment, identify the top 3 risks to passing and recommended mitigations.
+
+ - **Recommendations** — prioritised list of actions to improve compliance posture, grouped by criterion priority.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The DTA Digital Service Standard MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the compliance summary table showing status per criterion).
+
+## Important Notes
+
+- The DTA Digital Service Standard applies to **all new and redesigned Australian Government digital services**. Existing services may be assessed when undergoing significant change.
+- Criterion 5 (Make it secure) should cross-reference the ASD Essential Eight assessment (`/arckit:au-e8-posture`) if one exists.
+- Criterion 7 (Protect users' privacy) should cross-reference the Privacy Impact Assessment (`/arckit:au-pia`) if one exists.
+- Criterion 9 (Make it accessible) requires WCAG 2.2 Level AA as the minimum standard for Australian Government services.
+- The Standard is assessed at Alpha, Beta, and Live phases — the depth of evidence expected increases at each gate.
+- This assessment is analogous to the UK GDS Service Standard assessment (`/arckit:service-assessment`) but uses Australian criteria and governance structures.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit:au-e8-posture` -- DSS Criterion 5 (Make it secure) feeds into the E8 maturity posture assessment.
+- `/arckit:au-pia` -- DSS Criterion 7 (Protect users' privacy) feeds into the Privacy Impact Assessment.
+- `/arckit:risk` -- DSS gaps surface as delivery and compliance risks for the risk register.
diff --git a/arckit-codex/prompts/arckit.au-e8-posture.md b/arckit-codex/prompts/arckit.au-e8-posture.md
new file mode 100644
index 00000000..79886554
--- /dev/null
+++ b/arckit-codex/prompts/arckit.au-e8-posture.md
@@ -0,0 +1,97 @@
+---
+description: "[COMMUNITY] Generate an ASD Essential Eight maturity posture assessment for Australian Government projects against all eight mitigation strategies at ML0–ML3."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified CISO or security assessor before reliance. Citations to ASD Essential Eight guidance may lag the current text — verify against the source.
+
+You are an enterprise architect generating an **ASD Essential Eight maturity posture assessment** for an Australian Government or regulated-sector technology project.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Australian Signals Directorate (ASD) Essential Eight is the baseline cyber-security mitigation framework for Australian Government entities. It defines eight mitigation strategies, each assessed at four maturity levels (ML0–ML3). Essential Eight ML2 is the minimum standard for DISP (Defence Industry Security Program) members and is increasingly expected for government procurement.
+
+**Authoritative anchor**: ASD Essential Eight Maturity Model —
+
+**Key Australian Security References**:
+
+- ASD Essential Eight Maturity Model (current edition)
+- ASD Information Security Manual (ISM) —
+- Protective Security Policy Framework (PSPF) —
+- Australian Cyber Security Strategy 2023–2030
+- DISP Essential Eight ML2 mandate (effective 2025)
+- Privacy Act 1988 (Cth) — security of personal information (APP 11)
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract NFR-SEC requirements, data classification, compliance obligations
+ - The project's RISK artefact — extract existing security risks and mitigations
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - **First**, check `.arckit/templates-custom/au-e8-posture-template.md` (user override)
+ - **Then**, `.arckit/templates-custom/au-e8-posture-template.md`
+ - **Fallback**, `.arckit/templates/au-e8-posture-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUE8 --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **System Context** — system name, classification level (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET), deployment model (cloud / on-premise / hybrid), IRAP assessment status, data sovereignty position.
+
+ - **Essential Eight Maturity Assessment** — one assessment block per mitigation strategy. For each of the eight strategies:
+ 1. **Application Control** — only approved applications execute on systems
+ 2. **Patch Applications** — security patches for applications applied within timeframes
+ 3. **Configure Microsoft Office Macro Settings** — macros blocked or restricted per policy
+ 4. **User Application Hardening** — web browsers, email clients, Office configured to block untrusted content
+ 5. **Restrict Administrative Privileges** — admin access validated, separated, and time-limited
+ 6. **Patch Operating Systems** — OS patches applied within timeframes, unsupported OS replaced
+ 7. **Multi-Factor Authentication** — MFA on all remote access, privileged access, and data repositories
+ 8. **Regular Backups** — backups performed, tested, and stored securely per retention schedule
+
+ For each strategy, document:
+ - Current maturity level (ML0 / ML1 / ML2 / ML3) with evidence
+ - Target maturity level with rationale (regulatory driver or risk appetite)
+ - Gap description (specific controls not yet implemented)
+ - Remediation actions with owner and target date
+ - Residual risk if gap persists
+
+ - **Maturity Summary Matrix** — 8-row table: Strategy | Current ML | Target ML | Gap Count | Priority (Critical / High / Medium / Low)
+
+ - **DISP Compliance Position** — if the entity is a DISP member, assess whether current posture meets ML2 minimum across all eight strategies. Flag any strategy below ML2 as a DISP non-compliance risk.
+
+ - **Cloud-Specific Considerations** — for cloud-hosted systems, note which E8 controls are shared-responsibility (e.g., OS patching on PaaS vs IaaS), which are vendor-managed (e.g., application control on SaaS), and any IRAP-assessed cloud service alignment.
+
+ - **Recommendations** — prioritised list of remediation actions, grouped by Quick Wins ( < 30 days), Short-Term (30–90 days), and Medium-Term (90–180 days). Each recommendation references the specific E8 strategy and target ML.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The ASD Essential Eight Maturity Model MUST appear in the Document Register with its primary URL and verification date.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the maturity summary matrix showing current ML vs target ML per strategy).
+
+## Important Notes
+
+- ML0 means the strategy is **not implemented** — it does not mean "assessed and found satisfactory at a low level." Explicitly state this distinction.
+- Each maturity level has specific sub-controls defined by ASD. Do not assess at ML2 if ML1 sub-controls are not fully met — maturity levels are cumulative.
+- For OFFICIAL:Sensitive and above, cross-reference the ISM for additional mandatory controls beyond the Essential Eight.
+- The Essential Eight is a **mitigation** framework, not a comprehensive security standard. Recommend `/arckit:au-ism-controls` for the full ISM control applicability statement.
+- For energy-sector projects, recommend `/arckit:au-aescsf` as the AESCSF capability domains build on and extend the E8 baseline.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit:au-ism-controls` -- E8 posture feeds the ISM control applicability statement — target ML drives which ISM controls are mandatory.
+- `/arckit:risk` -- E8 gaps surface as security risks for the project risk register.
diff --git a/arckit-codex/prompts/arckit.au-ism-controls.md b/arckit-codex/prompts/arckit.au-ism-controls.md
new file mode 100644
index 00000000..83bea368
--- /dev/null
+++ b/arckit-codex/prompts/arckit.au-ism-controls.md
@@ -0,0 +1,113 @@
+---
+description: "[COMMUNITY] Generate an ASD Information Security Manual (ISM) control applicability statement for Australian Government projects, scoped to the system's classification and supporting DISP attestation."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified IRAP Assessor or CISO before reliance. ISM is updated quarterly — verify control identifiers against the current edition before any external use.
+
+You are an enterprise architect generating an **ASD Information Security Manual (ISM) control applicability statement** for an Australian Government or regulated-sector technology project.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Australian Signals Directorate (ASD) Information Security Manual (ISM) is the comprehensive set of cyber-security controls for Australian Government information systems. Where the Essential Eight is a mitigation framework targeting attack-vector defence, the ISM is the comprehensive control set covering governance, personnel, physical, communications, ICT system, networking, cryptography, gateway, data-transfer, evaluation, working-off-site, and incident-response domains. ISM compliance is the core technical-controls evidence for PSPF Information Security outcome and a primary input to DISP attestation.
+
+**Authoritative anchor**: ASD Information Security Manual —
+
+**Key Australian Security References**:
+
+- ASD Information Security Manual (current edition; updated quarterly)
+- Protective Security Policy Framework (PSPF) —
+- ASD Essential Eight Maturity Model (mitigation subset of ISM)
+- Defence Industry Security Program (DISP) requirements
+- IRAP (Information Security Registered Assessors Program) — control assurance methodology
+- Privacy Act 1988 (Cth) — APP 11 alignment
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract NFR-SEC requirements, data classification, compliance obligations
+ - The project's RISK artefact — extract existing security risks
+ - The project's E8 posture artefact (`ARC-{P}-AUE8-v*`) if available — provides E8 sub-control evidence
+ - The project's DATA artefact — for classification-driven control scoping
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-ism-controls-template.md` (user override)
+ - Then: `.arckit/templates-custom/au-ism-controls-template.md`
+ - Fallback: `.arckit/templates/au-ism-controls-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist.
+
+4. Use `scripts/bash/generate-document-id.sh AUISM --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **System Context** — system name, classification level (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET), deployment model, IRAP assessment status, sovereignty position. Classification drives applicability — controls applicable at OFFICIAL:Sensitive are a subset of those at PROTECTED.
+
+ - **Control Domain Applicability Matrix** — table covering all 17 ISM control areas (15 ASD ISM chapter domains plus 2 cross-cutting areas — Cloud/IaaS and Working-Off-Site), marking applicability per system classification:
+ 1. **Cyber Security Governance** — security risk management, security documentation, change management
+ 2. **Cyber Security Incidents** — detection, reporting, response, business continuity
+ 3. **Outsourced Services** — managed service providers, cloud, supply chain
+ 4. **Security Documentation** — system security plans, security risk management plans
+ 5. **Personnel Security** — clearance levels, awareness training, separation of duties
+ 6. **Physical Security** — facilities, equipment, ICT equipment lifecycle
+ 7. **Communications Infrastructure** — fibre, cabling, telephony
+ 8. **ICT Equipment Security** — hardware lifecycle, media, sanitisation
+ 9. **System Hardening** — operating systems, applications, authentication, network
+ 10. **System Management** — administration, monitoring, maintenance, vulnerability mgmt
+ 11. **System Monitoring** — event logging, audit, security metrics
+ 12. **Cryptography** — cryptographic fundamentals, ASD-approved algorithms, key management
+ 13. **Gateway Security** — gateway architecture, content filtering, DLP
+ 14. **Data Transfer** — between domains, between systems, data import/export
+ 15. **Cloud and IaaS Considerations** — IRAP assessment status, sovereign cloud, shared responsibility
+ 16. **Working-Off-Site Security** — remote work, mobile devices, BYOD
+ 17. **Evaluation Activities** — Common Criteria, FIPS, vendor product testing
+
+ - **Per-Domain Control Applicability Assessment** — for each in-scope domain, document:
+ - Applicability rationale (which controls apply at the system's classification level)
+ - Current implementation status: ✅ Implemented / ⚠️ Partial / ❌ Not Implemented / N/A
+ - Evidence supporting the status (cite E8 posture artefact, IRAP report, vendor attestations)
+ - Gap description with specific ISM control IDs not yet met
+ - Remediation actions with owner and target date
+ - Compensating controls if applicable
+
+ - **ISM-to-E8 Cross-Reference** — show which E8 strategies map to which ISM domains. Reinforces the E8-as-mitigation-subset framing for governance audiences.
+
+ - **Compliance Summary** — table summarising domain-by-domain compliance posture; overall ISM applicability score (controls implemented / controls applicable).
+
+ - **IRAP Assessment Position** — if the system holds or pursues IRAP assessment, note the IRAP scope, assessment date, residual risks accepted, and re-assessment cadence. For systems integrating with IRAP-assessed cloud services, note the inherited control posture.
+
+ - **Recommendations** — prioritised remediation actions grouped by Quick Wins ( < 30 days), Short-Term (30–90 days), Medium-Term (90–180 days). Each recommendation references the specific ISM control ID(s).
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The ASD ISM (with edition / publication date) MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the Compliance Summary table showing per-domain status).
+
+## Important Notes
+
+- ISM controls are tagged with applicability flags (ALL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET / TOP SECRET). The applicability statement must select controls appropriate to the *highest classification of information processed*, not the *lowest*.
+- ISM is updated quarterly — control IDs and wording can change. The artefact should record the ISM edition / publication date used as a verification anchor.
+- For systems integrating with IRAP-assessed cloud services, note explicit shared-responsibility — many ISM controls inherit from the cloud provider's IRAP attestation. Cite the IRAP scope statement, not the cloud provider's marketing.
+- Cross-reference the E8 posture artefact wherever an ISM control maps to an E8 sub-control — avoids duplication and keeps the two artefacts consistent.
+- For DISP members or systems supporting Defence work, scope the Personnel Security and Physical Security domains carefully — these are commonly under-assessed in cloud-only environments.
+- The Cyber Security Incidents domain should reference the project's NDB playbook (`/arckit:au-ndb-playbook`) for personal-information breach scenarios.
+- The Outsourced Services domain must include MSP-held admin role boundaries, contractual security-control flow-down, and supply-chain attestation review.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit:au-disp-attestation` -- ISM applicability is a primary input to the DISP Member self-attestation pack.
+- `/arckit:au-pspf` -- ISM is the technical-controls instantiation of PSPF Information Security outcome — feeds the PSPF assessment.
+- `/arckit:au-e8-posture` -- E8 is a mitigation subset of ISM. The ISM applicability statement extends beyond E8 to cover personnel security, physical security, and information governance controls.
+- `/arckit:risk` -- ISM control gaps surface as security risks for the project risk register.
diff --git a/arckit-codex/prompts/arckit.au-ndb-playbook.md b/arckit-codex/prompts/arckit.au-ndb-playbook.md
new file mode 100644
index 00000000..ef1d246a
--- /dev/null
+++ b/arckit-codex/prompts/arckit.au-ndb-playbook.md
@@ -0,0 +1,112 @@
+---
+description: "[COMMUNITY] Generate a Notifiable Data Breach (NDB) scheme response playbook under Privacy Act 1988 Part IIIC — eligible-data-breach test, 30-day OAIC notification timeline, individual notification, containment, and lessons-learned framework."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a Privacy Officer and legal counsel before adoption. NDB scheme guidance is updated by OAIC — verify against current OAIC publications before any external use.
+
+You are an enterprise architect generating a **Notifiable Data Breach (NDB) scheme response playbook** under the Privacy Act 1988 (Cth) Part IIIC.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Notifiable Data Breach (NDB) scheme under Privacy Act 1988 (Cth) Part IIIC requires APP entities (Australian Government agencies + private organisations subject to the Privacy Act) to notify the **OAIC and affected individuals** when an "eligible data breach" of personal information occurs and is likely to result in serious harm.
+
+The NDB scheme has three statutory tests:
+
+1. **Unauthorised access to / disclosure of, or loss of, personal information**
+2. **Likely to result in serious harm** to one or more individuals
+3. **Cannot be remediated through reasonable steps** to prevent the serious harm
+
+The notification clock is **30 days** to OAIC + affected individuals from the time the entity has reasonable grounds to believe an eligible data breach has occurred. Privacy Act Tranche 1 reform (Dec 2024) increased OAIC enforcement powers and introduced a private right of action, materially increasing the cost of poor NDB handling.
+
+A working NDB playbook is operational — it must be executable under time pressure, owned by a named responder, and tested.
+
+**Authoritative anchors**:
+
+- Privacy Act 1988 (Cth) Part IIIC —
+- OAIC NDB scheme guidance —
+
+## Process
+
+1. Read prerequisites:
+ - The project's PIA (`ARC-{P}-AUPIA-v*`) — APP 11 cross-reference
+ - The project's E8 posture (`ARC-{P}-AUE8-v*`) — security baseline
+ - The project's ISM applicability (`ARC-{P}-AUISM-v*`) — Domain 2 (Cyber Security Incidents)
+ - The project's RISK artefact
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-ndb-playbook-template.md`
+ - Then: `.arckit/templates-custom/au-ndb-playbook-template.md`
+ - Fallback: `.arckit/templates/au-ndb-playbook-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUNDB --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Entity Profile** — APP entity status, Privacy Officer designation, accountable officer for NDB response, business hours + after-hours contact details, key incident-team roles.
+
+ - **NDB Eligibility Test** — explicit decision tree:
+ 1. Has there been unauthorised access to / disclosure of, or loss of, personal information?
+ 2. Is serious harm likely to result?
+ 3. Can the entity remediate through reasonable steps to prevent the serious harm?
+
+ If 1 + 2 = Yes and 3 = No → eligible data breach → notify within 30 days.
+
+ - **30-Day Timeline Plan** — day-by-day milestones from Day 0 (becoming aware of suspected breach) through Day 30 (OAIC + individual notification deadline):
+ - Day 0–1: Detect, contain, assess + activate playbook
+ - Day 1–7: Investigate, scope, classify
+ - Day 7–14: Eligibility assessment, draft notifications
+ - Day 14–21: Legal review, executive sign-off, finalise notifications
+ - Day 21–30: OAIC notification, individual notifications, public statement (if required)
+
+ - **Roles & Responsibilities (RACI)** — Privacy Officer, Security Officer, CISO, Legal, Communications, accountable executive — clear responsibility matrix.
+
+ - **Detection + Containment Procedures** — how breaches become known to the playbook owner (SIEM alerts, customer reports, vendor disclosure, insider report); immediate containment steps; evidence preservation.
+
+ - **Assessment Procedure** — how to determine eligibility under the three statutory tests; serious-harm assessment criteria (financial loss, identity theft, emotional distress, physical safety, reputational harm); reasonable-steps mitigation to remove eligibility.
+
+ - **OAIC Notification Form Content** — what OAIC requires per the statutory form: nature of breach, kind of information involved, recommendations for affected individuals, contact details. Template language for use in the OAIC form.
+
+ - **Individual Notification Approach** — direct vs publication-based notification options, content requirements, channel decisions, language and accessibility considerations.
+
+ - **Communications Plan** — internal, external, media, regulator-coordinated. Pre-written holding statements + escalation triggers.
+
+ - **Post-Incident Review** — root cause analysis, lessons learned, control updates feeding back into AUE8 + AUISM + AUPIA artefacts.
+
+ - **Coordination With Other Reporting Obligations** — SOCI Act 12hr / 72hr (where applicable), DISP incident reporting, sectoral reporting (APRA, AHPRA, etc.). Single incident may trigger multiple obligations on different timelines.
+
+ - **Tabletop Exercise Plan** — annual tabletop scenario, evidence retention, lessons-learned cycle.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. Privacy Act 1988 + OAIC NDB scheme guidance MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the 30-day timeline summary).
+
+## Important Notes
+
+- The 30-day notification clock starts from "reasonable grounds to believe" an eligible breach has occurred — **not** from the breach itself, and **not** from confirmation. This is the most commonly misread part of the scheme. The recipe should make this distinction unambiguous.
+- The "reasonable steps to remediate" test is the off-ramp from notification — if the entity can prevent serious harm through containment / mitigation actions, no notification is required. But this needs to be assessed conservatively; OAIC will second-guess hindsight optimism.
+- For multi-jurisdictional incidents (e.g., breach affecting AU + NZ + EU residents), the 30-day clock is not the only timeline. EU GDPR is 72 hours; NZ Privacy Act is "as soon as practicable". The playbook should flag this for legal-counsel coordination.
+- "Serious harm" is a broad threshold including financial loss, identity theft, **emotional distress** (including humiliation), and **reputational harm**. It is materially broader than "real prospect of significant harm" some practitioners assume.
+- For SOCI-covered entities, the NDB 30-day clock runs in parallel with SOCI 12hr / 72hr cyber incident reporting. The playbook should explicitly coordinate both timelines so the 12hr SOCI report doesn't pre-commit positions before the NDB assessment is complete.
+- Pre-written holding statements and notification templates dramatically reduce time-to-notify under pressure. Recipes producing this artefact should include template language wherever possible.
+- The playbook is operational. It should be **tested** at least annually via tabletop exercise; the recipe should output an exercise scenario template as part of the deliverable.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit:au-pia` -- NDB playbook is the operational complement to AUPIA APP 11 mitigation; APP 11 references NDB.
+- `/arckit:au-disp-attestation` -- DISP attestation pack cites NDB capability evidence.
+- `/arckit:risk` -- NDB-relevant risks tagged into the project risk register.
diff --git a/arckit-codex/prompts/arckit.au-pia.md b/arckit-codex/prompts/arckit.au-pia.md
new file mode 100644
index 00000000..36fda142
--- /dev/null
+++ b/arckit-codex/prompts/arckit.au-pia.md
@@ -0,0 +1,110 @@
+---
+description: "[COMMUNITY] Generate a Privacy Impact Assessment (PIA) for Australian Government entities under Privacy Act 1988 s33D, assessing compliance with all 13 Australian Privacy Principles (APPs)."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified Privacy Officer, DPO, or legal counsel before reliance. Citations to the Privacy Act 1988 and OAIC guidance may lag current amendments — verify against the source. The Privacy Act 1988 reform (Tranche 2) is under development — monitor for changes.
+
+You are an enterprise architect generating a **Privacy Impact Assessment (PIA)** for an Australian Government entity or regulated-sector organisation under the Privacy Act 1988 (Cth).
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+Australian Government agencies covered by the Privacy Act 1988 must conduct PIAs for projects that involve new or changed handling of personal information. Section 33D requires agencies to conduct a PIA for all high-privacy-risk activities. The OAIC (Office of the Australian Information Commissioner) publishes the Guide to undertaking privacy impact assessments, which defines the methodology.
+
+**Authoritative anchors**:
+
+- Privacy Act 1988 (Cth) —
+- OAIC Guide to undertaking privacy impact assessments —
+- Australian Privacy Principles (APPs) — Schedule 1 of the Privacy Act 1988
+- Privacy (Australian Government Agencies — Governance) APP Code 2017
+- OAIC Privacy regulatory action policy
+
+**Key Privacy Act 1988 Reform Context**:
+
+- Tranche 1 effective December 2024 — enhanced enforcement powers, tiered penalties, private right of action
+- AI decision-making notification required from December 2026
+- Tranche 2 under development — ~93 remaining proposals from Attorney-General's review
+- Small business exemption changes from 1 July 2026
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract data requirements (DR-*), NFR-SEC requirements, integration requirements (INT-*)
+ - The project's DATA artefact — extract entity model, PII fields, data flows
+ - The project's STKE artefact — extract data subjects, stakeholder privacy expectations
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - **First**, check `.arckit/templates-custom/au-pia-template.md` (user override)
+ - **Then**, `.arckit/templates-custom/au-pia-template.md`
+ - **Fallback**, `.arckit/templates/au-pia-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUPIA --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Project Description** — what the project does, what personal information is involved, why it is needed, who the data subjects are, estimated data volumes.
+
+ - **Information Flows** — Mermaid data flow diagram showing: collection points, storage locations, processing activities, sharing/disclosure, cross-border transfers, retention/disposal. Mark each flow with the APP that governs it.
+
+ - **13 APP Compliance Assessment** — one assessment block per Australian Privacy Principle:
+ 1. **APP 1** — Open and transparent management of personal information
+ 2. **APP 2** — Anonymity and pseudonymity
+ 3. **APP 3** — Collection of solicited personal information
+ 4. **APP 4** — Dealing with unsolicited personal information
+ 5. **APP 5** — Notification of the collection of personal information
+ 6. **APP 6** — Use or disclosure of personal information
+ 7. **APP 7** — Direct marketing
+ 8. **APP 8** — Cross-border disclosure of personal information
+ 9. **APP 9** — Adoption, use or disclosure of government related identifiers
+ 10. **APP 10** — Quality of personal information
+ 11. **APP 11** — Security of personal information
+ 12. **APP 12** — Access to personal information
+ 13. **APP 13** — Correction of personal information
+
+ For each APP, document:
+ - Applicability: Applies / Does Not Apply (with rationale)
+ - Compliance status: ✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant
+ - Evidence of compliance measures
+ - Privacy risk if non-compliant (likelihood × impact)
+ - Mitigation actions with owner and target date
+
+ - **Privacy Risk Register** — risks identified during APP assessment, scored by likelihood and impact, with mitigations and residual risk.
+
+ - **Sensitive Information Assessment** — identify whether any sensitive information (as defined in s 6 of the Privacy Act) is processed: racial or ethnic origin, political opinions, religious beliefs, sexual orientation, criminal record, health information, genetic information, biometric information, trade union membership. If yes, note the additional consent requirements under APP 3.3.
+
+ - **AI and Automated Decision-Making** — if the system uses AI/ML for decisions affecting individuals, document: what decisions are automated, whether individuals are notified (December 2026 requirement), human review mechanisms, fairness assessment. Cross-reference `/arckit:au-ai-assurance` if applicable.
+
+ - **Recommendations** — prioritised list of privacy-enhancing measures.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The Privacy Act 1988 and OAIC PIA Guide MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the APP compliance summary table).
+
+## Important Notes
+
+- This is the **Australian** PIA, not the UK DPIA. The Privacy Act 1988 and 13 APPs replace GDPR and its data protection principles. Do not reference GDPR, ICO, or UK data protection law.
+- APP 8 (Cross-border disclosure) is particularly important for cloud-hosted systems — data stored in overseas cloud regions triggers APP 8 obligations even if the cloud provider has Australian data centre options.
+- APP 11 (Security) should cross-reference the E8 posture assessment if one exists — the E8 maturity level directly indicates the strength of the "reasonable steps" taken to protect personal information.
+- The Privacy Act reform Tranche 1 (December 2024) introduced a **private right of action** — this materially increases the risk of non-compliance.
+- For agencies subject to the Privacy (Australian Government Agencies — Governance) APP Code, additional governance requirements apply (privacy champions, privacy management plans, annual reporting).
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit:au-dss` -- PIA findings feed DSS Criterion 7 (Protect users' privacy).
+- `/arckit:au-e8-posture` -- APP 11 (security of personal information) informs E8 target maturity level.
+- `/arckit:risk` -- Privacy risks surface in the project risk register.
diff --git a/arckit-codex/prompts/arckit.au-pspf.md b/arckit-codex/prompts/arckit.au-pspf.md
new file mode 100644
index 00000000..c43ed1cf
--- /dev/null
+++ b/arckit-codex/prompts/arckit.au-pspf.md
@@ -0,0 +1,118 @@
+---
+description: "[COMMUNITY] Generate a Protective Security Policy Framework (PSPF) compliance assessment for Australian Government entities and contractors against the four security outcomes and 16 core requirements."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a PSPF-experienced security officer or government accreditation specialist. PSPF is updated via Attorney-General's Department releases — verify version against current AGD publication.
+
+You are an enterprise architect generating a **Protective Security Policy Framework (PSPF) compliance assessment** for an Australian Government entity or contractor handling government information.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Protective Security Policy Framework (PSPF) is the Australian Government's overarching security policy framework administered by the Attorney-General's Department. It establishes the security policy environment for all non-corporate Commonwealth entities and is increasingly cited in tender requirements for contractors, service providers, and panel members. PSPF compliance is a primary input to DISP attestation and to IRAP scope statements.
+
+PSPF is structured around **four security outcomes** with **16 core requirements**:
+
+- **Outcome 1: Security Governance** (4 core requirements)
+- **Outcome 2: Information Security** (4 core requirements — ISM is the technical instantiation)
+- **Outcome 3: Personnel Security** (4 core requirements)
+- **Outcome 4: Physical Security** (4 core requirements)
+
+**Authoritative anchor**: Protective Security Policy Framework —
+
+**Key references**:
+
+- PSPF (current edition) — Attorney-General's Department
+- ASD Information Security Manual (ISM) — instantiates Outcome 2
+- ASD Essential Eight — minimum cyber baseline supporting Outcome 2
+- DISP (Defence Industry Security Program) — adjacent framework
+
+## Process
+
+1. Read prerequisites:
+ - The project's E8 posture (`ARC-{P}-AUE8-v*`)
+ - The project's ISM applicability (`ARC-{P}-AUISM-v*`) — primary input
+ - The project's PIA (`ARC-{P}-AUPIA-v*`)
+ - The project's RISK artefact
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-pspf-template.md`
+ - Then: `.arckit/templates-custom/au-pspf-template.md`
+ - Fallback: `.arckit/templates/au-pspf-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUPSPF --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Entity Profile** — entity name, type (non-corporate Commonwealth / corporate Commonwealth / contractor / panel member / state-government with PSPF flow-down), PSPF applicability driver (direct / contractual flow-down), Chief Security Officer (CSO) designation, security maturity self-assessment level.
+
+ - **Outcome 1: Security Governance** — assessment of the 4 core requirements:
+ 1. CR1: Role of accountable authority (security governance leadership)
+ 2. CR2: Management structures and responsibilities (CSO, security committee, executives)
+ 3. CR3: Security planning and risk management
+ 4. CR4: Security maturity monitoring (Annual Self-Assessment + reporting to AGD)
+
+ - **Outcome 2: Information Security** — assessment of 4 core requirements (ISM is the primary instantiation here):
+ 1. CR5: Sensitive and classified information (information classification, marking, handling)
+ 2. CR6: Access to information (need-to-know, security clearances)
+ 3. CR7: Safeguarding information from cyber threats (E8 + ISM)
+ 4. CR8: Sensitive and classified discussions and communications
+
+ - **Outcome 3: Personnel Security** — assessment of 4 core requirements:
+ 1. CR9: Eligibility and suitability (vetting + AGSVA clearance process)
+ 2. CR10: Ongoing assessment (continuous suitability)
+ 3. CR11: Separation of personnel (off-boarding clearance debrief)
+ 4. CR12: Insider threat
+
+ - **Outcome 4: Physical Security** — assessment of 4 core requirements:
+ 1. CR13: Entity facilities (physical security zones)
+ 2. CR14: Working off-site (remote work + travel)
+ 3. CR15: Physical security risk
+ 4. CR16: Supporting services (cleaning, maintenance, contractor access)
+
+ For each Core Requirement document:
+ - Compliance status: ✅ Fully Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant / N/A
+ - Evidence supporting status (cite ARC-{P}-AUISM, AUE8, AUPIA, AUDISP where applicable)
+ - Specific gap description
+ - Remediation actions with owner and target date
+ - PSPF Self-Assessment Level achieved (if relevant — Compliant / Substantially Compliant / Partly Compliant / Not Compliant)
+
+ - **PSPF Annual Self-Assessment** — for non-corporate Commonwealth entities, document Annual Self-Assessment Report status, last submission to AGD, current self-assessed maturity level, gaps.
+
+ - **Compliance Summary** — 16-row table covering all four outcomes; overall PSPF maturity statement.
+
+ - **Recommendations** — prioritised remediations by Quick Wins / Short-Term / Medium-Term, each tagged to specific Core Requirement.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. PSPF (with edition) MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the four-outcome compliance summary table).
+
+## Important Notes
+
+- PSPF directly applies to **non-corporate Commonwealth entities**. Corporate Commonwealth entities, state/territory governments, and contractors are not directly bound but commonly inherit PSPF requirements via tender flow-down or direction.
+- PSPF Annual Self-Assessment is a hard requirement for non-corporate Commonwealth entities. Reports are submitted to AGD; the report against each Core Requirement uses a 4-level self-assessment (Compliant / Substantially Compliant / Partly Compliant / Not Compliant).
+- **ISM is the technical instantiation of Outcome 2 Information Security.** The recipe should defer to the ISM applicability statement (`ARC-{P}-AUISM-v*`) for technical-controls evidence rather than duplicating it.
+- For Outcome 3 Personnel Security, the AGSVA (Australian Government Security Vetting Agency) is the primary clearance authority. Cleared personnel records reference clearance levels (Baseline / NV1 / NV2 / PV) not individual identities.
+- For pure-cloud systems and contractors with no physical facilities, Outcome 4 Physical Security largely inherits from cloud provider IRAP attestations + host-organisation facilities. Document the inheritance explicitly.
+- For contractors handling Defence-related work, the PSPF assessment dovetails with DISP attestation — cite the DISP pack where it exists rather than re-evidencing.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit:au-ism-controls` -- ISM is the technical-controls instantiation of PSPF Information Security outcome — primary input to PSPF Outcome 2.
+- `/arckit:au-e8-posture` -- E8 supports PSPF Information Security outcome.
+- `/arckit:au-pia` -- APP 11 + PSPF Personnel Security overlap; PIA cross-reference.
+- `/arckit:au-disp-attestation` -- DISP attestation pack draws on PSPF compliance evidence.
diff --git a/arckit-codex/skills/arckit-au-ai-assurance/SKILL.md b/arckit-codex/skills/arckit-au-ai-assurance/SKILL.md
new file mode 100644
index 00000000..2ab0070a
--- /dev/null
+++ b/arckit-codex/skills/arckit-au-ai-assurance/SKILL.md
@@ -0,0 +1,126 @@
+---
+name: arckit-au-ai-assurance
+description: "[COMMUNITY] Generate an AI assurance assessment for Australian Government / regulated-sector AI systems covering DTA AI Policy v2.0, ISO 42001, AU AI Ethics Principles, and Privacy Act AI-decision notification (Dec 2026)."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified AI ethics specialist, Privacy Officer, or DTA-aligned AI assurance assessor before reliance. DTA AI Policy v2.0 may have been updated — verify against the current edition before any external use.
+
+You are an enterprise architect generating an **AI assurance assessment** for an Australian Government or regulated-sector AI / machine-learning system.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+Australia's AI assurance landscape combines several frameworks that together govern AI deployment in government and regulated industry:
+
+- **DTA Responsible AI Policy v2.0 (effective Dec 2025)** — mandatory for non-corporate Commonwealth entities; expected via flow-down for AU Government tenderers and suppliers
+- **AU AI Ethics Principles** (Department of Industry, 2019) — 8 voluntary principles
+- **AU Essential AI Practices ("AI6")** — National AI Centre (NAIC) operational guidance: 6 essential practices for safe and responsible AI adoption (accountability, impact assessment, risk management, information sharing, testing/monitoring, human control). Foundations + Implementation Guidance issued via ai.gov.au.
+- **ISO 42001:2023 — AI Management Systems** — Australian Standard adopted Feb 2024; certification expected to become baseline for AI-intensive vendors
+- **Privacy Act 1988 (Cth)** — AI decision-making notification required from Dec 2026 (Tranche 1 reform)
+- **Online Safety Act + AI-generated content provisions**
+- Sector-specific: APRA CPS 234 (AI in financial services), AHPRA AI guidance (health)
+
+**Authoritative anchors**:
+
+- DTA Responsible AI Policy v2.0 —
+- AU AI Ethics Principles —
+- AU Essential AI Practices (AI6) — Guidance for AI Adoption: Foundations —
+- AU Essential AI Practices — Implementation Guidance —
+- Privacy Act 1988 (Cth) —
+
+## Process
+
+1. Read prerequisites:
+ - Project's PIA artefact (`ARC-{P}-AUPIA-v*`) — APP 6 + APP 11 cross-reference
+ - Project's DATA artefact — for training/inference data classification
+ - Project's REQ artefact — extract AI-specific requirements
+ - Project's RISK artefact — existing AI risks
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-ai-assurance-template.md`
+ - Then: `.arckit/templates-custom/au-ai-assurance-template.md`
+ - Fallback: `.arckit/templates/au-ai-assurance-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUAIA --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **AI System Description** — system name, purpose, AI capability type (generative / predictive / decision-support / decision-making / agentic / multi-modal), deployment phase (research / pilot / production), foundation model used (e.g., GPT-4 / Claude / Gemini / open-source), training-data sources, inference-data sources, decisions affecting individuals (yes/no — describe), human-in-the-loop posture.
+
+ - **DTA Responsible AI Policy v2.0 Compliance** — assessment against the policy's six accountabilities:
+ 1. **Accountability** — designated AI accountable officer
+ 2. **Transparency** — public AI use disclosure
+ 3. **Risk-based approach** — AI risk assessment performed
+ 4. **Quality data + design integrity** — data lineage, model documentation
+ 5. **Privacy + security** — cross-reference PIA + ISM + E8
+ 6. **Human oversight + redress** — human review mechanism, individual appeal pathway
+
+ - **AU AI Ethics Principles Alignment** — assess against the 8 principles:
+ 1. Human, societal and environmental wellbeing
+ 2. Human-centred values
+ 3. Fairness
+ 4. Privacy protection and security
+ 5. Reliability and safety
+ 6. Transparency and explainability
+ 7. Contestability
+ 8. Accountability
+
+ For each principle: status (Aligned / Partial / Not Aligned), evidence, gap, mitigation.
+
+ - **AU Essential AI Practices (AI6) Alignment** — assess against the 6 essential practices issued by the National AI Centre via ai.gov.au:
+ 1. Decide who is accountable
+ 2. Understand impacts and plan accordingly
+ 3. Measure and manage risks
+ 4. Share essential information
+ 5. Test and monitor
+ 6. Maintain human control
+
+ For each practice: status (Implemented / Partial / Not Implemented / Not Applicable), evidence (artefact references where possible), gap, action. Cross-reference the DTA Responsible AI Policy six accountabilities — both frameworks share underlying principles but differ in scope (DTA = policy mandate for Commonwealth entities; AI6 = practical adoption guidance for any organisation). The AI6 *Implementation Guidance* on ai.gov.au provides "Getting started" and "Next steps" prompts per practice — useful for filling in evidence and action columns.
+
+ - **ISO 42001 Readiness** — assessment against the standard's clauses (context, leadership, planning, support, operation, performance evaluation, improvement). Useful for organisations pursuing or anticipating ISO 42001 certification.
+
+ - **Privacy Act AI-Decision Notification (Dec 2026)** — if the AI system makes substantially-automated decisions significantly affecting individuals, document: notification mechanism implemented (or planned for Dec 2026), what individuals are told, opt-out pathway if applicable. Cross-reference AUPIA APP 6 + APP 11.
+
+ - **Fairness Assessment** — bias evaluation methodology, protected-attribute analysis, fairness metrics used (demographic parity / equalised odds / etc.), test results across population segments, residual fairness risks.
+
+ - **Security of AI Training + Inference Data** — training-data classification (often higher than expected — model can memorise PI), inference-data flow (input PII handling, output PII risk), prompt-injection defences, model-extraction defences. Cross-reference E8 posture + ISM applicability.
+
+ - **Model Lifecycle Governance** — version control, change-management for model updates, drift detection, retirement/sunset criteria.
+
+ - **Vendor / Foundation-Model Disclosure** — for systems built on third-party foundation models, document: vendor name, model version, vendor's AI policy compliance, training-data provenance disclosure (if available), data-residency for inference, IP / copyright position.
+
+ - **Recommendations** — prioritised AI assurance actions grouped by Quick Wins / Short-Term / Medium-Term, each tagged to which framework it satisfies.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. DTA AI Policy v2.0, AU AI Ethics Principles, AU Essential AI Practices (AI6) — Foundations + Implementation Guidance, ISO 42001 (Australian Standard), and Privacy Act 1988 MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the DTA + Ethics Principles compliance summary table).
+
+## Important Notes
+
+- DTA AI Policy v2.0 applies to **non-corporate Commonwealth entities** directly. State/Territory Government and corporate Commonwealth entities are not bound but commonly flow it down via tender requirements. Suppliers to those entities should track for contractual flow-down.
+- The **December 2026 Privacy Act AI-decision notification** is a deadline. Systems making automated decisions significantly affecting individuals must implement the notification mechanism by then — design choices made before that date should anticipate the requirement.
+- Foundation-model use is a supply-chain concern. Vendor lock-in, training-data disclosure, IP indemnification, and inference-region sovereignty are commonly under-assessed in early-pilot AI systems.
+- Bias / fairness assessment is methodology-dependent. Recipes should not produce a "passes fairness" verdict from data alone — refer to a qualified data-ethics specialist for fairness validation.
+- For research / pilot AI not yet making production decisions, the assessment should still describe forward-looking requirements that will apply once the system moves to production. This avoids "we'll add it later" technical debt.
+- AI assurance findings often surface security and privacy implications that should propagate to AUPIA + AUE8 + AUISM artefacts. Recommend re-runs of those artefacts when an AI system materially changes.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `$arckit-au-pia` -- AI fairness + automated decision-making findings feed APP 6 + APP 11 in the PIA.
+- `$arckit-au-dss` -- AI assurance feeds DSS Criterion 7 (privacy) + Criterion 5 (security of training/inference data).
+- `$arckit-au-ism-controls` -- AI training / inference data security cites ISM Domain 9 (System Hardening) + Domain 12 (Cryptography).
+- `$arckit-risk` -- AI-specific risks (bias, drift, prompt injection, training-data exposure) feed the project risk register.
diff --git a/arckit-codex/skills/arckit-au-ai-assurance/agents/openai.yaml b/arckit-codex/skills/arckit-au-ai-assurance/agents/openai.yaml
new file mode 100644
index 00000000..5b1f887a
--- /dev/null
+++ b/arckit-codex/skills/arckit-au-ai-assurance/agents/openai.yaml
@@ -0,0 +1,2 @@
+policy:
+ allow_implicit_invocation: false
diff --git a/arckit-codex/skills/arckit-au-disp-attestation/SKILL.md b/arckit-codex/skills/arckit-au-disp-attestation/SKILL.md
new file mode 100644
index 00000000..f62bee75
--- /dev/null
+++ b/arckit-codex/skills/arckit-au-disp-attestation/SKILL.md
@@ -0,0 +1,111 @@
+---
+name: arckit-au-disp-attestation
+description: "[COMMUNITY] Generate a DISP (Defence Industry Security Program) Member self-attestation pack covering E8 ML2, ISM applicability, governance, personnel security, and incident reporting — supports DISP Levels 1, 2, 3."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified DISP-experienced security officer or DISP advisor before submission to Defence. DISP requirements may be updated — verify against the current DISP Membership Pack before any external use.
+
+You are an enterprise architect generating a **DISP (Defence Industry Security Program) Member self-attestation pack** for an Australian organisation supplying products or services to Defence.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Defence Industry Security Program (DISP) is the security accreditation framework for Australian organisations supplying Defence. DISP Membership has three levels (Levels 1, 2, 3 — formerly Entry, Level 1, Level 2 in earlier guidance) with progressively-deeper governance, personnel, ICT, physical, and supply-chain security obligations. Essential Eight ML2 has been the minimum cyber baseline for DISP members since 2025; ISM applicability scales with the level. The attestation pack is the supplier's self-evidence document referenced during DISP application, audit, and renewal.
+
+**Authoritative anchor**: Defence Industry Security Program —
+
+**Key references**:
+
+- DISP Membership Pack (current edition) — application form + evidence requirements
+- ASD Essential Eight Maturity Model (ML2 minimum for DISP) —
+- ASD Information Security Manual —
+- Protective Security Policy Framework (PSPF)
+- Defence Security Principles Framework (DSPF) — referenced sections only
+- Privacy Act 1988 (Cth) — APP 11 alignment
+
+## Process
+
+1. Read prerequisites:
+ - The project's E8 posture artefact (`ARC-{P}-AUE8-v*`) — primary input
+ - The project's ISM applicability statement (`ARC-{P}-AUISM-v*`) — primary input
+ - The project's PIA (`ARC-{P}-AUPIA-v*`) — APP 11 cross-reference
+ - The project's PSPF assessment (`ARC-{P}-AUPSPF-v*`) — physical / personnel / information security evidence
+ - The project's RISK artefact — for SecRisk register integration
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-disp-attestation-template.md` (user override)
+ - Then: `.arckit/templates-custom/au-disp-attestation-template.md`
+ - Fallback: `.arckit/templates/au-disp-attestation-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if needed.
+
+4. Use `scripts/bash/generate-document-id.sh AUDISP --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Organisation Profile** — entity name, ABN, primary business activity, Defence contracts in scope, headcount, sites, foreign ownership / control / influence (FOCI) declaration.
+
+ - **DISP Level Sought** — Level 1 / Level 2 / Level 3, regulatory driver (specific contract requirement, panel mandate, anticipated tender pipeline), justification of level chosen.
+
+ - **Security Officer Designation** — Chief Security Officer (CSO) name + role + authority, deputy / backup CSO, contact details, vetting status. **DISP requires a named, suitably-cleared CSO with authority across the four security domains.**
+
+ - **Four Security Domains Coverage** — DISP requires evidence across four domains:
+ 1. **Governance** — security policy, risk management, audit, incident management, change control
+ 2. **Personnel Security** — security clearances appropriate to work, security awareness training, separation of duties, off-boarding
+ 3. **Physical Security** — facility security, ICT equipment security, equipment lifecycle (cloud-only systems may inherit much of this from cloud provider's IRAP)
+ 4. **Information & Cyber Security** — Essential Eight ML2 minimum, ISM applicability, cryptography, gateway, monitoring, BCP
+
+ For each domain, document:
+ - Current implementation state (cite E8 posture, ISM applicability, supporting policies)
+ - Evidence references (artefact IDs + document register)
+ - Gap description
+ - Remediation plan with target dates
+ - Sign-off statement by accountable officer
+
+ - **Essential Eight ML2 Evidence Per Strategy** — for each of the 8 E8 strategies, summarise the current ML position and evidence supporting ML2 attestation. Cite the AUE8 artefact directly.
+
+ - **ISM Applicability Highlights** — beyond E8, summarise which ISM domains apply, current implementation summary, and identify any ISM gaps that materially affect DISP attestation. Cite the AUISM artefact.
+
+ - **Foreign Ownership, Control or Influence (FOCI) Declaration** — disclose any foreign ownership > 5%, foreign-board-member arrangements, foreign-supply-chain dependencies, foreign-personnel access. DISP Level 2 + 3 require FOCI mitigation plans where applicable.
+
+ - **Supply Chain Security** — disclose Tier 1 suppliers (MSPs, SaaS, cloud), supply-chain attestations held (SOC 2 / ISO 27001 / IRAP), supply-chain risk management process.
+
+ - **Incident Response & Reporting** — incident response plan summary, 24-hour rapid notification capability for Defence-relevant incidents, OAIC NDB scheme integration, evidence of last incident response exercise. Cite NDB playbook (`ARC-{P}-AUNDB-v*`) if available.
+
+ - **Security Awareness Training** — DISP-mandated security awareness training programme, completion rate, refresher cadence, security-clearance-holder additional briefings (pre/post-leave for cleared personnel).
+
+ - **Annual Self-Audit Plan** — DISP requires annual self-audit; describe scope, methodology, evidence retention.
+
+ - **Attestation Statement** — formal CSO + Director sign-off statement attesting to the accuracy of the pack, with signature blocks, date, and re-attestation cadence.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The DISP Membership Pack (with edition) MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the Four Security Domains coverage table).
+
+## Important Notes
+
+- The pack is a **self-attestation**, not a third-party assurance. Defence reserves the right to audit. Artefact tone should be evidence-based and conservative — do not claim controls not yet implemented.
+- The CSO designation is a hard requirement. If no CSO is named in the source artefacts, the pack must explicitly flag this as an outstanding action — it cannot be filled in by the recipe.
+- For Level 2 + 3 members supplying classified Defence work, security clearances of personnel handling that work must be evidenced. Records of clearance levels held may be sensitive — reference by clearance level (Baseline / NV1 / NV2 / PV) not by individual name.
+- Cloud-only systems that inherit Physical Security from an IRAP-assessed cloud provider should explicitly cite the cloud provider's IRAP scope statement, not generic marketing.
+- The pack should integrate with the project's risk register — material residual risks should appear both in the risk register and in the DISP pack's gap descriptions.
+- For DISP renewal cycles, the artefact should produce a redline-friendly format so year-on-year changes are easy to track.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `$arckit-au-e8-posture` -- E8 ML2 evidence per strategy is a primary input to the DISP attestation pack.
+- `$arckit-au-ism-controls` -- ISM applicability statement is a primary input — controls beyond E8 mandated by DISP level.
+- `$arckit-au-pia` -- Privacy Act + APP 11 alignment cited in attestation pack.
+- `$arckit-au-ndb-playbook` -- Notifiable Data Breach response is the operational complement to DISP incident reporting.
diff --git a/arckit-codex/skills/arckit-au-disp-attestation/agents/openai.yaml b/arckit-codex/skills/arckit-au-disp-attestation/agents/openai.yaml
new file mode 100644
index 00000000..5b1f887a
--- /dev/null
+++ b/arckit-codex/skills/arckit-au-disp-attestation/agents/openai.yaml
@@ -0,0 +1,2 @@
+policy:
+ allow_implicit_invocation: false
diff --git a/arckit-codex/skills/arckit-au-dss/SKILL.md b/arckit-codex/skills/arckit-au-dss/SKILL.md
new file mode 100644
index 00000000..8b209a43
--- /dev/null
+++ b/arckit-codex/skills/arckit-au-dss/SKILL.md
@@ -0,0 +1,103 @@
+---
+name: arckit-au-dss
+description: "[COMMUNITY] Generate a DTA Digital Service Standard compliance assessment for Australian Government digital services against all 13 criteria."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified DTA assessor or digital delivery lead before reliance. The DTA Digital Service Standard was refreshed in July 2025 — verify criteria against the current published version.
+
+You are an enterprise architect generating a **DTA Digital Service Standard compliance assessment** for an Australian Government digital service.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Digital Transformation Agency (DTA) Digital Service Standard sets the mandatory criteria that Australian Government digital services must meet. Services subject to the Standard must demonstrate compliance at key assessment points. The Standard replaced the earlier Digital Service Standard (2016) with a refreshed version in July 2025.
+
+**Authoritative anchor**: DTA Digital Service Standard —
+
+**Key Australian Digital Service References**:
+
+- DTA Digital Service Standard (July 2025 refresh)
+- DTA Service Design and Delivery Process
+- Digital Government Strategy
+- Web Content Accessibility Guidelines (WCAG) 2.2 Level AA
+- Style Manual for Australian Government (style.gov.au)
+- DTA Content Guide
+- Whole of Government Digital and ICT Investment Oversight Framework
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract user-facing requirements, accessibility requirements, technology choices
+ - The project's STKE artefact — extract user research, stakeholder engagement evidence
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - **First**, check `.arckit/templates-custom/au-dss-template.md` (user override)
+ - **Then**, `.arckit/templates-custom/au-dss-template.md`
+ - **Fallback**, `.arckit/templates/au-dss-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUDSS --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Service Context** — service name, owning agency/department, service phase (Discovery / Alpha / Beta / Live), user base (public-facing / internal / both), annual transaction volume (if known).
+
+ - **13-Criterion Assessment** — one assessment block per Digital Service Standard criterion:
+ 1. **Understand user needs** — research conducted with real users, needs documented
+ 2. **Have a multidisciplinary team** — team composition, capability coverage, DDaT roles
+ 3. **Agile and user-centred process** — delivery methodology, iteration cadence, user feedback loops
+ 4. **Understand tools and systems** — technology landscape mapped, legacy dependencies identified
+ 5. **Make it secure** — security posture, E8 alignment, threat assessment, incident response
+ 6. **Consistent and responsive design** — design system usage, responsive breakpoints, device testing
+ 7. **Protect users' privacy** — PIA completed, APP compliance, data minimisation, consent
+ 8. **Make source code open** — open-source strategy, code repository, licence
+ 9. **Make it accessible** — WCAG 2.2 AA compliance, assistive technology testing, accessibility statement
+ 10. **Test the service** — testing strategy (unit, integration, UAT, accessibility, performance, security)
+ 11. **Measure performance** — KPIs defined (completion rate, user satisfaction, cost per transaction, digital take-up)
+ 12. **Don't forget the non-digital experience** — assisted digital, phone, in-person channel design
+ 13. **Encourage everyone to use the digital service** — channel shift strategy, take-up targets
+
+ For each criterion, document:
+ - Assessment status: ✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A
+ - Evidence summary (what demonstrates compliance)
+ - Gap description (what is missing)
+ - Remediation actions with owner and target date
+
+ - **Compliance Summary** — table: Criterion # | Criterion Name | Status | Gap Count
+
+ - **Assessment Readiness** — for services approaching Alpha/Beta/Live assessment, identify the top 3 risks to passing and recommended mitigations.
+
+ - **Recommendations** — prioritised list of actions to improve compliance posture, grouped by criterion priority.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The DTA Digital Service Standard MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the compliance summary table showing status per criterion).
+
+## Important Notes
+
+- The DTA Digital Service Standard applies to **all new and redesigned Australian Government digital services**. Existing services may be assessed when undergoing significant change.
+- Criterion 5 (Make it secure) should cross-reference the ASD Essential Eight assessment (`$arckit-au-e8-posture`) if one exists.
+- Criterion 7 (Protect users' privacy) should cross-reference the Privacy Impact Assessment (`$arckit-au-pia`) if one exists.
+- Criterion 9 (Make it accessible) requires WCAG 2.2 Level AA as the minimum standard for Australian Government services.
+- The Standard is assessed at Alpha, Beta, and Live phases — the depth of evidence expected increases at each gate.
+- This assessment is analogous to the UK GDS Service Standard assessment (`$arckit-service-assessment`) but uses Australian criteria and governance structures.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `$arckit-au-e8-posture` -- DSS Criterion 5 (Make it secure) feeds into the E8 maturity posture assessment.
+- `$arckit-au-pia` -- DSS Criterion 7 (Protect users' privacy) feeds into the Privacy Impact Assessment.
+- `$arckit-risk` -- DSS gaps surface as delivery and compliance risks for the risk register.
diff --git a/arckit-codex/skills/arckit-au-dss/agents/openai.yaml b/arckit-codex/skills/arckit-au-dss/agents/openai.yaml
new file mode 100644
index 00000000..5b1f887a
--- /dev/null
+++ b/arckit-codex/skills/arckit-au-dss/agents/openai.yaml
@@ -0,0 +1,2 @@
+policy:
+ allow_implicit_invocation: false
diff --git a/arckit-codex/skills/arckit-au-e8-posture/SKILL.md b/arckit-codex/skills/arckit-au-e8-posture/SKILL.md
new file mode 100644
index 00000000..a4f7771d
--- /dev/null
+++ b/arckit-codex/skills/arckit-au-e8-posture/SKILL.md
@@ -0,0 +1,98 @@
+---
+name: arckit-au-e8-posture
+description: "[COMMUNITY] Generate an ASD Essential Eight maturity posture assessment for Australian Government projects against all eight mitigation strategies at ML0–ML3."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified CISO or security assessor before reliance. Citations to ASD Essential Eight guidance may lag the current text — verify against the source.
+
+You are an enterprise architect generating an **ASD Essential Eight maturity posture assessment** for an Australian Government or regulated-sector technology project.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Australian Signals Directorate (ASD) Essential Eight is the baseline cyber-security mitigation framework for Australian Government entities. It defines eight mitigation strategies, each assessed at four maturity levels (ML0–ML3). Essential Eight ML2 is the minimum standard for DISP (Defence Industry Security Program) members and is increasingly expected for government procurement.
+
+**Authoritative anchor**: ASD Essential Eight Maturity Model —
+
+**Key Australian Security References**:
+
+- ASD Essential Eight Maturity Model (current edition)
+- ASD Information Security Manual (ISM) —
+- Protective Security Policy Framework (PSPF) —
+- Australian Cyber Security Strategy 2023–2030
+- DISP Essential Eight ML2 mandate (effective 2025)
+- Privacy Act 1988 (Cth) — security of personal information (APP 11)
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract NFR-SEC requirements, data classification, compliance obligations
+ - The project's RISK artefact — extract existing security risks and mitigations
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - **First**, check `.arckit/templates-custom/au-e8-posture-template.md` (user override)
+ - **Then**, `.arckit/templates-custom/au-e8-posture-template.md`
+ - **Fallback**, `.arckit/templates/au-e8-posture-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUE8 --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **System Context** — system name, classification level (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET), deployment model (cloud / on-premise / hybrid), IRAP assessment status, data sovereignty position.
+
+ - **Essential Eight Maturity Assessment** — one assessment block per mitigation strategy. For each of the eight strategies:
+ 1. **Application Control** — only approved applications execute on systems
+ 2. **Patch Applications** — security patches for applications applied within timeframes
+ 3. **Configure Microsoft Office Macro Settings** — macros blocked or restricted per policy
+ 4. **User Application Hardening** — web browsers, email clients, Office configured to block untrusted content
+ 5. **Restrict Administrative Privileges** — admin access validated, separated, and time-limited
+ 6. **Patch Operating Systems** — OS patches applied within timeframes, unsupported OS replaced
+ 7. **Multi-Factor Authentication** — MFA on all remote access, privileged access, and data repositories
+ 8. **Regular Backups** — backups performed, tested, and stored securely per retention schedule
+
+ For each strategy, document:
+ - Current maturity level (ML0 / ML1 / ML2 / ML3) with evidence
+ - Target maturity level with rationale (regulatory driver or risk appetite)
+ - Gap description (specific controls not yet implemented)
+ - Remediation actions with owner and target date
+ - Residual risk if gap persists
+
+ - **Maturity Summary Matrix** — 8-row table: Strategy | Current ML | Target ML | Gap Count | Priority (Critical / High / Medium / Low)
+
+ - **DISP Compliance Position** — if the entity is a DISP member, assess whether current posture meets ML2 minimum across all eight strategies. Flag any strategy below ML2 as a DISP non-compliance risk.
+
+ - **Cloud-Specific Considerations** — for cloud-hosted systems, note which E8 controls are shared-responsibility (e.g., OS patching on PaaS vs IaaS), which are vendor-managed (e.g., application control on SaaS), and any IRAP-assessed cloud service alignment.
+
+ - **Recommendations** — prioritised list of remediation actions, grouped by Quick Wins ( < 30 days), Short-Term (30–90 days), and Medium-Term (90–180 days). Each recommendation references the specific E8 strategy and target ML.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The ASD Essential Eight Maturity Model MUST appear in the Document Register with its primary URL and verification date.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the maturity summary matrix showing current ML vs target ML per strategy).
+
+## Important Notes
+
+- ML0 means the strategy is **not implemented** — it does not mean "assessed and found satisfactory at a low level." Explicitly state this distinction.
+- Each maturity level has specific sub-controls defined by ASD. Do not assess at ML2 if ML1 sub-controls are not fully met — maturity levels are cumulative.
+- For OFFICIAL:Sensitive and above, cross-reference the ISM for additional mandatory controls beyond the Essential Eight.
+- The Essential Eight is a **mitigation** framework, not a comprehensive security standard. Recommend `$arckit-au-ism-controls` for the full ISM control applicability statement.
+- For energy-sector projects, recommend `$arckit-au-aescsf` as the AESCSF capability domains build on and extend the E8 baseline.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `$arckit-au-ism-controls` -- E8 posture feeds the ISM control applicability statement — target ML drives which ISM controls are mandatory.
+- `$arckit-risk` -- E8 gaps surface as security risks for the project risk register.
diff --git a/arckit-codex/skills/arckit-au-e8-posture/agents/openai.yaml b/arckit-codex/skills/arckit-au-e8-posture/agents/openai.yaml
new file mode 100644
index 00000000..5b1f887a
--- /dev/null
+++ b/arckit-codex/skills/arckit-au-e8-posture/agents/openai.yaml
@@ -0,0 +1,2 @@
+policy:
+ allow_implicit_invocation: false
diff --git a/arckit-codex/skills/arckit-au-ism-controls/SKILL.md b/arckit-codex/skills/arckit-au-ism-controls/SKILL.md
new file mode 100644
index 00000000..516e42e2
--- /dev/null
+++ b/arckit-codex/skills/arckit-au-ism-controls/SKILL.md
@@ -0,0 +1,114 @@
+---
+name: arckit-au-ism-controls
+description: "[COMMUNITY] Generate an ASD Information Security Manual (ISM) control applicability statement for Australian Government projects, scoped to the system's classification and supporting DISP attestation."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified IRAP Assessor or CISO before reliance. ISM is updated quarterly — verify control identifiers against the current edition before any external use.
+
+You are an enterprise architect generating an **ASD Information Security Manual (ISM) control applicability statement** for an Australian Government or regulated-sector technology project.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Australian Signals Directorate (ASD) Information Security Manual (ISM) is the comprehensive set of cyber-security controls for Australian Government information systems. Where the Essential Eight is a mitigation framework targeting attack-vector defence, the ISM is the comprehensive control set covering governance, personnel, physical, communications, ICT system, networking, cryptography, gateway, data-transfer, evaluation, working-off-site, and incident-response domains. ISM compliance is the core technical-controls evidence for PSPF Information Security outcome and a primary input to DISP attestation.
+
+**Authoritative anchor**: ASD Information Security Manual —
+
+**Key Australian Security References**:
+
+- ASD Information Security Manual (current edition; updated quarterly)
+- Protective Security Policy Framework (PSPF) —
+- ASD Essential Eight Maturity Model (mitigation subset of ISM)
+- Defence Industry Security Program (DISP) requirements
+- IRAP (Information Security Registered Assessors Program) — control assurance methodology
+- Privacy Act 1988 (Cth) — APP 11 alignment
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract NFR-SEC requirements, data classification, compliance obligations
+ - The project's RISK artefact — extract existing security risks
+ - The project's E8 posture artefact (`ARC-{P}-AUE8-v*`) if available — provides E8 sub-control evidence
+ - The project's DATA artefact — for classification-driven control scoping
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-ism-controls-template.md` (user override)
+ - Then: `.arckit/templates-custom/au-ism-controls-template.md`
+ - Fallback: `.arckit/templates/au-ism-controls-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist.
+
+4. Use `scripts/bash/generate-document-id.sh AUISM --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **System Context** — system name, classification level (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET), deployment model, IRAP assessment status, sovereignty position. Classification drives applicability — controls applicable at OFFICIAL:Sensitive are a subset of those at PROTECTED.
+
+ - **Control Domain Applicability Matrix** — table covering all 17 ISM control areas (15 ASD ISM chapter domains plus 2 cross-cutting areas — Cloud/IaaS and Working-Off-Site), marking applicability per system classification:
+ 1. **Cyber Security Governance** — security risk management, security documentation, change management
+ 2. **Cyber Security Incidents** — detection, reporting, response, business continuity
+ 3. **Outsourced Services** — managed service providers, cloud, supply chain
+ 4. **Security Documentation** — system security plans, security risk management plans
+ 5. **Personnel Security** — clearance levels, awareness training, separation of duties
+ 6. **Physical Security** — facilities, equipment, ICT equipment lifecycle
+ 7. **Communications Infrastructure** — fibre, cabling, telephony
+ 8. **ICT Equipment Security** — hardware lifecycle, media, sanitisation
+ 9. **System Hardening** — operating systems, applications, authentication, network
+ 10. **System Management** — administration, monitoring, maintenance, vulnerability mgmt
+ 11. **System Monitoring** — event logging, audit, security metrics
+ 12. **Cryptography** — cryptographic fundamentals, ASD-approved algorithms, key management
+ 13. **Gateway Security** — gateway architecture, content filtering, DLP
+ 14. **Data Transfer** — between domains, between systems, data import/export
+ 15. **Cloud and IaaS Considerations** — IRAP assessment status, sovereign cloud, shared responsibility
+ 16. **Working-Off-Site Security** — remote work, mobile devices, BYOD
+ 17. **Evaluation Activities** — Common Criteria, FIPS, vendor product testing
+
+ - **Per-Domain Control Applicability Assessment** — for each in-scope domain, document:
+ - Applicability rationale (which controls apply at the system's classification level)
+ - Current implementation status: ✅ Implemented / ⚠️ Partial / ❌ Not Implemented / N/A
+ - Evidence supporting the status (cite E8 posture artefact, IRAP report, vendor attestations)
+ - Gap description with specific ISM control IDs not yet met
+ - Remediation actions with owner and target date
+ - Compensating controls if applicable
+
+ - **ISM-to-E8 Cross-Reference** — show which E8 strategies map to which ISM domains. Reinforces the E8-as-mitigation-subset framing for governance audiences.
+
+ - **Compliance Summary** — table summarising domain-by-domain compliance posture; overall ISM applicability score (controls implemented / controls applicable).
+
+ - **IRAP Assessment Position** — if the system holds or pursues IRAP assessment, note the IRAP scope, assessment date, residual risks accepted, and re-assessment cadence. For systems integrating with IRAP-assessed cloud services, note the inherited control posture.
+
+ - **Recommendations** — prioritised remediation actions grouped by Quick Wins ( < 30 days), Short-Term (30–90 days), Medium-Term (90–180 days). Each recommendation references the specific ISM control ID(s).
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The ASD ISM (with edition / publication date) MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the Compliance Summary table showing per-domain status).
+
+## Important Notes
+
+- ISM controls are tagged with applicability flags (ALL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET / TOP SECRET). The applicability statement must select controls appropriate to the *highest classification of information processed*, not the *lowest*.
+- ISM is updated quarterly — control IDs and wording can change. The artefact should record the ISM edition / publication date used as a verification anchor.
+- For systems integrating with IRAP-assessed cloud services, note explicit shared-responsibility — many ISM controls inherit from the cloud provider's IRAP attestation. Cite the IRAP scope statement, not the cloud provider's marketing.
+- Cross-reference the E8 posture artefact wherever an ISM control maps to an E8 sub-control — avoids duplication and keeps the two artefacts consistent.
+- For DISP members or systems supporting Defence work, scope the Personnel Security and Physical Security domains carefully — these are commonly under-assessed in cloud-only environments.
+- The Cyber Security Incidents domain should reference the project's NDB playbook (`$arckit-au-ndb-playbook`) for personal-information breach scenarios.
+- The Outsourced Services domain must include MSP-held admin role boundaries, contractual security-control flow-down, and supply-chain attestation review.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `$arckit-au-disp-attestation` -- ISM applicability is a primary input to the DISP Member self-attestation pack.
+- `$arckit-au-pspf` -- ISM is the technical-controls instantiation of PSPF Information Security outcome — feeds the PSPF assessment.
+- `$arckit-au-e8-posture` -- E8 is a mitigation subset of ISM. The ISM applicability statement extends beyond E8 to cover personnel security, physical security, and information governance controls.
+- `$arckit-risk` -- ISM control gaps surface as security risks for the project risk register.
diff --git a/arckit-codex/skills/arckit-au-ism-controls/agents/openai.yaml b/arckit-codex/skills/arckit-au-ism-controls/agents/openai.yaml
new file mode 100644
index 00000000..5b1f887a
--- /dev/null
+++ b/arckit-codex/skills/arckit-au-ism-controls/agents/openai.yaml
@@ -0,0 +1,2 @@
+policy:
+ allow_implicit_invocation: false
diff --git a/arckit-codex/skills/arckit-au-ndb-playbook/SKILL.md b/arckit-codex/skills/arckit-au-ndb-playbook/SKILL.md
new file mode 100644
index 00000000..efa0737d
--- /dev/null
+++ b/arckit-codex/skills/arckit-au-ndb-playbook/SKILL.md
@@ -0,0 +1,113 @@
+---
+name: arckit-au-ndb-playbook
+description: "[COMMUNITY] Generate a Notifiable Data Breach (NDB) scheme response playbook under Privacy Act 1988 Part IIIC — eligible-data-breach test, 30-day OAIC notification timeline, individual notification, containment, and lessons-learned framework."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a Privacy Officer and legal counsel before adoption. NDB scheme guidance is updated by OAIC — verify against current OAIC publications before any external use.
+
+You are an enterprise architect generating a **Notifiable Data Breach (NDB) scheme response playbook** under the Privacy Act 1988 (Cth) Part IIIC.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Notifiable Data Breach (NDB) scheme under Privacy Act 1988 (Cth) Part IIIC requires APP entities (Australian Government agencies + private organisations subject to the Privacy Act) to notify the **OAIC and affected individuals** when an "eligible data breach" of personal information occurs and is likely to result in serious harm.
+
+The NDB scheme has three statutory tests:
+
+1. **Unauthorised access to / disclosure of, or loss of, personal information**
+2. **Likely to result in serious harm** to one or more individuals
+3. **Cannot be remediated through reasonable steps** to prevent the serious harm
+
+The notification clock is **30 days** to OAIC + affected individuals from the time the entity has reasonable grounds to believe an eligible data breach has occurred. Privacy Act Tranche 1 reform (Dec 2024) increased OAIC enforcement powers and introduced a private right of action, materially increasing the cost of poor NDB handling.
+
+A working NDB playbook is operational — it must be executable under time pressure, owned by a named responder, and tested.
+
+**Authoritative anchors**:
+
+- Privacy Act 1988 (Cth) Part IIIC —
+- OAIC NDB scheme guidance —
+
+## Process
+
+1. Read prerequisites:
+ - The project's PIA (`ARC-{P}-AUPIA-v*`) — APP 11 cross-reference
+ - The project's E8 posture (`ARC-{P}-AUE8-v*`) — security baseline
+ - The project's ISM applicability (`ARC-{P}-AUISM-v*`) — Domain 2 (Cyber Security Incidents)
+ - The project's RISK artefact
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-ndb-playbook-template.md`
+ - Then: `.arckit/templates-custom/au-ndb-playbook-template.md`
+ - Fallback: `.arckit/templates/au-ndb-playbook-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUNDB --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Entity Profile** — APP entity status, Privacy Officer designation, accountable officer for NDB response, business hours + after-hours contact details, key incident-team roles.
+
+ - **NDB Eligibility Test** — explicit decision tree:
+ 1. Has there been unauthorised access to / disclosure of, or loss of, personal information?
+ 2. Is serious harm likely to result?
+ 3. Can the entity remediate through reasonable steps to prevent the serious harm?
+
+ If 1 + 2 = Yes and 3 = No → eligible data breach → notify within 30 days.
+
+ - **30-Day Timeline Plan** — day-by-day milestones from Day 0 (becoming aware of suspected breach) through Day 30 (OAIC + individual notification deadline):
+ - Day 0–1: Detect, contain, assess + activate playbook
+ - Day 1–7: Investigate, scope, classify
+ - Day 7–14: Eligibility assessment, draft notifications
+ - Day 14–21: Legal review, executive sign-off, finalise notifications
+ - Day 21–30: OAIC notification, individual notifications, public statement (if required)
+
+ - **Roles & Responsibilities (RACI)** — Privacy Officer, Security Officer, CISO, Legal, Communications, accountable executive — clear responsibility matrix.
+
+ - **Detection + Containment Procedures** — how breaches become known to the playbook owner (SIEM alerts, customer reports, vendor disclosure, insider report); immediate containment steps; evidence preservation.
+
+ - **Assessment Procedure** — how to determine eligibility under the three statutory tests; serious-harm assessment criteria (financial loss, identity theft, emotional distress, physical safety, reputational harm); reasonable-steps mitigation to remove eligibility.
+
+ - **OAIC Notification Form Content** — what OAIC requires per the statutory form: nature of breach, kind of information involved, recommendations for affected individuals, contact details. Template language for use in the OAIC form.
+
+ - **Individual Notification Approach** — direct vs publication-based notification options, content requirements, channel decisions, language and accessibility considerations.
+
+ - **Communications Plan** — internal, external, media, regulator-coordinated. Pre-written holding statements + escalation triggers.
+
+ - **Post-Incident Review** — root cause analysis, lessons learned, control updates feeding back into AUE8 + AUISM + AUPIA artefacts.
+
+ - **Coordination With Other Reporting Obligations** — SOCI Act 12hr / 72hr (where applicable), DISP incident reporting, sectoral reporting (APRA, AHPRA, etc.). Single incident may trigger multiple obligations on different timelines.
+
+ - **Tabletop Exercise Plan** — annual tabletop scenario, evidence retention, lessons-learned cycle.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. Privacy Act 1988 + OAIC NDB scheme guidance MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the 30-day timeline summary).
+
+## Important Notes
+
+- The 30-day notification clock starts from "reasonable grounds to believe" an eligible breach has occurred — **not** from the breach itself, and **not** from confirmation. This is the most commonly misread part of the scheme. The recipe should make this distinction unambiguous.
+- The "reasonable steps to remediate" test is the off-ramp from notification — if the entity can prevent serious harm through containment / mitigation actions, no notification is required. But this needs to be assessed conservatively; OAIC will second-guess hindsight optimism.
+- For multi-jurisdictional incidents (e.g., breach affecting AU + NZ + EU residents), the 30-day clock is not the only timeline. EU GDPR is 72 hours; NZ Privacy Act is "as soon as practicable". The playbook should flag this for legal-counsel coordination.
+- "Serious harm" is a broad threshold including financial loss, identity theft, **emotional distress** (including humiliation), and **reputational harm**. It is materially broader than "real prospect of significant harm" some practitioners assume.
+- For SOCI-covered entities, the NDB 30-day clock runs in parallel with SOCI 12hr / 72hr cyber incident reporting. The playbook should explicitly coordinate both timelines so the 12hr SOCI report doesn't pre-commit positions before the NDB assessment is complete.
+- Pre-written holding statements and notification templates dramatically reduce time-to-notify under pressure. Recipes producing this artefact should include template language wherever possible.
+- The playbook is operational. It should be **tested** at least annually via tabletop exercise; the recipe should output an exercise scenario template as part of the deliverable.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `$arckit-au-pia` -- NDB playbook is the operational complement to AUPIA APP 11 mitigation; APP 11 references NDB.
+- `$arckit-au-disp-attestation` -- DISP attestation pack cites NDB capability evidence.
+- `$arckit-risk` -- NDB-relevant risks tagged into the project risk register.
diff --git a/arckit-codex/skills/arckit-au-ndb-playbook/agents/openai.yaml b/arckit-codex/skills/arckit-au-ndb-playbook/agents/openai.yaml
new file mode 100644
index 00000000..5b1f887a
--- /dev/null
+++ b/arckit-codex/skills/arckit-au-ndb-playbook/agents/openai.yaml
@@ -0,0 +1,2 @@
+policy:
+ allow_implicit_invocation: false
diff --git a/arckit-codex/skills/arckit-au-pia/SKILL.md b/arckit-codex/skills/arckit-au-pia/SKILL.md
new file mode 100644
index 00000000..68ebde7e
--- /dev/null
+++ b/arckit-codex/skills/arckit-au-pia/SKILL.md
@@ -0,0 +1,111 @@
+---
+name: arckit-au-pia
+description: "[COMMUNITY] Generate a Privacy Impact Assessment (PIA) for Australian Government entities under Privacy Act 1988 s33D, assessing compliance with all 13 Australian Privacy Principles (APPs)."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified Privacy Officer, DPO, or legal counsel before reliance. Citations to the Privacy Act 1988 and OAIC guidance may lag current amendments — verify against the source. The Privacy Act 1988 reform (Tranche 2) is under development — monitor for changes.
+
+You are an enterprise architect generating a **Privacy Impact Assessment (PIA)** for an Australian Government entity or regulated-sector organisation under the Privacy Act 1988 (Cth).
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+Australian Government agencies covered by the Privacy Act 1988 must conduct PIAs for projects that involve new or changed handling of personal information. Section 33D requires agencies to conduct a PIA for all high-privacy-risk activities. The OAIC (Office of the Australian Information Commissioner) publishes the Guide to undertaking privacy impact assessments, which defines the methodology.
+
+**Authoritative anchors**:
+
+- Privacy Act 1988 (Cth) —
+- OAIC Guide to undertaking privacy impact assessments —
+- Australian Privacy Principles (APPs) — Schedule 1 of the Privacy Act 1988
+- Privacy (Australian Government Agencies — Governance) APP Code 2017
+- OAIC Privacy regulatory action policy
+
+**Key Privacy Act 1988 Reform Context**:
+
+- Tranche 1 effective December 2024 — enhanced enforcement powers, tiered penalties, private right of action
+- AI decision-making notification required from December 2026
+- Tranche 2 under development — ~93 remaining proposals from Attorney-General's review
+- Small business exemption changes from 1 July 2026
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract data requirements (DR-*), NFR-SEC requirements, integration requirements (INT-*)
+ - The project's DATA artefact — extract entity model, PII fields, data flows
+ - The project's STKE artefact — extract data subjects, stakeholder privacy expectations
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - **First**, check `.arckit/templates-custom/au-pia-template.md` (user override)
+ - **Then**, `.arckit/templates-custom/au-pia-template.md`
+ - **Fallback**, `.arckit/templates/au-pia-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUPIA --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Project Description** — what the project does, what personal information is involved, why it is needed, who the data subjects are, estimated data volumes.
+
+ - **Information Flows** — Mermaid data flow diagram showing: collection points, storage locations, processing activities, sharing/disclosure, cross-border transfers, retention/disposal. Mark each flow with the APP that governs it.
+
+ - **13 APP Compliance Assessment** — one assessment block per Australian Privacy Principle:
+ 1. **APP 1** — Open and transparent management of personal information
+ 2. **APP 2** — Anonymity and pseudonymity
+ 3. **APP 3** — Collection of solicited personal information
+ 4. **APP 4** — Dealing with unsolicited personal information
+ 5. **APP 5** — Notification of the collection of personal information
+ 6. **APP 6** — Use or disclosure of personal information
+ 7. **APP 7** — Direct marketing
+ 8. **APP 8** — Cross-border disclosure of personal information
+ 9. **APP 9** — Adoption, use or disclosure of government related identifiers
+ 10. **APP 10** — Quality of personal information
+ 11. **APP 11** — Security of personal information
+ 12. **APP 12** — Access to personal information
+ 13. **APP 13** — Correction of personal information
+
+ For each APP, document:
+ - Applicability: Applies / Does Not Apply (with rationale)
+ - Compliance status: ✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant
+ - Evidence of compliance measures
+ - Privacy risk if non-compliant (likelihood × impact)
+ - Mitigation actions with owner and target date
+
+ - **Privacy Risk Register** — risks identified during APP assessment, scored by likelihood and impact, with mitigations and residual risk.
+
+ - **Sensitive Information Assessment** — identify whether any sensitive information (as defined in s 6 of the Privacy Act) is processed: racial or ethnic origin, political opinions, religious beliefs, sexual orientation, criminal record, health information, genetic information, biometric information, trade union membership. If yes, note the additional consent requirements under APP 3.3.
+
+ - **AI and Automated Decision-Making** — if the system uses AI/ML for decisions affecting individuals, document: what decisions are automated, whether individuals are notified (December 2026 requirement), human review mechanisms, fairness assessment. Cross-reference `$arckit-au-ai-assurance` if applicable.
+
+ - **Recommendations** — prioritised list of privacy-enhancing measures.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The Privacy Act 1988 and OAIC PIA Guide MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the APP compliance summary table).
+
+## Important Notes
+
+- This is the **Australian** PIA, not the UK DPIA. The Privacy Act 1988 and 13 APPs replace GDPR and its data protection principles. Do not reference GDPR, ICO, or UK data protection law.
+- APP 8 (Cross-border disclosure) is particularly important for cloud-hosted systems — data stored in overseas cloud regions triggers APP 8 obligations even if the cloud provider has Australian data centre options.
+- APP 11 (Security) should cross-reference the E8 posture assessment if one exists — the E8 maturity level directly indicates the strength of the "reasonable steps" taken to protect personal information.
+- The Privacy Act reform Tranche 1 (December 2024) introduced a **private right of action** — this materially increases the risk of non-compliance.
+- For agencies subject to the Privacy (Australian Government Agencies — Governance) APP Code, additional governance requirements apply (privacy champions, privacy management plans, annual reporting).
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `$arckit-au-dss` -- PIA findings feed DSS Criterion 7 (Protect users' privacy).
+- `$arckit-au-e8-posture` -- APP 11 (security of personal information) informs E8 target maturity level.
+- `$arckit-risk` -- Privacy risks surface in the project risk register.
diff --git a/arckit-codex/skills/arckit-au-pia/agents/openai.yaml b/arckit-codex/skills/arckit-au-pia/agents/openai.yaml
new file mode 100644
index 00000000..5b1f887a
--- /dev/null
+++ b/arckit-codex/skills/arckit-au-pia/agents/openai.yaml
@@ -0,0 +1,2 @@
+policy:
+ allow_implicit_invocation: false
diff --git a/arckit-codex/skills/arckit-au-pspf/SKILL.md b/arckit-codex/skills/arckit-au-pspf/SKILL.md
new file mode 100644
index 00000000..6ba3d493
--- /dev/null
+++ b/arckit-codex/skills/arckit-au-pspf/SKILL.md
@@ -0,0 +1,119 @@
+---
+name: arckit-au-pspf
+description: "[COMMUNITY] Generate a Protective Security Policy Framework (PSPF) compliance assessment for Australian Government entities and contractors against the four security outcomes and 16 core requirements."
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a PSPF-experienced security officer or government accreditation specialist. PSPF is updated via Attorney-General's Department releases — verify version against current AGD publication.
+
+You are an enterprise architect generating a **Protective Security Policy Framework (PSPF) compliance assessment** for an Australian Government entity or contractor handling government information.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Context
+
+The Protective Security Policy Framework (PSPF) is the Australian Government's overarching security policy framework administered by the Attorney-General's Department. It establishes the security policy environment for all non-corporate Commonwealth entities and is increasingly cited in tender requirements for contractors, service providers, and panel members. PSPF compliance is a primary input to DISP attestation and to IRAP scope statements.
+
+PSPF is structured around **four security outcomes** with **16 core requirements**:
+
+- **Outcome 1: Security Governance** (4 core requirements)
+- **Outcome 2: Information Security** (4 core requirements — ISM is the technical instantiation)
+- **Outcome 3: Personnel Security** (4 core requirements)
+- **Outcome 4: Physical Security** (4 core requirements)
+
+**Authoritative anchor**: Protective Security Policy Framework —
+
+**Key references**:
+
+- PSPF (current edition) — Attorney-General's Department
+- ASD Information Security Manual (ISM) — instantiates Outcome 2
+- ASD Essential Eight — minimum cyber baseline supporting Outcome 2
+- DISP (Defence Industry Security Program) — adjacent framework
+
+## Process
+
+1. Read prerequisites:
+ - The project's E8 posture (`ARC-{P}-AUE8-v*`)
+ - The project's ISM applicability (`ARC-{P}-AUISM-v*`) — primary input
+ - The project's PIA (`ARC-{P}-AUPIA-v*`)
+ - The project's RISK artefact
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-pspf-template.md`
+ - Then: `.arckit/templates-custom/au-pspf-template.md`
+ - Fallback: `.arckit/templates/au-pspf-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUPSPF --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Entity Profile** — entity name, type (non-corporate Commonwealth / corporate Commonwealth / contractor / panel member / state-government with PSPF flow-down), PSPF applicability driver (direct / contractual flow-down), Chief Security Officer (CSO) designation, security maturity self-assessment level.
+
+ - **Outcome 1: Security Governance** — assessment of the 4 core requirements:
+ 1. CR1: Role of accountable authority (security governance leadership)
+ 2. CR2: Management structures and responsibilities (CSO, security committee, executives)
+ 3. CR3: Security planning and risk management
+ 4. CR4: Security maturity monitoring (Annual Self-Assessment + reporting to AGD)
+
+ - **Outcome 2: Information Security** — assessment of 4 core requirements (ISM is the primary instantiation here):
+ 1. CR5: Sensitive and classified information (information classification, marking, handling)
+ 2. CR6: Access to information (need-to-know, security clearances)
+ 3. CR7: Safeguarding information from cyber threats (E8 + ISM)
+ 4. CR8: Sensitive and classified discussions and communications
+
+ - **Outcome 3: Personnel Security** — assessment of 4 core requirements:
+ 1. CR9: Eligibility and suitability (vetting + AGSVA clearance process)
+ 2. CR10: Ongoing assessment (continuous suitability)
+ 3. CR11: Separation of personnel (off-boarding clearance debrief)
+ 4. CR12: Insider threat
+
+ - **Outcome 4: Physical Security** — assessment of 4 core requirements:
+ 1. CR13: Entity facilities (physical security zones)
+ 2. CR14: Working off-site (remote work + travel)
+ 3. CR15: Physical security risk
+ 4. CR16: Supporting services (cleaning, maintenance, contractor access)
+
+ For each Core Requirement document:
+ - Compliance status: ✅ Fully Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant / N/A
+ - Evidence supporting status (cite ARC-{P}-AUISM, AUE8, AUPIA, AUDISP where applicable)
+ - Specific gap description
+ - Remediation actions with owner and target date
+ - PSPF Self-Assessment Level achieved (if relevant — Compliant / Substantially Compliant / Partly Compliant / Not Compliant)
+
+ - **PSPF Annual Self-Assessment** — for non-corporate Commonwealth entities, document Annual Self-Assessment Report status, last submission to AGD, current self-assessed maturity level, gaps.
+
+ - **Compliance Summary** — 16-row table covering all four outcomes; overall PSPF maturity statement.
+
+ - **Recommendations** — prioritised remediations by Quick Wins / Short-Term / Medium-Term, each tagged to specific Core Requirement.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. PSPF (with edition) MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the four-outcome compliance summary table).
+
+## Important Notes
+
+- PSPF directly applies to **non-corporate Commonwealth entities**. Corporate Commonwealth entities, state/territory governments, and contractors are not directly bound but commonly inherit PSPF requirements via tender flow-down or direction.
+- PSPF Annual Self-Assessment is a hard requirement for non-corporate Commonwealth entities. Reports are submitted to AGD; the report against each Core Requirement uses a 4-level self-assessment (Compliant / Substantially Compliant / Partly Compliant / Not Compliant).
+- **ISM is the technical instantiation of Outcome 2 Information Security.** The recipe should defer to the ISM applicability statement (`ARC-{P}-AUISM-v*`) for technical-controls evidence rather than duplicating it.
+- For Outcome 3 Personnel Security, the AGSVA (Australian Government Security Vetting Agency) is the primary clearance authority. Cleared personnel records reference clearance levels (Baseline / NV1 / NV2 / PV) not individual identities.
+- For pure-cloud systems and contractors with no physical facilities, Outcome 4 Physical Security largely inherits from cloud provider IRAP attestations + host-organisation facilities. Document the inheritance explicitly.
+- For contractors handling Defence-related work, the PSPF assessment dovetails with DISP attestation — cite the DISP pack where it exists rather than re-evidencing.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `$arckit-au-ism-controls` -- ISM is the technical-controls instantiation of PSPF Information Security outcome — primary input to PSPF Outcome 2.
+- `$arckit-au-e8-posture` -- E8 supports PSPF Information Security outcome.
+- `$arckit-au-pia` -- APP 11 + PSPF Personnel Security overlap; PIA cross-reference.
+- `$arckit-au-disp-attestation` -- DISP attestation pack draws on PSPF compliance evidence.
diff --git a/arckit-codex/skills/arckit-au-pspf/agents/openai.yaml b/arckit-codex/skills/arckit-au-pspf/agents/openai.yaml
new file mode 100644
index 00000000..5b1f887a
--- /dev/null
+++ b/arckit-codex/skills/arckit-au-pspf/agents/openai.yaml
@@ -0,0 +1,2 @@
+policy:
+ allow_implicit_invocation: false
diff --git a/arckit-codex/templates/au-ai-assurance-template.md b/arckit-codex/templates/au-ai-assurance-template.md
new file mode 100644
index 00000000..b913706e
--- /dev/null
+++ b/arckit-codex/templates/au-ai-assurance-template.md
@@ -0,0 +1,226 @@
+# AI Assurance Assessment
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:au-ai-assurance`
+
+## Document Control
+
+
+
+
+
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:au-ai-assurance` command | PENDING | PENDING |
+
+---
+
+## Executive Summary
+
+[Two to three paragraphs: AI system, deployment phase, regulatory frameworks in scope, overall assurance posture, key gaps.]
+
+---
+
+## 1. AI System Description
+
+| Field | Value |
+|-------|-------|
+| **System Name** | [System name] |
+| **Purpose** | [What the AI does and for whom] |
+| **AI Capability Type** | [Generative / Predictive / Decision-Support / Decision-Making / Agentic / Multi-Modal] |
+| **Deployment Phase** | [Research / Pilot / Production] |
+| **Foundation Model** | [Model + version + vendor — e.g., Claude Opus 4 / GPT-4 / Gemini 2.0 / open-source Llama 3] |
+| **Training-Data Sources** | [Public / proprietary / mixed; classification level] |
+| **Inference-Data Sources** | [User input / database / API / mixed] |
+| **Decisions Affecting Individuals** | [Yes — describe / No / Decision-support only] |
+| **Human-in-the-Loop Posture** | [Always / Threshold-triggered / None] |
+| **Population Affected** | [Internal users / customers / public / regulated cohort] |
+| **Assessment Date** | [YYYY-MM-DD] |
+| **AI Accountable Officer** | [Name + role] |
+
+---
+
+## 2. DTA Responsible AI Policy v2.0 Compliance
+
+| Accountability | Status | Evidence | Gap | Mitigation |
+|----------------|--------|----------|-----|------------|
+| 1. Accountability — designated AI accountable officer | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 2. Transparency — public AI use disclosure | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 3. Risk-based approach — AI risk assessment performed | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 4. Quality data + design integrity | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 5. Privacy + security (cross-ref PIA + ISM + E8) | [✅/⚠️/❌] | [Cite ARC-{P}-AUPIA, AUISM, AUE8] | [Gap] | [Action] |
+| 6. Human oversight + redress | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+
+---
+
+## 3. AU AI Ethics Principles Alignment
+
+| Principle | Status | Evidence | Gap | Mitigation |
+|-----------|--------|----------|-----|------------|
+| 1. Human, societal and environmental wellbeing | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 2. Human-centred values | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 3. Fairness | [✅/⚠️/❌] | [Cite Fairness Assessment §6] | [Gap] | [Action] |
+| 4. Privacy protection and security | [✅/⚠️/❌] | [Cite PIA + E8 + ISM] | [Gap] | [Action] |
+| 5. Reliability and safety | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 6. Transparency and explainability | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 7. Contestability | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+| 8. Accountability | [✅/⚠️/❌] | [Evidence] | [Gap] | [Action] |
+
+---
+
+## 4. AU Essential AI Practices (AI6) Alignment
+
+National AI Centre (NAIC) operational practices for safe and responsible AI adoption — see [Guidance for AI Adoption: Foundations](https://www.ai.gov.au/staying-safe-and-responsible/essential-ai-practices/guidance-ai-adoption-foundations) and the deeper [Implementation Guidance](https://www.ai.gov.au/staying-safe-and-responsible/essential-ai-practices/guidance-ai-adoption-implementation-guidance) (each practice has Getting started + Next steps prompts on the source).
+
+| # | Practice | Status | Evidence | Gap | Action |
+|---|----------|--------|----------|-----|--------|
+| 1 | Decide who is accountable | [✅/⚠️/❌/N/A] | [Cite accountable AI officer designation; cross-ref DTA Responsible AI Policy section 2] | [Gap] | [Action] |
+| 2 | Understand impacts and plan accordingly | [✅/⚠️/❌/N/A] | [Cite impact assessment / PIA / DPIA where relevant] | [Gap] | [Action] |
+| 3 | Measure and manage risks | [✅/⚠️/❌/N/A] | [Cite RISK register entries; AI-specific risk methodology] | [Gap] | [Action] |
+| 4 | Share essential information | [✅/⚠️/❌/N/A] | [Cite transparency artefacts; AI use disclosure; user-facing notices] | [Gap] | [Action] |
+| 5 | Test and monitor | [✅/⚠️/❌/N/A] | [Cite testing methodology; monitoring dashboards; drift detection] | [Gap] | [Action] |
+| 6 | Maintain human control | [✅/⚠️/❌/N/A] | [Cite human-in-the-loop posture; intervention pathways; redress mechanism] | [Gap] | [Action] |
+
+**Cross-framework note**: AI6 practices align closely with the DTA Responsible AI Policy v2.0 six accountabilities (section 2 of this assessment) but are framed as adoption *practices* rather than policy *accountabilities*. Use both lenses; the differences in framing surface different evidence gaps.
+
+---
+
+## 5. ISO 42001 Readiness
+
+| Clause | Topic | Readiness | Notes |
+|--------|-------|-----------|-------|
+| 4 | Context of the organisation | [✅/⚠️/❌] | [Notes] |
+| 5 | Leadership | [✅/⚠️/❌] | [Notes] |
+| 6 | Planning | [✅/⚠️/❌] | [Notes] |
+| 7 | Support | [✅/⚠️/❌] | [Notes] |
+| 8 | Operation | [✅/⚠️/❌] | [Notes] |
+| 9 | Performance evaluation | [✅/⚠️/❌] | [Notes] |
+| 10 | Improvement | [✅/⚠️/❌] | [Notes] |
+
+**Certification position**: [Targeting certification / Internal alignment only / Not pursuing]
+
+---
+
+## 6. Privacy Act AI-Decision Notification (Dec 2026)
+
+| Aspect | Detail |
+|--------|--------|
+| **Substantially-automated decisions affecting individuals** | [Yes / No] |
+| **Notification mechanism** | [Implemented / Planned for Dec 2026 / Not applicable] |
+| **What individuals are told** | [Description of notification content] |
+| **Opt-out pathway** | [Yes — describe / Not applicable] |
+| **Cross-reference** | [ARC-{P}-AUPIA-v* APP 6 + APP 11] |
+
+---
+
+## 7. Fairness Assessment
+
+| Aspect | Detail |
+|--------|--------|
+| **Methodology** | [E.g., demographic parity, equalised odds, predictive parity] |
+| **Protected Attributes Tested** | [List — race, ethnicity, gender, age, disability, geographic, socioeconomic] |
+| **Test Population Segments** | [Description] |
+| **Fairness Metrics + Results** | [Metric: result, threshold, pass/fail per segment] |
+| **Residual Fairness Risks** | [Description] |
+| **Validated by** | [Internal / External fairness specialist] |
+
+---
+
+## 8. Security of AI Training + Inference Data
+
+| Aspect | Detail |
+|--------|--------|
+| **Training-Data Classification** | [UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED — note model can memorise PII] |
+| **Inference-Data Classification** | [Same scale; consider input + output PII risk] |
+| **Prompt-Injection Defences** | [Implemented / Planned] |
+| **Model-Extraction Defences** | [Implemented / Planned] |
+| **Training-Data Sanitisation** | [Process description] |
+| **E8 Cross-Reference** | [ARC-{P}-AUE8-v* — Strategies 1, 4, 11 most relevant] |
+| **ISM Cross-Reference** | [ARC-{P}-AUISM-v* Domain 9 + 12] |
+
+---
+
+## 9. Model Lifecycle Governance
+
+| Aspect | Detail |
+|--------|--------|
+| **Version Control** | [Tooling + cadence] |
+| **Change Management** | [Process for model updates] |
+| **Drift Detection** | [Metrics + alerting] |
+| **Retraining Cadence** | [Trigger conditions] |
+| **Retirement / Sunset Criteria** | [Description] |
+| **Audit Trail** | [Inference logs retention + scope] |
+
+---
+
+## 10. Vendor / Foundation-Model Disclosure
+
+| Aspect | Detail |
+|--------|--------|
+| **Vendor Name** | [E.g., Anthropic / OpenAI / Google] |
+| **Model + Version** | [E.g., Claude Opus 4.7] |
+| **Vendor AI Policy Compliance** | [Vendor's published AI policy alignment] |
+| **Training-Data Provenance** | [Disclosed / Partially disclosed / Not disclosed] |
+| **Inference Region** | [AU / US / EU / global] |
+| **IP / Copyright Position** | [Vendor indemnification stance; user-content rights] |
+| **Data-Use Policy** | [Whether prompts/completions used for vendor training] |
+
+---
+
+## 11. Recommendations
+
+### Quick Wins ( < 30 days)
+
+| # | Recommendation | Framework | Effort |
+|---|---------------|-----------|--------|
+| 1 | [Recommendation] | [DTA / AIEP / ISO42001 / PrivacyAct] | [Low/Medium] |
+
+### Short-Term (30–90 days)
+
+| # | Recommendation | Framework | Effort |
+|---|---------------|-----------|--------|
+| 1 | [Recommendation] | [Framework] | [Medium/High] |
+
+### Medium-Term (90–180 days)
+
+| # | Recommendation | Framework | Effort |
+|---|---------------|-----------|--------|
+| 1 | [Recommendation] | [Framework] | [High] |
+
+---
+
+## 12. External References
+
+### Document Register
+
+| Doc ID | Filename | Type | Source | Description |
+|--------|----------|------|--------|-------------|
+| DTAAI | DTA Responsible AI Policy v2.0 | Policy | digital.gov.au | Effective Dec 2025 |
+| AUAIEP | AU AI Ethics Principles | Framework | industry.gov.au | 8 voluntary principles |
+| AI6F | AU Essential AI Practices — Foundations | Operational Guidance | ai.gov.au (NAIC) | 6 essential practices for safe and responsible AI adoption |
+| AI6IG | AU Essential AI Practices — Implementation Guidance | Operational Guidance | ai.gov.au (NAIC) | Per-practice Getting started + Next steps prompts |
+| ISO42001 | ISO 42001:2023 (AS adopted Feb 2024) | Standard | standards.org.au | AI Management Systems |
+| PA88 | Privacy Act 1988 (Cth) | Legislation | legislation.gov.au | AI-decision notification Dec 2026 |
+| AUPIA | ARC-{P}-AUPIA-v* | ArcKit Artefact | projects/ | APP 6 + APP 11 cross-ref |
+| AUE8 | ARC-{P}-AUE8-v* | ArcKit Artefact | projects/ | E8 cross-ref |
+| AUISM | ARC-{P}-AUISM-v* | ArcKit Artefact | projects/ | ISM cross-ref |
+
+### Verification
+
+| Standard | URL | Verification Date |
+|----------|-----|-------------------|
+| DTA Responsible AI Policy | https://www.digital.gov.au/policy/ai/policy | [YYYY-MM-DD] |
+| AU AI Ethics Principles | https://www.industry.gov.au/publications/australias-artificial-intelligence-ethics-framework/australias-ai-ethics-principles | [YYYY-MM-DD] |
+| AU Essential AI Practices (AI6) — Foundations | https://www.ai.gov.au/staying-safe-and-responsible/essential-ai-practices/guidance-ai-adoption-foundations | [YYYY-MM-DD] |
+| AU Essential AI Practices — Implementation Guidance | https://www.ai.gov.au/staying-safe-and-responsible/essential-ai-practices/guidance-ai-adoption-implementation-guidance | [YYYY-MM-DD] |
+| Privacy Act 1988 | https://www.legislation.gov.au/Details/C2024C00301 | [YYYY-MM-DD] |
+
+---
+
+**Generated by**: ArcKit `/arckit:au-ai-assurance` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
diff --git a/arckit-codex/templates/au-disp-attestation-template.md b/arckit-codex/templates/au-disp-attestation-template.md
new file mode 100644
index 00000000..9bd1c0ee
--- /dev/null
+++ b/arckit-codex/templates/au-disp-attestation-template.md
@@ -0,0 +1,283 @@
+# DISP Member Self-Attestation Pack
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:au-disp-attestation`
+
+## Document Control
+
+
+
+
+
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:au-disp-attestation` command | PENDING | PENDING |
+
+---
+
+## Executive Summary
+
+[Two to three paragraphs: organisation, DISP level sought, current attestation readiness, key gaps, target attestation date.]
+
+---
+
+## 1. Organisation Profile
+
+| Field | Value |
+|-------|-------|
+| **Legal Entity** | [Full name + ABN] |
+| **Trading Names** | [If applicable] |
+| **Primary Business Activity** | [e.g., Infrastructure Advisory] |
+| **Headcount** | [Total + by site] |
+| **Sites** | [Office locations + cloud-tenant region] |
+| **Defence Contracts in Scope** | [Active / pipeline contracts requiring DISP] |
+| **DISP Level Sought** | [Level 1 / 2 / 3] |
+| **Target Attestation Date** | [YYYY-MM-DD] |
+
+---
+
+## 2. DISP Level Sought
+
+| Aspect | Detail |
+|--------|--------|
+| **Level** | [Level 1 / 2 / 3] |
+| **Regulatory Driver** | [Specific contract / panel mandate / pipeline anticipation] |
+| **Justification** | [Why this level — types of Defence work, classified content handling] |
+| **Anticipated Defence Work** | [UNCLASSIFIED / OFFICIAL / OFFICIAL:Sensitive / PROTECTED — content categories handled] |
+
+---
+
+## 3. Security Officer Designation
+
+| Aspect | Detail |
+|--------|--------|
+| **Chief Security Officer (CSO)** | [Name + role title] |
+| **CSO Authority** | [Reporting line, signing authority, budget authority across the four security domains] |
+| **CSO Clearance Level** | [Baseline / NV1 / NV2 / PV] |
+| **Deputy CSO / Backup** | [Name + role + clearance] |
+| **CSO Contact** | [Email / phone for Defence engagement] |
+| **Vetting Status Verified** | [Yes / In progress / Not yet] |
+
+---
+
+## 4. Four Security Domains Coverage
+
+### Domain 1: Governance
+
+| Aspect | Detail |
+|--------|--------|
+| **Implementation Status** | [✅ / ⚠️ / ❌] |
+
+**Evidence**: [Security policy framework, risk management plan, audit cadence, incident management process, change control. Cite ISM applicability statement [ARC-{P}-AUISM] Domain 1 + 4]
+
+**Gaps**: [List]
+
+**Remediation**: [Actions, owners, target dates]
+
+**Sign-off**: [Accountable officer + date]
+
+---
+
+### Domain 2: Personnel Security
+
+| Aspect | Detail |
+|--------|--------|
+| **Implementation Status** | [✅ / ⚠️ / ❌] |
+| **Cleared Personnel Count** | [By clearance level — Baseline: n, NV1: n, NV2: n, PV: n] |
+| **Vetting Workflow** | [In-house / outsourced; turnaround time] |
+
+**Evidence**: [Clearance verification process, security awareness training programme, separation of duties model, off-boarding clearance debrief procedure, pre/post-leave briefing for cleared personnel. Cite ISM Domain 5]
+
+**Gaps**: [List]
+
+**Remediation**: [Actions, owners, target dates]
+
+**Sign-off**: [Accountable officer + date]
+
+---
+
+### Domain 3: Physical Security
+
+| Aspect | Detail |
+|--------|--------|
+| **Implementation Status** | [✅ / ⚠️ / ❌ / Inherited from IRAP cloud provider] |
+
+**Evidence**: [Facility access controls, ICT equipment lifecycle, secure media handling, equipment disposal. For cloud-only systems, cite cloud provider IRAP scope statement (Microsoft IRAP PROTECTED date / AWS IRAP date / GCP IRAP date) + customer-side responsibility implementation]
+
+**Gaps**: [Specific cloud-shared-responsibility gaps]
+
+**Remediation**: [Actions, owners, target dates]
+
+**Sign-off**: [Accountable officer + date]
+
+---
+
+### Domain 4: Information & Cyber Security
+
+| Aspect | Detail |
+|--------|--------|
+| **Implementation Status** | [✅ / ⚠️ / ❌] |
+| **E8 Posture Reference** | [ARC-{P}-AUE8-v*] |
+| **ISM Applicability Reference** | [ARC-{P}-AUISM-v*] |
+
+**Evidence**: [Defer to E8 posture artefact for E8 ML2 evidence; ISM applicability for additional controls. Specifically address: cryptography (Domain 12), gateway security (Domain 13), monitoring (Domain 11), BCP (cross-references E8 Strategy 8)]
+
+**Gaps**: [Beyond E8 ML2, list ISM-domain-specific gaps]
+
+**Remediation**: [Actions, owners, target dates]
+
+**Sign-off**: [Accountable officer + date]
+
+---
+
+## 5. Essential Eight ML2 Evidence Per Strategy
+
+(Summarised from `ARC-{P}-AUE8-v*` — refer to that artefact for evidence detail.)
+
+| # | Strategy | Current ML | ML2 Evidence | Gap to ML2 | Sign-off |
+|---|----------|-----------|--------------|------------|----------|
+| 1 | Application Control | [ML0–3] | [Evidence summary] | [Gap] | [Officer + date] |
+| 2 | Patch Applications | [ML0–3] | [Evidence summary] | [Gap] | [Officer + date] |
+| 3 | Configure MS Office Macros | [ML0–3] | [Evidence summary] | [Gap] | [Officer + date] |
+| 4 | User Application Hardening | [ML0–3] | [Evidence summary] | [Gap] | [Officer + date] |
+| 5 | Restrict Admin Privileges | [ML0–3] | [Evidence summary] | [Gap] | [Officer + date] |
+| 6 | Patch Operating Systems | [ML0–3] | [Evidence summary] | [Gap] | [Officer + date] |
+| 7 | Multi-Factor Authentication | [ML0–3] | [Evidence summary] | [Gap] | [Officer + date] |
+| 8 | Regular Backups | [ML0–3] | [Evidence summary] | [Gap] | [Officer + date] |
+
+---
+
+## 6. ISM Applicability Highlights
+
+(Summarised from `ARC-{P}-AUISM-v*`.)
+
+| ISM Domain | Material to DISP | Implementation | Gap |
+|------------|-------------------|----------------|-----|
+| 1. Cyber Security Governance | High | [✅/⚠️/❌] | [Gap] |
+| 3. Outsourced Services (MSP boundary) | High | [✅/⚠️/❌] | [Gap] |
+| 4. Security Documentation (SSP, SRMP) | High | [✅/⚠️/❌] | [Gap] |
+| 5. Personnel Security | High (DISP-specific) | [✅/⚠️/❌] | [Gap] |
+| 10. System Management (privileged access) | High | [✅/⚠️/❌] | [Gap] |
+| 11. System Monitoring (audit retention) | High | [✅/⚠️/❌] | [Gap] |
+| 12. Cryptography | Medium | [✅/⚠️/❌] | [Gap] |
+| 15. Cloud and IaaS Considerations | High (if cloud-only) | [✅/⚠️/❌ / Inherited] | [Gap] |
+
+---
+
+## 7. Foreign Ownership, Control or Influence (FOCI) Declaration
+
+| Aspect | Detail |
+|--------|--------|
+| **Foreign Ownership > 5%** | [Yes / No — if Yes: nation, percentage, entity] |
+| **Foreign Board Members** | [Number, nationalities, role authority] |
+| **Foreign Personnel with System Access** | [Number, nationalities, access scope] |
+| **Foreign Supply-Chain Dependencies** | [Description] |
+| **FOCI Mitigation Plan** | [If applicable, summary; cite supporting documentation] |
+
+---
+
+## 8. Supply Chain Security
+
+| Tier 1 Supplier | Service | Attestation Held | Last Reviewed | Cleared for DISP Level |
+|-----------------|---------|------------------|---------------|------------------------|
+| [MSP name] | M365 admin | [SOC 2 / ISO 27001 / IRAP] | [YYYY-MM-DD] | [Level 1/2/3] |
+| [Cloud Provider] | IaaS/PaaS | [IRAP PROTECTED date] | [YYYY-MM-DD] | [Level 1/2/3] |
+| [SaaS Provider] | [Service] | [Attestation] | [YYYY-MM-DD] | [Level 1/2/3] |
+
+**Supply-Chain Risk Management Process**: [Describe vendor onboarding, ongoing review, exit procedures]
+
+---
+
+## 9. Incident Response & Reporting
+
+| Aspect | Detail |
+|--------|--------|
+| **Incident Response Plan** | [Document reference] |
+| **24-Hour Defence Notification Capability** | [✅ / ⚠️ / ❌] |
+| **OAIC NDB Scheme Integration** | [✅ / ⚠️ / ❌; cite NDB playbook ARC-{P}-AUNDB-v* if available] |
+| **Last Tabletop / Live Exercise** | [YYYY-MM-DD] |
+| **Lessons Learned Process** | [Description] |
+
+---
+
+## 10. Security Awareness Training
+
+| Aspect | Detail |
+|--------|--------|
+| **Programme Name** | [E.g., DISP-aligned cyber awareness in ELMO] |
+| **Modules** | [Mandatory / role-specific / clearance-holder additional briefings] |
+| **Completion Rate (last 12mo)** | [%] |
+| **Refresher Cadence** | [Annual / event-driven] |
+| **Cleared-Personnel Briefings** | [Pre-leave / post-leave / change-of-role] |
+
+---
+
+## 11. Annual Self-Audit Plan
+
+| Aspect | Detail |
+|--------|--------|
+| **Scope** | [Four domains coverage; specific control sample] |
+| **Methodology** | [Self-assessment + evidence review + sample testing] |
+| **Frequency** | [Annual minimum; on-major-change additional] |
+| **Evidence Retention** | [Years] |
+| **Last Audit Date** | [YYYY-MM-DD] |
+| **Next Scheduled** | [YYYY-MM-DD] |
+
+---
+
+## 12. Attestation Statement
+
+I/we attest that the information in this pack is accurate to the best of my/our knowledge as at the date below. We commit to maintaining the security posture described, completing the listed remediation actions by their target dates, and notifying Defence promptly of any material change to the four security domains.
+
+| Role | Name | Signature | Date |
+|------|------|-----------|------|
+| Chief Security Officer | | | |
+| Director / Managing Director | | | |
+| Date of Attestation | | | [YYYY-MM-DD] |
+| Re-Attestation Due | | | [YYYY-MM-DD] |
+
+---
+
+## 13. External References
+
+### Upstream ArcKit Evidence
+
+| Artefact | Doc-ID | Cross-Reference |
+|----------|--------|-----------------|
+| ASD Essential Eight Posture | `ARC-{P}-AUE8-v*` | E8 maturity evidence per Strategy in section 6 |
+| ASD ISM Applicability | `ARC-{P}-AUISM-v*` | ISM control coverage per domain in section 6 |
+| Privacy Impact Assessment | `ARC-{P}-AUPIA-v*` | APP 11 personal-information protection evidence |
+| Notifiable Data Breach Playbook | `ARC-{P}-AUNDB-v*` | Incident-response capability evidence |
+| PSPF Compliance Assessment | `ARC-{P}-AUPSPF-v*` | Physical / personnel / governance security evidence |
+| DTA Digital Service Standard | `ARC-{P}-AUDSS-v*` | Service-design assurance evidence (where applicable) |
+| AI Assurance Assessment | `ARC-{P}-AUAIA-v*` | AI-system risk-control evidence (where applicable) |
+
+### Document Register
+
+| Doc ID | Filename | Type | Source | Description |
+|--------|----------|------|--------|-------------|
+| DISP | DISP Membership Pack | Standard | defence.gov.au | DISP application + evidence framework — edition [DATE] |
+| AUE8 | ARC-{P}-AUE8-v* | ArcKit Artefact | projects/ | Essential Eight evidence |
+| AUISM | ARC-{P}-AUISM-v* | ArcKit Artefact | projects/ | ISM applicability evidence |
+| AUPIA | ARC-{P}-AUPIA-v* | ArcKit Artefact | projects/ | Privacy Act + APP 11 evidence |
+| AUNDB | ARC-{P}-AUNDB-v* | ArcKit Artefact | projects/ | NDB playbook evidence (if available) |
+| ASDISM | ASD Information Security Manual | Standard | cyber.gov.au | Underlying control framework |
+| E8MM | ASD Essential Eight Maturity Model | Standard | cyber.gov.au | E8 ML2 minimum reference |
+
+### Verification
+
+| Standard | URL | Verification Date |
+|----------|-----|-------------------|
+| DISP | https://www.defence.gov.au/business-industry/programs/defence-industry-security-program | [YYYY-MM-DD] |
+| ASD ISM | https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism | [YYYY-MM-DD] |
+| ASD E8 | https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight/essential-eight-maturity-model | [YYYY-MM-DD] |
+
+---
+
+**Generated by**: ArcKit `/arckit:au-disp-attestation` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
diff --git a/arckit-codex/templates/au-dss-template.md b/arckit-codex/templates/au-dss-template.md
new file mode 100644
index 00000000..488b9eb2
--- /dev/null
+++ b/arckit-codex/templates/au-dss-template.md
@@ -0,0 +1,283 @@
+# DTA Digital Service Standard Compliance Assessment
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:au-dss`
+
+## Document Control
+
+
+
+
+
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:au-dss` command | PENDING | PENDING |
+
+---
+
+## Executive Summary
+
+[Two to three paragraphs: service under assessment, current compliance posture against the 13 criteria, key gaps, and assessment readiness for the current phase.]
+
+---
+
+## Service Context
+
+| Field | Value |
+|-------|-------|
+| **Service Name** | [Service name] |
+| **Owning Agency** | [Department / Agency] |
+| **Service Phase** | [Discovery / Alpha / Beta / Live] |
+| **User Base** | [Public-facing / Internal / Both] |
+| **Annual Transactions** | [Volume or estimate] |
+| **Assessment Date** | [YYYY-MM-DD] |
+| **Assessor** | [Name and role] |
+
+---
+
+## Digital Service Standard Assessment
+
+### Criterion 1: Understand User Needs
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [User research conducted, methods used, findings documented, personas created]
+
+**Gaps**: [Missing research, unvalidated assumptions, user groups not covered]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 2: Have a Multidisciplinary Team
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [Team composition, DDaT roles covered, decision-making authority]
+
+**Gaps**: [Missing roles, capability gaps, external dependencies]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 3: Agile and User-Centred Process
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [Delivery methodology, sprint cadence, user feedback integration, iteration evidence]
+
+**Gaps**: [Waterfall dependencies, missing feedback loops]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 4: Understand Tools and Systems
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [Technology landscape mapped, integration points, legacy dependencies, vendor dependencies]
+
+**Gaps**: [Unmapped systems, undocumented integrations]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 5: Make It Secure
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+| **E8 Posture Reference** | [ARC-{P}-AUE8-v{V} if available] |
+
+**Evidence**: [E8 maturity level, ISM controls, threat assessment, incident response plan, IRAP status]
+
+**Gaps**: [E8 strategies below target, missing controls, untested DR]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 6: Consistent and Responsive Design
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [Design system used, responsive breakpoints, device testing coverage, brand compliance]
+
+**Gaps**: [Missing breakpoints, untested devices, inconsistent components]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 7: Protect Users' Privacy
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+| **PIA Reference** | [ARC-{P}-AUPIA-v{V} if available] |
+
+**Evidence**: [PIA completed, APP compliance, data minimisation, consent mechanisms, OAIC notification]
+
+**Gaps**: [Missing PIA, non-compliant data handling, consent gaps]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 8: Make Source Code Open
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [Code repository, licence, open-source strategy, exemption justification if not open]
+
+**Gaps**: [Proprietary dependencies, missing licence, no public repo]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 9: Make It Accessible
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+| **WCAG Level** | [2.2 AA / 2.1 AA / Below AA] |
+
+**Evidence**: [Accessibility testing, assistive technology coverage, accessibility statement, audit results]
+
+**Gaps**: [WCAG failures, untested assistive technologies, missing accessibility statement]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 10: Test the Service
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [Test strategy, test types (unit, integration, UAT, accessibility, performance, security), coverage metrics]
+
+**Gaps**: [Missing test types, low coverage, no performance testing]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 11: Measure Performance
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [KPIs defined, measurement tools, reporting cadence, baseline metrics]
+
+**Gaps**: [Missing KPIs, no measurement tooling, no baseline]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 12: Don't Forget the Non-Digital Experience
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [Assisted digital channel, phone support, in-person options, channel integration]
+
+**Gaps**: [No assisted digital, missing channels, disconnected experience]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+### Criterion 13: Encourage Everyone to Use the Digital Service
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A] |
+
+**Evidence**: [Channel shift strategy, take-up targets, migration plan from legacy channels]
+
+**Gaps**: [No channel shift plan, no take-up measurement]
+
+**Remediation**: [Actions, owners, dates]
+
+---
+
+## Compliance Summary
+
+| # | Criterion | Status | Gap Count |
+|---|----------|--------|-----------|
+| 1 | Understand user needs | [✅/⚠️/❌/N/A] | [n] |
+| 2 | Have a multidisciplinary team | [✅/⚠️/❌/N/A] | [n] |
+| 3 | Agile and user-centred process | [✅/⚠️/❌/N/A] | [n] |
+| 4 | Understand tools and systems | [✅/⚠️/❌/N/A] | [n] |
+| 5 | Make it secure | [✅/⚠️/❌/N/A] | [n] |
+| 6 | Consistent and responsive design | [✅/⚠️/❌/N/A] | [n] |
+| 7 | Protect users' privacy | [✅/⚠️/❌/N/A] | [n] |
+| 8 | Make source code open | [✅/⚠️/❌/N/A] | [n] |
+| 9 | Make it accessible | [✅/⚠️/❌/N/A] | [n] |
+| 10 | Test the service | [✅/⚠️/❌/N/A] | [n] |
+| 11 | Measure performance | [✅/⚠️/❌/N/A] | [n] |
+| 12 | Non-digital experience | [✅/⚠️/❌/N/A] | [n] |
+| 13 | Encourage digital use | [✅/⚠️/❌/N/A] | [n] |
+
+**Overall**: [n] Met | [n] Partially Met | [n] Not Met | [n] N/A
+
+---
+
+## Assessment Readiness
+
+| Risk | Criterion | Impact | Mitigation |
+|------|----------|--------|-----------|
+| [Risk description] | [#] | [High/Medium/Low] | [Mitigation action] |
+
+---
+
+## External References
+
+### Document Register
+
+| Doc ID | Filename | Type | Source Location | Description |
+|--------|----------|------|-----------------|-------------|
+| DSS | DTA Digital Service Standard | Standard | dta.gov.au | Primary assessment framework |
+
+### Citations
+
+| Citation ID | Doc ID | Page/Section | Category | Quoted Passage |
+|-------------|--------|--------------|----------|----------------|
+| — | — | — | — | — |
+
+### Unreferenced Documents
+
+| Filename | Source Location | Reason |
+|----------|-----------------|--------|
+| — | — | — |
+
+---
+
+**Generated by**: ArcKit `/arckit:au-dss` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
diff --git a/arckit-codex/templates/au-e8-posture-template.md b/arckit-codex/templates/au-e8-posture-template.md
new file mode 100644
index 00000000..3466381e
--- /dev/null
+++ b/arckit-codex/templates/au-e8-posture-template.md
@@ -0,0 +1,362 @@
+# ASD Essential Eight Maturity Posture Assessment
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:au-e8-posture`
+
+## Document Control
+
+
+
+
+
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:au-e8-posture` command | PENDING | PENDING |
+
+---
+
+## Executive Summary
+
+[Two to three paragraphs: system under assessment, current overall E8 maturity posture, highest-priority gaps, and DISP compliance position if applicable.]
+
+---
+
+## System Context
+
+| Field | Value |
+|-------|-------|
+| **System Name** | [System name] |
+| **Classification** | [UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET] |
+| **Deployment Model** | [Cloud (SaaS/PaaS/IaaS) / On-Premise / Hybrid] |
+| **IRAP Assessment Status** | [Assessed / In Progress / Not Required / Not Started] |
+| **Cloud Provider(s)** | [AWS / Azure / GCP / Other — with IRAP status] |
+| **Data Sovereignty** | [All data in AU / Some offshore / Sovereign cloud] |
+| **DISP Member** | [Yes (Level 1/2/3) / No / Not Applicable] |
+| **Assessment Date** | [YYYY-MM-DD] |
+| **Assessor** | [Name and role] |
+
+---
+
+## Essential Eight Maturity Assessment
+
+### 1. Application Control
+
+| Aspect | Detail |
+|--------|--------|
+| **Current Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Target Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Regulatory Driver** | [DISP ML2 / PSPF / Contractual / Risk appetite] |
+
+**Evidence of Current State**:
+
+[Description of current application control measures — whitelisting tools, policy enforcement, coverage scope.]
+
+**Gap Analysis**:
+
+| ML Level | Sub-Control | Status | Gap Description |
+|----------|------------|--------|-----------------|
+| ML1 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML2 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML3 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+
+**Remediation Actions**:
+
+| Action | Owner | Target Date | Priority |
+|--------|-------|-------------|----------|
+| [Action description] | [Role/Name] | [YYYY-MM-DD] | [Critical / High / Medium / Low] |
+
+---
+
+### 2. Patch Applications
+
+| Aspect | Detail |
+|--------|--------|
+| **Current Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Target Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Regulatory Driver** | [DISP ML2 / PSPF / Contractual / Risk appetite] |
+
+**Evidence of Current State**:
+
+[Description of patching process — tools, SLAs, coverage, internet-facing vs internal.]
+
+**Gap Analysis**:
+
+| ML Level | Sub-Control | Status | Gap Description |
+|----------|------------|--------|-----------------|
+| ML1 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML2 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML3 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+
+**Remediation Actions**:
+
+| Action | Owner | Target Date | Priority |
+|--------|-------|-------------|----------|
+| [Action description] | [Role/Name] | [YYYY-MM-DD] | [Critical / High / Medium / Low] |
+
+---
+
+### 3. Configure Microsoft Office Macro Settings
+
+| Aspect | Detail |
+|--------|--------|
+| **Current Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Target Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Regulatory Driver** | [DISP ML2 / PSPF / Contractual / Risk appetite] |
+
+**Evidence of Current State**:
+
+[Description of macro policy — Group Policy settings, trusted locations, signing requirements.]
+
+**Gap Analysis**:
+
+| ML Level | Sub-Control | Status | Gap Description |
+|----------|------------|--------|-----------------|
+| ML1 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML2 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML3 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+
+**Remediation Actions**:
+
+| Action | Owner | Target Date | Priority |
+|--------|-------|-------------|----------|
+| [Action description] | [Role/Name] | [YYYY-MM-DD] | [Critical / High / Medium / Low] |
+
+---
+
+### 4. User Application Hardening
+
+| Aspect | Detail |
+|--------|--------|
+| **Current Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Target Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Regulatory Driver** | [DISP ML2 / PSPF / Contractual / Risk appetite] |
+
+**Evidence of Current State**:
+
+[Description of browser hardening, email client configuration, Office settings, ad-blocking, Java/Flash removal.]
+
+**Gap Analysis**:
+
+| ML Level | Sub-Control | Status | Gap Description |
+|----------|------------|--------|-----------------|
+| ML1 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML2 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML3 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+
+**Remediation Actions**:
+
+| Action | Owner | Target Date | Priority |
+|--------|-------|-------------|----------|
+| [Action description] | [Role/Name] | [YYYY-MM-DD] | [Critical / High / Medium / Low] |
+
+---
+
+### 5. Restrict Administrative Privileges
+
+| Aspect | Detail |
+|--------|--------|
+| **Current Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Target Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Regulatory Driver** | [DISP ML2 / PSPF / Contractual / Risk appetite] |
+
+**Evidence of Current State**:
+
+[Description of admin account management — PAM tools, JIT access, separation of duties, regular review cadence.]
+
+**Gap Analysis**:
+
+| ML Level | Sub-Control | Status | Gap Description |
+|----------|------------|--------|-----------------|
+| ML1 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML2 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML3 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+
+**Remediation Actions**:
+
+| Action | Owner | Target Date | Priority |
+|--------|-------|-------------|----------|
+| [Action description] | [Role/Name] | [YYYY-MM-DD] | [Critical / High / Medium / Low] |
+
+---
+
+### 6. Patch Operating Systems
+
+| Aspect | Detail |
+|--------|--------|
+| **Current Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Target Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Regulatory Driver** | [DISP ML2 / PSPF / Contractual / Risk appetite] |
+
+**Evidence of Current State**:
+
+[Description of OS patching — WSUS/SCCM/Intune, Linux patching, patching SLAs, unsupported OS inventory.]
+
+**Gap Analysis**:
+
+| ML Level | Sub-Control | Status | Gap Description |
+|----------|------------|--------|-----------------|
+| ML1 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML2 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML3 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+
+**Remediation Actions**:
+
+| Action | Owner | Target Date | Priority |
+|--------|-------|-------------|----------|
+| [Action description] | [Role/Name] | [YYYY-MM-DD] | [Critical / High / Medium / Low] |
+
+---
+
+### 7. Multi-Factor Authentication
+
+| Aspect | Detail |
+|--------|--------|
+| **Current Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Target Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Regulatory Driver** | [DISP ML2 / PSPF / Contractual / Risk appetite] |
+
+**Evidence of Current State**:
+
+[Description of MFA coverage — identity provider, MFA methods (FIDO2, authenticator app, SMS), coverage scope (VPN, email, admin portals, cloud services).]
+
+**Gap Analysis**:
+
+| ML Level | Sub-Control | Status | Gap Description |
+|----------|------------|--------|-----------------|
+| ML1 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML2 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML3 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+
+**Remediation Actions**:
+
+| Action | Owner | Target Date | Priority |
+|--------|-------|-------------|----------|
+| [Action description] | [Role/Name] | [YYYY-MM-DD] | [Critical / High / Medium / Low] |
+
+---
+
+### 8. Regular Backups
+
+| Aspect | Detail |
+|--------|--------|
+| **Current Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Target Maturity Level** | [ML0 / ML1 / ML2 / ML3] |
+| **Regulatory Driver** | [DISP ML2 / PSPF / Contractual / Risk appetite] |
+
+**Evidence of Current State**:
+
+[Description of backup strategy — RPO/RTO, backup scope, offline/immutable copies, restore testing cadence.]
+
+**Gap Analysis**:
+
+| ML Level | Sub-Control | Status | Gap Description |
+|----------|------------|--------|-----------------|
+| ML1 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML2 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+| ML3 | [Sub-control description] | [Met / Partial / Not Met] | [Gap detail] |
+
+**Remediation Actions**:
+
+| Action | Owner | Target Date | Priority |
+|--------|-------|-------------|----------|
+| [Action description] | [Role/Name] | [YYYY-MM-DD] | [Critical / High / Medium / Low] |
+
+---
+
+## Maturity Summary Matrix
+
+| # | Mitigation Strategy | Current ML | Target ML | Gap Count | Priority |
+|---|-------------------|-----------|-----------|-----------|----------|
+| 1 | Application Control | [ML0–3] | [ML0–3] | [n] | [Critical/High/Medium/Low] |
+| 2 | Patch Applications | [ML0–3] | [ML0–3] | [n] | [Critical/High/Medium/Low] |
+| 3 | Configure MS Office Macros | [ML0–3] | [ML0–3] | [n] | [Critical/High/Medium/Low] |
+| 4 | User Application Hardening | [ML0–3] | [ML0–3] | [n] | [Critical/High/Medium/Low] |
+| 5 | Restrict Admin Privileges | [ML0–3] | [ML0–3] | [n] | [Critical/High/Medium/Low] |
+| 6 | Patch Operating Systems | [ML0–3] | [ML0–3] | [n] | [Critical/High/Medium/Low] |
+| 7 | Multi-Factor Authentication | [ML0–3] | [ML0–3] | [n] | [Critical/High/Medium/Low] |
+| 8 | Regular Backups | [ML0–3] | [ML0–3] | [n] | [Critical/High/Medium/Low] |
+
+**Overall Posture**: [ML0 / ML1 / ML2 / ML3] (lowest common level across all eight strategies)
+
+---
+
+## DISP Compliance Position
+
+| Assessment | Result |
+|-----------|--------|
+| **DISP Member** | [Yes / No / Not Applicable] |
+| **Required Level** | ML2 (all eight strategies) |
+| **Current Compliance** | [Compliant / Non-Compliant — n strategies below ML2] |
+| **Strategies Below ML2** | [List strategies and current ML] |
+| **Estimated Remediation Timeline** | [Timeframe to achieve ML2 compliance] |
+
+---
+
+## Cloud-Specific Considerations
+
+| E8 Strategy | Shared Responsibility Model | Notes |
+|------------|---------------------------|-------|
+| Application Control | [Customer / Shared / Provider] | [Cloud-specific notes] |
+| Patch Applications | [Customer / Shared / Provider] | [Cloud-specific notes] |
+| Configure MS Office Macros | [Customer / Shared / Provider] | [Cloud-specific notes] |
+| User Application Hardening | [Customer / Shared / Provider] | [Cloud-specific notes] |
+| Restrict Admin Privileges | [Customer / Shared / Provider] | [Cloud-specific notes] |
+| Patch Operating Systems | [Customer / Shared / Provider] | [Cloud-specific notes] |
+| Multi-Factor Authentication | [Customer / Shared / Provider] | [Cloud-specific notes] |
+| Regular Backups | [Customer / Shared / Provider] | [Cloud-specific notes] |
+
+---
+
+## Recommendations
+
+### Quick Wins ( < 30 days)
+
+| # | Recommendation | E8 Strategy | Target ML | Effort |
+|---|---------------|------------|-----------|--------|
+| 1 | [Recommendation] | [Strategy] | [ML] | [Low/Medium] |
+
+### Short-Term (30–90 days)
+
+| # | Recommendation | E8 Strategy | Target ML | Effort |
+|---|---------------|------------|-----------|--------|
+| 1 | [Recommendation] | [Strategy] | [ML] | [Medium/High] |
+
+### Medium-Term (90–180 days)
+
+| # | Recommendation | E8 Strategy | Target ML | Effort |
+|---|---------------|------------|-----------|--------|
+| 1 | [Recommendation] | [Strategy] | [ML] | [High] |
+
+---
+
+## External References
+
+> This section provides traceability from generated content back to source documents.
+
+### Document Register
+
+| Doc ID | Filename | Type | Source Location | Description |
+|--------|----------|------|-----------------|-------------|
+| E8MM | ASD Essential Eight Maturity Model | Standard | cyber.gov.au | Primary assessment framework |
+
+### Citations
+
+| Citation ID | Doc ID | Page/Section | Category | Quoted Passage |
+|-------------|--------|--------------|----------|----------------|
+| — | — | — | — | — |
+
+### Unreferenced Documents
+
+| Filename | Source Location | Reason |
+|----------|-----------------|--------|
+| — | — | — |
+
+---
+
+**Generated by**: ArcKit `/arckit:au-e8-posture` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
diff --git a/arckit-codex/templates/au-ism-controls-template.md b/arckit-codex/templates/au-ism-controls-template.md
new file mode 100644
index 00000000..90731838
--- /dev/null
+++ b/arckit-codex/templates/au-ism-controls-template.md
@@ -0,0 +1,443 @@
+# ASD Information Security Manual (ISM) Control Applicability Statement
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:au-ism-controls`
+
+## Document Control
+
+
+
+
+
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:au-ism-controls` command | PENDING | PENDING |
+
+---
+
+## Executive Summary
+
+[Two to three paragraphs: system under assessment, classification, ISM edition used, overall control applicability posture, key gaps, and IRAP / DISP cross-reference position.]
+
+---
+
+## System Context
+
+| Field | Value |
+|-------|-------|
+| **System Name** | [System name] |
+| **Classification** | [UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET] |
+| **Deployment Model** | [Cloud (SaaS/PaaS/IaaS) / On-Premise / Hybrid] |
+| **IRAP Assessment Status** | [Assessed (date) / In Progress / Not Required / Not Started] |
+| **IRAP Scope** | [What's in scope / Cloud provider's IRAP boundary referenced] |
+| **DISP Member** | [Yes (Level 1/2/3) / In Progress / No] |
+| **ISM Edition Used** | [e.g., March 2026 — verification date] |
+| **Sovereignty** | [All data in AU / Some offshore / Sovereign cloud] |
+| **Assessment Date** | [YYYY-MM-DD] |
+| **Assessor** | [Name and role] |
+
+---
+
+## Control Domain Applicability Matrix
+
+ISM controls are organised into 17 domains. Applicability depends on the system's classification — controls flagged for the system's *highest classification of processed information* apply.
+
+| # | Domain | Applies | Implementation | Notes |
+|---|--------|---------|----------------|-------|
+| 1 | Cyber Security Governance | [Y/N] | [✅/⚠️/❌] | [Notes] |
+| 2 | Cyber Security Incidents | [Y/N] | [✅/⚠️/❌] | [Cross-ref NDB playbook] |
+| 3 | Outsourced Services | [Y/N] | [✅/⚠️/❌] | [MSP boundary, supply chain] |
+| 4 | Security Documentation | [Y/N] | [✅/⚠️/❌] | [SSP, SRMP] |
+| 5 | Personnel Security | [Y/N] | [✅/⚠️/❌] | [Clearance levels] |
+| 6 | Physical Security | [Y/N] | [✅/⚠️/❌] | [Cloud-only systems may N/A this in part] |
+| 7 | Communications Infrastructure | [Y/N] | [✅/⚠️/❌] | [Often N/A for pure-cloud] |
+| 8 | ICT Equipment Security | [Y/N] | [✅/⚠️/❌] | [Endpoint lifecycle] |
+| 9 | System Hardening | [Y/N] | [✅/⚠️/❌] | [Cross-ref E8] |
+| 10 | System Management | [Y/N] | [✅/⚠️/❌] | [Admin governance, vuln mgmt] |
+| 11 | System Monitoring | [Y/N] | [✅/⚠️/❌] | [SIEM, audit retention] |
+| 12 | Cryptography | [Y/N] | [✅/⚠️/❌] | [ASD-approved algorithms, key mgmt] |
+| 13 | Gateway Security | [Y/N] | [✅/⚠️/❌] | [Content filtering, DLP] |
+| 14 | Data Transfer | [Y/N] | [✅/⚠️/❌] | [Cross-domain, cross-system] |
+| 15 | Cloud and IaaS Considerations | [Y/N] | [✅/⚠️/❌] | [Inherit from IRAP cloud provider where applicable] |
+| 16 | Working-Off-Site Security | [Y/N] | [✅/⚠️/❌] | [Remote work, mobile, BYOD] |
+| 17 | Evaluation Activities | [Y/N] | [✅/⚠️/❌] | [Common Criteria, FIPS] |
+
+---
+
+## Per-Domain Control Applicability Assessment
+
+### Domain 1: Cyber Security Governance
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List ISM control identifiers — e.g., ISM-0027, ISM-0714, ISM-1567] |
+
+**Evidence**: [Security risk management plan, security documentation, change management process, accountable security officer]
+
+**Gaps**: [Specific control IDs not implemented + gap description]
+
+**Remediation**: [Actions, owners, target dates]
+
+**Compensating Controls**: [If any]
+
+---
+
+### Domain 2: Cyber Security Incidents
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List ISM control identifiers] |
+
+**Evidence**: [Incident response plan, NDB playbook reference (`ARC-{P}-AUNDB-v*`), 24/7 monitoring posture]
+
+**Gaps**: [Specific control IDs not implemented]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 3: Outsourced Services
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes — MSP / cloud providers in scope] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+
+**Evidence**: [MSP contractual security flow-down, supply-chain attestation review, IRAP-assessed cloud service inheritance, MSP-held admin role inventory]
+
+**Gaps**: [Specific control IDs not implemented]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 4: Security Documentation
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+
+**Evidence**: [System Security Plan (SSP), Security Risk Management Plan (SRMP), Continuous Monitoring Plan, Incident Response Plan]
+
+**Gaps**: [Specific control IDs not implemented]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 5: Personnel Security
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List — varies by classification + DISP membership] |
+
+**Evidence**: [Security clearance verification process, security awareness training, separation of duties, foreign national handling]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 6: Physical Security
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / Partial — cloud-only systems may inherit from cloud provider's IRAP] |
+| **Implementation** | [✅ / ⚠️ / ❌ / Inherited from IRAP cloud provider] |
+
+**Evidence**: [Facility access controls, ICT equipment lifecycle, media handling]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 7: Communications Infrastructure
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Often N/A for pure-cloud systems] |
+| **Implementation** | [Inherited / N/A] |
+
+**Notes**: For pure-cloud systems (SaaS/PaaS/IaaS), this domain typically inherits from the cloud provider's IRAP attestation.
+
+---
+
+### Domain 8: ICT Equipment Security
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes for endpoint estate] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+
+**Evidence**: [Endpoint hardening, secure media handling, sanitisation procedures, equipment disposal]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 9: System Hardening
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+| **E8 Cross-Reference** | [ARC-{P}-AUE8-v*] |
+
+**Evidence**: [Operating system hardening, application hardening, authentication mechanisms, network security] — **defer to E8 posture artefact for E8-mapped controls**.
+
+**Gaps**: [Beyond-E8 ISM control gaps]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 10: System Management
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+
+**Evidence**: [Privileged access management, vulnerability management, change management, configuration management]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 11: System Monitoring
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+
+**Evidence**: [Event logging, audit retention (typically 7 years for OFFICIAL+), SIEM integration, security metrics]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 12: Cryptography
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes for any encrypted data] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+
+**Evidence**: [ASD-Approved Cryptographic Algorithms (AACA) used; ASD-Approved Cryptographic Protocols (AACP) used; key lifecycle management; HSM use]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 13: Gateway Security
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes for systems with internet boundary] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+
+**Evidence**: [Gateway architecture, content filtering, DLP, certificate management]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 14: Data Transfer
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes if cross-domain or cross-system data movement] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+| **Applicable Controls** | [List] |
+
+**Evidence**: [Cross-domain solutions, secure file transfer, data import/export controls, sanitisation at boundary]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 15: Cloud and IaaS Considerations
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes for any cloud-hosted system] |
+| **Implementation** | [✅ / ⚠️ / ❌ / Inherited from IRAP cloud provider] |
+| **Applicable Controls** | [List] |
+| **IRAP Cloud Provider Inheritance** | [Microsoft Azure (IRAP PROTECTED date), AWS (IRAP date), GCP (IRAP date) — list applicable] |
+
+**Evidence**: [Cloud provider IRAP scope statements, customer-side responsibility implementation, sovereignty configuration]
+
+**Gaps**: [Specific control IDs not satisfied by inheritance]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 16: Working-Off-Site Security
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes if remote work supported] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+
+**Evidence**: [Remote work policy, BYOD posture, mobile device management, secure remote access]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### Domain 17: Evaluation Activities
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes if Common Criteria / FIPS-evaluated products in scope] |
+| **Implementation** | [✅ / ⚠️ / ❌] |
+
+**Evidence**: [Common Criteria / FIPS 140-2 product use, evaluated configurations]
+
+**Gaps**: [Specific control IDs]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+## ISM-to-E8 Cross-Reference
+
+| E8 Strategy | Primary ISM Domain(s) | Notes |
+|-------------|-----------------------|-------|
+| Application Control | 9 (System Hardening), 13 (Gateway Security) | App allowlist + boundary control |
+| Patch Applications | 9, 10 (System Management) | Vulnerability + patch management |
+| Configure MS Office Macro Settings | 9 | Application hardening sub-control |
+| User Application Hardening | 9 | Endpoint application configuration |
+| Restrict Administrative Privileges | 5 (Personnel), 10 (System Management) | Privileged access mgmt |
+| Patch Operating Systems | 9, 10 | OS-level patching |
+| Multi-Factor Authentication | 9, 12 (Cryptography) | Authentication mechanism |
+| Regular Backups | 4 (Security Documentation), 11 (System Monitoring), 17 (Working-Off-Site security for offline backups) | BCP + restore testing |
+
+---
+
+## Compliance Summary
+
+| Domain | Applies | Status | Applicable Controls | Implemented | Gap Count |
+|--------|---------|--------|---------------------|-------------|-----------|
+| 1. Cyber Security Governance | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 2. Cyber Security Incidents | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 3. Outsourced Services | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 4. Security Documentation | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 5. Personnel Security | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 6. Physical Security | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 7. Communications Infrastructure | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 8. ICT Equipment Security | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 9. System Hardening | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 10. System Management | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 11. System Monitoring | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 12. Cryptography | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 13. Gateway Security | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 14. Data Transfer | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 15. Cloud and IaaS Considerations | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 16. Working-Off-Site Security | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+| 17. Evaluation Activities | [Y/N] | [✅/⚠️/❌] | [n] | [n] | [n] |
+
+**Overall**: [n] Implemented / [n] Applicable = [n]% applicability score.
+
+---
+
+## IRAP Assessment Position
+
+| Item | Detail |
+|------|--------|
+| **IRAP Assessment Status** | [Assessed (date) / In Progress / Not Required / Not Started] |
+| **IRAP Scope** | [Description of system boundary assessed] |
+| **Residual Risks Accepted** | [List residual risks accepted by Authorising Officer] |
+| **Re-Assessment Cadence** | [Annual / On-major-change] |
+| **Cloud Provider Inheritance** | [Microsoft Azure / AWS / GCP — IRAP scope citation] |
+
+---
+
+## Recommendations
+
+### Quick Wins ( < 30 days)
+
+| # | Recommendation | ISM Control(s) | Domain | Effort |
+|---|---------------|----------------|--------|--------|
+| 1 | [Recommendation] | [Control IDs] | [#] | [Low/Medium] |
+
+### Short-Term (30–90 days)
+
+| # | Recommendation | ISM Control(s) | Domain | Effort |
+|---|---------------|----------------|--------|--------|
+| 1 | [Recommendation] | [Control IDs] | [#] | [Medium/High] |
+
+### Medium-Term (90–180 days)
+
+| # | Recommendation | ISM Control(s) | Domain | Effort |
+|---|---------------|----------------|--------|--------|
+| 1 | [Recommendation] | [Control IDs] | [#] | [High] |
+
+---
+
+## External References
+
+### Document Register
+
+| Doc ID | Filename | Type | Source | Description |
+|--------|----------|------|--------|-------------|
+| ASDISM | ASD Information Security Manual | Standard | cyber.gov.au | Primary control framework — edition [DATE] |
+| AUE8 | ARC-{P}-AUE8-v* | ArcKit Artefact | projects/ | E8 posture cross-reference (Domain 9) |
+
+### Citations
+
+| Citation ID | Doc ID | Section | Category | Quoted Passage |
+|-------------|--------|---------|----------|----------------|
+| — | — | — | — | — |
+
+### Verification
+
+| Standard | URL | Verification Date |
+|----------|-----|-------------------|
+| ASD Information Security Manual | https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism | [YYYY-MM-DD] |
+| Protective Security Policy Framework | https://www.protectivesecurity.gov.au/ | [YYYY-MM-DD] |
+| IRAP | https://www.cyber.gov.au/about-us/programs-and-services/irap | [YYYY-MM-DD] |
+
+---
+
+**Generated by**: ArcKit `/arckit:au-ism-controls` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
diff --git a/arckit-codex/templates/au-ndb-playbook-template.md b/arckit-codex/templates/au-ndb-playbook-template.md
new file mode 100644
index 00000000..f620835d
--- /dev/null
+++ b/arckit-codex/templates/au-ndb-playbook-template.md
@@ -0,0 +1,271 @@
+# Notifiable Data Breach (NDB) Response Playbook
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:au-ndb-playbook`
+
+## Document Control
+
+
+
+
+
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:au-ndb-playbook` command | PENDING | PENDING |
+
+---
+
+## Executive Summary
+
+[One to two paragraphs: APP entity status, NDB scheme applicability, playbook readiness, last test date, key risks.]
+
+---
+
+## 1. Entity Profile
+
+| Field | Value |
+|-------|-------|
+| **APP Entity Status** | [Australian Government agency / APP organisation per s 6C / s 6D] |
+| **Privacy Officer** | [Name + role + contact] |
+| **Accountable Officer for NDB Response** | [Name + role; named single accountable officer] |
+| **Business Hours Response Team Lead** | [Name + role + contact] |
+| **After-Hours Response Team Lead** | [Name + role + 24/7 contact] |
+| **External Legal Counsel** | [Firm name + contact] |
+| **Communications Lead** | [Name + role] |
+| **CISO / Security Officer** | [Name + role; cross-ref ARC-{P}-AUE8 governance] |
+| **Last Tabletop Exercise** | [YYYY-MM-DD] |
+| **Last Live Incident** | [YYYY-MM-DD or N/A] |
+
+---
+
+## 2. NDB Eligibility Test (Decision Tree)
+
+```text
+Step 1: Has there been unauthorised access to,
+ unauthorised disclosure of, or loss of
+ personal information?
+ │
+ ├── No → Not an eligible data breach. Document as
+ │ "incident — not eligible". STOP.
+ │
+ └── Yes
+ │
+ ▼
+Step 2: Is serious harm likely to result to one
+ or more individuals?
+ (Financial loss, identity theft, emotional
+ distress, physical safety, reputational harm)
+ │
+ ├── No (assessed conservatively) → Not eligible. Document. STOP.
+ │
+ └── Yes
+ │
+ ▼
+Step 3: Can the entity remediate through reasonable
+ steps to prevent the serious harm?
+ │
+ ├── Yes → Take reasonable steps. If steps successful, NOT eligible
+ │ for notification (document the reasonable-steps action).
+ │ If steps fail or cannot be applied in time, return to
+ │ Step 2.
+ │
+ └── No → ELIGIBLE DATA BREACH.
+ 30-day notification clock starts from when reasonable
+ grounds to believe were established (typically Day 0).
+ Notify OAIC + affected individuals.
+```
+
+---
+
+## 3. 30-Day Timeline Plan
+
+| Day | Milestone | Owner | Output |
+|-----|-----------|-------|--------|
+| **Day 0** | Detect → Contain → Activate playbook → Notify Privacy Officer + accountable officer | SOC / detector | Incident ticket, containment evidence |
+| **Day 0–1** | Initial scoping → preliminary eligibility assessment → set 30-day clock | Privacy Officer | Eligibility memo (preliminary) |
+| **Day 1–3** | Forensic investigation → identify affected individuals + types of personal information involved | Security Officer + Privacy Officer | Scope statement |
+| **Day 3–7** | Serious-harm assessment per individual cohort → identify reasonable-steps mitigations | Privacy Officer + Legal | Harm assessment + mitigation list |
+| **Day 7–10** | Reasonable-steps execution → re-test eligibility | Security Officer | Mitigation evidence |
+| **Day 10–14** | Final eligibility decision → if eligible, draft OAIC notification + individual notifications | Privacy Officer + Legal + Comms | Draft notifications |
+| **Day 14–21** | Legal review → executive sign-off → finalise OAIC form + individual notification | Legal + accountable officer | Approved notifications |
+| **Day 21–25** | Submit OAIC notification → execute individual notifications | Privacy Officer + Comms | OAIC submission receipt; individual notification log |
+| **Day 25–30** | Public statement if required → media response → regulator follow-up | Comms + accountable officer | Public statement; media log |
+| **Day 30** | Notification deadline → all required notifications complete | Privacy Officer | Compliance evidence pack |
+| **Day 30+** | Post-incident review (within 90 days) → lessons-learned → AUE8/AUISM/AUPIA artefact updates | Privacy Officer + Security Officer | Post-incident review document |
+
+---
+
+## 4. Roles & Responsibilities (RACI)
+
+| Role | Detect | Contain | Assess Eligibility | Notify OAIC | Notify Individuals | Public Statement | Lessons Learned |
+|------|--------|---------|---------------------|-------------|--------------------|--------------------|-----------------|
+| Privacy Officer | I | I | **R+A** | **R** | **R** | C | **R+A** |
+| Security Officer / CISO | I | **R+A** | C | I | I | I | C |
+| SOC / Detection team | **R** | C | I | I | I | I | I |
+| Accountable Officer (Director / CEO) | I | I | A | A | A | **R+A** | A |
+| Legal Counsel | I | C | C | C | C | **R+A** | C |
+| Communications | I | I | I | I | C | **R+A** | C |
+| Affected business owner | I | C | C | I | I | I | C |
+
+R = Responsible · A = Accountable · C = Consulted · I = Informed
+
+---
+
+## 5. Detection + Containment Procedures
+
+### Detection sources
+
+- SIEM alerts (cross-ref ARC-{P}-AUE8 + ARC-{P}-AUISM Domain 11)
+- Customer / data-subject reports (front-line intake to Privacy Officer)
+- Vendor / supply-chain notification (cross-ref AUDISP supply-chain provisions)
+- Insider report
+- Regulator notification
+- Media discovery
+
+### Immediate containment
+
+- Isolate affected systems (cross-ref ARC-{P}-AUE8 incident response capability)
+- Preserve evidence (logs, system images) per ISM Domain 11 retention
+- Engage forensic capability (internal SOC + external IR retainer)
+- **Do not** publicly comment until eligibility assessment complete
+
+---
+
+## 6. Assessment Procedure
+
+### Three statutory tests
+
+1. Unauthorised access / disclosure / loss
+2. Likely serious harm
+3. No reasonable-steps remediation
+
+### Serious-harm criteria (broadly read)
+
+- **Financial harm**: identity theft, financial loss, fraud
+- **Emotional / psychological harm**: humiliation, anxiety, stress
+- **Physical safety**: violence, intimidation, stalking
+- **Reputational harm**: defamation, social impact
+- **Discrimination harm**: protected attributes exposure
+- **Loss of opportunity**: employment, services, insurance
+
+### Reasonable-steps test
+
+- Encryption recovery (e.g., breach is of encrypted data + key not compromised)
+- Wiping recovered devices
+- Rapid password reset + MFA enforcement
+- Data deletion at recipient (with verification)
+- Court order / contractual return of data
+
+If reasonable steps **successful**, document and treat as a non-eligible incident. If **unsuccessful or unavailable**, eligible breach — proceed to notification.
+
+---
+
+## 7. OAIC Notification Form Content
+
+Required fields per OAIC NDB form:
+
+- Entity name + contact details
+- Description of the breach (concise factual summary)
+- Kind of information involved (PII categories)
+- Likely consequences for individuals (serious-harm assessment)
+- Recommendations for affected individuals (e.g., change passwords, monitor accounts, contact IDCare)
+- Steps the entity has taken / will take to remediate
+
+### Sample notification text (placeholder — adapt per incident)
+
+> [Entity name] regrets to advise that a data breach occurred on [DATE] affecting [INDIVIDUAL COHORT — number + type]. The breach involved [INFORMATION CATEGORY]. The breach is believed to have been caused by [CAUSE]. We have taken the following steps to contain the breach: [STEPS]. Affected individuals are advised to: [RECOMMENDATIONS]. Please contact our Privacy Officer at [CONTACT] with any questions.
+
+---
+
+## 8. Individual Notification Approach
+
+| Aspect | Detail |
+|--------|--------|
+| **Direct or publication-based** | [Direct preferred where contactable; publication where direct not practicable] |
+| **Channel** | [Email primary; SMS / postal mail backup; published notice if required] |
+| **Language + accessibility** | [Plain-English; alternative formats on request] |
+| **Content** | [What happened, what info, what consequences, what to do, who to contact] |
+| **Cohort segmentation** | [Tailor notification by data-subject category if appropriate] |
+
+---
+
+## 9. Communications Plan
+
+| Audience | Channel | Pre-Approved Holding Statement |
+|----------|---------|---------------------------------|
+| Internal staff | All-staff email + leadership briefing | [Holding statement] |
+| Affected individuals | Direct (email/SMS/post) | [Per §8] |
+| OAIC | OAIC NDB form | [Per §7] |
+| Media | Statement + spokesperson | [Pre-written holding statement] |
+| Sector regulator (if applicable — APRA / AHPRA / etc.) | Sector reporting channel | [Per sector requirement] |
+
+---
+
+## 10. Post-Incident Review
+
+Conducted within 90 days of incident closure.
+
+| Aspect | Detail |
+|--------|--------|
+| **Root cause analysis** | [5-whys methodology] |
+| **Control effectiveness review** | [What worked, what didn't] |
+| **Artefact updates triggered** | [AUE8 strategy refresh / AUISM domain refresh / AUPIA APP refresh] |
+| **Lessons learned cycle** | [Action register; review at next risk forum] |
+| **Tabletop exercise refresh** | [Update annual exercise scenario based on incident pattern] |
+
+---
+
+## 11. Coordination With Other Reporting Obligations
+
+| Obligation | Trigger | Timeline | Coordination Note |
+|------------|---------|----------|-------------------|
+| SOCI cyber incident (if SOCI-covered entity) | Significant operational impact | 12 hours | Runs parallel to NDB; coordinate so 12hr report doesn't pre-commit eligibility position |
+| SOCI cyber incident (relevant impact) | Relevant impact | 72 hours | As above |
+| DISP-relevant incident | Defence-classified content involvement | 24 hours | Cross-ref ARC-{P}-AUDISP-v* incident reporting |
+| Sector regulator (e.g., APRA CPS 234) | Material information security incident | 72 hours | Sector-specific |
+| EU GDPR (if EU residents affected) | Personal data breach | 72 hours | Concurrent jurisdiction — legal counsel coordinate |
+| NZ Privacy Act (if NZ residents) | Notifiable privacy breach | "As soon as practicable" | Trans-Tasman coordination |
+
+---
+
+## 12. Tabletop Exercise Plan
+
+| Aspect | Detail |
+|--------|--------|
+| **Cadence** | [Annual minimum; semi-annual recommended] |
+| **Last Exercise** | [YYYY-MM-DD] |
+| **Next Scheduled** | [YYYY-MM-DD] |
+| **Scenario Theme (next exercise)** | [E.g., ransomware on payroll system; insider exfiltration; vendor compromise] |
+| **Participants** | [Privacy Officer, Security Officer, Legal, Comms, accountable officer] |
+| **Evidence Retention** | [Years; storage location] |
+
+---
+
+## 13. External References
+
+### Document Register
+
+| Doc ID | Filename | Type | Source | Description |
+|--------|----------|------|--------|-------------|
+| PA88 | Privacy Act 1988 (Cth) Part IIIC | Legislation | legislation.gov.au | NDB scheme statute |
+| OAIC-NDB | OAIC NDB scheme guidance | Guidance | oaic.gov.au | Operational guidance |
+| AUPIA | ARC-{P}-AUPIA-v* | ArcKit Artefact | projects/ | APP 11 cross-ref |
+| AUE8 | ARC-{P}-AUE8-v* | ArcKit Artefact | projects/ | Security baseline |
+| AUISM | ARC-{P}-AUISM-v* | ArcKit Artefact | projects/ | Domain 2 (incidents) cross-ref |
+
+### Verification
+
+| Standard | URL | Verification Date |
+|----------|-----|-------------------|
+| Privacy Act 1988 (Cth) | https://www.legislation.gov.au/Details/C2024C00301 | [YYYY-MM-DD] |
+| OAIC NDB Scheme | https://www.oaic.gov.au/privacy/notifiable-data-breaches | [YYYY-MM-DD] |
+
+---
+
+**Generated by**: ArcKit `/arckit:au-ndb-playbook` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
diff --git a/arckit-codex/templates/au-pia-template.md b/arckit-codex/templates/au-pia-template.md
new file mode 100644
index 00000000..950cf7cd
--- /dev/null
+++ b/arckit-codex/templates/au-pia-template.md
@@ -0,0 +1,378 @@
+# Privacy Impact Assessment (Privacy Act 1988)
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:au-pia`
+
+## Document Control
+
+
+
+
+
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:au-pia` command | PENDING | PENDING |
+
+---
+
+## Executive Summary
+
+[Two to three paragraphs: project under assessment, personal information involved, overall privacy risk posture, key findings and recommendations.]
+
+---
+
+## Project Description
+
+| Field | Value |
+|-------|-------|
+| **Project Name** | [Project name] |
+| **Owning Agency** | [Department / Agency] |
+| **Project Phase** | [Discovery / Alpha / Beta / Live] |
+| **Data Subjects** | [Citizens / Employees / Contractors / Business entities] |
+| **Personal Information Types** | [Contact details / Identity / Financial / Health / Criminal / Biometric] |
+| **Sensitive Information** | [Yes — categories / No] |
+| **Estimated Data Volume** | [Number of records / data subjects] |
+| **AI/Automated Decisions** | [Yes — describe / No] |
+| **Assessment Date** | [YYYY-MM-DD] |
+| **Privacy Officer** | [Name and role] |
+
+---
+
+## Information Flows
+
+```mermaid
+graph LR
+ subgraph Collection
+ C1[Web Form]
+ C2[API Integration]
+ C3[Manual Entry]
+ end
+
+ subgraph Processing
+ P1[Application Server]
+ P2[Analytics Engine]
+ end
+
+ subgraph Storage
+ S1[Primary Database
AU Region]
+ S2[Backup
AU Region]
+ end
+
+ subgraph Disclosure
+ D1[Reporting Dashboard]
+ D2[Partner Agency]
+ end
+
+ C1 -->|APP 3| P1
+ C2 -->|APP 3| P1
+ C3 -->|APP 3| P1
+ P1 -->|APP 6| S1
+ P1 -->|APP 6| P2
+ S1 -->|APP 11| S2
+ P2 -->|APP 6| D1
+ P1 -->|APP 6| D2
+```
+
+[Replace with actual information flows for the project. Annotate each flow with the governing APP.]
+
+---
+
+## APP Compliance Assessment
+
+### APP 1 — Open and Transparent Management
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Privacy policy published, privacy management plan, complaints process, staff training]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 2 — Anonymity and Pseudonymity
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Option to transact anonymously/pseudonymously, exceptions documented]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 3 — Collection of Solicited Personal Information
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Collection limited to necessary information, lawful basis, consent for sensitive information (APP 3.3)]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 4 — Dealing with Unsolicited Personal Information
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Process for unsolicited information — assess, retain or destroy]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 5 — Notification of Collection
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Collection notices, privacy statements at point of collection, matters covered in notice]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 6 — Use or Disclosure
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Use limited to primary purpose, secondary use exceptions documented, disclosure register]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 7 — Direct Marketing
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant / N/A] |
+
+**Evidence**: [Direct marketing controls, opt-out mechanism, consent records]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 8 — Cross-Border Disclosure
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Data residency, cloud hosting regions, offshore processing, reasonable steps to ensure APP compliance by overseas recipient]
+
+**Overseas Recipients**:
+
+| Recipient | Country | Purpose | APP Compliance Mechanism |
+|-----------|---------|---------|-------------------------|
+| [Name] | [Country] | [Purpose] | [Contract / Consent / Substantially similar laws] |
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 9 — Government Related Identifiers
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Government identifiers used (TFN, Medicare, myGovID), adoption restrictions, disclosure controls]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 10 — Quality of Personal Information
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Data quality processes, validation at collection, update mechanisms, accuracy checks]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 11 — Security of Personal Information
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+| **E8 Posture Reference** | [ARC-{P}-AUE8-v{V} if available] |
+
+**Evidence**: [Security controls — encryption, access controls, E8 maturity level, destruction/de-identification procedures]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 12 — Access to Personal Information
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Access request process, response timeframes, FOI integration, exceptions documented]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+### APP 13 — Correction of Personal Information
+
+| Aspect | Detail |
+|--------|--------|
+| **Applies** | [Yes / No] |
+| **Status** | [✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant] |
+
+**Evidence**: [Correction request process, notification of corrections to third parties]
+
+**Risk**: [Likelihood] × [Impact] = [Risk Level]
+
+**Mitigation**: [Actions, owners, dates]
+
+---
+
+## APP Compliance Summary
+
+| APP | Principle | Applies | Status | Risk Level |
+|-----|----------|---------|--------|-----------|
+| 1 | Open and transparent management | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 2 | Anonymity and pseudonymity | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 3 | Collection of solicited information | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 4 | Unsolicited personal information | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 5 | Notification of collection | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 6 | Use or disclosure | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 7 | Direct marketing | [Y/N] | [✅/⚠️/❌/N/A] | [H/M/L] |
+| 8 | Cross-border disclosure | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 9 | Government related identifiers | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 10 | Quality of personal information | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 11 | Security of personal information | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 12 | Access to personal information | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+| 13 | Correction of personal information | [Y/N] | [✅/⚠️/❌] | [H/M/L] |
+
+---
+
+## Privacy Risk Register
+
+| Risk ID | APP | Risk Description | Likelihood | Impact | Risk Level | Mitigation | Residual Risk |
+|---------|-----|-----------------|-----------|--------|-----------|-----------|---------------|
+| PR-001 | [#] | [Description] | [1-5] | [1-5] | [H/M/L] | [Action] | [H/M/L] |
+
+---
+
+## Sensitive Information Assessment
+
+| Category (Privacy Act s 6) | Processed | Consent Mechanism | Notes |
+|---------------------------|-----------|-------------------|-------|
+| Racial or ethnic origin | [Y/N] | [Mechanism] | |
+| Political opinions | [Y/N] | [Mechanism] | |
+| Religious beliefs | [Y/N] | [Mechanism] | |
+| Sexual orientation | [Y/N] | [Mechanism] | |
+| Criminal record | [Y/N] | [Mechanism] | |
+| Health information | [Y/N] | [Mechanism] | |
+| Genetic information | [Y/N] | [Mechanism] | |
+| Biometric information | [Y/N] | [Mechanism] | |
+| Trade union membership | [Y/N] | [Mechanism] | |
+
+---
+
+## AI and Automated Decision-Making
+
+| Aspect | Detail |
+|--------|--------|
+| **Uses AI/ML** | [Yes / No] |
+| **Automated decisions affecting individuals** | [Yes — describe / No] |
+| **Individual notification** | [Implemented / Planned for Dec 2026 / Not applicable] |
+| **Human review mechanism** | [Describe] |
+| **Fairness assessment** | [Completed / In progress / Not started] |
+| **AU AI Assurance Reference** | [ARC-{P}-AUAIA-v{V} if available] |
+
+---
+
+## Recommendations
+
+| # | Recommendation | APP | Priority | Owner | Target Date |
+|---|---------------|-----|----------|-------|-------------|
+| 1 | [Recommendation] | [#] | [Critical/High/Medium/Low] | [Role] | [Date] |
+
+---
+
+## External References
+
+### Document Register
+
+| Doc ID | Filename | Type | Source Location | Description |
+|--------|----------|------|-----------------|-------------|
+| PA88 | Privacy Act 1988 (Cth) | Legislation | legislation.gov.au | Primary privacy legislation |
+| OAIC-PIA | OAIC Guide to undertaking PIAs | Guidance | oaic.gov.au | PIA methodology guide |
+
+### Citations
+
+| Citation ID | Doc ID | Page/Section | Category | Quoted Passage |
+|-------------|--------|--------------|----------|----------------|
+| — | — | — | — | — |
+
+### Unreferenced Documents
+
+| Filename | Source Location | Reason |
+|----------|-----------------|--------|
+| — | — | — |
+
+---
+
+**Generated by**: ArcKit `/arckit:au-pia` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
diff --git a/arckit-codex/templates/au-pspf-template.md b/arckit-codex/templates/au-pspf-template.md
new file mode 100644
index 00000000..16c287a9
--- /dev/null
+++ b/arckit-codex/templates/au-pspf-template.md
@@ -0,0 +1,362 @@
+# PSPF Compliance Assessment
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:au-pspf`
+
+## Document Control
+
+
+
+
+
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---------|------|--------|---------|-------------|---------------|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:au-pspf` command | PENDING | PENDING |
+
+---
+
+## Executive Summary
+
+[Two to three paragraphs: entity, PSPF applicability, current self-assessment posture, key gaps, AGD reporting status.]
+
+---
+
+## Entity Profile
+
+| Field | Value |
+|-------|-------|
+| **Entity Name** | [Entity name] |
+| **Entity Type** | [Non-corporate Commonwealth / Corporate Commonwealth / Contractor / Panel Member / State Govt with flow-down] |
+| **PSPF Applicability Driver** | [Direct / Contractual flow-down — cite source] |
+| **Chief Security Officer (CSO)** | [Name + role + clearance] |
+| **CSO Authority** | [Reporting line, signing authority] |
+| **PSPF Edition Used** | [E.g., PSPF 2024 release] |
+| **Last AGD Self-Assessment Submission** | [YYYY-MM-DD] |
+| **Self-Assessed Maturity Level** | [Compliant / Substantially Compliant / Partly Compliant / Not Compliant] |
+| **Assessment Date** | [YYYY-MM-DD] |
+| **Assessor** | [Name + role] |
+
+---
+
+## Outcome 1: Security Governance
+
+### CR1: Role of accountable authority
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅ Compliant / ⚠️ Substantially Compliant / ⚠️ Partly Compliant / ❌ Not Compliant] |
+
+**Evidence**: [Accountable authority designated, security leadership, governance documents]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR2: Management structures and responsibilities
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [CSO designated, security committee, executive structures]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR3: Security planning and risk management
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Security plan, risk-management plan; cross-ref ARC-{P}-AUISM Domain 1]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR4: Security maturity monitoring
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Annual self-assessment process; AGD reporting submission]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+## Outcome 2: Information Security
+
+### CR5: Sensitive and classified information
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Classification policy, marking + handling procedures, classification training]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR6: Access to information
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Need-to-know enforcement; security-clearance verification at point of access]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR7: Safeguarding information from cyber threats
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+| **E8 Cross-Reference** | [ARC-{P}-AUE8-v*] |
+| **ISM Cross-Reference** | [ARC-{P}-AUISM-v*] |
+
+**Evidence**: [Defer to ISM applicability statement + E8 posture]
+
+**Gap**: [Beyond-E8 gaps]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR8: Sensitive and classified discussions and communications
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Approved communications channels for classified content; meeting room ratings; encrypted comms]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+## Outcome 3: Personnel Security
+
+### CR9: Eligibility and suitability
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [AGSVA clearance process; vetting workflow; cleared-personnel inventory]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR10: Ongoing assessment
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Continuous suitability programme, periodic reviews, change-of-circumstance reporting]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR11: Separation of personnel
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Off-boarding clearance debrief, access revocation cadence, return of equipment]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR12: Insider threat
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Insider threat programme, detection capability, role-based controls]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+## Outcome 4: Physical Security
+
+### CR13: Entity facilities
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌ / Inherited from cloud provider IRAP] |
+
+**Evidence**: [Physical security zones, facility ratings, access controls]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR14: Working off-site
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Remote work policy, travel security, mobile device management]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR15: Physical security risk
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Physical risk assessment, treatment plan, incident response]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+### CR16: Supporting services
+
+| Aspect | Detail |
+|--------|--------|
+| **Status** | [✅/⚠️/❌] |
+
+**Evidence**: [Cleaning, maintenance, contractor access governance, escort policy]
+
+**Gap**: [Description]
+
+**Remediation**: [Actions, owners, target dates]
+
+---
+
+## PSPF Annual Self-Assessment
+
+| Aspect | Detail |
+|--------|--------|
+| **Self-Assessment Cycle** | [Annual; deadline 31 October] |
+| **Last Submission Date** | [YYYY-MM-DD] |
+| **Self-Assessed Levels** | [List per Core Requirement] |
+| **AGD Feedback** | [Notes from last submission] |
+| **Material Improvements Since Last** | [Description] |
+| **Identified Issues for Next Cycle** | [Description] |
+
+---
+
+## Compliance Summary
+
+| Outcome | CR | Title | Status | Gap Count |
+|---------|----|-------|--------|-----------|
+| 1. Governance | CR1 | Role of accountable authority | [✅/⚠️/❌] | [n] |
+| 1. Governance | CR2 | Management structures | [✅/⚠️/❌] | [n] |
+| 1. Governance | CR3 | Security planning + risk | [✅/⚠️/❌] | [n] |
+| 1. Governance | CR4 | Security maturity monitoring | [✅/⚠️/❌] | [n] |
+| 2. Information | CR5 | Sensitive/classified information | [✅/⚠️/❌] | [n] |
+| 2. Information | CR6 | Access to information | [✅/⚠️/❌] | [n] |
+| 2. Information | CR7 | Safeguarding from cyber threats | [✅/⚠️/❌] | [n] |
+| 2. Information | CR8 | Discussions + communications | [✅/⚠️/❌] | [n] |
+| 3. Personnel | CR9 | Eligibility + suitability | [✅/⚠️/❌] | [n] |
+| 3. Personnel | CR10 | Ongoing assessment | [✅/⚠️/❌] | [n] |
+| 3. Personnel | CR11 | Separation of personnel | [✅/⚠️/❌] | [n] |
+| 3. Personnel | CR12 | Insider threat | [✅/⚠️/❌] | [n] |
+| 4. Physical | CR13 | Entity facilities | [✅/⚠️/❌] | [n] |
+| 4. Physical | CR14 | Working off-site | [✅/⚠️/❌] | [n] |
+| 4. Physical | CR15 | Physical security risk | [✅/⚠️/❌] | [n] |
+| 4. Physical | CR16 | Supporting services | [✅/⚠️/❌] | [n] |
+
+**Overall PSPF Maturity**: [Compliant / Substantially Compliant / Partly Compliant / Not Compliant]
+
+---
+
+## Recommendations
+
+### Quick Wins ( < 30 days)
+
+| # | Recommendation | Outcome / CR | Effort |
+|---|---------------|--------------|--------|
+| 1 | [Recommendation] | [Outcome.CR] | [Low/Medium] |
+
+### Short-Term (30–90 days)
+
+| # | Recommendation | Outcome / CR | Effort |
+|---|---------------|--------------|--------|
+| 1 | [Recommendation] | [Outcome.CR] | [Medium/High] |
+
+### Medium-Term (90–180 days)
+
+| # | Recommendation | Outcome / CR | Effort |
+|---|---------------|--------------|--------|
+| 1 | [Recommendation] | [Outcome.CR] | [High] |
+
+---
+
+## External References
+
+### Document Register
+
+| Doc ID | Filename | Type | Source | Description |
+|--------|----------|------|--------|-------------|
+| PSPF | Protective Security Policy Framework | Standard | protectivesecurity.gov.au | Primary framework |
+| AUE8 | ARC-{P}-AUE8-v* | ArcKit Artefact | projects/ | E8 cross-ref (Outcome 2) |
+| AUISM | ARC-{P}-AUISM-v* | ArcKit Artefact | projects/ | ISM cross-ref (Outcome 2) |
+| AUPIA | ARC-{P}-AUPIA-v* | ArcKit Artefact | projects/ | PIA cross-ref (Outcomes 2 + 3) |
+| AUDISP | ARC-{P}-AUDISP-v* | ArcKit Artefact | projects/ | DISP cross-ref where applicable |
+
+### Verification
+
+| Standard | URL | Verification Date |
+|----------|-----|-------------------|
+| PSPF | https://www.protectivesecurity.gov.au/ | [YYYY-MM-DD] |
+| ASD ISM | https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism | [YYYY-MM-DD] |
+
+---
+
+**Generated by**: ArcKit `/arckit:au-pspf` command
+**Generated on**: [DATE]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
diff --git a/arckit-copilot/config/doc-types.mjs b/arckit-copilot/config/doc-types.mjs
index 00d58bee..611ed971 100644
--- a/arckit-copilot/config/doc-types.mjs
+++ b/arckit-copilot/config/doc-types.mjs
@@ -152,18 +152,32 @@ export const DOC_TYPES = {
'OLA': { name: 'Canada Official Languages Act Review', category: 'Compliance', regime: 'CA' },
'PROC': { name: 'Canada Federal Procurement Strategy', category: 'Procurement', regime: 'CA' },
'OCAP': { name: 'Canada First Nations OCAP Sovereignty Assessment', category: 'Governance', regime: 'CA' },
+ // Australian Federal Overlay (Community-contributed, maintained by @royster70) — ASD Essential Eight, ISM, DTA DSS, Privacy Act 1988 PIA,
+ // OAIC NDB scheme, DISP, PSPF, DTA AI Assurance Framework + Responsible AI Policy v2.0
+ 'AUE8': { name: 'AU Essential Eight Maturity Posture', category: 'Compliance', regime: 'AU', severity: 'HIGH' },
+ 'AUISM': { name: 'AU ISM Statement of Applicability', category: 'Compliance', regime: 'AU', severity: 'HIGH' },
+ 'AUPIA': { name: 'AU Privacy Impact Assessment (Privacy Act 1988)', category: 'Compliance', regime: 'AU', severity: 'HIGH' },
+ 'AUNDB': { name: 'AU Notifiable Data Breach Response Playbook', category: 'Compliance', regime: 'AU' },
+ 'AUDSS': { name: 'AU DTA Digital Service Standard Conformance', category: 'Governance', regime: 'AU', severity: 'HIGH' },
+ 'AUPSPF': { name: 'AU Protective Security Policy Framework Scorecard', category: 'Governance', regime: 'AU', severity: 'HIGH' },
+ 'AUAIA': { name: 'AU AI Assurance Baseline (DTA AI Policy v2.0)', category: 'Compliance', regime: 'AU', severity: 'HIGH' },
+ 'AUDISP': { name: 'AU DISP Member Self-Attestation Pack', category: 'Compliance', regime: 'AU', severity: 'HIGH' },
};
// Derived: regimes in canonical order (officially-maintained first, then community alphabetical)
-export const REGIMES = ['UK', 'MOD', 'EU', 'FR', 'AT', 'UAE'];
+// CA + AU added retroactively — both shipped doc-types without REGIMES registration
+// (CA since v4.15.0, AU in v5.0.0). REGIME_LABELS ordering matches.
+export const REGIMES = ['UK', 'MOD', 'AT', 'AU', 'CA', 'EU', 'FR', 'UAE'];
// Human-readable regime labels
export const REGIME_LABELS = {
UK: 'UK Gov',
MOD: 'MOD',
+ AT: 'Austria',
+ AU: 'Australia',
+ CA: 'Canada',
EU: 'EU',
FR: 'France',
- AT: 'Austria',
UAE: 'UAE',
};
diff --git a/arckit-copilot/prompts/arckit-au-ai-assurance.prompt.md b/arckit-copilot/prompts/arckit-au-ai-assurance.prompt.md
new file mode 100644
index 00000000..b4783ab8
--- /dev/null
+++ b/arckit-copilot/prompts/arckit-au-ai-assurance.prompt.md
@@ -0,0 +1,127 @@
+---
+description: '[COMMUNITY] Generate an AI assurance assessment for Australian Government / regulated-sector AI systems covering DTA AI Policy v2.0, ISO 42001, AU AI Ethics Principles, and Privacy Act AI-decision notification (Dec 2026).'
+agent: 'agent'
+tools: ['readFile', 'editFiles', 'runCommand', 'codebase', 'search']
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified AI ethics specialist, Privacy Officer, or DTA-aligned AI assurance assessor before reliance. DTA AI Policy v2.0 may have been updated — verify against the current edition before any external use.
+
+You are an enterprise architect generating an **AI assurance assessment** for an Australian Government or regulated-sector AI / machine-learning system.
+
+## User Input
+
+```text
+${input:topic:Enter project name or topic}
+```
+
+## Context
+
+Australia's AI assurance landscape combines several frameworks that together govern AI deployment in government and regulated industry:
+
+- **DTA Responsible AI Policy v2.0 (effective Dec 2025)** — mandatory for non-corporate Commonwealth entities; expected via flow-down for AU Government tenderers and suppliers
+- **AU AI Ethics Principles** (Department of Industry, 2019) — 8 voluntary principles
+- **AU Essential AI Practices ("AI6")** — National AI Centre (NAIC) operational guidance: 6 essential practices for safe and responsible AI adoption (accountability, impact assessment, risk management, information sharing, testing/monitoring, human control). Foundations + Implementation Guidance issued via ai.gov.au.
+- **ISO 42001:2023 — AI Management Systems** — Australian Standard adopted Feb 2024; certification expected to become baseline for AI-intensive vendors
+- **Privacy Act 1988 (Cth)** — AI decision-making notification required from Dec 2026 (Tranche 1 reform)
+- **Online Safety Act + AI-generated content provisions**
+- Sector-specific: APRA CPS 234 (AI in financial services), AHPRA AI guidance (health)
+
+**Authoritative anchors**:
+
+- DTA Responsible AI Policy v2.0 —
+- AU AI Ethics Principles —
+- AU Essential AI Practices (AI6) — Guidance for AI Adoption: Foundations —
+- AU Essential AI Practices — Implementation Guidance —
+- Privacy Act 1988 (Cth) —
+
+## Process
+
+1. Read prerequisites:
+ - Project's PIA artefact (`ARC-{P}-AUPIA-v*`) — APP 6 + APP 11 cross-reference
+ - Project's DATA artefact — for training/inference data classification
+ - Project's REQ artefact — extract AI-specific requirements
+ - Project's RISK artefact — existing AI risks
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-ai-assurance-template.md`
+ - Then: `.arckit/templates/au-ai-assurance-template.md`
+ - Fallback: `.arckit/templates/au-ai-assurance-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUAIA --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **AI System Description** — system name, purpose, AI capability type (generative / predictive / decision-support / decision-making / agentic / multi-modal), deployment phase (research / pilot / production), foundation model used (e.g., GPT-4 / Claude / Gemini / open-source), training-data sources, inference-data sources, decisions affecting individuals (yes/no — describe), human-in-the-loop posture.
+
+ - **DTA Responsible AI Policy v2.0 Compliance** — assessment against the policy's six accountabilities:
+ 1. **Accountability** — designated AI accountable officer
+ 2. **Transparency** — public AI use disclosure
+ 3. **Risk-based approach** — AI risk assessment performed
+ 4. **Quality data + design integrity** — data lineage, model documentation
+ 5. **Privacy + security** — cross-reference PIA + ISM + E8
+ 6. **Human oversight + redress** — human review mechanism, individual appeal pathway
+
+ - **AU AI Ethics Principles Alignment** — assess against the 8 principles:
+ 1. Human, societal and environmental wellbeing
+ 2. Human-centred values
+ 3. Fairness
+ 4. Privacy protection and security
+ 5. Reliability and safety
+ 6. Transparency and explainability
+ 7. Contestability
+ 8. Accountability
+
+ For each principle: status (Aligned / Partial / Not Aligned), evidence, gap, mitigation.
+
+ - **AU Essential AI Practices (AI6) Alignment** — assess against the 6 essential practices issued by the National AI Centre via ai.gov.au:
+ 1. Decide who is accountable
+ 2. Understand impacts and plan accordingly
+ 3. Measure and manage risks
+ 4. Share essential information
+ 5. Test and monitor
+ 6. Maintain human control
+
+ For each practice: status (Implemented / Partial / Not Implemented / Not Applicable), evidence (artefact references where possible), gap, action. Cross-reference the DTA Responsible AI Policy six accountabilities — both frameworks share underlying principles but differ in scope (DTA = policy mandate for Commonwealth entities; AI6 = practical adoption guidance for any organisation). The AI6 *Implementation Guidance* on ai.gov.au provides "Getting started" and "Next steps" prompts per practice — useful for filling in evidence and action columns.
+
+ - **ISO 42001 Readiness** — assessment against the standard's clauses (context, leadership, planning, support, operation, performance evaluation, improvement). Useful for organisations pursuing or anticipating ISO 42001 certification.
+
+ - **Privacy Act AI-Decision Notification (Dec 2026)** — if the AI system makes substantially-automated decisions significantly affecting individuals, document: notification mechanism implemented (or planned for Dec 2026), what individuals are told, opt-out pathway if applicable. Cross-reference AUPIA APP 6 + APP 11.
+
+ - **Fairness Assessment** — bias evaluation methodology, protected-attribute analysis, fairness metrics used (demographic parity / equalised odds / etc.), test results across population segments, residual fairness risks.
+
+ - **Security of AI Training + Inference Data** — training-data classification (often higher than expected — model can memorise PI), inference-data flow (input PII handling, output PII risk), prompt-injection defences, model-extraction defences. Cross-reference E8 posture + ISM applicability.
+
+ - **Model Lifecycle Governance** — version control, change-management for model updates, drift detection, retirement/sunset criteria.
+
+ - **Vendor / Foundation-Model Disclosure** — for systems built on third-party foundation models, document: vendor name, model version, vendor's AI policy compliance, training-data provenance disclosure (if available), data-residency for inference, IP / copyright position.
+
+ - **Recommendations** — prioritised AI assurance actions grouped by Quick Wins / Short-Term / Medium-Term, each tagged to which framework it satisfies.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. DTA AI Policy v2.0, AU AI Ethics Principles, AU Essential AI Practices (AI6) — Foundations + Implementation Guidance, ISO 42001 (Australian Standard), and Privacy Act 1988 MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the DTA + Ethics Principles compliance summary table).
+
+## Important Notes
+
+- DTA AI Policy v2.0 applies to **non-corporate Commonwealth entities** directly. State/Territory Government and corporate Commonwealth entities are not bound but commonly flow it down via tender requirements. Suppliers to those entities should track for contractual flow-down.
+- The **December 2026 Privacy Act AI-decision notification** is a deadline. Systems making automated decisions significantly affecting individuals must implement the notification mechanism by then — design choices made before that date should anticipate the requirement.
+- Foundation-model use is a supply-chain concern. Vendor lock-in, training-data disclosure, IP indemnification, and inference-region sovereignty are commonly under-assessed in early-pilot AI systems.
+- Bias / fairness assessment is methodology-dependent. Recipes should not produce a "passes fairness" verdict from data alone — refer to a qualified data-ethics specialist for fairness validation.
+- For research / pilot AI not yet making production decisions, the assessment should still describe forward-looking requirements that will apply once the system moves to production. This avoids "we'll add it later" technical debt.
+- AI assurance findings often surface security and privacy implications that should propagate to AUPIA + AUE8 + AUISM artefacts. Recommend re-runs of those artefacts when an AI system materially changes.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit-au-pia` -- AI fairness + automated decision-making findings feed APP 6 + APP 11 in the PIA.
+- `/arckit-au-dss` -- AI assurance feeds DSS Criterion 7 (privacy) + Criterion 5 (security of training/inference data).
+- `/arckit-au-ism-controls` -- AI training / inference data security cites ISM Domain 9 (System Hardening) + Domain 12 (Cryptography).
+- `/arckit-risk` -- AI-specific risks (bias, drift, prompt injection, training-data exposure) feed the project risk register.
diff --git a/arckit-copilot/prompts/arckit-au-disp-attestation.prompt.md b/arckit-copilot/prompts/arckit-au-disp-attestation.prompt.md
new file mode 100644
index 00000000..ce04e055
--- /dev/null
+++ b/arckit-copilot/prompts/arckit-au-disp-attestation.prompt.md
@@ -0,0 +1,112 @@
+---
+description: '[COMMUNITY] Generate a DISP (Defence Industry Security Program) Member self-attestation pack covering E8 ML2, ISM applicability, governance, personnel security, and incident reporting — supports DISP Levels 1, 2, 3.'
+agent: 'agent'
+tools: ['readFile', 'editFiles', 'runCommand', 'codebase', 'search']
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified DISP-experienced security officer or DISP advisor before submission to Defence. DISP requirements may be updated — verify against the current DISP Membership Pack before any external use.
+
+You are an enterprise architect generating a **DISP (Defence Industry Security Program) Member self-attestation pack** for an Australian organisation supplying products or services to Defence.
+
+## User Input
+
+```text
+${input:topic:Enter project name or topic}
+```
+
+## Context
+
+The Defence Industry Security Program (DISP) is the security accreditation framework for Australian organisations supplying Defence. DISP Membership has three levels (Levels 1, 2, 3 — formerly Entry, Level 1, Level 2 in earlier guidance) with progressively-deeper governance, personnel, ICT, physical, and supply-chain security obligations. Essential Eight ML2 has been the minimum cyber baseline for DISP members since 2025; ISM applicability scales with the level. The attestation pack is the supplier's self-evidence document referenced during DISP application, audit, and renewal.
+
+**Authoritative anchor**: Defence Industry Security Program —
+
+**Key references**:
+
+- DISP Membership Pack (current edition) — application form + evidence requirements
+- ASD Essential Eight Maturity Model (ML2 minimum for DISP) —
+- ASD Information Security Manual —
+- Protective Security Policy Framework (PSPF)
+- Defence Security Principles Framework (DSPF) — referenced sections only
+- Privacy Act 1988 (Cth) — APP 11 alignment
+
+## Process
+
+1. Read prerequisites:
+ - The project's E8 posture artefact (`ARC-{P}-AUE8-v*`) — primary input
+ - The project's ISM applicability statement (`ARC-{P}-AUISM-v*`) — primary input
+ - The project's PIA (`ARC-{P}-AUPIA-v*`) — APP 11 cross-reference
+ - The project's PSPF assessment (`ARC-{P}-AUPSPF-v*`) — physical / personnel / information security evidence
+ - The project's RISK artefact — for SecRisk register integration
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - First: `.arckit/templates-custom/au-disp-attestation-template.md` (user override)
+ - Then: `.arckit/templates/au-disp-attestation-template.md`
+ - Fallback: `.arckit/templates/au-disp-attestation-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if needed.
+
+4. Use `scripts/bash/generate-document-id.sh AUDISP --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Organisation Profile** — entity name, ABN, primary business activity, Defence contracts in scope, headcount, sites, foreign ownership / control / influence (FOCI) declaration.
+
+ - **DISP Level Sought** — Level 1 / Level 2 / Level 3, regulatory driver (specific contract requirement, panel mandate, anticipated tender pipeline), justification of level chosen.
+
+ - **Security Officer Designation** — Chief Security Officer (CSO) name + role + authority, deputy / backup CSO, contact details, vetting status. **DISP requires a named, suitably-cleared CSO with authority across the four security domains.**
+
+ - **Four Security Domains Coverage** — DISP requires evidence across four domains:
+ 1. **Governance** — security policy, risk management, audit, incident management, change control
+ 2. **Personnel Security** — security clearances appropriate to work, security awareness training, separation of duties, off-boarding
+ 3. **Physical Security** — facility security, ICT equipment security, equipment lifecycle (cloud-only systems may inherit much of this from cloud provider's IRAP)
+ 4. **Information & Cyber Security** — Essential Eight ML2 minimum, ISM applicability, cryptography, gateway, monitoring, BCP
+
+ For each domain, document:
+ - Current implementation state (cite E8 posture, ISM applicability, supporting policies)
+ - Evidence references (artefact IDs + document register)
+ - Gap description
+ - Remediation plan with target dates
+ - Sign-off statement by accountable officer
+
+ - **Essential Eight ML2 Evidence Per Strategy** — for each of the 8 E8 strategies, summarise the current ML position and evidence supporting ML2 attestation. Cite the AUE8 artefact directly.
+
+ - **ISM Applicability Highlights** — beyond E8, summarise which ISM domains apply, current implementation summary, and identify any ISM gaps that materially affect DISP attestation. Cite the AUISM artefact.
+
+ - **Foreign Ownership, Control or Influence (FOCI) Declaration** — disclose any foreign ownership > 5%, foreign-board-member arrangements, foreign-supply-chain dependencies, foreign-personnel access. DISP Level 2 + 3 require FOCI mitigation plans where applicable.
+
+ - **Supply Chain Security** — disclose Tier 1 suppliers (MSPs, SaaS, cloud), supply-chain attestations held (SOC 2 / ISO 27001 / IRAP), supply-chain risk management process.
+
+ - **Incident Response & Reporting** — incident response plan summary, 24-hour rapid notification capability for Defence-relevant incidents, OAIC NDB scheme integration, evidence of last incident response exercise. Cite NDB playbook (`ARC-{P}-AUNDB-v*`) if available.
+
+ - **Security Awareness Training** — DISP-mandated security awareness training programme, completion rate, refresher cadence, security-clearance-holder additional briefings (pre/post-leave for cleared personnel).
+
+ - **Annual Self-Audit Plan** — DISP requires annual self-audit; describe scope, methodology, evidence retention.
+
+ - **Attestation Statement** — formal CSO + Director sign-off statement attesting to the accuracy of the pack, with signature blocks, date, and re-attestation cadence.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The DISP Membership Pack (with edition) MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the Four Security Domains coverage table).
+
+## Important Notes
+
+- The pack is a **self-attestation**, not a third-party assurance. Defence reserves the right to audit. Artefact tone should be evidence-based and conservative — do not claim controls not yet implemented.
+- The CSO designation is a hard requirement. If no CSO is named in the source artefacts, the pack must explicitly flag this as an outstanding action — it cannot be filled in by the recipe.
+- For Level 2 + 3 members supplying classified Defence work, security clearances of personnel handling that work must be evidenced. Records of clearance levels held may be sensitive — reference by clearance level (Baseline / NV1 / NV2 / PV) not by individual name.
+- Cloud-only systems that inherit Physical Security from an IRAP-assessed cloud provider should explicitly cite the cloud provider's IRAP scope statement, not generic marketing.
+- The pack should integrate with the project's risk register — material residual risks should appear both in the risk register and in the DISP pack's gap descriptions.
+- For DISP renewal cycles, the artefact should produce a redline-friendly format so year-on-year changes are easy to track.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit-au-e8-posture` -- E8 ML2 evidence per strategy is a primary input to the DISP attestation pack.
+- `/arckit-au-ism-controls` -- ISM applicability statement is a primary input — controls beyond E8 mandated by DISP level.
+- `/arckit-au-pia` -- Privacy Act + APP 11 alignment cited in attestation pack.
+- `/arckit-au-ndb-playbook` -- Notifiable Data Breach response is the operational complement to DISP incident reporting.
diff --git a/arckit-copilot/prompts/arckit-au-dss.prompt.md b/arckit-copilot/prompts/arckit-au-dss.prompt.md
new file mode 100644
index 00000000..092a1ed0
--- /dev/null
+++ b/arckit-copilot/prompts/arckit-au-dss.prompt.md
@@ -0,0 +1,104 @@
+---
+description: '[COMMUNITY] Generate a DTA Digital Service Standard compliance assessment for Australian Government digital services against all 13 criteria.'
+agent: 'agent'
+tools: ['readFile', 'editFiles', 'runCommand', 'codebase', 'search']
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified DTA assessor or digital delivery lead before reliance. The DTA Digital Service Standard was refreshed in July 2025 — verify criteria against the current published version.
+
+You are an enterprise architect generating a **DTA Digital Service Standard compliance assessment** for an Australian Government digital service.
+
+## User Input
+
+```text
+${input:topic:Enter project name or topic}
+```
+
+## Context
+
+The Digital Transformation Agency (DTA) Digital Service Standard sets the mandatory criteria that Australian Government digital services must meet. Services subject to the Standard must demonstrate compliance at key assessment points. The Standard replaced the earlier Digital Service Standard (2016) with a refreshed version in July 2025.
+
+**Authoritative anchor**: DTA Digital Service Standard —
+
+**Key Australian Digital Service References**:
+
+- DTA Digital Service Standard (July 2025 refresh)
+- DTA Service Design and Delivery Process
+- Digital Government Strategy
+- Web Content Accessibility Guidelines (WCAG) 2.2 Level AA
+- Style Manual for Australian Government (style.gov.au)
+- DTA Content Guide
+- Whole of Government Digital and ICT Investment Oversight Framework
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract user-facing requirements, accessibility requirements, technology choices
+ - The project's STKE artefact — extract user research, stakeholder engagement evidence
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - **First**, check `.arckit/templates-custom/au-dss-template.md` (user override)
+ - **Then**, `.arckit/templates/au-dss-template.md`
+ - **Fallback**, `.arckit/templates/au-dss-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUDSS --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **Service Context** — service name, owning agency/department, service phase (Discovery / Alpha / Beta / Live), user base (public-facing / internal / both), annual transaction volume (if known).
+
+ - **13-Criterion Assessment** — one assessment block per Digital Service Standard criterion:
+ 1. **Understand user needs** — research conducted with real users, needs documented
+ 2. **Have a multidisciplinary team** — team composition, capability coverage, DDaT roles
+ 3. **Agile and user-centred process** — delivery methodology, iteration cadence, user feedback loops
+ 4. **Understand tools and systems** — technology landscape mapped, legacy dependencies identified
+ 5. **Make it secure** — security posture, E8 alignment, threat assessment, incident response
+ 6. **Consistent and responsive design** — design system usage, responsive breakpoints, device testing
+ 7. **Protect users' privacy** — PIA completed, APP compliance, data minimisation, consent
+ 8. **Make source code open** — open-source strategy, code repository, licence
+ 9. **Make it accessible** — WCAG 2.2 AA compliance, assistive technology testing, accessibility statement
+ 10. **Test the service** — testing strategy (unit, integration, UAT, accessibility, performance, security)
+ 11. **Measure performance** — KPIs defined (completion rate, user satisfaction, cost per transaction, digital take-up)
+ 12. **Don't forget the non-digital experience** — assisted digital, phone, in-person channel design
+ 13. **Encourage everyone to use the digital service** — channel shift strategy, take-up targets
+
+ For each criterion, document:
+ - Assessment status: ✅ Met / ⚠️ Partially Met / ❌ Not Met / N/A
+ - Evidence summary (what demonstrates compliance)
+ - Gap description (what is missing)
+ - Remediation actions with owner and target date
+
+ - **Compliance Summary** — table: Criterion # | Criterion Name | Status | Gap Count
+
+ - **Assessment Readiness** — for services approaching Alpha/Beta/Live assessment, identify the top 3 risks to passing and recommended mitigations.
+
+ - **Recommendations** — prioritised list of actions to improve compliance posture, grouped by criterion priority.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The DTA Digital Service Standard MUST appear in the Document Register.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the compliance summary table showing status per criterion).
+
+## Important Notes
+
+- The DTA Digital Service Standard applies to **all new and redesigned Australian Government digital services**. Existing services may be assessed when undergoing significant change.
+- Criterion 5 (Make it secure) should cross-reference the ASD Essential Eight assessment (`/arckit:au-e8-posture`) if one exists.
+- Criterion 7 (Protect users' privacy) should cross-reference the Privacy Impact Assessment (`/arckit:au-pia`) if one exists.
+- Criterion 9 (Make it accessible) requires WCAG 2.2 Level AA as the minimum standard for Australian Government services.
+- The Standard is assessed at Alpha, Beta, and Live phases — the depth of evidence expected increases at each gate.
+- This assessment is analogous to the UK GDS Service Standard assessment (`/arckit:service-assessment`) but uses Australian criteria and governance structures.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit-au-e8-posture` -- DSS Criterion 5 (Make it secure) feeds into the E8 maturity posture assessment.
+- `/arckit-au-pia` -- DSS Criterion 7 (Protect users' privacy) feeds into the Privacy Impact Assessment.
+- `/arckit-risk` -- DSS gaps surface as delivery and compliance risks for the risk register.
diff --git a/arckit-copilot/prompts/arckit-au-e8-posture.prompt.md b/arckit-copilot/prompts/arckit-au-e8-posture.prompt.md
new file mode 100644
index 00000000..05c354a2
--- /dev/null
+++ b/arckit-copilot/prompts/arckit-au-e8-posture.prompt.md
@@ -0,0 +1,99 @@
+---
+description: '[COMMUNITY] Generate an ASD Essential Eight maturity posture assessment for Australian Government projects against all eight mitigation strategies at ML0–ML3.'
+agent: 'agent'
+tools: ['readFile', 'editFiles', 'runCommand', 'codebase', 'search']
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified CISO or security assessor before reliance. Citations to ASD Essential Eight guidance may lag the current text — verify against the source.
+
+You are an enterprise architect generating an **ASD Essential Eight maturity posture assessment** for an Australian Government or regulated-sector technology project.
+
+## User Input
+
+```text
+${input:topic:Enter project name or topic}
+```
+
+## Context
+
+The Australian Signals Directorate (ASD) Essential Eight is the baseline cyber-security mitigation framework for Australian Government entities. It defines eight mitigation strategies, each assessed at four maturity levels (ML0–ML3). Essential Eight ML2 is the minimum standard for DISP (Defence Industry Security Program) members and is increasingly expected for government procurement.
+
+**Authoritative anchor**: ASD Essential Eight Maturity Model —
+
+**Key Australian Security References**:
+
+- ASD Essential Eight Maturity Model (current edition)
+- ASD Information Security Manual (ISM) —
+- Protective Security Policy Framework (PSPF) —
+- Australian Cyber Security Strategy 2023–2030
+- DISP Essential Eight ML2 mandate (effective 2025)
+- Privacy Act 1988 (Cth) — security of personal information (APP 11)
+
+## Process
+
+1. Read prerequisites:
+ - `projects/000-global/ARC-000-PRIN-*.md` (architecture principles, if present)
+ - The project's REQ artefact — extract NFR-SEC requirements, data classification, compliance obligations
+ - The project's RISK artefact — extract existing security risks and mitigations
+ - `.arckit/templates/_partials/RENDERING.md`
+
+2. Read the template:
+ - **First**, check `.arckit/templates-custom/au-e8-posture-template.md` (user override)
+ - **Then**, `.arckit/templates/au-e8-posture-template.md`
+ - **Fallback**, `.arckit/templates/au-e8-posture-template.md`
+
+3. Use `scripts/bash/create-project.sh --json ` if the project does not yet exist; otherwise locate it.
+
+4. Use `scripts/bash/generate-document-id.sh AUE8 --filename` for the artefact filename.
+
+5. Resolve the `` marker per `RENDERING.md`. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) — replace the standard UK line in the header.
+
+6. Generate the following sections:
+
+ - **System Context** — system name, classification level (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET), deployment model (cloud / on-premise / hybrid), IRAP assessment status, data sovereignty position.
+
+ - **Essential Eight Maturity Assessment** — one assessment block per mitigation strategy. For each of the eight strategies:
+ 1. **Application Control** — only approved applications execute on systems
+ 2. **Patch Applications** — security patches for applications applied within timeframes
+ 3. **Configure Microsoft Office Macro Settings** — macros blocked or restricted per policy
+ 4. **User Application Hardening** — web browsers, email clients, Office configured to block untrusted content
+ 5. **Restrict Administrative Privileges** — admin access validated, separated, and time-limited
+ 6. **Patch Operating Systems** — OS patches applied within timeframes, unsupported OS replaced
+ 7. **Multi-Factor Authentication** — MFA on all remote access, privileged access, and data repositories
+ 8. **Regular Backups** — backups performed, tested, and stored securely per retention schedule
+
+ For each strategy, document:
+ - Current maturity level (ML0 / ML1 / ML2 / ML3) with evidence
+ - Target maturity level with rationale (regulatory driver or risk appetite)
+ - Gap description (specific controls not yet implemented)
+ - Remediation actions with owner and target date
+ - Residual risk if gap persists
+
+ - **Maturity Summary Matrix** — 8-row table: Strategy | Current ML | Target ML | Gap Count | Priority (Critical / High / Medium / Low)
+
+ - **DISP Compliance Position** — if the entity is a DISP member, assess whether current posture meets ML2 minimum across all eight strategies. Flag any strategy below ML2 as a DISP non-compliance risk.
+
+ - **Cloud-Specific Considerations** — for cloud-hosted systems, note which E8 controls are shared-responsibility (e.g., OS patching on PaaS vs IaaS), which are vendor-managed (e.g., application control on SaaS), and any IRAP-assessed cloud service alignment.
+
+ - **Recommendations** — prioritised list of remediation actions, grouped by Quick Wins ( < 30 days), Short-Term (30–90 days), and Medium-Term (90–180 days). Each recommendation references the specific E8 strategy and target ML.
+
+7. Populate the External References section per `.arckit/references/citation-instructions.md`. The ASD Essential Eight Maturity Model MUST appear in the Document Register with its primary URL and verification date.
+
+8. Write the artefact via the Write tool to `projects//`.
+
+9. Show only a summary to the user (one paragraph plus the maturity summary matrix showing current ML vs target ML per strategy).
+
+## Important Notes
+
+- ML0 means the strategy is **not implemented** — it does not mean "assessed and found satisfactory at a low level." Explicitly state this distinction.
+- Each maturity level has specific sub-controls defined by ASD. Do not assess at ML2 if ML1 sub-controls are not fully met — maturity levels are cumulative.
+- For OFFICIAL:Sensitive and above, cross-reference the ISM for additional mandatory controls beyond the Essential Eight.
+- The Essential Eight is a **mitigation** framework, not a comprehensive security standard. Recommend `/arckit:au-ism-controls` for the full ISM control applicability statement.
+- For energy-sector projects, recommend `/arckit:au-aescsf` as the AESCSF capability domains build on and extend the E8 baseline.
+
+## Suggested Next Steps
+
+After completing this command, consider running:
+
+- `/arckit-au-ism-controls` -- E8 posture feeds the ISM control applicability statement — target ML drives which ISM controls are mandatory.
+- `/arckit-risk` -- E8 gaps surface as security risks for the project risk register.
diff --git a/arckit-copilot/prompts/arckit-au-ism-controls.prompt.md b/arckit-copilot/prompts/arckit-au-ism-controls.prompt.md
new file mode 100644
index 00000000..105ff44c
--- /dev/null
+++ b/arckit-copilot/prompts/arckit-au-ism-controls.prompt.md
@@ -0,0 +1,115 @@
+---
+description: '[COMMUNITY] Generate an ASD Information Security Manual (ISM) control applicability statement for Australian Government projects, scoped to the system''s classification and supporting DISP attestation.'
+agent: 'agent'
+tools: ['readFile', 'editFiles', 'runCommand', 'codebase', 'search']
+---
+
+> ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified IRAP Assessor or CISO before reliance. ISM is updated quarterly — verify control identifiers against the current edition before any external use.
+
+You are an enterprise architect generating an **ASD Information Security Manual (ISM) control applicability statement** for an Australian Government or regulated-sector technology project.
+
+## User Input
+
+```text
+${input:topic:Enter project name or topic}
+```
+
+## Context
+
+The Australian Signals Directorate (ASD) Information Security Manual (ISM) is the comprehensive set of cyber-security controls for Australian Government information systems. Where the Essential Eight is a mitigation framework targeting attack-vector defence, the ISM is the comprehensive control set covering governance, personnel, physical, communications, ICT system, networking, cryptography, gateway, data-transfer, evaluation, working-off-site, and incident-response domains. ISM compliance is the core technical-controls evidence for PSPF Information Security outcome and a primary input to DISP attestation.
+
+**Authoritative anchor**: ASD Information Security Manual —