AI Compatible by Design: Every Field in the Standard Carries Its Own Instructions

OMPN Team

Open Matter Plans Network

Every legal AI tool faces the same unglamorous problem before it can do anything clever: working out what the data in front of it actually means. Is "completion date" the same thing as "settlement date"? Is the purchaser the client, or the other side? Does this date field want DD/MM/YYYY or something else entirely? Most AI failures in legal workflows are not reasoning failures. They are vocabulary failures - the model guessed what a field meant, and guessed wrong.

Our universal matter plans are built to remove the guessing. Every field in the OMPN field standard carries its own inbuilt instructions - a machine-readable definition of what the field means, how it is formatted, and what values it accepts. Not documentation sitting in a PDF somewhere. Instructions attached to the field itself, streamed with the plans, readable by any system or model that consumes them.

What Travels with Every Field

When a matter plan streams into your practice management system or AI workflow, every field it binds to arrives carrying the full context a machine needs to handle it correctly:

A canonical token - a stable, unique identifier like party.purchaser.fullName that means exactly one thing across every plan in the registry
A plain-language label and definition, so a model can match "the field on this form" to "the field in the standard" by meaning, not string luck
A data type and format rule - date, currency, phone, email - down to the expected pattern, such as DD/MM/YYYY
Allowed values for select fields, so an AI filling "title tenure" chooses from the actual options rather than inventing one
An example value, showing a model what correct data looks like before it ever sees real matter data
A party role - purchaser, vendor, acting solicitor, agent - so the AI knows whose details it is handling
Keyword aliases covering the different names practitioners and forms use for the same thing

Note

This is the difference between AI compatible and merely AI adjacent. A plan that is just JSON can be parsed. A plan whose every field explains itself can be understood - by a PMS, by an integration script, or by a language model, with no bespoke prompt engineering per matter type.

We Run Our Own AI on It Every Day

This is not a theoretical claim about future AI readiness. Our own document automation pipeline uses the field standard as its instruction set today. When we ingest a court or government form, an AI reads the form's fields alongside the field catalogue - tokens, labels, keywords, formats - and proposes the mapping between them. Every suggestion is then validated against the standard: a token the model invents is dropped, a low-confidence guess is flagged for human review, and format rules always come from the catalogue, never from the model.

That last part matters. The field standard does not just make AI integration possible - it makes it safe. The standard acts as the guardrail: the model proposes, the vocabulary disposes. Any AI tool built on OMPN data can use the same pattern, constraining model output to fields that actually exist, with formats that are actually correct.

One Vocabulary, Everywhere

The instructions would be worth little if every plan defined its own fields. They do not. The standard is one layered vocabulary shared across the whole registry: a geo-neutral base tier defines the fields every matter shares, a country tier adds jurisdiction-specific detail, practice-area sets add what a whole area of law needs, and an individual plan states only what makes it different. Hundreds of standardised matter plans across five countries draw from the same well - and so do the hundreds of court and government forms in our document automation layer, which bind to the very same tokens.

For anyone integrating, that collapses the problem. Map your system's matter data to the standard once, and every plan, every form, and every AI workflow built on the network understands it. There is no per-plan translation exercise, because there is nothing per-plan to translate.

Tip

As always, your matter data never touches our network. We stream the standard - the fields, their instructions, and the plans that bind to them. Your AI tools apply that standard to your data, on your infrastructure.

Why This Matters Now

Firms and legaltech teams are wiring language models into matter workflows at speed, and most are discovering the same thing: the model is rarely the bottleneck. The bottleneck is the absence of a trusted, structured, self-describing data layer for the model to stand on. That layer is exactly what an open, community-governed field standard provides - deterministic scaffolding for non-deterministic tools. AI does its best work when it does not have to guess: give a model a field that explains itself, and integration stops being a research project and becomes a lookup.