How English Works | The Schema

A database receives:

{ “student”: “Maya”, “score”: “banana” }

The sentence-shaped object is readable to a human.

It may still be structurally wrong.

Perhaps score must be a number.

Perhaps student_id is required.

Perhaps score must sit between 0 and 100.

Perhaps the field “student” is not allowed at all.

A schema exists to define these structural expectations before data begins circulating.

A schema is English turned into a grammar for data objects.

It says what kinds of things may appear, where they may appear, what form they must take, and which combinations are valid.

Quick Read

One-sentence answer: a schema works when it defines the structural constraints of data clearly enough that creators, validators and consuming systems can agree on what a valid instance may contain without confusing structural validity with factual truth.

The JSON Schema validation specification describes JSON Schema as a vocabulary for describing the meaning of JSON documents, giving hints to user interfaces and making assertions about what a valid document must look like.

This gives us the schema’s main architecture:

properties: which named fields may exist;
types: string, number, object, array, boolean or null;
required fields: what must be present;
allowed values: which values are valid;
constraints: ranges, lengths, patterns and combinations;
nesting: how objects contain other objects or arrays;
conditional rules: what becomes required when another state is present;
version: which schema rules the instance claims to follow.

The Schema Is Not the Form

A form asks a human for data.

A schema defines the structure that data must satisfy.

Form:

Student name: ______
Score: ______

Schema:

student_name = required string
score = required integer from 0 to 100

The form is an interface for collection.

The schema is a structural contract for the resulting data.

form = ask for values
schema = define valid structure

The Schema Is Not the Taxonomy

A taxonomy classifies concepts.

A schema defines fields and structural relations.

Taxonomy:

Animal → Mammal → Primate

Schema:

species_record contains scientific_name, common_name, conservation_status and habitat.

One organises categories of meaning.

The other organises the shape of records about those meanings.

taxonomy = concept organisation
schema = data structure

Field Names Are Tiny Ontological Claims

A schema contains:

first_name
last_name
birth_date
nationality

Those fields do not merely store data.

They assert that the system believes these are useful categories for representing a person.

Another system might need:

preferred_name
legal_name
name_in_original_script
multiple_nationalities

Schema design therefore contains assumptions about reality.

Every field is a question the system has decided is worth asking.

Types Are Structural Expectations, Not Merely Storage Choices

Consider:

“score”: “85”

and:

“score”: 85

They look similar to a human reader.

One is a string.

One is a number.

The distinction affects sorting, comparison, calculation and validation.

type tells the system what kind of operation a value can legitimately participate in

A schema therefore does more than prevent malformed input. It gives downstream systems predictable expectations about how values behave.

Required and Optional Fields Encode Necessity

A field can be structurally defined without being mandatory.

Example:

student_id — required
score — required
teacher_comment — optional
moderation_note — optional

The difference matters.

If teacher_comment is optional, absence can mean “no comment was provided.” It should not automatically be interpreted as “the teacher entered an empty comment.” Missing, null and empty-string states may therefore need different meanings.

absence is data too when the schema distinguishes its possible meanings

Enumerations Turn Open Language into Controlled Values

Free text can produce “finished,” “complete” and “done” for the same state.

Humans understand the similarity. A system may not.

An enumeration constrains the field:

status ∈ {draft, submitted, approved, rejected}

This reduces lexical variation in exchange for controlled semantics. The price is that the value set must actually represent the real states users encounter.

Constraints Narrow Validity Further Than Type

“Integer” is not enough if the valid domain is 0–100. “String” is not enough if an identifier must match a pattern.

JSON Schema supports constraints such as minimum and maximum values, string lengths, patterns, array length, unique items and property rules.

field exists → value has type → value satisfies constraints → object satisfies combined structure

Nested Objects Preserve Relationships

Flat data can place student, guardian and school fields beside one another. Nested structure can group them as student {…}, guardian {…} and school {…}.

Nesting says these fields belong together conceptually.

group related values so their relationship survives transport

Conditional Schemas Represent Context-Dependent Structure

Suppose:

if status = rejected, rejection_reason becomes required

The field is not globally mandatory. It becomes mandatory under a defined condition.

This lets schema rules represent branching logic rather than only static lists of fields.

conditional validity = structure that changes with state

Schema Validity Does Not Mean Truth

Data such as { “student_name”: “Maya”, “score”: 100 } may be structurally perfect while Maya actually scored 73.

The schema can validate structure and constraints. It cannot by itself verify the world.

schema-valid ≠ factually true

This distinction is crucial in databases, APIs and AI systems because structurally perfect falsehood can travel very efficiently.

Unknown Fields Force an Openness Decision

An incoming object contains:

“preferred_language”: “English”

The current schema never defined that property.

Should validation reject the entire object?

Should it accept and preserve the unknown field?

Should it ignore it?

This is an openness decision.

closed schema = only known structure allowed
open schema = extensions may travel beyond what the current validator understands

Closed schemas increase predictability.

Open schemas can improve extensibility.

The right choice depends on the system’s tolerance for unknown structure.

Defaults Can Fill Structure Without Filling Reality

A schema or application may attach a default:

country = Singapore

This can reduce repetitive input when Singapore is genuinely the usual state.

It can also silently create wrong data when absence means “unknown” rather than “Singapore.”

default value = convenient assumption, not observed fact

Schema designers should distinguish convenience for user interfaces from claims about the underlying world.

Validation Errors Should Point to the Broken Constraint

Weak:

Invalid object.

Useful validation can report:

which field failed;
which constraint was violated;
which value was received;
what valid state was expected.

For example:

score: value 118 exceeds maximum 100.

Now the schema becomes part of recovery rather than merely rejection.

This connects directly to Error Message: internal validation and human-readable recovery should describe the same broken state at different levels.

Schema Versions Define Different Valid Worlds

Version 1 requires:

name

Version 2 replaces it with:

given_name + family_name

An object valid under v1 may fail under v2.

The data did not necessarily become bad.

The structural contract changed.

validity always means valid against some rule set

Schema version should therefore travel with data or be recoverable from context when different versions coexist.

Schema Evolution Creates Migration Work

Adding an optional field may be easy.

Renaming a required field can break every downstream consumer.

Changing a string into an object can transform old valid data into incompatible data.

Schema evolution therefore needs questions similar to protocol versioning:

Can old readers ignore the new field?
Can new readers understand old objects?
Must existing records be migrated?
How long will both versions be supported?
What transformation preserves meaning?

The challenge is not merely syntax migration.

It is semantic preservation across structural change.

A Schema Can Make Reality Disappear

If the schema has no field for a phenomenon, systems built around the schema may stop seeing that phenomenon easily.

A school dataset contains:

attendance;
marks;
discipline incidents.

It contains no field for:

care responsibilities;
transport disruption;
language access;
temporary housing instability.

The missing fields do not prove those realities do not exist.

what a schema cannot represent can become hard for the system to remember

Schema design is therefore also an epistemic design problem.

Primary School: Design a Book Record

Ask children to design a record for classroom books.

title;
author;
genre;
borrowed?
borrower;
due date.

Then ask:

If borrowed = no, should borrower and due date still be required?

The child encounters conditional structure naturally.

Lower Secondary: Valid Structure versus True Data

Give students three records:

one structurally invalid;
one structurally valid but factually impossible;
one valid and plausible.

Ask them to separate:

Can the schema reject this?
Would we need external evidence to reject this?

This teaches a powerful distinction between formal validation and truth checking.

Upper Secondary: Audit the Data Grammar

What fields exist?
What reality assumptions do they encode?
Which fields are required?
How are absence, null and empty distinguished?
Which values are enumerated?
What constraints apply?
What conditional branches exist?
Are unknown fields allowed?
Which schema version applies?
What important reality cannot be represented?

This turns schema reading into a lesson in language, data modelling and epistemology.

Ten Failure Modes of Schema English

Field ambiguity. A property name can be interpreted in several incompatible ways.
Type mismatch. Values arrive in forms downstream systems cannot safely operate on.
Required-field inflation. Data is forced into fields even when the information is genuinely unknown.
Missing-state collapse. absent, null and empty are treated as identical despite different meanings.
Enumeration poverty. Real states have no available controlled value.
Constraint mismatch. Valid ranges do not match real-world possibilities.
Truth-validity confusion. Schema conformance is mistaken for factual correctness.
Default fabrication. Missing information is silently replaced with an assumed value.
Version fracture. Producers and consumers validate against different schema worlds.
Representation blindness. Important reality disappears because the schema never created a place to record it.

How to Design a Better Schema

What real objects are being represented?
Which fields are genuinely necessary?
What type should each value have?
What does missing mean?
Which values need controlled vocabularies?
What ranges or patterns are legitimate?
Which fields depend on other states?
Should unknown fields be rejected or preserved?
How will versions migrate?
What cannot this schema represent?

Then perform the valid-but-wrong test:

What false, misleading or incomplete object could pass this schema perfectly—and what additional evidence system would be needed to detect it?

The Deeper Idea: Schemas Decide Which Shapes of Reality Can Enter the System

Reality is large.

Data systems are finite.

A schema decides which pieces of reality get named, typed, constrained and stored.

reality → selected fields → valid data structure → downstream computation

That makes schema design much more than technical housekeeping.

It is a decision about what a system is capable of noticing.

Reader Checklist

What structure is valid?
Which fields are required?
What do the types mean?
How is absence represented?
Which values are controlled?
What constraints apply?
Which conditions change structure?
Does valid mean true?
Which version applies?
What reality is missing from the model?

Research and Further Reading

JSON Schema — Validation Vocabulary for Structural Validation

Final idea: a schema is good when it makes structure predictable without tempting us to confuse a well-shaped record with a complete or truthful picture of the world.