AI Factory coverage¶
The reference estate is assembled incrementally. The shipped ai-factory blueprint currently emits its CPU management substrate and sparse platform automation. GPU inventory is declarable but its compute cluster remains emit: false; declaring hardware does not establish a collection adapter or vendor telemetry profile.
Available building blocks¶
- Shared syslog mechanic: source-shaped decoded records and the real Alloy receiver-health surfaces. The library is not a raw network listener or parser. Receiver-health metrics do not imply that device logs are CLI-wired.
- GPU topology: PCIe, NVL72 and additive eight-GPU H100 SXM HGX inventory. The HGX switch/link map and qualified hardware limits are sourced; other product capabilities remain nullable where unconfirmed. Physical inventory alone does not establish DCGM or NVSwitch exporter support.
- GPU clock constraints: shared requested/achieved clocks and active synthetic thermal/power causes for the exact H100 SXM/595.91.07 profile. Unsupported profiles retain absent achieved clocks; this is not a vendor telemetry adapter.
- H100 HGX DCGM: pinned stock/DCP/fault profiles, shared clock constraints, allocation-safe pod labels and source-supported collection events. Other products remain unsupported.
- Gateway pools: an optional declared Alloy process pool with role-specific receiver, queue, peer, scrape and remote-configuration health. The pilot uses a two-member HA pool. Queues retain synthetic requests for the emitter lifetime, not an actual disk WAL; generic send failures do not uniquely identify expired credentials. Member-local remote-configuration data can be omitted while independent component health and the other member remain observable.
- Platform automation: low-frequency operational runs, with the real-world basis beside each rate. A short live window can legitimately contain no trace arrival; do not raise those rates to force readiness.
The gateway's health instruments are Prometheus Remote-Write metrics describing modeled intake and forwarding. Their presence is not proof of native OTLP metrics, OTLP logs or a real forwarded trace payload.
Source and implementation barriers¶
The following consumers are not enabled in this reference estate:
| Consumer | Barrier and resume boundary |
|---|---|
| DCGM | The narrowed H100 HGX consumer is available, but it is not enabled in the shipped reference estate. NVSwitch, Grace, MIG and other product profiles remain deferred. |
| GPU driver logs | Resume after the source-correct DCGM consumer lands; topology alone does not prove Xid/SXid/NVRM log projection. |
| GPU and Network Operator adapters | Resume after DCGM and the driver-log disposition, with actual GPU resource and pod-identity join evidence. Only that evidence can justify enabling compute-cluster collection. |
| Full GPU reference blueprint | Its remaining vendor consumers and compute collection adapters are not admitted. The current increment is not completion of the GPU reference estate. |
Unconfirmed NVSwitch exposition, Grace profiles and absolute HBM thermal limits remain explicit source barriers. No unsupported metric or hardware envelope is emitted to fill them.
Verification limits¶
Local public-loader/runner checks, source-inventory comparisons and integrated CI cover the shipped building blocks. A partial historical backend readback found the receiver-health metrics and CPU node/event data, but the deployment's configured OTLP lane had no attempt and global readiness was not green. A later final-candidate live run was blocked before startup by expired operator authentication. Neither is a full live verification of the current gateway estate; repeat the exact-source build and backend readback after restoring the authorized credential access.