The W3C tabular data model<\/a> provides a useful distinction between tabular values and metadata that helps describe or validate them. Use that distinction when specifying your own exchange. Document both how a value is written and what a receiving system is allowed to conclude from it.<\/p>\n For example, a column called energy could represent a cumulative register or interval consumption. Renaming it is less consequential than changing that meaning without a new contract. State the measurement boundary, direction and unit explicitly. Otherwise an importer may create a plausible chart from the wrong quantity.<\/p>\n Assign a stable identifier to the format and a controlled revision to its interpretation. Record where the receiving system obtains them: a companion metadata record, an agreed file envelope or an explicitly specified column. A filename alone is only suitable if the receiving workflow validates it and preserves the association throughout processing.<\/p>\n Do not infer a revision from the number of columns. Different revisions can have the same field count. Similarly, do not guess from a recent date in the filename. The date could indicate extraction time rather than the version under which the data was produced.<\/p>\n Keep the exporter software version separate from the exchange contract version. A software patch may leave the file unchanged; a configuration adjustment may change field meaning without updating the executable. The contract must describe the actual exchange, while a separate provenance record identifies what created it.<\/p>\n Create a short controlled document that a second engineer can use without asking the original author. For every field, record its stable name, meaning, type, allowed empty state and validation rule. Include examples that expose ambiguity rather than examples that only show the easiest case.<\/p>\n These are project design checks, not universal meter specifications. The syntax and metadata references above support the distinction; the actual allowed values come from your documented installation and receiving application.<\/p>\n An added optional field may be compatible with a receiver that selects known columns by name and deliberately ignores approved extras. It can break a receiver that expects an exact positional layout. Therefore optional does not automatically mean safe. Compatibility is a property of the documented producer and consumer pair.<\/p>\n Removing a required field, changing a unit, reversing the energy direction or altering an interval boundary normally requires explicit migration work. Treat a changed quality-code meaning with the same care as a changed numeric field. The number may remain identical while its permitted use changes.<\/p>\n Column reordering deserves its own test. If the contract promises name-based mapping, verify that the receiver honors that promise. If the exchange is positional, reject an unexpected sequence. Never rely on a person noticing that a spreadsheet heading has moved.<\/p>\n Keep one approved file for each supported revision and a separate set of intentionally rejected examples. Include quoted commas, a blank field, an unknown asset identifier, an unsupported quality code and a timestamp that exercises the chosen time convention. Label invented test readings as test data and keep them away from production ingestion.<\/p>\n For a unit change, choose a synthetic example whose wrong interpretation is unmistakable. Compare the expected interpreted quantity with the actual receiver output, not just the import-success message. A test that proves only that a file was accepted says nothing about whether its measurements were preserved.<\/p>\n Also test the transition boundary. A batch may contain files produced before and after the change. Decide whether both revisions can coexist, whether they use separate queues, and how corrected historic files are handled. Store the decision with the test evidence so that a later re-import does not rely on memory.<\/p>\n Suppose an external reporting service currently sends cumulative energy and a planned update adds interval energy. Keep the cumulative field meaning intact and give the additional quantity a distinct name. Specify its unit, interval duration, timestamp boundary and missing-data behavior before anyone updates the receiving report.<\/p>\n Run an approved sample through a nonproduction receiver. Check that the existing cumulative display remains unchanged and that the new interval series is calculated or stored according to the contract. Then send an intentionally mislabeled sample and confirm that the importer rejects it with a useful explanation.<\/p>\n If the proposed update replaces the original field rather than adding a new one, do not reuse the old contract identifier. Prepare a migration mapping and decide which historical outputs need a version marker. This example describes exchange design; it does not establish an export feature, accuracy rating or billing approval for a particular instrument.<\/p>\n A rejected file should remain available in a controlled evidence location, alongside the reason, receiving software version and attempted contract identifier. Preserve the received bytes. If a corrected file is supplied, give it a distinct revision and record what it supersedes rather than overwriting the rejected original.<\/p>\n The receiver should distinguish syntax errors from contract errors and engineering validation errors. An unmatched quote differs from an unsupported unit, and both differ from an implausible reading. Separate reasons help the right person resolve the problem without repeatedly modifying a valid source file.<\/p>\n For related controls, use the meter export file integrity guide<\/a> to preserve received files and the CSV header and encoding guide<\/a> to address text interpretation. Those checks complement a version contract; neither establishes semantic compatibility alone.<\/p>\n Name the owner of the exporter configuration, the receiving import rules and the electrical interpretation. One person may fill several roles, but the approval record should still answer each question. A data specialist can validate field types without being authorized to approve a change in the measurement boundary.<\/p>\n Set a transition date and a rollback decision point. Record what happens to files waiting in a queue during the change. If the receiver is reverted, determine whether newer files remain quarantined or require a separately validated conversion. Never silently reinterpret them under an older contract because the older software happens to accept their shape.<\/p>\n A support handover should include the approved contract, sample files, expected results, known rejection messages and the current compatibility matrix. This makes future changes testable and reduces the chance that a replacement integrator reverse engineers the format from one convenient file.<\/p>\n Begin with the correct device and its documented settings. The BY194 multifunctional instrument product page<\/a> is the product reference for this article. Confirm the exact ordered variant and available measurements separately; a product photograph cannot establish an export format, gateway function or archive capability.<\/p>\nIdentify the contract before processing rows<\/h2>\n
![\"BY194](\"https:\/\/cnbygele.com\/wp-content\/uploads\/2026\/11\/meter-csv-schema-version-contract-inspection-20261108.png\")
Write the minimum field agreement<\/h2>\n
\n\n
\n \nContract item<\/th>\n Record explicitly<\/th>\n Reject or quarantine when<\/th>\n<\/tr>\n<\/thead>\n \n Meter identity<\/td>\n Stable asset identifier and approved mapping<\/td>\n Identifier is unknown or maps to multiple assets<\/td>\n<\/tr>\n \n Quantity<\/td>\n Physical quantity, direction and measurement boundary<\/td>\n Meaning differs from the approved calculation<\/td>\n<\/tr>\n \n Unit and scale<\/td>\n Unit, multiplier and application location<\/td>\n Scaling would be applied twice or cannot be established<\/td>\n<\/tr>\n \n Time<\/td>\n Zone, interval convention and timestamp interpretation<\/td>\n A timestamp cannot be assigned unambiguously<\/td>\n<\/tr>\n \n Missing reading<\/td>\n Difference between missing, invalid and measured zero<\/td>\n A blank would silently become zero<\/td>\n<\/tr>\n \n Quality<\/td>\n Permitted codes and downstream handling<\/td>\n A new code has no agreed interpretation<\/td>\n<\/tr>\n \n Revision<\/td>\n Supported contract identifiers and transition rule<\/td>\n The receiver does not recognize the version<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Classify a change by its effect on the receiver<\/h2>\n
Build a small but deliberate test pack<\/h2>\n
A practical migration example<\/h2>\n
Preserve the original evidence during rejection<\/h2>\n
![\"BY194](\"https:\/\/cnbygele.com\/wp-content\/uploads\/2026\/11\/meter-csv-schema-version-contract-records-20261108.png\")
Assign approval and operational ownership<\/h2>\n
Relate the exchange to the actual installed meter<\/h2>\n