A Schema Is Not a Policy

“A perfectly valid message can still represent an invalid business operation.”

Modern systems are very good at validating data.

We have JSON Schema, XML Schema, Avro, Protobuf, OpenAPI specifications, database constraints, and validation frameworks.

We can define whether a field is required, whether a value is numeric, which formats are accepted, and which values are allowed.

Then the message passes validation.

And we call it valid.

But valid according to what?

A schema can tell us whether data has the expected structure.

It cannot tell us whether the business operation represented by that data should be allowed.

That distinction matters.

Especially in financial systems.

Structurally Valid. Financially Wrong.

Consider a simple payment instruction:

{

  "amount": 10000.00,

  "currency": "SEK",

  "debtorAccount": "SE123456789",

  "executionDate": "2026-09-14"

}

A schema might validate that:

• amount is a decimal and greater than zero

• currency contains a valid currency code

• debtorAccount matches the expected format

• executionDate is a valid date

Everything passes.

The message is valid.

But should the payment be executed?

We still don’t know.

The account might be closed.

The customer might not have authority to move the funds.

The payment might exceed an approval limit.

The account might not support the requested currency.

The execution date might violate a cut-off rule.

The transaction might require additional approval.

The exact same payment might already have been executed.

The data is structurally valid.

The business operation may be completely invalid.

Schema and Policy Answer Different Questions

This is the distinction:

Schema asks:

Is this information represented correctly?

Policy asks:

Is this business operation permitted and correct?

Those questions belong at different levels of the architecture.

A schema defines things such as data types, formats, required fields, cardinality and structural constraints.

Business policy defines responsibilities, authority, invariants, limits, lifecycle rules and acceptable outcomes.

Trying to make the schema carry both responsibilities creates the wrong abstraction.

Meaning Cannot Be Captured by Type Alone

Suppose a schema contains:

{

  "status": "COMPLETED"

}

The value might be perfectly valid according to an enumeration.

But what does COMPLETED mean?

Was the payment accepted?

Executed?

Booked?

Settled?

Irrevocably settled?

Does a consumer receiving COMPLETED have permission to update the customer’s available balance?

The schema can define the word.

It cannot, by itself, establish the business agreement behind that word.

This is the same distinction we encounter with APIs and contracts.

Structure is necessary.

Meaning is what allows systems to work together correctly.

Validation Is Not a Business Decision

This becomes particularly dangerous when schema validation is treated as a security or business control.

Imagine a payment API accepting:

{

  "amount": 500000,

  "currency": "EUR"

}

The schema accepts the request.

That does not mean the customer is authorised to make a €500,000 payment.

Authorisation is policy.

The same applies to many other financial concepts.

A schema can validate that an approval identifier exists.

Policy determines whether that approval is sufficient.

A schema can validate an account identifier.

Policy determines whether that account may participate in the transaction.

A schema can validate a date.

Policy determines whether the transaction may execute on that date.

The schema protects the interface.

Policy protects the business.

Some Rules Can Be Expressed in a Schema

There is an important nuance here.

Not every validation rule belongs outside the schema.

If an amount must be positive, expressing that constraint in the schema can be useful.

If a field has a defined format, validate it.

If only a known set of values is structurally permitted, encode that constraint.

Good schemas should be restrictive enough to reject information that cannot possibly be meaningful.

But that does not turn the schema into the policy.

The architectural mistake happens when we assume:

The message passed schema validation, therefore the operation is valid.

It isn’t.

Schema validation is one control.

Business validation is another.

Policy Often Depends on Context

Schemas are particularly poor at representing rules whose outcome depends on business state.

Consider a payment limit.

Perhaps a customer may normally transfer €10,000.

But corporate customers have different limits.

Certain users have delegated authority.

Some payments require dual approval.

Limits may depend on currency.

Risk classification may affect the decision.

A regulatory or fraud control may temporarily prevent execution.

The validity of the transaction cannot be determined by looking at the message alone.

It depends on context.

That context belongs to the business policy.

Schemas Change Differently From Policies

Separating schema from policy also matters because they evolve differently.

A new optional field might change the schema without changing business behaviour.

A new payment approval rule might change business policy without changing the schema at all.

Those are different kinds of change.

If the two are tightly coupled, every policy change risks becoming an interface change.

And every interface change risks accidentally changing business behaviour.

Good architecture separates those concerns.

This Matters Even More Across System Boundaries

Imagine two systems communicating through Kafka.

The producer publishes a perfectly valid Avro message.

The consumer successfully deserialises it.

Schema compatibility passes.

Nothing crashes.

Yet the systems can still disagree about what the information means.

That’s one of the most dangerous integration failures because technically everything appears healthy.

The transport worked.

The schema worked.

The consumer worked.

The business was wrong.

This is why semantic compatibility matters more than schema compatibility alone.

Financial Systems Make the Difference Obvious

Financial systems provide particularly clear examples because many rules cannot safely be reduced to data validation.

LANDA™ FIN-11 makes this distinction explicit in cash and liquidity management: payment state must have defined semantics and ownership; payment execution must remain unambiguous through retries and timeouts; balances require source, timestamp and meaning; and bank interfaces should be translated into stable internal business semantics rather than defining the domain themselves. 

A valid balance message does not prove the balance is current.

A valid payment message does not prove the payment is authorised.

A valid transaction status does not prove both systems interpret that status identically.

Correct structure is only one dimension of correctness.

Regulation Works the Same Way

This distinction extends beyond business rules.

A regulation is not a schema either.

A regulation may create an obligation or required outcome. That obligation then needs to be interpreted and translated into an architecture requirement before controls and evidence can be defined.

That is why LANDA™ explicitly uses the chain:

Regulatory context → Applicability → Obligation → Architecture requirement → Control → Validation → Evidence

rather than turning regulation names directly into technical requirements. 

The same Policy vs Detail principle applies.

The obligation defines what must be achieved.

A schema, API gateway, database constraint or validation framework may become one control used to help achieve it.

But the technology is not the obligation.

AI Makes the Distinction More Important

AI can generate excellent schemas.

Give an AI model a description of an API and it can quickly produce:

• OpenAPI definitions

• JSON Schema

• Protobuf definitions

• Avro schemas

• validators

• serializers

• API clients

• automated tests

That is useful.

But it creates a new architectural risk.

AI can produce an enormous amount of technically correct implementation from an incomplete business policy.

If we tell AI that a payment consists of:

amount

currency

account

executionDate

it can generate everything around those fields.

Perfectly.

But it still doesn’t know who may authorise the payment, what happens after an ambiguous timeout, which financial state is authoritative, or what business invariants must never be violated.

AI accelerates implementation.

That makes defining policy more important, not less.

Policy Before Detail

This is one of the core principles behind LANDA™:

Policy before detail 

stable business responsibilities and semantics are separated from implementation technology. 

Start by defining what must be true.

Then define the business rules and responsibilities that protect it.

Then define the information and contracts required to communicate it.

Only then decide how those rules should be represented technically.

Sometimes part of that answer will be a schema.

But the schema comes after the meaning.

Not before it.

Final Thoughts

Schemas are essential.

Use them.

Make them precise.

Validate them aggressively.

Version them carefully.

But don’t ask them to solve a problem they were never designed to solve.

A schema can tell you whether the message is well formed.

It cannot tell you whether the business decision is correct.

Schema defines structure.

Policy defines meaning and permissible behaviour.

And architecture must protect the second from becoming trapped inside the first.

A schema is not a policy.