VERCY

Vercy in five minutes

For a technical leader who has heard of AI agents and does not work in semantics. No jargon here. Where a technical term is unavoidable, it is defined in the same sentence.

The problem, in one paragraph

Every team and every AI system holds its knowledge in its own shape. Your sales team calls something a "customer"; your finance system calls it an "account"; a partner's software calls it a "party"; your new AI agent has read all three and quietly guessed they are the same thing. They often are not. Today the only way to combine that knowledge is to pick one shape and flatten everyone else into it: one big database, one master schema, one owner who wins. No owner accepts being flattened, so most cross-team knowledge never gets combined. It gets copied, re-keyed, and hoped over. Vercy is a shared way to describe knowledge so it can stay where it is, in the shape its owner chose, and still connect to the rest. It moves the agreement from "store your data our way" to "describe your data a common way," which is a far smaller thing to agree on.

What Vercy is not

It is easy to hear "shared knowledge" and picture a database or a knowledge base. Vercy is neither, and the difference is the whole point.

A rough analogy: a shipping container standard does not own your cargo. It fixes the dimensions of the box so any crane, ship, and truck can carry it, while you decide what goes inside. Vercy fixes the dimensions of a unit of meaning. What the meaning is stays yours.

Before and after, in everyday terms

Before. Two teams, two spreadsheets. Sales keeps a sheet where each row is a "client," keyed by email. Support keeps a sheet where each row is a "customer," keyed by an internal ticket ID. A director asks a question that spans both: "for our top ten accounts by revenue, what is the average support response time?" There is no single place that can answer. Someone spends a day exporting both sheets, guessing which client matches which customer, fixing the mismatches by hand, and producing a number nobody fully trusts. Do it again next month from scratch. Point an AI agent at the two raw sheets and it will confidently join "client" to "customer" on names that almost match, and be wrong in the cases that matter.

After. Each team writes, once, a short description of the shape of its own sheet: what a row means, what the key is, which field is the same real-world thing the other team also tracks. Neither sheet moves. Neither team adopts the other's words. Because both descriptions follow the same common format, the link between "client" and "customer" is stated explicitly and checkably instead of guessed. The director's question can now be answered by following the stated links, and an AI agent reading the two descriptions joins them the way the owners said to, not the way the strings happened to look. Next month the same descriptions still hold, so the answer is repeatable.

The work did not disappear. It moved to a better place: from a monthly manual reconciliation that rots, to a one-time description that is reused and can be validated.

How it actually works, in plain steps

No jargon, just the sequence.

  1. Each owner describes their own shape. The sales team writes down what a row in its sheet is, and support does the same. Each owner writes their own; nobody writes anyone else's.
  2. They use the same common format to write it. Not the same words, not the same meanings, the same format for describing. This is the one shared thing.
  3. Overlaps are stated, not guessed. Where two owners track the same real-world thing, they say so explicitly: "our client key lines up with their customer key on this field." The link is a stated fact, not a string coincidence.
  4. A checker can reject a bad description. Because the format is fixed, a broken or contradictory description fails a check and says which rule it broke, the same way a compiler rejects broken code. This matters: a format that can never say "no" would just be decoration. Vercy's can say no.
  5. Others read a view, not a copy. When a partner or an agent needs your knowledge, they receive a controlled view built from your description, on your terms. Your store never leaves your hands.

The honest price

Vercy is not magic and it is not "no central agreement." There is exactly one thing everyone must agree on: the common format for describing a unit of meaning. That agreement is mandatory. If you will not describe your knowledge in the shared format, you cannot connect through Vercy, the same way a container that ignores the standard dimensions cannot ride the standard ships.

What you are not asked to agree on is what any word means. Nobody tells you what a "customer" is, or forces your definition to match your partner's. The shared layer is deliberately thin: it standardizes the shape of a description, never the content of your domain. That is the deal, stated plainly: you give up freedom over the format of description; you keep full control over the meaning of your domain. This is the same trade every working standard makes. TCP/IP fixes the packet, not your traffic. HTML fixes the markup, not your words.

Because the format is the one mandatory thing, the fair question is: who controls the format, and what happens if you disagree with a change to it? The answer is three concrete rights, not a promise of good behavior. Right to leave: every Vercy artifact is a plain file under an open license, so you can walk away and take your models with you at any time. Right to fork: the shared standard can be copied and taken in a different direction by anyone, like any open standard, which keeps the stewards honest. Right to participate: changes to the format go through a public, documented change process, not a private decision. So the working definition of sovereignty here is not "there are no shared rules." It is: you may leave with your models, you may fork the shared layer, and you may take part in changing it. Conforming to the shared format is the price of interoperability, and it is named out loud rather than hidden.

But can't an AI agent just read everything and figure it out?

This is the reasonable modern instinct, so it deserves a straight answer. An agent reading raw sources will guess the links, and its guesses are confident whether or not they are right. On "client" versus "customer" it will usually be right on the easy rows and wrong on exactly the hard ones, the merged company, the renamed account, the duplicate with a typo, which are the rows that carry the money and the risk. There is no record of what it assumed, so no one can check it, and next week it may assume something different. Vercy does not replace the agent; it gives the agent something better to read. Instead of guessing links from data that looks similar, the agent follows links the owners stated on purpose. The join becomes auditable and repeatable, and the agent spends its intelligence on the question instead of on re-guessing the plumbing every time.

When to use it, and when not to

Reach for Vercy when:

Do not reach for Vercy when:

Vercy earns its keep exactly when merging is off the table but connecting is not.

Three objections you are probably forming

"Isn't a shared format just a central schema by another name, with the control moved one floor up?" Fair, and worth being precise about. There is centralization here, but only of form: the shape of a description. There is no centralization of content: nobody defines your "customer," your "part," or your "contract" for you. A central schema forces shared meaning; Vercy forces only a shared way to write meaning down. That is a much smaller surrender, and it is the same one every network standard already asks of you.

"So whoever controls the format controls me." Only as far as you let them, and that is bounded by the three rights above: you can leave with your files, you can fork the standard, and the format changes through a public process you can join. Control of the format is real, but it is contestable and escapable, which is the difference between a steward and an owner.

"Why not just have everyone agree on one data model and be done?" If they will, do that; it is simpler and you do not need Vercy. This is for the common case where they will not, because each owner has real reasons for their own shape and no authority to impose one. Vercy is the answer to "we cannot merge, but we still have to connect."

The five-minute takeaway

If you remember one thing: Vercy does not hold your knowledge, it standardizes how you describe it, so knowledge kept in many different shapes by many different owners can connect without anyone being flattened into one database. The one mandatory agreement is the format of the description; the meaning of your domain stays entirely yours. The price is named, not hidden, and it comes with the right to leave, to fork, and to help change the standard. Use it when knowledge is split across owners who will not merge; skip it when everything already lives in one place under one owner.

You should now be able to say back, in your own words, both what Vercy is and the one thing it deliberately refuses to be: a place that holds your data.