IPF-EF 2.4: supported TCPU temperature binding and namespace discovery errors

Start by reading the IPF-EF SDK R6 client API and the installed 2.4 properties-configuration schema described in the report. Reproduce the namespace-only GetProperties failure and the GetNode("Platform") /Core=null validation error using the reported normal-user setup, then trace their request and schema handling. Done means documenting a supported way to discover the TCPU binding and clarify the reported API errors; the payload names no source files or tests.

We are diagnosing Windows thermal shutdown events that name the zone "Intel(R) Innovation Platform Framework: TCPU". We need a supported read-only way to observe that exact zone or participant, its current temperature, units, and freshness while preserving the running work session and performance settings.

The modern published Intel IPF-EF SDK connects successfully to the installed framework. We built the unmodified static ClientApiLib from https://github.com/intel/ipf at commit 19ab9c30afe79565d007fdf5a2022210ccfdfdf0. Its R6 interface matches the installed signed ClientApiProxy version 2.4.10400.27. We use the existing installation and default provider isolation. These reads installed no new drivers or providers.

A normal-user client successfully completed four operations:

• GetSchema(DATA), Platform.SOC.Thermal
• GetNode, Platform.SOC.Thermal
• GetSchema(DATA), Platform.Features.DTT
• GetNode, Platform.Features.DTT

The SOC node returned PackageTemp=3662, TjMax=3732 and TCCOffset=2812. Its schema specifies decikelvin. Intel's published temperature representation, (raw-2732)/10, gives 93 C, 100 C and an 8 C offset respectively. DTT reported its software connection Online, version 9.1.10011.2963. The TCC offset has not been treated as a correction to the measured package temperature or as the Windows critical-shutdown threshold.

The missing qualification is whether Platform.SOC.Thermal.PackageTemp is sourced from the exact TCPU participant/domain used by the Windows shutdown zone. Its returned schema and node do not identify that binding. GetCapabilities(Platform.SOC.Thermal) advertises Public/Elevated roles and SamplingIntervalMin=1000 for PackageTemp, while Static is null. No measurement timestamp or participant identity was returned.

The following discovery attempts produced narrower failures after successful client creation:

1. IpfGetProperties with an empty configuration succeeds but returns module_properties for NamespaceMgr.dll version 2.4.10400.27.

2. The installed proxy's properties-configuration schema explicitly gives this example:
   {"properties_type":["namespace","catalog"]}
   Using that exact configuration fails with:
   [json.exception.type_error.302] type must be string, but is null

3. The same schema permits the namespace-only selection:
   {"properties_type":["namespace"]}
   It fails with the same JSON type_error.302 message.

4. A single IpfGetNode call for the known parent path "Platform", using a fixed 1 MiB buffer without a preliminary size query, resizing or retries, fails with:
   Failed to validate against JSON schema: data: At /Core of null - unexpected instance type
   This was an API error, not a buffer-too-small result. No parent-node data was returned.

All these attempts used a normal-user client. They returned or failed cleanly with explicit client cleanup. Windows boot time and the running IPF/DTT service PIDs were unchanged across the attempts. The successful narrow SOC/DTT reads establish a working modern client connection; the broader discovery failures remain unexplained. Further discovery attempts have stopped.

Could you please clarify:

1. Which supported read-only node, property or API exposes the named TCPU participant's actual current temperature and its binding to Platform.SOC.Thermal.PackageTemp? If they are equivalent, what version-specific contract establishes the identity?
2. What freshness or caching guarantees apply to these temperature getters, and is a measurement timestamp or validity/status indicator available?
3. Are the shown GetProperties configurations correct for this installed 2.4/R6 framework? Is an additional documented request envelope required, or is there a supported workaround for the namespace serialization errors?
4. Is GetNode("Platform") supported for enumerating readable child data in this version, and how should an application handle the /Core=null schema-validation failure while discovering available thermal nodes?

This report contains no hostnames, serial numbers, account details, raw device logs or private binaries. Additional sanitized request/response details can be supplied if needed.