help wanted: contribute a /arckit:build recipe for your jurisdiction

[tractorjuice]

Open invitation

Three recipes ship with the ArcKit plugin today:

• uk-saas — UK Government civilian SaaS (38 targets, GDS / TCoP / NCSC CAF)
• uk-mod-sovereign — UK MOD / sovereign / air-gapped (38 targets, MOD-SBD / JSP 936)
• uae-federal-ai — UAE Federal AI under the 23 April 2026 Cabinet decree (48 targets)

That covers roughly 0.5% of the world's public sectors. The other 99.5% need recipes too. If you architect for a jurisdiction not on the list above, this is the issue to claim.

The full launch article: https://arckit.org/article-viewer.html?a=2026-05-03-community-recipes-wanted

What a recipe is

A YAML file that lists which /arckit:* commands form a coherent governance bundle for projects in your jurisdiction, the dependency graph between them, and the args each command should be invoked with. The build harness reads it, computes parallel waves, dispatches subagents.

A recipe is not a fork of ArcKit. It does not change the underlying commands. It is configuration that says "for projects in my jurisdiction, this is the bundle, this is the order, here are the topic seeds for the eight architecture decision records".

What we'd accept as a contribution

The bar is "a serious architect for that jurisdiction would recognise this as a credible governance bundle". Concretely:

• YAML file at arckit-claude/skills/arckit-build/recipes/{your-recipe}.yaml matching the schema documented in arckit-claude/skills/arckit-build/SKILL.md § "Recipe schema (v1)"
• ~8 architecture decision record topics that reflect the cloud, identity, data, AI, and procurement choices an architect actually faces in your jurisdiction
• Whichever core ArcKit commands fit (most do, regardless of jurisdiction)
• Plus relevant community-overlay commands if they exist (fr-*, eu-*, at-*, uae-* already shipped; new prefixes welcome)
• Optional research wave following the ORG_RESEARCH → per-project pattern established in v4.13.1
• YAML validates: python3 -c "import yaml; r=yaml.safe_load(open('YOUR-RECIPE.yaml')); ids = {t['id'] for t in r['targets']}; deps_ok = all(d.rstrip('*') in {i.rstrip('-') for i in ids} or any(i.startswith(d.rstrip('*')) for i in ids) for t in r['targets'] for d in t['deps']); print('ok' if deps_ok else 'FAIL')"
• PR description names the regulatory anchors the recipe is designed to satisfy (e.g. "EU AI Act + NIS2 + DORA + GDPR" for an eu-saas recipe)

Most-wanted jurisdictions

Tagging the ones likely to land most cleanly given existing community-overlay commands:

Recipe slot	Anchor regulations	Existing community commands to compose
eu-saas	EU AI Act, NIS2, DORA, Data Act, DSA, GDPR	7 eu-* commands
fr-public	SecNumCloud, ANSSI, EBIOS, PSSI, marché public, RGPD	12 fr-* commands
at-bund	DSGVO, NISG, BVergG	3 at-* commands
de-bund	BSI / IT-Grundschutz / C5 catalogue	(no de-* commands yet — recipe pioneers them)
au-fed	DTA standards, IRAP, Essential Eight	(no au-* commands yet)
ca-fed	TBS directives, ITSG-33, PIPEDA	(no ca-* commands yet)
sg-gov	IMDA standards, GovTech patterns	(no sg-* commands yet)
ch-finma	FINMA, Swiss data residency	(no ch-* commands yet)

These aren't exclusive. If your jurisdiction isn't on the list, that's not a no.

How to claim and contribute

Option 1 — Just send a PR

The simplest path. Copy uk-saas.yaml to .arckit/recipes/{your-jurisdiction}.yaml in your project, edit, run /arckit:build {project} --recipe {your-jurisdiction} --plan to confirm the wave plan looks right, then /arckit:build {project} --recipe {your-jurisdiction} for real on a representative project. Once you're happy with the artefacts it produces, send the YAML in as a PR adding it under arckit-claude/skills/arckit-build/recipes/.

Option 2 — Discuss first

Comment on this issue with the jurisdiction you're claiming and a sketch (regulatory anchors, ~8 ADR topics you'd seed, which community-overlay commands you'd include). We'll discuss before you write the YAML.

Recognition

• Recipe lands with the contributor's name in commit history and description: field
• Significant recipes establishing a new jurisdiction overlay get article-history credit at arckit.org (the way uae-federal-ai was credited at v4.13.1)
• New jurisdictional command prefixes (e.g. de-*, au-*) follow the existing community-overlay pattern — contributor becomes the domain co-maintainer

References

• Full article: https://arckit.org/article-viewer.html?a=2026-05-03-community-recipes-wanted
• Build harness guide: https://arckit.org/guides/build.md
• SKILL.md: arckit-claude/skills/arckit-build/SKILL.md
• Three reference recipes: arckit-claude/skills/arckit-build/recipes/
• Build harness launch: https://arckit.org/article-viewer.html?a=2026-05-03-build-harness-parallel-architecture-generation

[royster70]

Community Recipe Submission: au-fed — Australian Federal Government

Jurisdiction

Australian Federal Government — digital services, defence industry suppliers, and critical infrastructure operators under Commonwealth regulatory frameworks.

Regulatory Anchors

Framework	Authority	Scope	Notes
ASD Essential Eight	Australian Signals Directorate (ASD)	Mandatory cyber security baseline for all federal entities and DISP members	8 mitigation strategies assessed at 4 maturity levels (ML0–ML3); ML2 is the current minimum for Defence suppliers
ASD Information Security Manual (ISM)	Australian Signals Directorate	Comprehensive security controls manual (~1,000+ controls by classification level)	The ISM is what NCSC CAF is to UK — the authoritative control set. E8 is a subset/prioritisation
DTA Digital Service Standard	Digital Transformation Agency (DTA)	13-criteria assessment for all new/redesigned AU Government digital services	Equivalent to UK GDS Service Standard; refreshed July 2025
Privacy Act 1988 (Cth)	Office of the Australian Information Commissioner (OAIC)	13 Australian Privacy Principles (APPs) governing all personal information handling	Tranche 1 reform (Dec 2024) introduced private right of action + enhanced enforcement; Tranche 2 in progress
DISP	Department of Defence	Defence Industry Security Program — security accreditation for defence supply chain	Mandates E8 ML2 (effective 2025); ~120-question cyber questionnaire; Level 1/2/3 membership tiers
PSPF	Attorney-General's Department	Protective Security Policy Framework — governance, personnel, physical, and information security	Defines the AU classification system (UNOFFICIAL → TOP SECRET) and handling requirements
Commonwealth Procurement Rules	Department of Finance	Mandatory procurement framework for all Commonwealth entities	November 2025 overhaul: threshold AUD 125K, SME mandates, ethical conduct in value-for-money, AI transparency clauses
DTA AI Assurance Framework	Digital Transformation Agency	Responsible AI principles + AI Impact Assessment Tool for government use of AI/ML	Published 2025; lightweight compared to UK AI Playbook but mandatory for federal procurement involving AI
PGPA Act (s16)	Department of Finance	Commonwealth Risk Management Policy — risk governance framework for federal entities	Equivalent to HMT Orange Book; mandates entity-level risk management under Public Governance, Performance and Accountability Act 2013
IRAP	Australian Signals Directorate	Infosec Registered Assessors Program — security assessment of cloud services for government use	AU equivalent of FedRAMP (US) or NCSC cloud principles (UK); cloud services assessed at classification levels

Energy Sector Extension (au-energy — separate recipe, future PR)

Framework	Authority	Scope	Notes
AESCSF	Australian Energy Market Operator (AEMO)	Australian Energy Sector Cyber Security Framework — capability-based maturity assessment (MIL1/2/3)	Builds on E8 baseline with energy-specific OT/SCADA controls; published controls per maturity level
SOCI Act 2018	Department of Home Affairs	Security of Critical Infrastructure — mandatory for declared critical assets in 11 sectors	72hr incident reporting, Critical Infrastructure Risk Management Program (CIRMP), positive security obligations
AER Ring-Fencing	Australian Energy Regulator	Constrains shared services, data access, and infrastructure between regulated network and contestable operations	Directly impacts SaaS architecture and shared-platform decisions for energy network businesses
NER / NGR	Australian Energy Market Commission (AEMC)	National Electricity Rules / National Gas Rules — market and operational obligations	AEMO is the market/system operator; compliance obligations flow to participants

Proposed ADR Topics (~8 for au-fed)

ADR	Topic	AU-Specific Framing
001	Cloud platform	IRAP-assessed providers only; AU regions (ap-southeast-2, australiaeast, australia-southeast1); data sovereignty at PROTECTED classification
002	Identity & access	myGovID / Digital ID Act 2024 / AGDIS for citizen identity; Entra ID for workforce; separation of workforce vs citizen identity domains
003	Data sovereignty & classification	AU classification scheme (UNOFFICIAL → TOP SECRET); PROTECTED hosting requirements; data residency obligations under Privacy Act APP 8
004	AI / LLM provider & enterprise AI	DTA AI Policy v2.0; sovereign AI options; M365 Copilot federal guidance; ISO 42001; on-premise vs cloud AI trade-off
005	Logging & observability	ASD ISM logging requirements; PSPF incident reporting obligations; SOC integration; audit trail retention per classification
006	Deployment topology	AU regions with multi-AZ DR; SOCI Act implications for critical infrastructure; network segmentation per PSPF zones
007	Build vs buy	AusTender / Commonwealth Procurement Rules (Nov 2025 revision); SME mandates; value-for-money assessment; ethical conduct requirements
008	Open-source licence policy	DTA open source guidance; Commonwealth IP management; OSS licence compatibility

Planned Community-Overlay Commands (au-* prefix)

Phase 1 (built and validated):

• au-e8-posture — ASD Essential Eight ML0–ML3 maturity posture assessment (8 strategies × gap/remediation)
• au-dss — DTA Digital Service Standard (13 criteria) compliance assessment
• au-pia — Privacy Impact Assessment under Privacy Act 1988 s33D (13 APPs + Mermaid information flow diagram)

Phase 2 (planned):

• au-ism-controls — ISM control applicability statement by data classification level
• au-pgpa-risk — Risk register under Commonwealth Risk Management Policy (PGPA Act s16)
• au-dip — Digital Investment Plan (DTA spending controls; replaces HMT Green Book SOBC)
• au-ai-assurance — DTA AI Assurance Framework + AI Impact Assessment Tool

Phase 3 (au-energy recipe — separate PR):

• au-aescsf — AESCSF MIL1/2/3 capability domain assessment (includes OT/IT convergence)
• au-energy-compliance — NER/NGR obligations, SOCI Act critical asset provisions, AER ring-fencing

Validation Status

Phase 1 commands (au-e8-posture, au-dss, au-pia) have been tested against a real AU advisory engagement:

• Test subject: Australian SMB professional services firm (private sector; federal and state government clients); pure cloud estate; MSP-managed M365; DISP accreditation in progress; mixed SaaS portfolio; handles OFFICIAL:Sensitive content
• Method: Clean-slate evaluation — discovery inputs only (engagement proposal, pre-discovery checklist, strategic context brief, interview transcripts); no pre-built ArcKit artifacts
• Result: 20/20 on evaluation scorecard (content quality, AU-vs-UK differentiation, cross-reference integrity, professional judgment alignment)
• Key quality signals: zero UK framework leakage across ~1,500 lines of output; correct AU classification system; E8 controls correctly reframed for pure-SaaS shared-responsibility model; PIA correctly identifies cross-border APP 8 obligations for NZ/EU-headquartered SaaS vendors

Recipe Design Notes

• Mirrors uk-saas.yaml structure (same wave pattern, same core commands)
• Swaps: arckit:tcop → arckit:au-dss; arckit:secure → arckit:au-e8-posture; arckit:dpia → arckit:au-pia
• Adds AU_VENDOR_RESEARCH optional target — searches for vendor-specific E8 guidance (AWS Audit Manager E8 framework, Microsoft Compliance Manager E8 premium templates, IRAP PROTECTED assessment packs)
• Drops GOV_REUSE (no AU equivalent of govreposcrape) and SVCASS (AU service standard process differs)
• au-energy recipe (future) extends au-fed with AESCSF + SOCI Act + AER ring-fencing targets

Questions for Maintainer

1. Naming preference: Issue table shows au-fed — should the recipe file be au-fed.yaml or au-gov.yaml? (I have it as au-gov.yaml currently but happy to rename)
2. Command bundling: Should the 3 Phase 1 community commands (au-e8-posture.md, au-dss.md, au-pia.md) + templates be submitted in the same PR as the recipe YAML, or as a separate PR?
3. au-energy as separate recipe: The energy-sector extension (AESCSF + SOCI + AER ring-fencing) builds on au-fed — is a separate recipe YAML the right pattern, or should it be optional targets within au-fed?

Happy to submit the PR directly if the approach looks right, or iterate based on feedback.

[tractorjuice]

Thanks @royster70 — the au-fed proposal is excellent. Splitting into dedicated tracking issues so this thread stays open for other jurisdictions:

• au-fed recipe + Phase 1 commands (au-e8-posture, au-dss, au-pia) #439 — au-fed recipe + Phase 1 commands (au-e8-posture, au-dss, au-pia). Maintainer answers to your three questions are in the issue body.
• au-energy recipe (AESCSF + SOCI Act + AER ring-fencing) #440 — au-energy recipe (AESCSF + SOCI Act + AER ring-fencing) — held for after au-fed recipe + Phase 1 commands (au-e8-posture, au-dss, au-pia) #439 lands.

Please continue the discussion on #439.

[royster70]

Thanks for the clear direction @tractorjuice. Locking in the plan below and one question before I get onto opening the PR.

PR 1 — au-federal (this issue, #424)

Single bundle PR (matching UAE / Canada precedent). Everything ships together.

Recipe: arckit-claude/skills/arckit-build/recipes/au-federal.yaml

8 community commands (all validated end-to-end against a real AU SMB engagement working with Federal Clients):

• au-e8-posture — ASD Essential Eight ML0–ML3 maturity
• au-pia — Privacy Act 1988 s33D PIA (13 APPs)
• au-dss — DTA Digital Service Standard (13 criteria)
• au-ism-controls — ASD ISM applicability statement (17 control domains)
• au-ndb-playbook — Notifiable Data Breach response playbook
• au-disp-attestation — DISP Member self-attestation pack (Levels 1–3)
• au-pspf — Protective Security Policy Framework (4 outcomes / 16 CRs)
• au-ai-assurance — DTA AI Assurance Framework + Responsible AI Policy v2.0

Recipe swaps from uk-saas.yaml baseline (per your guidance):

arckit:tcop    → arckit:au-dss
arckit:secure  → arckit:au-e8-posture
arckit:dpia    → arckit:au-pia
Drops: GOV_REUSE, SVCASS
Adds:  AU_VENDOR_RESEARCH (AusTender + Digital Marketplace research support)

Regulatory anchors named in the PR description: Essential Eight · ISM · Privacy Act 1988 · DTA Digital Service Standard · IRAP · PSPF · Commonwealth Procurement Rules (Nov 2025 overhaul) · DTA AI Assurance Framework + Responsible AI Policy v2.0 · PGPA Act s16 · Notifiable Data Breach scheme.

8 ADR topics seeded: cloud (IRAP + ap-southeast-2) · identity (myGovID/AGDIS vs Entra) · data classification (UNOFFICIAL→TOP SECRET) · AI/LLM (DTA AI Policy v2.0) · logging (ISM-aligned) · deployment (SOCI/PSPF zones) · build vs buy (AusTender + Digital Marketplace) · OSS policy.

Acceptance criteria covered: recipe YAML at the canonical path · 8 community commands in arckit-claude/commands/ following fr-* / eu-* / at-* / uae-* / ca-* pattern · templates in arckit-claude/templates/ and .arckit/templates/ · python scripts/converter.py run to generate Codex / OpenCode / Gemini / Copilot variants · README.md + docs/index.html + docs/DEPENDENCY-MATRIX.md + CHANGELOG.md updated · community classification + @royster70 as domain co-maintainer.

Validation evidence: 9 evaluation runs, 8 ArcKit artefacts (~4,093 lines of compliance documentation), 25/25 evaluation scorecard pass at Run 3, 0 UK framework leakage, 220 AU framework references. Test fixture compatible with arckit-test-project-v44.

PR 2 — au-energy (follow-on, issue #440)

Held until au-federal lands. Drafted and ready to ship after — not in scope of this PR.

Recipe: au-energy.yaml — composes on top of au-federal

2 community commands:

• au-aescsf — AESCSF capability assessment (11 domains × MIL-1/2/3 + OT overlay + anti-patterns)
• au-soci-cirmp — SOCI Act CIRMP (4 hazard categories + 12hr/72hr reporting)

Both built and mechanically clean (0 UK leakage, YAML frontmatter present, handoffs declared) but not yet validated end-to-end — the federal test fixture is an advisory firm, not an energy market participant or SOCI-designated critical-asset operator. Will note in the #440 PR that validation against an appropriate sector test fixture is required before merge — open invitation for community collaboration on the validation work.

AER ring-fencing captured as ADR seed in au-energy.yaml; will be considered for a future discrete command after the recipe lands and a DNSP test fixture is available.

One outstanding question before I open the PR

Schema validation approach — do you want me to run the YAML schema check from #424 locally before opening the PR, or is the schema check part of CI on the PR? Either works; just want to know whether to ship the YAML pre-validated or expect CI feedback to iterate.

Will raise the PR once you confirm. Estimated turnaround: will work through it this week and submit.

/cc @tractorjuice

[johnfelipe]

@tractorjuice can u guide me witch will be Colombian jurisdiction, i want to contribute with that

[tractorjuice]

Welcome @johnfelipe — Colombian jurisdiction is absolutely in scope. The recruiting issue isn't an exclusive list; the most-wanted column just reflects which slots have existing community-overlay commands ready to compose.

Suggested slot name

co-federal (matches ca-federal-fitaa / uae-federal-ai precedent) — or co-gov if you'd prefer.

Likely regulatory anchors to consider

These are starting points — you're the domain expert, override anything that's not how it actually works in Colombia:

• Ley 1581 (2012) + Decreto 1377 (2013) — habeas data / personal data protection (GDPR-adjacent, SIC enforcement)
• Política de Gobierno Digital (Decreto 1078, Capítulo 1, Título 9 — MinTIC) — digital government policy and standards
• CONPES 3995 — National Digital Security Policy
• CONPES 3854 / 3920 — depending on whether your bundle leans cyber or data
• Modelo Integrado de Planeación y Gestión (MIPG) — risk and management framework, equivalent to UK Orange Book
• Colombia Compra Eficiente — public procurement (SECOP II platform)
• Marco de Referencia de Arquitectura Empresarial del Estado — MinTIC enterprise architecture reference framework

If your work touches AI: there's an emerging Colombian AI ethics framework worth referencing.

What good looks like for the recipe

The bar is in #424's body — same for every jurisdiction. Concretely:

1. Pick anchor regulations that an architect actually has to satisfy on a real Colombian government project
2. Sketch ~8 ADR topics that reflect cloud / identity / data / AI / procurement choices specific to Colombia (data residency under SIC, IPv6/IPv4 mandates from MinTIC, etc.)
3. List which existing ArcKit commands fit — most do regardless of jurisdiction (requirements, principles, risk, adr, hld, dld, etc.)
4. Identify community-overlay commands you'd want to add. There are no co-* commands yet, so you'd be pioneering them — see how fr-* (12), at-* (3), ca-* (12), uae-* (12) are structured under arckit-claude/commands/

Two paths

Mirroring the options in the issue body:

• Option A: Comment back here with a sketch (anchors + ~8 ADRs + which co-* commands you'd start with) and we'll discuss before you write code
• Option B: Open a draft PR with arckit-claude/skills/arckit-build/recipes/co-federal.yaml and any pioneering co-* commands; iterate from there

If you go with Option A, I'll spin up a co-federal tracking issue (like #439 for au-federal) so the discussion has a dedicated home and #424 stays focused on recruitment.

What's the use case driving your contribution — public sector platform you're working on, advisory engagement, or general open-source contribution? That helps tune the recipe scope.

[royster70]

PR raised → #441.

Schema validation: passes locally — your verbatim snippet from this issue returns ok against the recipe.

Wave plan: 35 targets across 9 build waves + 2 post-build hooks (max parallelism 11 in W2). Computed via topological sort matching the algorithm in arckit-claude/skills/arckit-build/SKILL.md § "Wave plan algorithm". Full wave plan inline in the PR description.

Scorecard: published as docs/au-federal-validation-scorecard.md per your explicit request — Layer A (SKILL.md content quality) and Layer B (recipe wave-plan validity), with mechanical-grep commands reviewers can run to sanity-check the headline numbers.

Test fixture: arckit-test-project-v44-australian-gov (full name; the arckit-test-project-v44 shorthand here expanded — found via the README test-repo table).

Acceptance criteria: all checked. python scripts/converter.py ran (Codex/OpenCode/Gemini/Copilot/Paperclip variants generated for the 8 new commands); doc-types and pages.md allow-list dual-registered for the 8 new type codes; README, CHANGELOG, arckit-build/SKILL.md recipes table, single overlay guide all updated.

One transparency note in the PR description: the converter run incidentally synchronised pre-existing variant drift on arckit-pages (7 files). Drift is not introduced by this PR — happy to split into a separate housekeeping commit if you prefer.

au-energy sector overlay (#440) remains held until this lands and a sector test fixture is identified.

Ready for review when convenient.