Meter Data Export Manifest: Proving a Delivery Is Complete
A meter data export manifest is a controlled list of what a delivery should contain and what the recipient actually received. Use it to reconcile files, meter channels, time coverage, revisions and declared exceptions before accepting a batch. A valid checksum proves neither that every expected file arrived nor that every required reading was exported. Completeness needs a separately defined scope.
This guide concerns external collection and reporting systems used around industrial meters. It does not imply that a meter generates manifests or stores downloadable history. The useful outcome is a delivery record that lets a second person explain what is present, what is missing and what remains unresolved.
Define the delivery before counting files
Start with the business question: which measurement points and periods must be available for this delivery? A monthly energy report and a maintenance investigation can require different channels, resolutions and evidence. Write the scope before examining the received folder, otherwise the folder contents can quietly become the definition of success.
Give the delivery an identifier and name its producer, recipient and intended use. Record whether it is a first delivery, a correction or a supplement. Identify the authoritative point list and the version used to select the export. A large folder may still omit an entire panel if that panel never entered the export selection.
Use an unambiguous time convention. Record the requested start and end, whether the end is included, the relevant zone, and the relationship between an interval timestamp and its measurement window. State whether the manifest describes source readings, processed intervals or final report rows.
Keep integrity and completeness separate
The NIST glossary definition of a hash value describes a value produced by applying a hash function. For a delivery, comparing a received file with a trusted recorded digest can help detect changes. It does not independently establish who supplied the digest or whether the sender selected all the right files.
The W3C tabular data model also illustrates why a table and its descriptive metadata serve different purposes. A CSV payload needs context about its columns and interpretation. For an engineering delivery, the manifest adds a further project-specific layer: what was requested and how the payload relates to that request.
Keep the original payload and the original received manifest. If the producer corrects either, store a new revision and link it to the superseded delivery. Do not silently alter a manifest to match the folder after discovering an omission.
Use a manifest that supports a real decision
A manifest can be a controlled spreadsheet, a machine-readable file or an approved record in a document system. Choose a form that the recipient can validate and preserve. Its fields matter more than its visual complexity. Avoid confidential access details and unnecessary personal information.
| Manifest section | Minimum useful record | Recipient check |
|---|---|---|
| Delivery identity | Batch identifier, producer and revision | Matches the requested delivery and supersession chain |
| Selection scope | Approved point-list revision and filters | Every required asset and channel is represented |
| File inventory | Relative name, size and agreed digest | Files exist and match the recorded evidence |
| Time coverage | Requested and actual bounds with convention | Gaps and overlaps are identified explicitly |
| Interpretation | Contract revision, unit and quality-code context | Receiver can interpret the supplied values |
| Exceptions | Missing items, reason, owner and disposition | No unresolved item is silently accepted |
| Acceptance | Reviewer, decision and evidence reference | Decision can be reproduced later |
This is a project checklist, not a mandated industry file standard. Derive the actual required fields and acceptance limits from the receiving agreement, applicable obligations and measurement purpose.
Reconcile files without mistaking names for identity
Compare the expected inventory with the received inventory. Flag missing, unexpected and duplicate entries separately. Two files with similar names may cover different periods; two differently named files may contain identical bytes. Keep those situations distinct in the review record.
If a delivery is split into multiple parts, identify all parts and define when the batch is complete. A recipient should not accept part one as the whole delivery simply because it arrived without an error. Store the expected part count or another explicit completion signal in the agreed envelope.
Do not trust an archive’s filename as proof of its contents. Inspect its inventory in an appropriate controlled environment and compare its members with the manifest. Apply your organization’s security and handling procedures before opening unfamiliar material. This workflow does not require bypassing endpoint controls to finish an engineering review.
Reconcile coverage at the measurement level
A file count is only the first layer. Compare the supplied point identifiers with the approved point list. Then check the requested time coverage for each channel, accounting for documented outages, commissioning dates and deliberate exclusions. A valid file can contain an empty selection.
For regular interval data, derive the expected interval count from the agreed window and time convention. For an illustrative 24-hour fixed-offset window at 15-minute intervals, the expected number is 24 multiplied by 60 divided by 15, or 96 intervals per channel. This example assumes a full fixed-offset day, uninterrupted eligibility and one row per interval. Local civil days, daylight-saving transitions and other export layouts require their own calculation.
If a hypothetical batch covers ten eligible channels under those assumptions, the expected total is 960 interval records. Receiving 960 rows is still insufficient by itself: one channel could be duplicated while another is missing. Check the combination of channel and interval identity, not only the grand total.
Handle gaps as evidence, not cosmetic defects
Classify a missing file separately from missing readings within a file. Record whether the cause is selection, collection, communication, processing or delivery. If the cause is unknown, say so and assign an investigation owner instead of substituting a convenient explanation.
A zero reading is not a substitute for an unavailable reading. Likewise, an interpolated or estimated value should carry the agreed quality meaning rather than being presented as an original observation. The manifest should reference the applicable quality convention and summarize unresolved coverage, while detailed row-level evidence remains in the supporting record.
Where a gap is accepted for a restricted purpose, document that restriction. A dataset may support a maintenance trend while remaining unsuitable for a complete energy reconciliation. Acceptance should describe the permitted use, not give the whole folder an unrestricted pass.
A correction workflow that avoids double counting
Suppose a delivery omits one feeder for part of the requested period. The producer sends an additional file later. Identify whether the new file supplements the original batch or replaces an earlier file. Include explicit scope so the receiver knows which records should be added and which should be superseded.
Keep the original received files unchanged. Reconcile the correction against the same approved selection, then record the new accepted delivery state. Test how the receiving system handles overlapping intervals before importing the correction into a live reporting dataset.
For related controls, see the duplicate meter energy record guide and the export file integrity guide. The former addresses record identity and duplicate handling; the latter addresses preservation and byte comparison. Neither replaces a delivery-wide completeness decision.
Make the record usable during handover
Assign a reviewer who can access both the agreed scope and the delivered evidence. Record the review date, checks performed, exceptions and decision. A signature alone is insufficient when the scope and evidence cannot be found. Link to a controlled location rather than a temporary personal download folder.
Set ownership for unresolved items and a follow-up date. Avoid closing an exception merely because a supplier acknowledged an email. Close it when the missing evidence is delivered and checked, or when an authorized person accepts a documented limitation for a defined purpose.
Preserve the manifest alongside the relevant contract revision and point mapping. A later reviewer needs to know what the recipient expected at the time, even if the current system now has more meters or a different export structure. This is particularly useful when investigating a report that was produced before a configuration change.
Connect the delivery back to the installation
The BY194 multifunctional power instrument is the real product reference used for this article’s illustrations. Verify the installed variant and documented measurement options before building an external point list. A front-panel image does not establish built-in file storage, export or communication capabilities.
Use the three-phase electric power meter overview to establish the measurement context, then trace each delivered channel through the documented collection system. If a scaling or mapping problem exists upstream, a complete manifest can reveal which evidence was delivered but cannot make the readings correct.
The following Computerphile lesson explains hash functions as educational background. It helps distinguish a file fingerprint from a completeness or authenticity decision. It does not specify a product feature or replace the delivery agreement.
Frequently asked questions
Is a folder listing enough to serve as a manifest?
A folder listing can support the inventory, but it does not normally define the requested meter points, periods, interpretation or exceptions. Add the controlled scope and acceptance evidence needed to reconcile what was delivered with what was required.
Does a matching checksum mean an export is complete?
No. It supports comparison with the referenced file bytes when the recorded digest is trusted. A file can match perfectly while omitting an expected channel or time range. Check integrity and measurement coverage separately.
Should missing intervals be filled before delivery acceptance?
Follow the agreed data-quality and permitted-use rules. Preserve original readings and identify any derived replacements. Do not convert missing values to measured zeros or hide unresolved gaps merely to make a row count appear complete.
How should a corrected delivery be identified?
Give it a distinct revision and state whether it supplements or replaces earlier material. Record the affected points and periods, preserve the original evidence and validate overlap handling before applying the correction to operational reports.