From 862d3300eee6f60e66fc9738bb7b952d2c48a56c Mon Sep 17 00:00:00 2001 From: Yvonne Yao Date: Sun, 30 Aug 2026 11:45:23 +1000 Subject: [PATCH] docs: add AI infrastructure procurement readiness --- README.md | 6 +- docs/architecture/README.md | 4 +- .../ai-factory-gpu-workload-readiness.md | 36 ++++++++++- docs/architecture/architecture-library.md | 7 ++- docs/architecture/architecture.md | 12 ++-- .../ai-workload-operating-contract.md | 63 ++++++++++++++++++- docs/practices/current-status.md | 6 ++ docs/solutions/featured-solutions.md | 4 +- 8 files changed, 124 insertions(+), 14 deletions(-) diff --git a/README.md b/README.md index a7e4fef..a99fbcb 100644 --- a/README.md +++ b/README.md @@ -112,7 +112,11 @@ not a deployed GPU runtime. The AgentCore sandbox does not claim a production or autonomous agent platform. The [AI Workload Operating Contract](docs/practices/ai-workload-operating-contract.md) defines this as a future/design practice track within the portfolio: it does -not add a scheduler, GPU cluster, or cloud runtime by default. +not add a scheduler, GPU cluster, or cloud runtime by default. It now also +records applicability-led energy, water, land-use, location, supplier, and +external-requirement evidence so future capacity decisions can respond to +current procurement signals and planned infrastructure standards without +claiming that those standards are already in force. ## Run Locally in Mock Mode diff --git a/docs/architecture/README.md b/docs/architecture/README.md index ef098b7..d9fa7e4 100644 --- a/docs/architecture/README.md +++ b/docs/architecture/README.md @@ -16,7 +16,9 @@ provider boundaries, and future capacity design. future capacity and accelerator context. - [AI Factory, GPU, and AI Data-Centre Workload Readiness](ai-factory-gpu-workload-readiness.md) — workload profiles, accelerator placement, GPU observability, FinOps, - resilience, and safe future-sandbox gates; no GPU deployment. + resilience, supplier evidence, and applicability-led energy, water, + land-use, location, and regulatory-readiness gates; no GPU or data-centre + deployment. - [AI Factory Workload Placement Comparison](ai-factory-workload-placement-comparison.md) — design-only routing criteria and correlation-first evidence chain for Kubernetes, queue governance, managed training, future HPC, and managed diff --git a/docs/architecture/ai-factory-gpu-workload-readiness.md b/docs/architecture/ai-factory-gpu-workload-readiness.md index 454d32c..933fb16 100644 --- a/docs/architecture/ai-factory-gpu-workload-readiness.md +++ b/docs/architecture/ai-factory-gpu-workload-readiness.md @@ -157,6 +157,35 @@ AI data-centre readiness review should treat power, cooling, fibre, storage, accelerator supply, and compliance as external dependencies of the compute platform. +### National infrastructure and facility readiness + +On 26 August 2026, Australia's National Cabinet agreed that large data centres +have material energy, water, and land-use impacts. It also agreed to develop +nationally consistent mandatory standards in these areas, with Commonwealth +legislation intended for early 2027. This is a confirmed policy and regulatory +direction, not a statement that the future legislation, thresholds, or detailed +standards are already in force. See the [official National Cabinet communique](https://www.pm.gov.au/media/meeting-national-cabinet-26-august-26). + +The platform should therefore make facility and location evidence an explicit +input when a workload depends on large dedicated or supplier-operated capacity. +Managed-model consumption and small cloud sandboxes should first record whether +this gate is applicable; they must not inherit facility-level requirements by +assumption. + +| Readiness concern | Minimum assessment evidence | Decision supported | +| --- | --- | --- | +| Applicability and jurisdiction | Capacity type, site/operator, location, scale threshold when published, and accountable assessor | Apply the correct current requirement without treating a future proposal as enacted law. | +| Energy and grid impact | Power source and capacity, expected peak/base demand, demand flexibility, efficiency measure, expansion assumption, and grid-constraint evidence | Approve, condition, relocate, defer, or right-size the capacity plan. | +| Water and cooling | Cooling design, water source and intensity where available, local scarcity, heat-rejection trade-off, and degraded-mode plan | Identify water, thermal, resilience, and energy trade-offs before site or supplier commitment. | +| Land and location | Planning status, land-use impact, fibre and grid proximity, natural-hazard exposure, sovereignty/data-residency need, and community dependency | Select a location whose operational and approval boundaries are understood. | +| Sustainability and reporting | Named owner, measurement method, evidence period, supplier assumptions, and review cadence | Keep energy, water, emissions, and utilisation claims attributable and reviewable. | +| Regulatory readiness | Current obligations, announced or planned requirements, evidence owner, last review date, and change trigger | Distinguish enforceable controls from watch items and update the architecture when requirements mature. | + +The assessment is fail-closed for a material facility or dedicated-capacity +commitment when applicability, ownership, or required evidence is unknown. A +missing future metric whose definition has not yet been published is recorded +as a watch item rather than invented locally. + ## Observability model GPU telemetry must connect hardware health to workload outcomes. A dashboard @@ -249,6 +278,8 @@ The readiness gate must verify more than capacity: | Operations | No telemetry, alert owner, SLO, or incident path | | Recovery | No checkpoint, retry, rollback, pause, or teardown plan | | Governance | No human approval for high-risk data, training, or customer impact | +| Facility and location | Material dedicated capacity has no applicability decision, accountable assessor, or required energy, water, land-use, and location evidence | +| Supplier | A material external dependency has no named owner, evidence basis, lifecycle boundary, or reassessment trigger | Preemption is a design choice, not an outage. Batch and training workloads should be checkpointable and restartable. Interactive inference should have a @@ -266,7 +297,8 @@ boundaries. | FinOps | AI FinOps principles and bounded cost metadata | Create a synthetic GPU-hour/queue/cost allocation example | | Scheduling | Conceptual placement and queue boundaries plus a Kueue source contract | Compare Kubernetes scheduler, Kueue, and managed task governance | | Accelerated runtime | Source implementation is not a deployed GPU runtime | Review one small, time-boxed sandbox only after budget and teardown approval | -| Data-centre readiness | AI Factory infrastructure lens and public research | Add power, cooling, storage, fabric, sovereignty, and capacity checklist | +| Data-centre readiness | National infrastructure direction translated into an applicability-led energy, water, land-use, location, and regulatory-readiness contract | Add evidence fixtures only after detailed standards or a bounded supplier assessment provides stable fields | +| Supplier readiness | Workload contract defines security, governance, risk, compliance, operational, sustainability, and exit evidence | Create a synthetic supplier assessment without representing program participation or external assurance | ## Explicit non-goals @@ -287,3 +319,5 @@ boundaries. - [HyperPod usage reporting for cost attribution](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-usage-reporting.html) - [NVIDIA DCGM Exporter installation](https://docs.nvidia.com/datacenter/dcgm/latest/installation/install-dcgm-exporter.html) - [NVIDIA DCGM Exporter metrics](https://docs.nvidia.com/datacenter/dcgm/latest/reference/dcgm-exporter-metrics.html) +- [National Cabinet communique, 26 August 2026](https://www.pm.gov.au/media/meeting-national-cabinet-26-august-26) +- [National AI Centre: Buy Australian AI Partnership Program](https://www.ai.gov.au/buy-australian-ai-partnership-program) diff --git a/docs/architecture/architecture-library.md b/docs/architecture/architecture-library.md index 3a18ca5..ac2df2d 100644 --- a/docs/architecture/architecture-library.md +++ b/docs/architecture/architecture-library.md @@ -117,13 +117,16 @@ implementation record and deferred scope. training, fine-tuning, or high-scale serving implementation. - [AI Factory/GPU workload readiness](./ai-factory-gpu-workload-readiness.md) — profile-specific admission, placement, scheduling, observability, FinOps, - resilience, and data-centre readiness; design-only, with no GPU deployment. + resilience, supplier evidence, and applicability-led energy, water, + land-use, location, and regulatory readiness; design-only, with no GPU or + data-centre deployment. - [AI Factory workload placement comparison](./ai-factory-workload-placement-comparison.md) — design-only routing matrix for interactive, batch, fine-tuning, distributed, and managed-inference workloads; no GPU deployment. - [AI Workload Operating Contract](../practices/ai-workload-operating-contract.md) — documentation-first, vendor-neutral workload readiness model for service, - batch, fine-tuning, and future distributed-training profiles. + batch, fine-tuning, and future distributed-training profiles, including + supplier/procurement evidence and external-requirement status control. ## Demonstration and Portfolio Navigation diff --git a/docs/architecture/architecture.md b/docs/architecture/architecture.md index e5dcb33..54a8c48 100644 --- a/docs/architecture/architecture.md +++ b/docs/architecture/architecture.md @@ -22,7 +22,7 @@ flowchart TB policy["Governance, Responsible AI,
and data policy"] subgraph platform["Shared CloudAI Platform"] - foundations["Secure cloud
foundations"] + foundations["Secure cloud and
infrastructure foundations"] access["Governed model, agent,
and data access"] delivery["Delivery and
operations controls"] capacity["Optional AI Factory
and capacity extension"] @@ -57,7 +57,7 @@ deployment diagram. | Governance | What is allowed, what risk applies, and what evidence is required? | | Data and knowledge | Which information may be used, retained, retrieved, or shared? | | AI platform | How do workloads access shared models, agents, tools, and knowledge safely? | -| Cloud foundations | Under what identity, network, encryption, policy, and runtime boundary does it operate? | +| Cloud and infrastructure foundations | Under what identity, network, encryption, policy, runtime, capacity, location, and resource boundary does it operate? | | Delivery and operations | How is it released, evaluated, observed, cost-managed, supported, and retired? | ## 3. CloudAI Platform Reference Architecture @@ -78,7 +78,7 @@ flowchart TB integration["7. Application and
enterprise-system integration"] delivery["8. Infrastructure as code, CI/CD,
testing, release, and rollback"] operations["9. Evaluation, observability,
audit evidence, and AI FinOps"] - lifecycle["10. Resilience, capacity, support,
retirement, and improvement"] + lifecycle["10. Resilience, capacity, location,
sustainability, support, retirement,
and improvement"] intake --> risk --> data --> foundation --> model --> traffic --> integration integration --> delivery --> operations --> lifecycle @@ -96,8 +96,8 @@ flowchart TB | Governance | 2. Governance, risk, Responsible AI, and approval | | Data and knowledge | 3. Data, knowledge, classification, and lifecycle | | AI platform | 5. Governed model and provider access; 6. Agent, tool, retrieval, workflow, and egress governance; 7. Application and enterprise-system integration | -| Cloud foundations | 4. Identity, network, encryption, secrets, and policy | -| Delivery and operations | 8. Delivery engineering; 9. Evaluation, observability, audit evidence, and AI FinOps; 10. Resilience, capacity, support, retirement, and improvement | +| Cloud and infrastructure foundations | 4. Identity, network, encryption, secrets, and policy; applicable location and physical-resource boundaries | +| Delivery and operations | 8. Delivery engineering; 9. Evaluation, observability, audit evidence, and AI FinOps; 10. Resilience, capacity, location, sustainability, support, retirement, and improvement | The six layers and the ten domains are complementary. The former describes the enterprise capability model; the latter describes the CloudAI platform @@ -162,7 +162,7 @@ is intentionally bounded and should be read with its stated evidence boundary. | Private EKS target | [Private EKS reference architecture](./private-eks-reference-architecture.md) and [protected delivery runbook](../solutions/eks-private-sandbox-runbook.md): one network state supplies reviewed inputs to separate runner and EKS states through a protected CI path; runtime worker/bootstrap validation is pending. | | Bounded provider access | [P8 Bedrock sandbox design](../solutions/p8-real-bedrock-sandbox-design.md) and the [Bounded Bedrock Sandbox case study](../solutions/featured-solutions.md#bounded-bedrock-sandbox): bounded synthetic sandbox validation, not a persistent Bedrock application. | | Agent runtime extension | [AgentCore Governed RAG POC](./agentcore-governed-rag-poc.md) and [P8i data foundation](../solutions/p8i-agentcore-rag-data-foundation.md): deployed synthetic AWS sandbox with protected ingestion, direct Bedrock preflight, and Gateway end-to-end evidence; no production claim. | -| AI Factory and accelerated capacity | [AI Factory infrastructure lens](./ai-factory-infrastructure-lens.md), [AI Workload Operating Contract](../practices/ai-workload-operating-contract.md), and [GPU workload readiness](./ai-factory-gpu-workload-readiness.md): design context for LLMOps, workload profiles, placement, scheduling, capacity, observability, FinOps, and accelerator patterns; no GPU, training, fine-tuning, or high-scale serving implementation. | +| AI Factory and accelerated capacity | [AI Factory infrastructure lens](./ai-factory-infrastructure-lens.md), [AI Workload Operating Contract](../practices/ai-workload-operating-contract.md), and [GPU workload readiness](./ai-factory-gpu-workload-readiness.md): design context for LLMOps, workload profiles, placement, scheduling, capacity, location, sustainability, supplier evidence, observability, FinOps, and accelerator patterns; no GPU, training, fine-tuning, high-scale serving, or data-centre implementation. | | Multi-cloud mappings | [AWS](./aws-reference-architecture.md), [Azure](./azure-reference-architecture.md), and [GCP](./gcp-reference-architecture.md) mappings: AWS-first implementation context with Azure/GCP reference mappings, not provider parity claims. | ## 6. Current Implementation and Evidence Status diff --git a/docs/practices/ai-workload-operating-contract.md b/docs/practices/ai-workload-operating-contract.md index 18502b8..ef76845 100644 --- a/docs/practices/ai-workload-operating-contract.md +++ b/docs/practices/ai-workload-operating-contract.md @@ -17,12 +17,73 @@ Every workload should declare the following before it is eligible to proceed. | Identity and accountability | Workload ID, class, purpose, owner, environment, workload identity, escalation contact, and shutdown owner. | | Access and data | Approved model, capability, tool scope, data classification, allowed data sources, and egress boundary. | | Supply chain | Approved image, model, framework, dependency provenance, lifecycle state, and required evaluation evidence. | +| External dependency and supplier | Applicability decision plus supplier owner, service boundary, evidence basis, assurance date, material subcontractors, reassessment trigger, portability, and exit path when an external dependency is material. | | Capacity and cost | Required capacity, quota, budget boundary, allocation dimensions, and stop condition. | +| Location and sustainability | Applicability decision plus required energy, water, land-use, location, and reporting evidence for material dedicated or supplier-operated capacity. | | Approval and delivery | Human approval requirement, release gate, change owner, and rollback path. | | Operation and evidence | Telemetry requirements, trace/evidence IDs, policy verdicts, health signals, and retention boundary. | | Closure | Pause, rollback, retirement, cleanup, output retention, and owner confirmation. | -Missing owner, identity, approval, required evidence, or profile-specific readiness is fail-closed: the workload is not eligible to proceed. Telemetry/export failure is recorded as an operating gap and must not create a false healthy decision. +Missing owner, identity, approval, required evidence, supplier-applicability +decision, or profile-specific readiness is fail-closed: the workload is not eligible to +proceed. Telemetry/export failure is recorded as an operating gap and must not +create a false healthy decision. Location and sustainability fields are +required only after an explicit applicability decision; a small sandbox must +not claim large-facility assurance, and a material dedicated-capacity decision +must not bypass it. + +## Supplier and Procurement Readiness + +The National AI Centre's Buy Australian AI Partnership Program is a current +public signal that AI suppliers seeking large-organisation opportunities need +evidence across security, governance, risk, compliance, procurement, and +commercial readiness. The program is not a certification, regulation, or proof +that a supplier satisfies this contract. Its first cohort focuses on financial +services, runs from October to November 2026, and closes expressions of interest +on 24 September 2026. See the [official program page](https://www.ai.gov.au/buy-australian-ai-partnership-program). + +A platform or workload owner should evaluate a material supplier through one +evidence record rather than distribute the decision across disconnected +questionnaires. + +| Evidence family | Minimum questions | Example evidence | +| --- | --- | --- | +| Security and privacy | Which identities, data, networks, administrators, subprocessors, and incident paths are in scope? | Architecture boundary, access model, encryption statement, incident process, recent assurance report. | +| AI governance | Who owns intended use, model/tool changes, evaluation, human oversight, and prohibited use? | Responsible-AI policy, model/service card, evaluation summary, change and escalation process. | +| Risk and compliance | Which obligations and risk classifications apply, and how are exceptions accepted and reviewed? | Control mapping, risk register, legal/compliance review, exception owner and expiry. | +| Data, model, and tool lifecycle | Where are inputs, outputs, embeddings, logs, models, and tool calls stored, retained, reused, and deleted? | Data-flow record, retention/deletion evidence, lineage, residency statement, tool-access contract. | +| Operations and resilience | How are availability, capacity, observability, support, incident response, recovery, and dependency concentration managed? | SLO/SLA, support model, continuity test, status history, telemetry and escalation evidence. | +| Sustainability and location | Does the service depend on material dedicated capacity, and what energy, water, land-use, location, and reporting evidence is available? | Applicability decision, site/operator evidence, measurement method, reporting period, regulatory review. | +| Commercial lifecycle and exit | How are usage, cost, licensing, portability, termination, data return/deletion, and replacement handled? | Pricing boundary, usage report, exit plan, export format, deletion confirmation requirement. | + +The assessment records one of three outcomes: + +- **eligible** — required evidence is current, owned, and accepted; +- **conditional** — a named owner has accepted bounded gaps with an expiry and + compensating control; +- **not eligible** — a material evidence or control gap remains unresolved. + +Each outcome records scope, assessor, approver, evidence date, next-review date, +and the workload or platform decision it authorises. Marketing claims or an +application to an external program are not substitutes for evidence. + +## Requirement Status and Change Control + +Every external requirement in an architecture or supplier assessment should +carry a status so that the platform neither ignores a credible direction nor +claims that future obligations already apply. + +| Status | Meaning | Permitted use | +| --- | --- | --- | +| Current requirement | An applicable law, contract, policy, or approved internal control is in force. | Enforce it and retain the required evidence. | +| Announced policy direction | A responsible authority has announced an intended direction without final operative detail. | Assess readiness, assign an owner, and avoid claiming legal compliance. | +| Planned legislation or standard | Legislation or a standard is intended but not yet enacted or final. | Track scope and likely evidence fields; do not invent thresholds. | +| Watch item | A program, market signal, proposal, or practice may influence later decisions. | Monitor with a review date; do not treat it as mandatory. | + +As at 30 August 2026, the nationally consistent large-data-centre standards +described by National Cabinet are a planned regulatory direction with +Commonwealth legislation intended for early 2027. They are not recorded here +as enacted detailed standards. See the [official National Cabinet communique](https://www.pm.gov.au/media/meeting-national-cabinet-26-august-26). ## Service Inference diff --git a/docs/practices/current-status.md b/docs/practices/current-status.md index 6d69a63..bf72be8 100644 --- a/docs/practices/current-status.md +++ b/docs/practices/current-status.md @@ -63,6 +63,11 @@ The repository can now demonstrate: evaluation is not implemented. `local-contract` remains the only validated evidence; future `provider-direct` and `provider-runtime` evidence are not provider, runtime, or production validation. +- **AI infrastructure and supplier readiness:** design-only operating-contract + extension for supplier evidence plus applicability-led energy, water, + land-use, location, sustainability, and external-requirement status. It does + not claim enacted future standards, supplier assurance, program + participation, or a deployed data centre. - **P5a AI-Assisted DevSecOps Boundary:** advisory AI use, human review, CI/security checks, and release evidence - **P5b AI-Assisted Review Evidence:** review summaries, threat-model checklists, CI failure summaries, and release-note drafts - **P6f AI Platform Security and Operations Controls:** identity, data protection, AI AppSec, delivery, operations, and FinOps @@ -124,6 +129,7 @@ It currently has six mock-first lanes: | P8i AgentCore synthetic contract pack | Complete local synthetic contract evidence; provider-neutral pack remains separate from the live AWS validation | `shared/schemas/agentcore-readiness/`, `shared/examples/agentcore-readiness/`, `providers/aws/app/api/tests/agentcoreReadinessContracts.test.ts`, and `docs/solutions/p8i-agentcore-synthetic-contract-pack.md` | | AgentCore governed RAG POC | Synthetic data foundation, arm64 Runtime, IAM Gateway/Runtime target, direct Bedrock preflight, Gateway end-to-end evidence, and bounded CloudWatch observability complete through protected CI; teardown remains separately gated | `providers/aws/app/agentcore-rag-runtime/`, `providers/aws/agentcore/`, `.github/workflows/terraform-agentcore-rag-sandbox.yml`, `providers/aws/infra/bootstrap/github-oidc-terraform-backend.yaml`, `docs/solutions/p8i-agentcore-rag-data-foundation.md`, `docs/solutions/p8i-agentcore-rag-key-process-record.md`, and `docs/solutions/agentcore-governed-rag-poc-runbook.md` | | Framework-neutral agent evaluation telemetry | Stage A source implemented; provider validation pending. The protected lane is manual, synthetic-only, evaluate-only, and bounded to six calls. Stage B Runtime-to-CloudWatch evaluation is not implemented. | `shared/schemas/agent-evaluation-telemetry/`, `shared/examples/agent-evaluation-telemetry/`, `providers/aws/app/api/src/evals/agentEvaluationTelemetryNormalizer.ts`, `providers/aws/app/api/src/evals/agentEvaluationTelemetryGate.ts`, `providers/aws/app/api/src/evals/agentCoreEvaluationProviderGate.ts`, `.github/workflows/agentcore-evaluation-provider-parity.yml`, and `docs/solutions/agent-evaluation-telemetry-runbook.md` | +| AI infrastructure and supplier readiness | Design-only contract extension; no data-centre deployment, regulatory compliance, supplier assurance, or program participation claimed | `docs/architecture/ai-factory-gpu-workload-readiness.md` and `docs/practices/ai-workload-operating-contract.md` | | P5a AI-assisted DevSecOps boundary | Complete | `docs/practices/ai-assisted-devsecops-pattern.md` and `.github/workflows/ai-assisted-devsecops.yml` | | P5b AI-assisted review evidence | Complete | `docs/evidence/ai-assisted-review-evidence.md`, `shared/schemas/ai-assisted-devsecops/`, and `shared/examples/ai-assisted-devsecops/` | | P6d control-plane evidence map | Complete | `docs/evidence/control-plane-evidence-map.md`, `shared/schemas/control-plane-evidence/`, and `shared/examples/control-plane-evidence/` | diff --git a/docs/solutions/featured-solutions.md b/docs/solutions/featured-solutions.md index 9a1f4a2..d186c3e 100644 --- a/docs/solutions/featured-solutions.md +++ b/docs/solutions/featured-solutions.md @@ -50,11 +50,11 @@ It is not a production gateway, persistent audit service, enterprise model catal ### Scope -The [AI Workload Operating Contract](../practices/ai-workload-operating-contract.md) defines a shared operating model for service inference, batch processing, fine-tuning, and future distributed training. It makes ownership, identity, access, capacity, cost, approval, evidence, and shutdown expectations explicit. +The [AI Workload Operating Contract](../practices/ai-workload-operating-contract.md) defines a shared operating model for service inference, batch processing, fine-tuning, and future distributed training. It makes ownership, identity, access, capacity, cost, approval, supplier evidence, applicable infrastructure sustainability/location evidence, and shutdown expectations explicit. ### What this demonstrates -How the existing CloudAI control-plane patterns can extend into a vendor-neutral AI Factory practice track without changing the portfolio's mock-first operating boundary. +How the existing CloudAI control-plane patterns can extend into a vendor-neutral AI Factory practice track while distinguishing current requirements, announced policy directions, planned standards, and watch items without changing the portfolio's mock-first operating boundary. ### What it does not claim