Schemas
A disputed invoice can be useful before it contains everything required for payment. The team may know the customer's reason while still investigating the amount owed. Rejecting that invoice because payment details are missing would prevent recording the information already available. Paying it without those details would also be wrong.
The investigation and payment operations have different requirements for the same entity. An investigation can use the invoice tag and the recorded reason. A payment operation needs a more precise agreement about the fields and values it will use. A schema expresses that agreement without making it a condition for storing every invoice.
A schema is another way to select data suitable for an operation. A query can combine a schema condition with tags and other predicates. The same invoice can satisfy several schemas, each expressing requirements for a different use. It can also remain useful to an investigation while failing the schema selected for payment.
Validation
A schema checks the structure and values in the entity's document. For payment, it might require an amount with a numeric value and a reference to the recipient. Meeting those requirements establishes that the expected information is present in the required form. The payment operation still needs rules for deciding whether the amount is owed and the recipient should be paid.
Validation can also protect changes made by an operation. A mutation that selects a target through a schema checks that its resulting document still satisfies that schema. An invalid result causes the mutation to be rejected. Operations that do not select that schema can still record other information, so its requirements apply at the places the application chooses.
Changing requirements
Schemas are stored definitions with their own transaction history, following the same reification principle as queries and mutations. The team can inspect the definition of payment readiness and how it changed. The transaction recording a revision can also carry the reason for changing that requirement.
Suppose payment now requires an additional approval reference. Changing the schema changes which invoices meet that requirement without rewriting their stored facts. Earlier invoices remain available for investigation even if they no longer qualify for payment. The application can identify which invoices lack an approval and request it before including them in the payment operation.