A Value Has Type, Meaning, and Units

The text 42 can mean many things.

It could be:

• an integer count;
• the string characters 4 and 2;
• 42 degrees Celsius;
• 42 percent battery;
• a device identifier;
• a timeout in milliseconds; or
• an error code.

Computers need representation. Systems also need meaning.

Confusing those two creates bugs that look mysterious until you inspect the data contract.

Representation is not semantics

Consider this fictional telemetry row:

{
  "motor_temp": 72,
  "battery": 61,
  "enabled": true
}

A parser can tell you that 72 is a number, 61 is a number, and true is boolean.

It cannot infer the full contract.

Questions remain:

• Is motor temperature Celsius or Fahrenheit?
• Is battery a percentage, voltage, or raw ADC value?
• Is enabled allowed to be missing?
• Are decimal temperatures valid?
• What range is physically or logically expected?

A type system answers part of the question. A data contract answers more.

Build a field dictionary

For each field, document at least:

That is much stronger than “motor_temp: number.”

Strings are especially deceptive

These are different values:

65
"65"
"065"
"65%"
"sixty-five"

A permissive parser may try to convert all of them. A strict parser may accept only one documented representation.

Neither strategy is automatically correct. The contract decides.

The defensive principle is avoid silent interpretation when ambiguity matters.

Missing is a real state

Suppose a field is absent:

{
  "battery": 61,
  "enabled": true
}

What should the program do without temperature?

Possible policies include:

• reject the message;
• use a documented safe default;
• retain the previous value;
• mark the value unknown; or
• switch to a fallback mode.

Each policy has consequences.

Silently treating missing as zero is especially dangerous because zero may be a perfectly valid measurement. Unknown and zero are not the same state.

Units belong in the contract

Consider two components:

sensor reports: 35 C
consumer assumes: 35 F

The bytes are valid. The number parses. The system is still wrong.

That is a semantic contract failure.

A strong field name can reduce ambiguity:

motor_temp_c
latency_ms
battery_percent

Names do not replace documentation, but they make the contract harder to misunderstand.

Activity: audit a fictional message

Review:

{
  "robot_id": "RNX-07",
  "motor_temp": "84",
  "battery": 0.73,
  "enabled": "true",
  "timestamp": 1780000123
}

The receiving component expects:

robot_id: string matching RNX-##
motor_temp_c: integer, -20..120
battery_percent: integer, 0..100
enabled: boolean
timestamp_ms: integer Unix milliseconds

List every mismatch you can defend from the evidence.

Do not claim the robot is unsafe or compromised. You have only a contract mismatch.

A strong answer notices at least:

• field name mismatch for temperature;
• temperature represented as string;
• battery likely represented as fraction rather than integer percent;
• enabled represented as string;
• timestamp name/units mismatch.

Why this matters in security

Data contracts sit on trust boundaries.

A network service, API, log collector, robot process, and database all receive data produced elsewhere. If the receiver accepts ambiguous or malformed state, downstream controls may reason from values that never matched the intended model.

That does not mean every parsing bug is exploitable. It means parsing deserves the same evidence discipline as any other boundary.

Begin your Data Contract and Parser Test Record

Document five fields for a fictional telemetry message:

Field name
Type
Meaning
Units
Allowed range/set
Required or optional
Behavior if invalid/missing

Then write one sentence explaining why a type check alone is insufficient for one field.