Schemas Turn Assumptions Into Tests

A schema is a machine-checkable or human-checkable statement about the shape of data.

It turns “we expect this message to look right” into explicit conditions that can be tested.

A small schema is enough to teach the idea

For the fictional telemetry message, define:

schema_version
  integer
  allowed: 1
  required

robot_id
  string
  pattern: RNX-##
  required

motor_temp_c
  integer
  allowed: -20..120
  required

battery_percent
  integer
  allowed: 0..100
  required

enabled
  boolean
  required

Now every field has a boundary.

Validation order should be deliberate

A useful sequence is:

1. can the message be decoded?
2. is the top-level structure correct?
3. is the schema version supported?
4. are required fields present?
5. are field types correct?
6. are values inside allowed ranges or sets?
7. do cross-field rules hold?

Cross-field rules matter because individually valid values can form an invalid combination.

Example:

enabled = false
command = "move"

Both fields may be individually valid, but the pair may violate the system contract.

Lab: design a validator without hiding assumptions

Use pseudocode or Python:

def validate(message):
    required = {
        "schema_version",
        "robot_id",
        "motor_temp_c",
        "battery_percent",
        "enabled",
    }

    if set(message) != required:
        return False, "field-set"
    if message["schema_version"] != 1:
        return False, "schema-version"
    if type(message["motor_temp_c"]) is not int:
        return False, "motor-temp-type"
    if not -20 <= message["motor_temp_c"] <= 120:
        return False, "motor-temp-range"
    if type(message["battery_percent"]) is not int:
        return False, "battery-type"
    if not 0 <= message["battery_percent"] <= 100:
        return False, "battery-range"
    if type(message["enabled"]) is not bool:
        return False, "enabled-type"
    return True, "ok"

This is intentionally incomplete. It gives you something inspectable to improve.

Add checks for:

• robot_id shape;
• no extra fields;
• supported schema version; and
• one cross-field rule you can justify.

Do not connect the validator to a real robot or external service. Use supplied fictional messages only.

Test with a matrix, not one example

Create at least eight cases:

Add one cross-field mismatch.

Then record the actual result.

A schema does not make data true

This limitation matters.

Suppose the message says:

{"motor_temp_c":72}

The value can be structurally valid and still be inaccurate because:

• the sensor is miscalibrated;
• the value is stale;
• the wrong sensor was mapped to the field;
• the timestamp is wrong;
• the upstream component fabricated or corrupted the measurement; or
• the unit conversion happened incorrectly before validation.

A schema validates representation and declared constraints. It does not prove the physical world matches the message.

That is a perfect example of bounded evidence.

Contracts need ownership

Someone has to decide:

• who may change the schema;
• how versions are introduced;
• how old consumers are handled;
• how failures are logged;
• what tests must pass before deployment; and
• how the change is documented.

That turns a simple schema into a governance object.

You will return to this idea during change control and risk governance later in CS1337.

Finish the Data Contract and Parser Test Record

Submit:

1. field dictionary;
2. schema/version rule;
3. one valid message;
4. at least seven malformed/boundary messages;
5. expected and observed result for each;
6. one cross-field rule;
7. rejection/logging behavior;
8. one limitation; and
9. one change-control rule for future schema versions.

A strong final claim:

The validator enforced the documented Week 5 field set, types, version, and tested value boundaries for the supplied messages. It does not prove that accepted sensor values are physically accurate or trustworthy.

That is what a defensible data claim sounds like.