# Data-chain card

Template structure 0.1 · Wording edition 0.1.4 · Pingxin Wang / LFR · 1 October 2026

Use this card for one dataset version and one intended use. It is not a completeness score, a standard or an approval to operate equipment. Unknown answers are useful when they identify which comparison remains unsupported.

<div class="download-row"><a class="button" href="data-chain-card.md" download>Download editable Markdown</a><a class="button secondary" href="data-chain-card.json" download>Download JSON</a></div>

### A filled fragment: does this row mean every field is fresh?

Here, *fresh* means newly acquired, rather than copied from an earlier reading.

**Question.** Does an OpenCEM row timestamp mean every field was just updated?

**Answer — documented behavior.** No such guarantee follows from the documented polling rule: some register blocks rotate between polls, and unpolled fields keep their previous values.

**Basis.** OpenCEM v1.0.0, [Electrical snapshot acquisition](source-documents/opencem-acquisition.md), polling-cycle and persistent-output-dictionary paragraphs.

**What this supports.** Check for a field update before treating a repeated value as a new measurement.

**Still not confirmed.** Which fields were updated in a particular row, and the age of each retained reading. This fragment reads the documentation; it does not reconstruct a row.

**Next step.** Choose one field and one snapshot. Look for its update record or polling log. If unavailable, record its age as unknown.

## 1. Start with the question

- Dataset name, version and persistent identifier:
- System and rack, unit or cell identities:
- Question or comparison this card should support:
- Time range and operating conditions:
- What this use does not attempt to establish:

## 2. Record the status of each answer

Choose a status and cite its basis. Do not convert a blank or an unsuccessful search into “absent”.

| Status | Meaning |
|---|---|
| Documented | A named source explicitly describes this property; implementation has not necessarily been independently verified. |
| Observed in inspected material | An identified inspection found it within the stated scope; say exactly what was inspected. |
| Explicitly not recorded | A source or check establishes non-recording within a defined system and interval. |
| Explicitly not released | The source explicitly excludes it from this release; upstream existence remains unconfirmed unless separately documented. |
| Not confirmed | The evidence reviewed so far does not settle it. |
| Not applicable | The question does not apply to this use; give the reason. |

For each entry keep: **answer · status · source and locator · inspection scope · remaining limitation**.

## 3. Channel identity and clocks

- Channel, rack/unit/cell, physical location and wiring/topology mapping:
- Role: measured/converted quantity, estimate, request, limit, command, execution feedback or metadata:
- Units, sign, sensor range, resolution and calibration basis:
- Timestamp meaning and timezone; clock source and synchronization evidence:
- Physical-event time, acquisition time, communication time, storage time and release interval—known or unknown:
- Native cadence or trigger rule; field refresh/carry-forward behavior:
- Delay, missingness, error, zero, sentinel and any documented deadband rules:
- Filtering, aggregation, interpolation, trimming or other transformations:

Repeat this section by channel when the answers differ. A row timestamp must not silently become every channel's acquisition time.

## 4. Request, decision and execution

- External request and the boundary relative to which it is external:
- Limits and settings applicable at that time:
- Relevant mode, contactor, balancing or other event records, if available:
- Command issue time, acknowledgement and actual execution feedback:
- Known correspondence between these records; unresolved correspondence:

Unknown control records do not invalidate every description of current. They limit the explanations that require those records.

## 5. Estimates and accumulated quantities

- SOC or other estimate: producing system/model, update time, reference capacity and correction events where disclosed:
- Integration or accumulated-charge coordinate: sign rule, origin, intervals with readings used in the calculation, gap treatment and units:
- Alignment or summary: which racks, units or cells and intervals were included, with which weights or selection rule:
- Shared-source dependencies: which quantities were derived from the same records:

An estimate is not an independent measurement simply because it has a separate column. Charge passed over intervals with readings used in the calculation is not, by itself, remaining capacity.

## 6. Keep a history of how readings were taken

| Effective from / to | Rack/unit/cell or channel | Change | Source / evidence | Comparisons affected | What remains unresolved |
|---|---|---|---|---|---|
| | | | | | |

Include relevant sensor replacements, recalibration, firmware or filtering changes, logging policy, estimator changes, topology and identity changes. If effective time is unknown, record that rather than inventing a boundary. Preserve earlier versions of the card.

## 7. Close only the supported question

- What can this version support for the intended use?
- Which comparison is qualified or unavailable, and why?
- Which observation can continue despite the gap?
- What additional record, correction or changed condition would require reopening this reading?

Do not turn the card into an automatic fault, derating or shutdown rule. Existing protection and operational responsibilities remain outside this documentation template.


## Boundary

Documentary examples and a proposed documentation template. No new telemetry analysis, causal identification or control validation.

## Reuse licence

Original LFR research-note and data-chain-card content: CC BY 4.0. Third-party material, fonts, stylesheets and code are excluded; their own terms apply. [Scope and attribution](LICENSE-LFR-CONTENT.txt).