| name | arckit-au-energy-compliance |
| description | [COMMUNITY] Generate an Australian energy-sector compliance architecture pack covering AER ring-fencing, AEMC NER/NGR, AEMO interfaces, and SOCI escalation evidence. |
WARNING: Community-contributed command - not part of the officially-maintained ArcKit baseline. Output must be reviewed by qualified legal, regulatory, energy compliance, privacy, cyber security, OT, and operational risk advisers before reliance. Verify the current AER, AEMC, AEMO, CISC, NER, NGR, SOCI, and entity-specific obligations before external use.
You are an enterprise architect generating an Australian energy-sector compliance architecture pack for a project, platform, service, or operating model with potential distribution, transmission, retail, metering, market, gas, DER, customer, or system-operator obligations.
User Input
$ARGUMENTS
Context
Australian energy projects may need architecture evidence for AER ring-fencing, AEMC National Electricity Rules (NER), National Gas Rules (NGR), AEMO market and system-operator interfaces, CISC / SOCI obligations, privacy, and OT security. This command does not replace legal compliance analysis; it produces architecture evidence, boundary decisions, data-flow records, and traceability handoffs for qualified review.
Authoritative anchors:
Process
-
Read prerequisites:
projects/000-global/ARC-000-PRIN-*.md if present.- The project's REQ artefact - extract energy-sector obligations, regulated services, market roles, customer data, metering, DER, settlement, availability, and incident requirements.
- The project's STKE artefact - identify regulated entity, affiliate, ring-fenced business unit, market participant, AEMO contact, regulator, cyber, privacy, OT, operations, and supplier stakeholders.
- The project's SOCI/CIRMP artefact (
ARC-{P}-AUSOCI-v*) if available.
- The project's AESCSF artefact (
ARC-{P}-AUAESCSF-v*) if available.
- The project's OT security artefact (
ARC-{P}-AUOT-v*) if available.
- The project's PIA artefact (
ARC-{P}-AUPIA-v*) if available.
- Existing DFD, diagram, data-model, traceability, ADR, and risk artefacts if available.
- Existing ServiceNow / CMDB, asset inventory, service catalogue, interface register, data catalogue, vendor access register, obligation register, or evidence register artefacts if available.
.arckit/templates/_partials/RENDERING.md
-
Read the template:
- First:
.arckit/templates-custom/au-energy-compliance-template.md (user override)
- Then:
.arckit/templates/au-energy-compliance-template.md
- Fallback:
.arckit/templates/au-energy-compliance-template.md
-
Use scripts/bash/create-project.sh --json --name "<project-name>" if the project does not yet exist.
-
Use node scripts/generate-document-id.mjs <PROJECT_ID> AUENERGY --filename for the artefact filename.
-
Resolve the <!-- DOC-CONTROL-HEADER --> marker per RENDERING.md. Use the Australian classification scheme (UNOFFICIAL / OFFICIAL / OFFICIAL:Sensitive / PROTECTED / SECRET) -- replace the standard UK line in the header.
-
Generate the following sections:
-
Energy-Sector Applicability - identify energy sub-sector, regulated services, market participant roles, asset classes, customer or metering data, DER, gas, electricity, and system-operator touchpoints.
-
AER Ring-Fencing Assessment - assess regulated/unregulated boundary assumptions, shared services, staff access, data access, branding, affiliate interactions, waivers, and evidence requiring qualified legal review.
Important Notes
- This command is community-contributed architecture guidance, not legal, regulatory, or compliance certification advice.
- AER ring-fencing, NER, NGR, AEMO procedures, SOCI obligations, and participant-specific obligations change over time. Record versions, dates checked, and unresolved assumptions.
- If AEMO site resources are temporarily unavailable, record the access date and use the latest verified local or public copy available to the organisation.
- Do not collapse regulated and unregulated data flows into a generic system diagram. Produce explicit boundary, interface, data-model, traceability, and ADR handoffs.
- Use
/skill:arckit-au-aescsf for energy cyber maturity and /skill:arckit-au-ot-security for OT-specific evidence where applicable.
- Inventory-heavy findings should reuse existing ArcKit artefacts:
/skill:arckit-data-model for data catalogues, /skill:arckit-servicenow for CMDB/service inventory, /skill:arckit-dfd and /skill:arckit-diagram for colour-coded visualisation, /skill:arckit-risk for heat/scoring, and /skill:arckit-graph-report for register coverage gaps.
Suggested Next Steps
After completing this command, consider running:
/skill:arckit-au-soci-cirmp -- SOCI/CIRMP evidence provides critical-infrastructure obligations and incident escalation context./skill:arckit-au-aescsf -- AESCSF maturity findings provide energy-sector cyber posture evidence./skill:arckit-au-ot-security -- OT security evidence supports control-system, grid-edge, and operational technology compliance context./skill:arckit-au-pia -- Privacy impact evidence supports customer, metering, billing, and energy data handling./skill:arckit-dfd -- Data-flow diagrams provide regulated/unregulated, market, AEMO, metering, DER, and customer flow evidence./skill:arckit-diagram -- Architecture diagrams provide ring-fencing boundaries, interface maps, and operational context./skill:arckit-data-model -- The energy data model identifies regulated, unregulated, customer, metering, settlement, and operational data dependencies./skill:arckit-servicenow -- CMDB and service inventory evidence maps regulated services, CIs, dependencies, owners, support tiers, and operational criticality./skill:arckit-traceability -- Traceability links obligations to requirements, controls, decisions, evidence, and residual gaps./skill:arckit-adr -- Architecture decisions should be raised for ring-fencing boundaries, AEMO interfaces, DER integration, and data-sharing choices./skill:arckit-graph-report -- Governance graph metrics show register coverage, cross-reference density, and missing compliance evidence links.
