Wednesday, 3 June 2026

From Validation to Interpretation: A Missing Layer in Information Architecture

 From Validation to Interpretation: A Missing Layer in Information Architecture


Written by ChatGPT, as prompted by Stephen D Green, June 2026 


Many information technologies were designed during an era in which the primary consumers of information were deterministic software systems.

A document was created.

A schema described its structure.

A validator determined whether the document conformed to that schema.

If the document was valid, software could process it according to predefined rules.

This model has proven extraordinarily successful. It underpins much of modern computing, data exchange, document processing, and systems integration.

Yet there is a growing recognition that validation and interpretation are not the same thing.

A document may be valid while still being misunderstood.

A value may conform to its datatype while still being interpreted incorrectly.

A representation may satisfy every formal constraint while lacking the contextual information necessary to understand what it actually means.

The increasing use of AI systems and large language models makes this distinction particularly visible.

It reveals what may be a missing architectural layer in many information systems.


Validation Is Not Interpretation

Traditional information architectures are often built around a relatively simple model:

Instance

        +

Schema

        

Validation

The schema defines constraints.

The validator checks conformance.

The result is typically binary:

Valid

or

Invalid

This approach works well when the consumer already knows how to interpret the content.

However, many real-world situations require more than validation.

Consider a document containing an integer value with around 7 digits.

The value may be perfectly valid.

But what does it represent?

Is it:

  • a quantity?
  • an identifier?
  • a date?
  • a Julian Day Number?
  • an offset from some epoch?
  • a code in a controlled vocabulary?

Validation alone does not answer these questions.

Interpretation requires context.


The Hidden Role of Documentation

For decades, information systems have quietly relied upon documentation to bridge this gap.

Schemas often contain explanatory notes.

Standards contain descriptive text.

Specifications include examples, caveats, historical explanations, and guidance.

For example, a schema may contain documentation such as:

This integer represents a Julian Day Number.

Or:

This currency code was reassigned in 2015.

Use the document date to determine which

currency is intended.

Historically, such information was written for human readers.

Software generally ignored it.

The assumption was that humans would read the documentation and software would process the data.

This division of responsibilities made sense when software lacked the ability to make use of explanatory prose.


AI Changes the Situation

Large language models challenge this assumption.

Unlike traditional validators, an LLM can directly consume explanatory text.

It can use descriptions, examples, warnings, and historical notes as part of its reasoning process.

Information that was once treated as informal documentation becomes operationally significant.

For example, consider a document containing:

CurrencyCode = ABC

A validator may confirm that ABC is a valid code.

An LLM, however, may also need to know:

ABC referred to Currency A until

31 December 2010.


The code was subsequently reused

for Currency B from 1 January 2015.


Interpret according to document date.

This information is not primarily about validity.

It is about interpretation.

The distinction matters.


The Missing Layer

Many information architectures appear to lack an explicit place for contextual interpretation guidance.

They contain:

  • data;
  • structure;
  • validation rules.

But they often lack a first-class mechanism for expressing how information should be understood in particular contexts.

As a result, contextual guidance is frequently placed into documentation fields.

This works, but it feels unsatisfactory.

Documentation is being used as a substitute for something that does not formally exist.

The architecture often looks like this:

Instance

        

Schema

        

Documentation

        

Human Interpretation

The documentation layer is essential, yet it is often treated as secondary.


Interpretation Profiles

A more complete architecture might recognize contextual interpretation as a first-class concept.

Instead of viewing documentation merely as commentary, it could be treated as part of an explicit interpretation profile.

The architecture would become:

Instance

        

Canonical Model

        

Interpretation Profile

        

Contextual Understanding

An interpretation profile might contain:

  • explanatory notes;
  • historical context;
  • terminology mappings;
  • code-list guidance;
  • assumptions;
  • caveats;
  • examples;
  • ambiguity-resolution rules;
  • references to authoritative sources.

Its purpose would not be to validate.

Its purpose would be to guide interpretation.


A Stable Core and Multiple Interpretations

This idea aligns naturally with a broader architectural pattern.

A stable representation remains unchanged.

Different contexts provide different interpretive overlays.

The same underlying content may therefore support multiple valid interpretations.

For example:

BusinessDocument

        +

Invoice Interpretation Profile

        

Invoice Understanding


BusinessDocument

        +

Order Interpretation Profile

        

Order Understanding


BusinessDocument

        +

Accounting Interpretation Profile

        

Accounting Understanding

The representation remains stable.

The contextual understanding changes.

This resembles the distinction between a canonical model and contextual overlays.

The same foundation supports multiple perspectives.


Beyond Validation

Historically, information technologies have emphasized correctness.

The central question has often been:

Is the document valid?

An interpretation-oriented architecture introduces a different question:

How should the document be understood?

The two questions are related but distinct.

Validity concerns conformance.

Interpretation concerns meaning.

A document may be perfectly valid and yet still require substantial contextual knowledge before it can be understood correctly.


A Gap in Existing Technologies

Many existing technologies provide partial support for this idea.

Schema annotations.

Metadata systems.

Controlled vocabularies.

Ontologies.

Documentation frameworks.

Rule languages.

All contribute pieces of the solution.

Yet there is often no explicit architectural concept that unifies them around interpretation.

Instead, contextual guidance tends to be scattered across specifications, comments, documentation fields, and institutional knowledge.

The result is that interpretation remains largely implicit.


Toward Interpretation-Centric Architectures

As intelligent systems become increasingly important consumers of information, the need for explicit interpretation support may grow.

Future architectures may place greater emphasis on:

Representation

        +

Context

        

Interpretation

rather than simply:

Representation

        +

Constraints

        

Validation

The goal is not to replace validation.

Validation remains essential.

Rather, it is to recognize that validation is only one stage in a larger process.

Information must not only be correct.

It must also be understood.


Conclusion

Much of modern information architecture has been built around validation.

This emphasis has served the computing world well.

However, the growing importance of AI systems highlights a distinction that has always existed but was often overlooked.

Validation determines whether information conforms to rules.

Interpretation determines how information should be understood.

Many existing technologies provide mechanisms for expressing structure and constraints, yet offer only indirect support for contextual interpretation.

As a result, documentation often performs a role far more important than originally intended.

It becomes the carrier of interpretive knowledge.

The emergence of AI may therefore reveal a missing architectural layer—one that sits between representation and understanding.

Whether implemented through annotations, profiles, overlays, metadata systems, or entirely new mechanisms, this layer would make contextual interpretation a first-class concern.

In doing so, it would recognize something fundamental:

Information is not useful merely because it is valid.

Information becomes useful when it is understood.


June 2026