Site icon Digital Thought Disruption

Green Hardware Does Not Mean a Ready AI Platform: Commissioning VCF Private AI Services

Paul Bryant

TL;DR

A rack of healthy GPU servers is not a production-ready VCF Private AI platform. Production acceptance should prove the complete service chain: supported hardware, aligned ESXi and NVIDIA software, a healthy VCF 9.1 workload domain, stable NSX and shared infrastructure services, a ready Supervisor and VKS layer, functioning tenant controls, trusted Harbor and model supply paths, deployable Private AI Services, a working NVIDIA NIM endpoint, persistent model behavior, complete telemetry, enforceable quotas, and tested recovery.

The commissioning decision should distinguish three states:

Do not approve production tenants until the service-ready gate has evidence, an owner, and a remediation plan for every failed control.

Introduction

AI infrastructure projects often reach an awkward point where every dashboard looks green, the GPUs appear in inventory, and the delivery team is under pressure to declare success. The servers are powered, ESXi is installed, the workload domain exists, and perhaps a test VM can run nvidia-smi. That is meaningful progress, but it is not the same as a commissioned AI service.

VCF Private AI Services sits above a long dependency chain. The service depends on physical hardware, firmware, drivers, vGPU software, VCF workload-domain health, NSX, DNS, NTP, certificates, identity, Supervisor services, Kubernetes, registries, model repositories, storage, scheduling, telemetry, and tenant policy. A defect in any layer can produce a platform that looks installed but fails when the first production tenant requests a model endpoint.

Broadcom’s VCF 9.1 and VMware Private AI Foundation with NVIDIA documentation describes the platform as an integrated path for AI workloads across Deep Learning VMs, VKS clusters, Private AI Services, Harbor-backed model storage, and NVIDIA acceleration [1]-[7]. NVIDIA’s current vGPU, GPU Operator, DCGM, and NIM guidance adds another set of compatibility and runtime dependencies that must be validated as a single bill of materials rather than as independent products [10]-[14].

This article provides an end-to-end commissioning framework for architecture teams, platform engineering teams, VCF administrators, network and storage teams, MLOps engineers, and operational acceptance authorities. The objective is simple: prove the complete path from physical GPU hardware to a governed, observable, recoverable model endpoint.

Commissioning Starts by Defining the Acceptance States

The most important design decision is not which test command to run. It is what the organization means by ready.

Readiness stateWhat it provesWhat it does not proveMinimum decision authority
Installation completeSoftware and infrastructure components were deployed without an unresolved installer failureTenant usability, service behavior, governance, scale, recovery, or supportabilityBuild lead
Platform availableCore administrators can configure organizations, projects, namespaces, infrastructure mappings, registries, and supported AI consumption pathsA production tenant can deploy and operate a model service under realistic policy and failure conditionsPlatform owner and architecture lead
Service readyAn authorized tenant can deploy or consume the approved model endpoint, telemetry is complete, quotas work, dependencies recover, and evidence is acceptedFuture capacity, every model, every failure scenario, or every application integrationService owner, operations, security, architecture, and business acceptance authority

This separation prevents a common delivery failure: treating the completion of an installation workflow as proof that the delivered service is safe to advertise to tenants.

A production commissioning plan should also declare its test boundary. At minimum, record the exact VCF 9.1 build, ESXi build, vCenter and NSX versions, server model, BIOS and firmware bundle, GPU model, NVIDIA vGPU branch, guest driver branch, Deep Learning VM image version, VKS and Kubernetes versions, GPU Operator version, Private AI Services version, NIM or model-runtime version, Harbor version, and storage classes used. Version-sensitive claims must be checked against the current Broadcom Compatibility Guide, Broadcom release notes, and NVIDIA support matrices before the test window [2], [3], [10], [11], [21].

The Complete Commissioning Path

The platform should be tested as a chain, not as a collection of product consoles. The diagram below shows the dependency order and the evidence handoff between layers.

The architecture team should notice two things. First, every upper layer inherits the failure modes of the layers below it. Second, the final acceptance test must start from the tenant boundary. An administrator proving that a component exists is not equivalent to a tenant proving that the service works with least-privilege access.

Validate the Physical GPU Platform Before VCF Commissioning

Server Firmware and BIOS Must Match the Certified Configuration

Begin with the exact server configuration, not merely the server model. The Broadcom Compatibility Guide records certified server, device, BIOS, firmware, driver, and accelerator combinations. An approved chassis with an unapproved firmware bundle is not the same tested configuration [21].

Validate and capture evidence for:

Do not accept screenshots showing only that the GPU is present. Capture inventory exports and compare every component to the approved bill of materials. Run sustained GPU, network, memory, and storage burn-in tests long enough to reveal thermal throttling, PCIe instability, packet errors, path failover defects, or media faults.

Green Health LEDs Are Necessary but Insufficient

A server can pass a basic hardware health check while still failing under AI load. AI commissioning should include concurrent stress because GPU workloads can expose power, cooling, NUMA, PCIe, and storage problems that ordinary VM workloads do not.

A useful test combines:

The pass condition is not simply “the test completed.” The architecture team should define acceptable error counts, thermal headroom, clock stability, packet loss, storage latency, and recovery behavior before testing begins.

Align ESXi, NVIDIA vGPU Manager, Guest Drivers, and Licensing

NVIDIA vGPU is a software compatibility chain. The ESXi version, vGPU Manager branch, GPU model, vGPU profile, guest operating system, guest driver, and NVIDIA licensing method must be mutually supported. NVIDIA explicitly documents compatible and incompatible vGPU Manager and guest driver combinations, and an incompatible guest driver can prevent the vGPU from initializing [10], [11].

Commissioning should verify:

Use an explicit compatibility record rather than relying on installer defaults. The evidence should include host VIB or component versions, guest driver versions, the selected profile, nvidia-smi output, licensing state, and links to the governing support matrices in the acceptance repository.

The following commands are useful evidence collectors. Object names and permissions will vary by environment.

# ESXi host: confirm installed NVIDIA software components.
esxcli software vib list | grep -i nvidia

# Guest or GPU-enabled worker node: confirm device, driver, memory, and license state.
nvidia-smi

# Kubernetes: confirm GPU labels and allocatable resources.
kubectl get nodes -L nvidia.com/gpu.present
kubectl get node <gpu-worker> -o jsonpath='{.status.allocatable.nvidia\.com/gpu}'

# Confirm NVIDIA and telemetry workloads are running.
kubectl get pods -A | grep -E 'nvidia|gpu-operator|dcgm'

Successful execution should show the approved software branch, the expected GPU or vGPU profile, and the planned allocatable resource count. A zero value, missing label, unlicensed state, or node-to-node difference is a commissioning failure until explained and remediated.

Prove the VCF 9.1 Workload Domain Is Operationally Healthy

The GPU workload domain must be healthy as a VCF domain before it is accepted as an AI platform. VCF Operations diagnostics is designed to surface known issues and the operational state of private cloud infrastructure, while VCF Operations also provides monitoring, capacity, alerting, and integration capabilities [3], [19].

Validate the following domain-level conditions:

Do not suppress alarms to make a commissioning report green. Every suppressed alert needs a documented risk decision, expiry date, owner, and support position.

Validate NSX, DNS, NTP, Certificates, and Identity as One Dependency Set

Private AI deployments depend heavily on infrastructure services that are often tested independently. Commissioning should test them through the AI request path.

NSX Networking Must Support Every Control and Data Flow

Validate management, workload, registry, storage, model-download, telemetry, and tenant application paths. This includes:

A simple ping is not enough. Test the actual protocols, TLS handshakes, image layers, model artifacts, health probes, and API request sizes that the production service will use.

DNS, NTP, and Certificates Are Commissioning Controls

The Broadcom community thread supplied with this assignment describes a VCF 9.1 deployment that completed only after an NTP problem was corrected [18]. That thread is a community signal, not authoritative support guidance, but it illustrates the larger point: time synchronization is a platform dependency, not a housekeeping item.

Validate:

Inject controlled defects. Use an invalid DNS record in a test namespace, block an NTP source, present an untrusted registry certificate, and expire a non-production token. The platform should fail visibly, generate actionable telemetry, and recover through a documented procedure.

Commission Supervisor and VKS Before Installing AI Services

vSphere Supervisor provides the integrated control plane used to expose infrastructure through Kubernetes APIs, while VKS provides the Kubernetes consumption path for containerized AI workloads [9], [17]. A Supervisor that reports healthy but lacks usable VM classes, storage classes, namespace permissions, or routable workload networks is not ready for AI.

Validate:

The first acceptance cluster should be created using the same self-service or automation path that production tenants will use. A one-off cluster built by an administrator with elevated credentials can conceal missing policies and permissions.

Validate NVIDIA GPU Operator and Device Discovery

The NVIDIA GPU Operator automates deployment of the components required to expose NVIDIA GPUs to Kubernetes, including drivers where appropriate, the container toolkit, the Kubernetes device plugin, GPU feature discovery, validation, and DCGM-based telemetry [12]. Broadcom’s Private AI documentation also identifies the GPU Operator as a dependency for GPU-accelerated VKS clusters [4], [17].

Commissioning should verify more than pod status:

Capture node labels, allocatable resources, operator custom resources, pod logs, validator results, and the exact Helm or operator values used. Treat drift between GPU nodes as a failed control.

Establish Organizations, Projects, Namespaces, and Tenant Permissions

VCF Automation organizations and projects provide the administrative and logical boundaries used to group users and infrastructure. vSphere Namespaces add resource quotas and user permissions at the Supervisor layer [8], [9]. Private AI Services in VCF 9.1 can be activated and managed within organization namespaces, which makes the mapping between these layers part of the production security model [22].

Define and test the hierarchy explicitly:

This is an operating-model mapping, not a claim that each layer is automatically created or enforced by the layer above it. The commissioning team must verify the actual integrations, assignments, and policy boundaries used in its VCF design.

The commissioning test should prove:

A role matrix should be part of the acceptance evidence. Test both allowed and denied actions. Security is not proven by a successful administrator workflow alone.

Validate Harbor, Image Pulls, and Model Downloads

Broadcom documents Harbor as the local private OCI registry used for Private AI Services components and as a central model store that can distribute validated models across Deep Learning VMs, Kubernetes clusters, and Private AI Services workloads [5]-[7]. That makes Harbor part of the runtime supply chain, not just an installation convenience.

Commission Harbor across four dimensions.

Availability and Trust

Validate high availability where required, TLS trust, DNS, load balancing, storage capacity, backup, restore, replication, garbage collection, retention, and upgrade ownership. Confirm that failure of one registry component does not leave production endpoints dependent on an undocumented manual recovery.

Authorization and Governance

Test project isolation, robot accounts, token expiry, least-privilege pull and push permissions, artifact immutability, scanning policy, signature or provenance policy where implemented, and audit logging. A model-store administrator should not automatically become a tenant endpoint administrator.

Image-Pull Behavior

Perform cold pulls from every production consumption path. A cached image on one worker node does not prove registry availability. Test pulls from a newly created VKS node, a newly deployed Deep Learning VM, and the Private AI Services runtime path.

Model-Download Behavior

Test the approved connected or disconnected workflow. In connected environments, validate egress controls, NGC credentials, gated-model credentials, download duration, retry behavior, and checksum or provenance validation. In disconnected environments, validate artifact mirroring, local availability, version pinning, and the process for promoting new artifacts into the trusted registry. Private AI Services 2.1 includes an artifact mirroring capability intended to support disconnected operations, but the local operational workflow still needs commissioning evidence [22].

Prove Private AI Services Deployment Dependencies

Private AI Services should not be installed until its prerequisite services have passed their own gates. The deployment plan should identify at least:

After installation, validate the service APIs, user interface, CLI where used, internal controllers, health probes, logs, metrics, and dependency references. Confirm that a service restart, namespace reconciliation, or node replacement returns the system to the declared desired state.

The Private AI Services installer finishing is only the installation-complete gate. Platform availability requires tenant-scoped activation and successful service use. Service readiness requires a governed model endpoint and operational evidence.

Exercise Both Deep Learning VM and Kubernetes Consumption Paths

VMware Private AI Foundation with NVIDIA supports multiple AI consumption models. Broadcom documents Deep Learning VMs for GPU-enabled virtual-machine workflows and VKS clusters for GPU-accelerated Kubernetes workloads [1], [4], [17]. These paths serve different operating models and should be commissioned separately.

Deep Learning VM Path

Validate:

Kubernetes Path

Validate:

Do not treat success on one path as evidence for the other. A Deep Learning VM can succeed while Kubernetes image pulls, device discovery, storage classes, or quotas remain broken.

Deploy and Validate a Governed NVIDIA NIM Endpoint

NVIDIA NIM packages optimized inference runtimes as containerized microservices with standard APIs. On Kubernetes, the NVIDIA NIM Operator can manage deployment, scaling, health probes, GPU scheduling, and persistent model caching through resources such as NIMService and NIMCache [14]. Within VCF Private AI Services, the Model Runtime path can expose governed model endpoints from approved model content stored in Harbor [5], [7].

The architecture team should choose and document the production service boundary rather than mixing the two models accidentally:

The production commissioning test should deploy one representative NIM endpoint using the exact tenant workflow. Validate:

A minimal endpoint validation can use environment variables so the article does not hard-code a site-specific address or secret.

# Confirm that the endpoint is reachable and exposes the expected model metadata.
curl -fsS -H "Authorization: Bearer $NIM_TOKEN" \
  "$NIM_ENDPOINT/v1/models"

# Submit a representative completion request stored in an approved test payload.
curl -fsS -H "Authorization: Bearer $NIM_TOKEN" \
  -H "Content-Type: application/json" \
  --data @commissioning-request.json \
  "$NIM_ENDPOINT/v1/completions"

The pass condition should include status code, schema validation, expected model identity, response quality checks, latency, telemetry correlation, and audit evidence. A single successful curl response is not a complete service acceptance test.

Validate Persistent Storage and Model-Cache Behavior

Model endpoints often appear healthy after a warm start because images and model artifacts are already cached. Commissioning must prove the cold path and the recovery path.

NVIDIA’s NIM Operator documentation describes persistent model caching through NIMCache so artifacts can be populated once and reused across pod restarts and scaling events [14]. The broader NIM runtime also supports configurable cache locations. Regardless of implementation, the architecture team must know where model artifacts live, who owns the storage, how access is controlled, and what happens when a pod moves.

Test at least these scenarios:

Record download duration, cache population time, endpoint readiness time, storage throughput, capacity consumed, failure messages, and recovery steps. The service-level objective should distinguish warm restart, cold restart, and complete artifact rehydration.

Prove DCGM and Infrastructure Telemetry End to End

DCGM Exporter exposes NVIDIA GPU metrics for Prometheus-compatible monitoring and can run as a daemonset on Kubernetes GPU nodes. The NVIDIA GPU Operator deploys DCGM Exporter by default unless it is disabled [12], [13]. Broadcom also documents Private AI Services metrics and DCGM-based monitoring for Deep Learning VMs [15], [16].

A production-ready monitoring design should correlate four views:

The commissioning test should deliberately create a measurable workload and prove that the same transaction can be traced from the tenant request to the endpoint, runtime, GPU, host, network, and storage. Alert routing should reach the correct on-call team, and the runbook should explain which team owns each layer.

Avoid exposing sensitive prompts, retrieved documents, model inputs, or secrets in logs and metric labels. Observability must improve diagnosis without becoming a data-loss path.

Validate Scheduler Behavior, Quotas, and Capacity Protection

A platform is not multi-tenant merely because multiple tenants can log in. Commissioning must prove that one tenant cannot consume the GPU pool, starve platform services, or bypass the intended placement model.

VCF Automation supports resource quota policies for users, projects, and organizations, while vSphere Namespaces support resource quotas and permissions [9], [20]. Kubernetes adds requests, limits, priorities, taints, tolerations, affinity, and quota controls. The final design should coordinate these layers rather than assuming one quota mechanism controls everything.

Test:

A useful negative test submits a workload that intentionally exceeds the tenant quota. The workload should remain unscheduled or be rejected with an actionable reason, while other tenants and platform services remain healthy.

# Inspect namespace quotas and current consumption.
kubectl get resourcequota -A
kubectl describe resourcequota -n <tenant-namespace>

# Inspect pending workloads and scheduler events.
kubectl get pods -A --field-selector=status.phase=Pending
kubectl describe pod <pending-pod> -n <tenant-namespace>

The pass condition is controlled refusal, not eventual success through an undocumented administrator override.

Use Failure Injection to Prove Recovery

Failure testing should be controlled, reversible, approved, and performed before production tenants arrive. The goal is not chaos for its own sake. It is to prove that the service fails predictably and that operational teams can restore it with evidence.

Recommended commissioning scenarios include:

Failure injectedExpected platform behaviorRequired evidence
One GPU worker node drained or powered offWorkload reschedules or remains unavailable according to the declared availability designScheduler events, endpoint state, recovery time, capacity impact
DCGM Exporter stoppedMonitoring alert fires without breaking inferenceAlert, missing-series detection, runbook execution
Harbor temporarily unavailableExisting warm endpoints continue if designed; new cold pulls fail clearlyEndpoint tests, pull errors, alert, recovery proof
Model-cache volume unavailableEndpoint fails or falls back according to design, without corrupting artifactsPod events, storage alarms, cache recovery results
DNS record incorrectDependency fails visibly and recovers after correctionDNS test, service events, recovery time
NTP source blockedDrift alert appears before token, certificate, or cluster behavior becomes unsafeTime metrics, alert, remediation log
Registry certificate untrustedPull is rejected rather than silently bypassing trustTLS error, audit event, corrected trust test
Tenant quota exhaustedAdditional workload is denied while existing services remain stableQuota status, scheduler event, tenant-facing message
NIM pod or runtime process terminatedController recreates workload and endpoint returns within objectiveRestart event, readiness timeline, request success
One NSX Edge or network path failsTraffic follows the approved availability behaviorRouting, load-balancer, flow, and endpoint evidence
Credential revokedAccess fails immediately or within documented token lifetimeAudit log, API response, token-expiry evidence

Every test needs a declared success criterion, maximum recovery time, rollback point, safety owner, and data-protection check. Failed tests are not reasons to hide evidence. They are inputs to remediation and retest.

Commissioning Scorecard

Use the following scorecard as the operational acceptance record. Replace the sample evidence descriptions with links or identifiers from the organization’s evidence repository.

Commissioning controlPass / FailEvidence requiredAccountable ownerRemediation if failed
Server model and component certificationPASS / FAILBroadcom Compatibility Guide record, OEM BOM, serial inventoryInfrastructure architectReplace unsupported component or move to certified configuration
BIOS and firmware baselinePASS / FAILExported firmware report, approved baseline comparisonHardware operationsApply approved OEM bundle and rerun burn-in
GPU health and PCIe placementPASS / FAILBMC health, PCIe width and speed, sustained GPU testHardware operationsCorrect slot, riser, power, cooling, or replace GPU
NIC and network firmwarePASS / FAILNIC inventory, firmware, switch-port and error countersNetwork engineeringAlign firmware, optics, MTU, switch configuration, or replace device
Storage certification and performancePASS / FAILHCL check, path test, latency and throughput resultsStorage engineeringCorrect firmware, policy, pathing, capacity, or media
ESXi lifecycle compliancePASS / FAILvLCM image and compliance reportVCF platform teamRemediate host image and rerun cluster compliance
NVIDIA vGPU Manager alignmentPASS / FAILHost component version and NVIDIA support-matrix recordVCF platform teamInstall approved branch and reboot or remediate hosts
Guest driver and licensingPASS / FAILnvidia-smi, guest driver, profile, license statusAI platform teamAlign guest image, driver branch, profile, or license service
VCF 9.1 workload-domain healthPASS / FAILVCF inventory, VCF Operations diagnostics, active-alert reviewVCF service ownerResolve alarms, drift, capacity, lifecycle, or integration defects
NSX routing and load balancingPASS / FAILFlow tests, route tables, load-balancer checks, failover resultNetwork engineeringCorrect segments, routes, firewall, MTU, pool, or edge capacity
DNS readinessPASS / FAILForward and reverse lookup matrix from each network zoneCore infrastructureCorrect records, forwarding, search domains, or resolver reachability
NTP readinessPASS / FAILSynchronization status, drift metrics, failure-injection resultCore infrastructureCorrect sources, firewall, hierarchy, or host configuration
Certificate trust and rotationPASS / FAILChain validation, SAN review, expiry report, rotation testPKI and securityReplace certificate, update trust store, or assign rotation workflow
Identity and role mappingPASS / FAILGroup-to-role matrix, allowed and denied action testsIAM and securityCorrect federation, groups, service accounts, or policy
Supervisor readinessPASS / FAILControl-plane health, network, VM class, storage class evidenceVCF platform teamCorrect Supervisor configuration or lifecycle state
VKS lifecycle readinessPASS / FAILCreate, scale, upgrade, replace-node, and delete testsKubernetes platform teamCorrect cluster class, image, networking, storage, or automation
GPU Operator healthPASS / FAILOperator resources, validator logs, node labels, allocatable GPUsKubernetes platform teamPin supported version, correct driver mode, or repair nodes
Organization and project governancePASS / FAILTenant hierarchy, project mappings, administrator scope testsCloud governanceCorrect organization, project, policy, or role design
Namespace permissions and quotasPASS / FAILResourceQuota output, allowed and denied tenant testsKubernetes and securityCorrect quota, permission, policy, or project mapping
Harbor availability and trustPASS / FAILHealth, TLS, project policy, backup and restore, failover testRegistry service ownerRepair HA, storage, certificate, access, or backup design
Image-pull validationPASS / FAILCold-pull logs from new DLVM, VKS node, and runtime pathAI platform teamCorrect credentials, trust, routing, mirrors, or artifact path
Model-download and provenancePASS / FAILDownload logs, checksum or signature evidence, promotion recordMLOps and securityRe-mirror, validate, pin version, or block untrusted model
Private AI Services deploymentPASS / FAILService health, controller state, logs, namespace activationAI platform teamRepair prerequisite, package, configuration, capacity, or service
Deep Learning VM consumption pathPASS / FAILTenant deployment, GPU, storage, telemetry, reboot and recoveryAI platform teamCorrect image, VM class, network, driver, storage, or policy
VKS AI workload pathPASS / FAILTenant cluster, CUDA workload, scheduling, persistence, recoveryKubernetes platform teamCorrect operator, resource, storage, network, or policy
NVIDIA NIM endpointPASS / FAILEndpoint deployment, API tests, model identity, latency, authMLOps service ownerCorrect model, image, cache, GPU, endpoint, or access configuration
Persistent storage and cachePASS / FAILCold start, restart, reschedule, capacity, restore resultsStorage and MLOpsCorrect storage class, access mode, capacity, affinity, or cache design
DCGM and infrastructure telemetryPASS / FAILDashboards, metrics, alerts, trace correlation, retentionObservability ownerRepair exporter, scrape, integration, labeling, or alert routing
Scheduler and quota protectionPASS / FAILPlacement, saturation, denial, priority, and maintenance testsPlatform architectureCorrect requests, quotas, priorities, reservations, or capacity
Failure recoveryPASS / FAILApproved injection records, recovery time, data-integrity checksService operationsRemediate design or runbook and repeat the failed scenario
Operational documentation and supportPASS / FAILRunbooks, RACI, escalation, vendor support data, known issuesService ownerComplete ownership, support, and lifecycle documentation
Final tenant acceptancePASS / FAILLeast-privilege tenant deploys and invokes governed endpointAcceptance authorityKeep service closed, remediate failed controls, and retest

A failed mandatory control should keep the service out of production. Conditional acceptance should be reserved for defects with documented compensating controls, a named risk owner, an expiry date, and an approved remediation window.

Evidence Required for Operational Acceptance

The commissioning package should be reproducible by someone who was not part of the build. At minimum, retain:

Evidence should be time-stamped, tied to the exact environment and versions, and stored in a controlled repository. Screenshots without context are weak evidence. Prefer exported configuration, command output, test records, logs, metrics, and signed acceptance decisions.

The Production Readiness Decision

The final go or no-go meeting should answer one question: can a production tenant safely obtain and operate the promised AI service through the intended governance model?

Approve the service only when:

If only the installers are complete, report installation complete. If administrators can create resources but tenants cannot yet consume a governed endpoint, report platform available. Use service ready only when the tenant-to-model path has been proven and accepted.

Conclusion

A green GPU server is an input to a private AI platform, not the finished service. VCF Private AI Services depends on an integrated chain of hardware, firmware, ESXi, NVIDIA software, VCF workload-domain services, NSX, shared infrastructure, Supervisor, VKS, tenant governance, registries, model artifacts, storage, scheduling, telemetry, and operations.

The architecture team’s job is to turn that chain into evidence. That means testing the supported bill of materials, validating every dependency through the production path, exercising both positive and negative tenant actions, deploying a representative NVIDIA NIM endpoint, measuring its behavior, and proving recovery when components fail.

The most useful commissioning outcome is not a polished green dashboard. It is a defensible acceptance record that clearly states what is installed, what is available, what is ready, who owns each layer, and what must happen when the platform stops behaving as designed.

External References

Exit mobile version