The Schema Underneath

Part 5 of 11: The Schema Underneath

---

I'm a developer, so the first thing I wanted to know about Lists was what a list actually is when nobody's looking. The answer is satisfying: every list you build by clicking around in the visual builder is really a small, structured schema. The builder is a friendly front end that writes it for you. Knowing the shape underneath doesn't change how you use the app, but it changes how you think about what a list can be.

What your list looks like as data

Strip away the UI and my Field Recording Kit is a schema: a name, a description, and an ordered set of fields. Each field carries a key, a type, a label, and a few optional flags.

{
  "name": "Field Recording Kit",
  "fields": [
    { "key": "gear", "type": "text", "label": "Gear", "required": true },
    { "key": "category", "type": "select", "label": "Category",
      "options": ["Recorder", "Microphone", "Cable", "Windscreen", "Bag"] },
    { "key": "price", "type": "number", "label": "Price ($)" },
    { "key": "battery_powered", "type": "boolean", "label": "Battery Powered" },
    { "key": "acquired", "type": "date", "label": "Acquired" }
  ]
}

That's it. Every column you saw in the builder is one object in that fields array. When you set a default or a placeholder, you're setting another property on the same object. The list "remembers" its shape as this schema, and each row is just structured values keyed to those field keys.

You can even see the schema reflected back at you in the app. The Entity Diagram view draws each list as a table of its fields and types, which is the schema made visible.

The Entity Diagram view showing Field Recording Kit as a table of its fields and types, with a primary key marker and a foreign-key link to a nested list

What the format can do beyond the common case

Here's where it gets interesting for the curious. The schema format is richer than the everyday controls you'll usually touch. Two capabilities in particular live at this layer.

The first is validation rules. Beyond "required," a field can carry constraints: a minimum and maximum for a number, a length range for text, a pattern a value has to match. The type system already understands these.

The second is conditional visibility. A field can declare that it only appears when another field has a certain value, using a set of comparison operators (equals, greater than, contains, is empty, and more). In schema terms it reads like this:

{
  key: "student_id",
  type: "text",
  label: "Student ID",
  visibility: {
    condition: { field: "ticket_type", operator: "equals", value: "student" }
  }
}

That says: only show the Student ID field when the ticket type is "student." The engine that renders and validates rows honors it.

I'm being deliberately precise here, because I don't like blog posts that describe a control that isn't where they say it is. The point-and-click builder focuses on the fields you reach for constantly: name, type, options, required, defaults, help text, nesting, public or private. The schema model itself carries more than that. Seeing the format is how you understand the ceiling, not just the floor.

Why "it's just a schema" is the good news

The practical payoff of a list being clean structured data rather than a pile of cells is everything the rest of this series is about. Because the shape is known, the app can show the same data four different ways, diagram how your lists relate, validate a row before it's saved, and hand your data back to you in a portable form when you want out. A spreadsheet can't do those things because it doesn't really know what its columns mean. Yours does.

Next: those four ways of seeing the same data, including the diagram that turns your whole workspace into a map.

Adron