> For the complete documentation index, see [llms.txt](https://docs.internetobject.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.internetobject.org/conformance/validation-model.md).

# Validation Model

The parse, validate, load, and stringify pipeline.

Processing an Internet Object document is defined as a pipeline of four stages. Each stage has a clear input and output, so implementations behave consistently.

```
text ──parse──▶ document tree ──validate──▶ checked tree ──load──▶ values
                                                              ◀─stringify── values
```

## Parse

**Input:** UTF-8 text. **Output:** a document tree (header, sections, records, values).

Parsing checks only *syntax* — that the text is well-formed. It does not consult any schema. Syntax errors are produced here (see [Error Model](/parsing-and-errors/error-model.md)).

## Validate

**Input:** the document tree + a schema. **Output:** the same tree, with each value checked.

Validation applies the schema: types, constraints (`min`, `maxLen`, `pattern`, `choices`, …), optionality, and nullability. Validation errors are produced here. With no schema, data is accepted structurally and mapped to positional keys.

### Entry points

An implementation will usually offer **two ways in**: validating a document read from text, and validating values the host language already holds — an object from an API response, a row from a database.

```
   IO text ──parse──▶ document tree ──┐
                                      ├──validate──▶ same outcome, either way
   native values ─────────────────────┘
```

These are two routes to one stage, not two stages. **Validation is defined on the logical value.** For the same schema and the same logical value, both routes **MUST** reach the same outcome: the same accept-or-reject decision, the same error codes, in the same order.

Two values are *the same logical value* when they hold the same members with the same names and the same typed contents — regardless of spelling. Text `~ Alice, 15` under `{name: string, age: int}` is the same logical value as the native `{name: "Alice", age: 15}`, because positional binding is part of reading the text, not part of validating it.

This is worth stating because the two routes are commonly written as **separate code**, each walking its own kind of input. Nothing forces them to stay in step, and a divergence is close to undetectable from inside a single implementation: each route has its own tests, and both pass. It surfaces only when the same data is sent both ways, or when a second implementation reads the specification and builds **one** validator — at which point the specification can only describe one of the two behaviors, and every user of the other one is affected.

> **Testing this.** Run the conformance corpus's validation cases through **every** entry point the implementation offers, asserting both produce the same codes. Sampling a handful of cases is not enough: the routes agree on the common shapes by construction, so the disagreements live in exactly the cases nobody thinks to pick.

## Load

**Input:** the validated tree. **Output:** in-memory values.

Loading converts checked values into their final representations (numbers, booleans, dates, byte data, nested objects/arrays), applying defaults for omitted fields.

## Stringify

The inverse of the pipeline: in-memory values are serialized back to Internet Object text, honoring schema hints such as a number's `format` or a string's quote style. A value that is loaded and then stringified SHOULD round-trip to an equivalent document.

## See Also

* [Conformance Requirements](/conformance/requirements.md)
* [Parsing & Errors](/parsing-and-errors/parsing-and-errors.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.internetobject.org/conformance/validation-model.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.