arckit-cli 6.1.1__py3-none-any.whl

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/at-bvergg.md

@@ -0,0 +1,86 @@
+# Austrian Federal Procurement Act (BVergG 2018) Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:at-bvergg` generates Austrian public procurement documentation aligned with **Bundesvergabegesetz 2018**. Covers Oberschwellen / Unterschwellen determination, ANKÖ publication requirements, BVergGVS secondary rules, and the BVwG review pathway.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | Scope to be procured |
+| SOBC (`ARC-<id>-SOBC-v*.md`) | Strategic case and budget |
+| Risk register (`ARC-<id>-RISK-v*.md`) | Risks allocated supplier vs entity |
+| AT DSGVO assessment (`ARC-<id>-ATDSG-v*.md`) | If processors of personal data are involved |
+| AT NISG assessment (`ARC-<id>-ATNISG-v*.md`) | If contracting entity is Essential or Important |
+
+---
+
+## Command
+
+```bash
+/arckit:at-bvergg <project ID or procurement description>
+```
+
+Output: `projects/<id>/ARC-<id>-BVERGG-v1.0.md`
+
+---
+
+## Strategy Structure
+
+| Section | Contents |
+|---------|----------|
+| Scope and Threshold Determination | Oberschwellen vs Unterschwellen calculation against current EU thresholds |
+| Procurement Procedure Selection | Open / restricted / negotiated / competitive dialogue / innovation partnership |
+| ANKÖ Publication Plan | Notice timing, language, content per BVergG §§ |
+| Award Criteria | Mandatory / quality / price weights and scoring rubric |
+| BVergGVS Secondary Rules | Defence / security / utilities / concessions where applicable |
+| Vendor Security & Data-Protection Clauses | DSGVO processor clauses, NISG supply-chain clauses |
+| BVwG Review Pathway | Standstill, pre-review request, BVwG appeal route and timing |
+| External References | BVergG 2018 + EU directive transposition citations |
+
+---
+
+## Threshold Reference
+
+| Tier | Trigger |
+|------|---------|
+| Oberschwellen | Above EU threshold — full BVergG regime, ANKÖ publication, EU OJ |
+| Unterschwellen | Below EU threshold — lighter regime, national publication |
+
+> EU thresholds are updated every two years — confirm the current value against the latest EU threshold regulation.
+
+---
+
+## One-Page Workflow
+
+| Phase | Key Activities | ArcKit Commands |
+|-------|----------------|-----------------|
+| Strategic case | Business case and budget | `/arckit:sobc` |
+| Compliance pre-checks | Personal data + critical-entity status | `/arckit:at-dsgvo`, `/arckit:at-nisg` |
+| Procurement | BVergG strategy + tender pack | `/arckit:at-bvergg` |
+| Evaluation | Score vendor responses | `/arckit:evaluate` |
+| Traceability | Link procurement requirements back | `/arckit:traceability` |
+
+---
+
+## Review Checklist
+
+- Threshold determination cites the current EU threshold regulation.
+- Procurement procedure choice has documented rationale (matches BVergG criteria).
+- ANKÖ publication timing, content, and language meet BVergG §§ requirements.
+- Award criteria pre-published with weights summing to 100%.
+- DSGVO processor clauses included where personal data is processed.
+- NISG supply-chain clauses included where contracting entity is Essential / Important.
+- Standstill period and BVwG review pathway documented in vendor pack.
+
+---
+
+## Key Notes
+
+- **Threshold drift**: EU procurement thresholds change every two years — items marked `[NEEDS VERIFICATION]` must be confirmed against the latest regulation before external publication.
+- **Defence / utilities / concessions**: BVergGVS imposes additional rules — confirm sectoral scope before relying on the standard BVergG path.
+- **Run after pre-checks**: `/arckit:at-dsgvo` and `/arckit:at-nisg` should run first if either applies — their clauses feed the vendor pack.
+- **Community-contributed**: Output should be reviewed by qualified Vergabejurist / Rechtsabteilung before reliance.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/at-dsgvo.md

@@ -0,0 +1,75 @@
+# Austrian DSG / DSGVO Compliance Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:at-dsgvo` generates an **Austrian Data Protection Assessment** — the Austria-specific GDPR layer applied by the Datenschutzbehörde (DSB) under the Datenschutzgesetz (DSG 2018, BGBl. I Nr. 165/1999 as amended). Covers DSB enforcement patterns, §§ 12–13 DSG special provisions, image processing under § 12 DSG, and Austrian DPIA blacklist criteria.
+
+> **Run after** `/arckit:eu-rgpd` — this command supplements the EU GDPR baseline.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | Processing activities and data flows |
+| EU GDPR assessment (`ARC-<id>-RGPD-v*.md`) | Base GDPR compliance — required prerequisite |
+| Data model (`ARC-<id>-DMOD-v1.0.md`) | Personal-data categories and entities |
+
+---
+
+## Command
+
+```bash
+/arckit:at-dsgvo <project ID or processing description>
+```
+
+Output: `projects/<id>/ARC-<id>-ATDSG-v1.0.md`
+
+---
+
+## Assessment Structure
+
+| Section | Contents |
+|---------|----------|
+| Austrian Layer Scope | Processing activities subject to DSG-specific obligations beyond GDPR |
+| § 12 DSG Image Processing | CCTV / image-processing rules (more restrictive than GDPR baseline) |
+| §§ 12–13 DSG Special Provisions | Public-interest, scientific, statistical, archival processing |
+| DSB Blacklist Screening | Austrian DPIA blacklist criteria and outcome |
+| Data Subject Rights — AT Layer | DSB complaint pathway and timelines |
+| DSB Enforcement Patterns | Recent DSB decisions and priority areas |
+| Cross-Border Transfers — AT Specifics | National derogations and DSB notification |
+| Gap Analysis | Austrian-specific gaps beyond EU GDPR baseline |
+| External References | DSG 2018, DSB guidance, recent DSB decisions |
+
+---
+
+## One-Page Workflow
+
+| Phase | Key Activities | ArcKit Commands |
+|-------|----------------|-----------------|
+| EU baseline | GDPR compliance | `/arckit:eu-rgpd` |
+| Austrian layer | DSB-specific assessment | `/arckit:at-dsgvo` |
+| High-risk | Full DPIA if blacklist criteria triggered | `/arckit:dpia` |
+| Critical entity | NISG obligations where applicable | `/arckit:at-nisg` |
+
+---
+
+## Review Checklist
+
+- EU GDPR baseline (`ARC-<id>-RGPD-v*.md`) completed first.
+- § 12 DSG checked explicitly if any image / video / CCTV processing occurs.
+- DSB Blacklist screening result is explicit (triggered / not triggered + which criteria).
+- DPIA escalation triggered when 2+ blacklist criteria apply or DSB Blacklist explicitly applies.
+- Public-interest / scientific / statistical / archival processing covered if relevant.
+- DSB complaint pathway documented for data subjects.
+- Gap analysis lists Austrian-specific gaps (not duplicates of EU GDPR gaps).
+
+---
+
+## Key Notes
+
+- **§ 12 DSG is stricter than GDPR**: Image processing rules in Austria are more restrictive than Article 6 GDPR — workplace and public-space CCTV needs explicit § 12 DSG analysis.
+- **DSB Blacklist**: Austria has published a national DPIA blacklist on top of the GDPR Article 35(4) list — this is checked separately.
+- **Run order**: This command supplements `/arckit:eu-rgpd`. Do not run in isolation.
+- **Community-contributed**: Output should be reviewed by qualified DSB-Beauftragter / DPO / Rechtsabteilung before reliance.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/at-nisg.md

@@ -0,0 +1,94 @@
+# Austrian NIS Act (NISG) Compliance Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:at-nisg` assesses Austrian NISG obligations (BGBl. I Nr. 94/2025) — the Austrian transposition of NIS2. Covers Essential / Important entity classification, BKA (GovCERT) and BMI (SPOC) reporting, KSÖ coordination, and Austrian sectoral rules.
+
+> **Run after** `/arckit:eu-nis2` — this command supplements the EU NIS2 baseline with Austrian transposition specifics.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | Service / sector context |
+| EU NIS2 assessment (`ARC-<id>-NIS2-v*.md`) | Base NIS2 compliance — required prerequisite |
+| Architecture (`ARC-<id>-ARCH-v1.0.md`) | Components and trust boundaries |
+| Security NFRs (`ARC-<id>-NFR-SEC-v1.0.md`) | Existing security posture |
+
+---
+
+## Command
+
+```bash
+/arckit:at-nisg <project ID or organisation>
+```
+
+Output: `projects/<id>/ARC-<id>-ATNISG-v1.0.md`
+
+---
+
+## Assessment Structure
+
+| Section | Contents |
+|---------|----------|
+| Entity Classification | Essential vs Important under NISG, sectoral mapping |
+| Article 21 Ten Minimum Measures | Per-measure compliance posture and gaps |
+| BKA / GovCERT Reporting Pathway | Incident reporting workflow, timing, content |
+| BMI Single Point of Contact | Registration, contact maintenance, escalation |
+| KSÖ Coordination | National cyber-coordination role and obligations |
+| Austrian Sectoral Rules | Sector-specific requirements above NIS2 baseline |
+| Supply-Chain Security | Vendor obligations under NISG (feeds procurement) |
+| Gap Analysis | Austrian-specific gaps beyond NIS2 baseline |
+| External References | NISG idF BGBl. I Nr. 94/2025 + implementing ordinances |
+
+---
+
+## Article 21 — The Ten Minimum Measures
+
+| # | Measure |
+|---|---------|
+| 1 | Risk analysis and information system security policies |
+| 2 | Incident handling |
+| 3 | Business continuity / crisis management |
+| 4 | Supply chain security |
+| 5 | Security in network and information systems acquisition, development, maintenance |
+| 6 | Policies and procedures to assess effectiveness |
+| 7 | Basic cyber hygiene and training |
+| 8 | Cryptography and encryption policies |
+| 9 | Human resources security, access control, asset management |
+| 10 | Multi-factor authentication, secured comms, secured emergency comms |
+
+---
+
+## One-Page Workflow
+
+| Phase | Key Activities | ArcKit Commands |
+|-------|----------------|-----------------|
+| EU baseline | NIS2 compliance | `/arckit:eu-nis2` |
+| Austrian layer | NISG-specific assessment | `/arckit:at-nisg` |
+| Risk | Surface gaps to risk register | `/arckit:risk` |
+| Controls | Implement Article 21 measures | `/arckit:secure` |
+| Procurement | Supply-chain clauses | `/arckit:at-bvergg` |
+
+---
+
+## Review Checklist
+
+- EU NIS2 baseline (`ARC-<id>-NIS2-v*.md`) completed first.
+- Entity classification (Essential vs Important) is explicit with sectoral basis.
+- All 10 Article 21 measures assessed (no skipped rows).
+- BKA / GovCERT reporting pathway has named owner and incident-class triggers.
+- BMI SPOC registration status and contact maintenance documented.
+- Supply-chain clauses fed to procurement (`/arckit:at-bvergg`).
+- Gaps surfaced to project risk register.
+
+---
+
+## Key Notes
+
+- **Recent legislation**: NISG idF BGBl. I Nr. 94/2025 is recent and evolving — items marked `[NEEDS VERIFICATION]` must be confirmed against the current text and implementing ordinances before external use.
+- **Sectoral overlay**: Some sectors (energy, transport, finance, health) have additional Austrian rules above NIS2 — confirm sectoral scope.
+- **Run order**: Supplements `/arckit:eu-nis2`. Do not run in isolation.
+- **Community-contributed**: Output should be reviewed by qualified CISO / BMI-liaison / Rechtsabteilung before reliance.

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

@@ -0,0 +1,98 @@
+# Algorithmic Transparency Recording Standard Playbook
+
+> **Guide Origin**: Official | **ArcKit Version**: [VERSION]
+
+`/arckit:atrs` generates an Algorithmic Transparency Recording Standard (ATRS) record for AI and algorithmic tools used in public services.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | System purpose and user impact |
+| AI Playbook assessment | Responsible AI context |
+| Data model | Data sources and processing |
+| Stakeholder drivers | Business context and affected groups |
+
+---
+
+## Command
+
+```bash
+/arckit:atrs Create ATRS record for <algorithmic tool>
+```
+
+Output: `projects/<id>/ARC-<id>-ATRS-v1.0.md`
+
+---
+
+## ATRS Record Structure
+
+| Section | Contents |
+|---------|----------|
+| Basic Information | Name, owner, description, deployment date |
+| Purpose and Scope | Why the tool exists and what decisions it supports |
+| How It Works | Technical overview (accessible to public) |
+| Data Used | Input data, sources, personal data handling |
+| Human Oversight | How humans are involved in the process |
+| Risk Management | Identified risks and mitigations |
+| Impact Assessment | Who is affected and how |
+| Performance Monitoring | How accuracy and fairness are measured |
+| Contact Information | Who to contact for questions |
+
+---
+
+## ATRS Tiers
+
+| Tier | Description | Disclosure Level |
+|------|-------------|------------------|
+| Tier 1 | Low impact, simple algorithms | Basic disclosure |
+| Tier 2 | Moderate impact, ML-based | Standard disclosure |
+| Tier 3 | High impact, complex AI | Full disclosure |
+
+---
+
+## One-Page Workflow
+
+| Phase | Key Activities | ArcKit Commands |
+|-------|----------------|-----------------|
+| Discovery | Define algorithmic tool and impact | `/arckit:requirements`, `/arckit:stakeholders` |
+| Assessment | Assess AI compliance and risks | `/arckit:ai-playbook`, `/arckit:dpia` |
+| Transparency | Create ATRS record | `/arckit:atrs` |
+| Publication | Publish record to gov.uk | Manual process |
+| Review | Regular review and updates | Annual cycle |
+
+---
+
+## Review Checklist
+
+- Tool purpose and scope clearly described in plain language.
+- Technical description accessible to non-technical readers.
+- All data sources identified with personal data flagged.
+- Human oversight mechanisms documented.
+- Risk mitigations in place for identified risks.
+- Impact assessment covers all affected groups.
+- Performance metrics defined for ongoing monitoring.
+- Contact information current and accessible.
+
+---
+
+## Publication Requirements
+
+| Requirement | Description |
+|-------------|-------------|
+| Format | Structured format per CDDO guidance |
+| Location | Published on gov.uk algorithmic transparency hub |
+| Review Cycle | Annual review minimum |
+| Updates | Material changes require record update |
+
+---
+
+## Key Principles
+
+1. **Plain Language**: Records must be understandable by the public.
+2. **Proactive Disclosure**: Publish before being asked.
+3. **Living Document**: Update when the system changes.
+4. **Honest Assessment**: Acknowledge limitations and risks.
+5. **Accessibility**: Information available to all affected citizens.

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

@@ -0,0 +1,45 @@
+# AU AESCSF Maturity Assessment
+
+`/arckit:au-aescsf` generates an Australian Energy Sector Cyber Security Framework (AESCSF) maturity assessment for Australian electricity, gas, energy-market, DER, OT, or energy-sector supplier projects.
+
+AESCSF is energy-specific, but it should not be run as an isolated cyber checklist. It composes the AU federal community overlay: `au-e8-posture` and `au-ism-controls` provide the ASD cyber baseline, while optional `au-ot-security` and `au-soci-cirmp` add connected OT and critical-infrastructure evidence where they apply.
+
+## Prerequisites
+
+| Artefact | Why it helps |
+|----------|--------------|
+| `/arckit:requirements` | Source for resilience, safety, customer, market, and regulatory requirements |
+| `/arckit:stakeholders` | Identifies responsible entity, operator, accountable officer, market participants, suppliers, and regulators |
+| `/arckit:au-e8-posture` (`ARC-<id>-AUE8-v1.0.md`) | Enterprise cyber baseline for AESCSF maturity evidence |
+| `/arckit:au-ism-controls` (`ARC-<id>-AUISM-v1.0.md`) | Broader ASD control evidence and IRAP/cloud inheritance context |
+| `/arckit:au-ot-security` (`ARC-<id>-AUOT-v1.0.md`) | Optional OT evidence for IT/OT convergence, segmentation, remote access, telemetry, and recovery constraints |
+| `/arckit:au-soci-cirmp` (`ARC-<id>-AUSOCI-v1.0.md`) | Optional SOCI/CIRMP evidence for critical asset and all-hazards governance |
+| `/arckit:dfd` and `/arckit:diagram` | IT/OT, market, DER, customer, vendor, and telemetry data-flow evidence |
+| `/arckit:data-model` | NMI, meter, DER, customer, life-support, outage, settlement, and network-constraint data relationships |
+| `/arckit:traceability` | Links AESCSF domains to requirements, controls, risks, diagrams, decisions, and evidence |
+
+## Usage
+
+```text
+/arckit:au-aescsf 001
+/arckit:au-aescsf "DNSP ADMS/DERMS Program"
+```
+
+Output: `projects/<id>/ARC-<id>-AUAESCSF-v1.0.md`
+
+## What It Produces
+
+- AESCSF scope and energy-sector operating context.
+- Current and target maturity assessment.
+- Evidence mapped from E8, ISM, OT security, SOCI/CIRMP, architecture, and operating records.
+- IT/OT convergence, DER, market, supplier, and grid-edge considerations.
+- Gap register, uplift pathway, and residual risk handoff.
+- Traceability back to requirements, risks, diagrams, data models, and ADRs.
+
+## Source Currency
+
+AEMO source material can be intermittently unavailable. At run time, verify the current AESCSF package, version, guidance material, and source availability rather than relying on cached assumptions.
+
+## Evaluation Fixtures
+
+The public AU energy fixture corpus under `tests/fixtures/au-energy` is synthetic, including organisations, scenarios, evidence, and personas. It is intended for public evaluation, regression testing, and community improvement.

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

@@ -0,0 +1,84 @@
+# Australian AI Assurance Baseline Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:au-ai-assurance` generates an AI assurance baseline against the Digital Transformation Agency's AI Assurance Framework and the Responsible AI Policy v2.0 (effective December 2025). It captures the AI system's risk classification, runs the assurance assessment against the Framework's principles, surfaces the Privacy Act AI-decision notification posture (Tranche 1 reforms, December 2024), captures ISO 42001 readiness, and surfaces the human-oversight and accountability model.
+
+The AI Assurance Framework is the operational expression of Australia's responsible-AI commitments for Federal entities. For DISP suppliers offering AI-enabled services to Defence, this is the gate artefact alongside the ISM SoA. The Tranche 1 Privacy Act reforms add a discrete obligation around automated decision-making notifications that the assurance baseline must address.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | AI system description, intended use, user populations |
+| `/arckit:au-pia` output (`ARC-<id>-AUPIA-v1.0.md`) | Automated decision-making notification posture |
+| Data model (`ARC-<id>-DMOD-v1.0.md`) | Training, validation, and inference data flows |
+| Risk register (`ARC-<id>-RISK-v1.0.md`) | AI-specific risks (bias, drift, hallucination, misuse) |
+| HLD (`ARC-<id>-HLD-v1.0.md`) | Model architecture, hosting, monitoring posture |
+
+---
+
+## Command
+
+```bash
+/arckit:au-ai-assurance <project ID or service description>
+```
+
+Output: `projects/<id>/ARC-<id>-AUAIA-v1.0.md`
+
+---
+
+## Assurance Structure
+
+| Section | Contents |
+|---------|----------|
+| Document Control | Australian classification (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET / TOP SECRET) |
+| Revision History | Version, date, author, changes, approvals |
+| Executive Summary | Risk classification, headline assurance posture, residual issues, decisions for accountable authority |
+| AI System Description | Use case, deployment context, lifecycle stage |
+| Risk Classification | Per the AI Assurance Framework rubric: low / medium / high / unacceptable |
+| Principle-by-Principle Assessment | Each Framework principle: posture, evidence, gaps, mitigations |
+| Responsible AI Policy v2.0 Conformance | Specific obligations: usage register, deployment approval, ministerial visibility |
+| Privacy Act Tranche 1 Notification | Automated decision-making notification posture and pathway |
+| Human Oversight Model | Where humans remain in the loop, escalation criteria, override workflow |
+| ISO 42001 Readiness | Gap analysis against ISO/IEC 42001 (AI management systems) for organisations targeting certification |
+| Monitoring & Drift | Performance metrics, drift detection, retraining triggers |
+| Incident Response | AI-specific incident criteria (hallucination, bias drift, misuse, model compromise) |
+| Maintenance Cadence | Quarterly review minimum; per-release for active development |
+
+---
+
+## Regulatory Anchors
+
+- **DTA AI Assurance Framework** — primary assurance methodology (current version)
+- **Responsible AI Policy v2.0** — effective December 2025; usage transparency obligations
+- **Privacy Act 1988 (Cth)** — Tranche 1 reforms (Dec 2024): automated decision-making notification
+- **ISO/IEC 42001** — AI management system standard; voluntary but increasingly procurement-relevant
+- **NSW AI Assurance Framework** — sub-federal reference; non-binding for Commonwealth but informative
+- **DTA Generative AI Framework / Guardrails** — generative-AI-specific extensions
+
+---
+
+## When to Run
+
+- For any AI / ML system entering Federal use; for DISP suppliers shipping AI to Defence
+- Pre-deployment and at each material model change (retraining, new use case, new population)
+- Quarterly minimum once Live; per-release in active development
+- On regulatory update (Framework version change, new policy version)
+
+---
+
+## Common Pitfalls
+
+- **Treating LLMs as low risk by default** — generative AI in customer-facing or decision-support contexts is typically medium or high. Map honestly.
+- **Missing the Tranche 1 notification trigger** — automated decisions that affect individuals trigger notification obligations under the amended Privacy Act. Cross-check the PIA explicitly.
+- **No drift monitoring** — assurance is a posture at a point in time. Without continuous monitoring, the posture lapses immediately.
+- **ISO 42001 confused with conformance** — readiness is a gap analysis, not a certification claim. Mark certification status explicitly.
+
+---
+
+## Handoff
+
+Cross-references `/arckit:au-pia` (automated decision-making notification), `/arckit:au-ism-controls` (technical controls for model serving), and feeds `/arckit:au-disp-attestation` (DISP supplier AI assurance evidence for Defence-facing systems).

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

@@ -0,0 +1,90 @@
+# Australian DISP Member Self-Attestation Pack Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:au-disp-attestation` generates a Defence Industry Security Program (DISP) Member self-attestation pack. It consolidates the evidence base across the 4 DISP security domains (Governance, Personnel Security, Physical Security, Information & Cyber), captures the Foreign Ownership Control & Influence (FOCI) declaration, surfaces the supply-chain security posture, and structures the annual board attestation that DISP membership requires.
+
+DISP is the Department of Defence's supplier-side security accreditation. Level 2 (the most common operational ceiling for non-classified Defence work) requires demonstrable evidence across all four domains and depends on E8 ML2 as the cyber baseline. This pack is the consolidation artefact that the other AU commands feed into — run it last.
+
+---
+
+## Inputs
+
+This is the consolidation artefact. It draws from every other AU command's output:
+
+| Artefact | Purpose |
+|----------|---------|
+| `/arckit:au-e8-posture` (`ARC-<id>-AUE8-v1.0.md`) | E8 ML2+ baseline for the cyber domain |
+| `/arckit:au-ism-controls` (`ARC-<id>-AUISM-v1.0.md`) | ISM SoA underpinning Information & Cyber |
+| `/arckit:au-pia` (`ARC-<id>-AUPIA-v1.0.md`) | Personal information handling for Information & Cyber |
+| `/arckit:au-ndb-playbook` (`ARC-<id>-AUNDB-v1.0.md`) | Breach response capability |
+| `/arckit:au-pspf` (`ARC-<id>-AUPSPF-v1.0.md`) | PSPF maturity for Governance, Personnel, Physical, Information |
+| `/arckit:au-ai-assurance` (`ARC-<id>-AUAIA-v1.0.md`) | AI assurance for Defence-facing AI systems |
+| Stakeholders (`ARC-<id>-STKE-v1.0.md`) | Accountable authority, security advisor, FOCI signatory |
+| Risk register (`ARC-<id>-RISK-v1.0.md`) | Supplier-side risks |
+
+---
+
+## Command
+
+```bash
+/arckit:au-disp-attestation <project ID or service description>
+```
+
+Output: `projects/<id>/ARC-<id>-AUDISP-v1.0.md`
+
+---
+
+## Pack Structure
+
+| Section | Contents |
+|---------|----------|
+| Document Control | Australian classification (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET / TOP SECRET) |
+| Revision History | Version, date, author, changes, approvals |
+| Executive Summary | DISP level targeted, attestation status, headline gaps, board action required |
+| Member Identity | Legal entity, ABN, ownership tree, accountable individuals |
+| Foreign Ownership Control & Influence (FOCI) Declaration | Ownership, control, influence; mitigation arrangements where required |
+| Domain 1 — Governance | Security governance, risk, accountability; evidence cross-references to PSPF Outcome 1 |
+| Domain 2 — Personnel Security | Vetting, ongoing suitability, separation; evidence from PSPF Outcome 3 |
+| Domain 3 — Physical Security | Premises, certified zones, custody; evidence from PSPF Outcome 4 |
+| Domain 4 — Information & Cyber | E8, ISM, PIA, NDB evidence; AI assurance for AI-enabled Defence services |
+| Supply Chain Security | Sub-contractor vetting, supply-chain risk register, security clauses |
+| Incident History | Material security incidents in attestation window |
+| Annual Board Attestation | Statement signed by accountable authority confirming the posture |
+| Maintenance Cadence | Annual attestation cycle; per-incident updates |
+
+---
+
+## Regulatory Anchors
+
+- **DISP Member Manual** — authoritative source for DISP-level requirements
+- **Defence Security Principles Framework (DSPF)** — incorporated by reference for DISP suppliers
+- **ASD Essential Eight Maturity Model** — ML2 baseline for DISP Level 2
+- **ASD Information Security Manual** — control evidence base for Domain 4
+- **Privacy Act 1988 (Cth)** — for personal information handling
+- **Protective Security Policy Framework** — referenced across Domains 1, 2, 3, 4
+- **Cyber Security Act 2024 (Cth)** — incident-reporting interactions
+
+---
+
+## When to Run
+
+- During DISP application or upgrade (Level 1 → 2 → 3)
+- Annually for ongoing DISP members (the attestation cycle)
+- On material change to FOCI, leadership, or the security posture (re-attestation may be required)
+- On significant security incident in attestation window
+
+---
+
+## Common Pitfalls
+
+- **Treating it as paperwork** — DISP attestation is a board-level statement of fact. Inaccuracies create criminal exposure under Defence security legislation. Validate every cross-reference.
+- **Thin FOCI declaration** — full ownership tree is required, including indirect control. Engage corporate counsel early if ownership is non-trivial.
+- **Inheriting evidence without verification** — if Domain 4 cites the ISM SoA, the underlying SoA must be current and accurate. Don't cite stale evidence.
+- **Missing sub-contractor coverage** — DISP suppliers carry obligations across the supply chain. Sub-contractor vetting evidence must be in the pack.
+
+---
+
+## Handoff
+
+This is the consolidation artefact for DISP attestation. It is read by the Department of Defence, Defence Industry Security Branch, and (where relevant) procurement-side security assessors. After board sign-off, the attestation cycle resets for 12 months.

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

@@ -0,0 +1,76 @@
+# Australian DTA Digital Service Standard Conformance Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:au-dss` generates a conformance assessment against the Digital Transformation Agency's Digital Service Standard (13 criteria). It scopes the service in delivery-phase terms (Discovery / Alpha / Beta / Live), evaluates each of the 13 criteria with evidence and gaps, captures the cross-jurisdictional procurement implications under the Commonwealth Procurement Rules (November 2025 overhaul), and surfaces the readiness posture for DTA assessment.
+
+The DTA DSS is the Australian counterpart to the UK GDS Service Standard. The conformance assessment is the gate that Australian Federal services use to demonstrate user-centred, accessible, and accountable design before launch.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | Service description, user needs, accessibility targets |
+| Stakeholders (`ARC-<id>-STKE-v1.0.md`) | User populations, accountable authority, partners |
+| Strategy (`ARC-<id>-STRAT-v1.0.md`) | Programme phase, success measures |
+| HLD (`ARC-<id>-HLD-v1.0.md`) | Technical posture, accessibility implementation |
+
+---
+
+## Command
+
+```bash
+/arckit:au-dss <project ID or service description>
+```
+
+Output: `projects/<id>/ARC-<id>-AUDSS-v1.0.md`
+
+---
+
+## Assessment Structure
+
+| Section | Contents |
+|---------|----------|
+| Document Control | Australian classification (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET / TOP SECRET) |
+| Revision History | Version, date, author, changes, approvals |
+| Executive Summary | Headline conformance, gaps to launch, DTA assessment readiness |
+| Service Scope | Description, owner, user populations, current delivery phase |
+| Criterion-by-Criterion Assessment | All 13 criteria: posture, evidence cited, gaps, planned remediation |
+| Accessibility (WCAG 2.2 AA) | Conformance level, audit evidence, remediation backlog |
+| Procurement Implications | CPR November 2025 obligations, ICT supplier ethical conduct, AI transparency clauses |
+| Performance Measures | KPIs aligned to DSS criteria 1, 8, and 13 |
+| Treatment & Monitoring | Outstanding remediation, review cadence, governance routes |
+
+---
+
+## Regulatory Anchors
+
+- **DTA Digital Service Standard** — 13 criteria (authoritative source for scoring)
+- **DTA Digital Service Standard Guidance** — criterion-by-criterion interpretation
+- **WCAG 2.2 AA** — accessibility target referenced by Criterion 9
+- **Commonwealth Procurement Rules (November 2025 overhaul)** — supplier ethical conduct, AI transparency
+- **PGPA Act 2013 s16** — federal accountable-authority duties
+
+---
+
+## When to Run
+
+- At each delivery-phase gate (end of Discovery, end of Alpha, end of Beta, pre-Live)
+- On material change to user-facing design, accessibility implementation, or accountability model
+- Refresh annually in steady-state Live to track residual conformance
+
+---
+
+## Common Pitfalls
+
+- **Marking criteria green without dated evidence** — every "met" criterion needs an evidence pointer (research output, audit report, monitoring dashboard) with a date. Older than 12 months is stale.
+- **Confusing WCAG 2.1 AA with 2.2 AA** — Criterion 9 references the current target. Verify against the version cited in current DTA guidance.
+- **Skipping the procurement criteria** — Criterion 13 (sustainability and value for money) materially changed with the CPR November 2025 overhaul. Cite the new obligations explicitly.
+
+---
+
+## Handoff
+
+Feeds the assurance package alongside `/arckit:au-pia` (Privacy Act compliance) and `/arckit:au-e8-posture` (cyber baseline). Pre-Live and Live phase artefacts cross-reference DSS conformance evidence in `/arckit:au-disp-attestation` for supplier-side accreditation.