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,<br/>and data policy"]
 
   subgraph platform["Shared CloudAI Platform"]
-    foundations["Secure cloud<br/>foundations"]
+    foundations["Secure cloud and<br/>infrastructure foundations"]
     access["Governed model, agent,<br/>and data access"]
     delivery["Delivery and<br/>operations controls"]
     capacity["Optional AI Factory<br/>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<br/>enterprise-system integration"]
   delivery["8. Infrastructure as code, CI/CD,<br/>testing, release, and rollback"]
   operations["9. Evaluation, observability,<br/>audit evidence, and AI FinOps"]
-  lifecycle["10. Resilience, capacity, support,<br/>retirement, and improvement"]
+  lifecycle["10. Resilience, capacity, location,<br/>sustainability, support, retirement,<br/>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