Designing a Schema People Can Actually Agree To

Opening Scene

Three co-founders sit around a table drafting a partnership agreement, and each brings a different priority: one wants flexibility to bring on future partners, another wants clear, fixed ownership percentages that won’t be renegotiated every year, and the third mostly wants an exit clause that protects them if things go wrong. A good partnership agreement doesn’t pick one person’s priorities and call it done — it finds language every founder can actually sign, even where their interests genuinely pull in different directions.

In Plain English

Designing a schema is the same kind of negotiation, not a purely technical exercise one engineer does alone at a whiteboard. A producer usually wants a schema that’s easy to generate and flexible to change; a consumer usually wants one that’s stable, well-typed, and unlikely to shift underneath them; and often several different consumers want subtly different things from the same dataset. A schema that people can actually agree to — rather than one quietly imposed by whichever team got there first — takes real negotiation, and it’s usually worth more time up front than it gets.

The Old Way

Before schema design was treated as a genuine, multi-party negotiation:

Whichever team built the source system designed the schema entirely around their own internal needs, and everyone downstream simply had to adapt. Consumer needs were an afterthought, if they were considered at all.
Schemas were frequently designed once and never revisited, even as new consumers with different needs started depending on the same dataset. The original design calcified into something nobody felt empowered to change.
Disagreements about schema design, when they happened at all, were resolved informally — whoever pushed hardest, or shipped first, usually won — rather than through any structured process.

A schema genuinely designed with input from every real stakeholder is far more likely to survive contact with actual, ongoing use.

What’s Changing (and Why AI Is the Reason)

More organizations now run explicit schema design reviews before a dataset ships, bringing producer and known consumers into the same conversation rather than letting the producer decide alone.
This draws directly on the collaborative modeling practices covered in this content library’s dedicated data modelling series, applying the same structured thinking about entities and relationships to a negotiation involving multiple stakeholders rather than one designer.
As AI systems become consumers with their own particular needs — consistent typing, low tolerance for ambiguity, a strong preference for well-documented fields — schema design increasingly has to account for a consumer that can’t just ask a human “wait, what does this field actually mean?”

The Metaphor, Fully Extended

The Three Co-Founders Drafting Their Agreement	Schema Design Concept
Each founder bringing a different priority to the table	Each stakeholder bringing different needs to schema design
Language every founder can actually sign, not just one person’s preference	A schema every real consumer can actually build against
Negotiating the agreement’s terms before anyone signs	Reviewing and negotiating a schema before it ships
An agreement built to last, not one imposed by whoever got there first	A schema designed to be stable, not one dictated solely by the producer

For Beginners: What to Actually Do

Before finalizing any schema you own, ask at least one real consumer what they’d actually need from it.
Practice reading a schema design from the perspective of a consumer who’s never seen the source system, not just the producer who built it.
Get in the habit of naming ambiguous fields clearly rather than leaving their meaning to be inferred.

For Practitioners and Leaders: The Deeper Layer

Institute a lightweight schema design review for any dataset with more than one known consumer, before it ships.
Weigh producer convenience against consumer stability explicitly in these reviews, rather than letting producer convenience win by default.
Document field-level meaning, not just type, especially for datasets an AI system will consume without a human in the loop to ask questions.

Quick Recap

Schema design is a negotiation between stakeholders with different needs, not a solo technical exercise.
Schemas designed unilaterally by producers tend to serve the producer’s convenience over consumer stability.
Structured design reviews involving real consumers produce schemas that survive actual, ongoing use better.
AI consumers raise the bar for clear field-level meaning, since they can’t simply ask a human to clarify.

Where This Fits in the Series

Article 8 covered the delivery guarantees layered onto a contract. This article covered the negotiation behind designing a schema people actually agree to. Article 10 looks at how that design changes depending on whether the data arrives in a stream or a batch.