Start with the meaning of a value
For each important signal, write its physical meaning, unit, valid range and measurement boundary. Record whether it is an instantaneous reading, an interval total or a cumulative counter. A name such as output_count is ambiguous until the counting boundary and reset behavior are explicit. Include an example that a non-PLC engineer can interpret.
Keep source time and quality
Distinguish when a value was measured from when a gateway received it. Specify the time zone, clock source and acceptable age. Preserve quality information when a protocol provides it. A valid-looking number with bad quality should not silently replace a trusted reading; define how each downstream consumer should display or exclude it.
Define changes and error behavior
Name the owner of the schema and how consumers learn about changes. Treat a unit change as a contract change even if the field name remains the same. Describe missing values, duplicates, out-of-order events and resets with examples. Choose a versioning approach that lets old and new consumers coexist during an approved migration.
Test the contract at both ends
Ask the automation owner to verify the source examples and the application owner to verify interpretation. Include a normal reading, a bad-quality reading and a restart sequence. Store the examples with the schema. A contract is useful when both teams can detect a breaking change before an operator sees a misleading result.
Put it into practice
Use the related tool to check your assumptions, then bring the results to your project discussion.