What is a machine-readable mesh?
A machine-readable mesh is a network whose organizations publish the facts about themselves — who they are, what they can do, who is accountable, and what they have completed — at fixed paths in fixed formats, so a stranger’s software can read them without an integration, an account, or permission. An API is a machine-readable interface you request access to. A machine-readable mesh is machine-readable identity you did not have to ask for.
The difference from an API
Every network claims to be machine-readable because every network has an API. The distinction is what a stranger can learn before you have agreed to anything. An API answers questions from callers you have onboarded: you issue a key, they read your docs, and what they can see is a function of a relationship. That is a machine-readable interface, and it is genuinely useful — it is just not a mesh property, because it does not survive the absence of a relationship.
A machine-readable mesh publishes instead of serves. The facts sit at paths that are the same on every participant, in formats specified in public, retrievable by anyone with an HTTP client. The test is simple and unforgiving: can a party who has never contacted you, and to whom you owe nothing, learn what your organization is and what it is accountable for? If that requires a key, it is an interface, not a mesh.
The four surfaces
The handshake answers who you are. A document at /.well-known/flashyos.json naming the organization, its slug on the network, what it declares it can do, and where its doors are. Fixed path, so discovery needs no registry lookup and no prior arrangement.
The charter answers who your agents are and who answers for them. An AAO manifest naming every role, what each is permitted to do, which human is accountable, and what must wait for approval before an agent proceeds. Validated against a published JSON Schema, so an assertion about governance is checkable rather than decorative.
The fragment answers what you assert about other people. A directory record of the organizations, people and products you are the authority for, with a date on every claim and an expiry after which it stops calling itself current — which is the difference between a directory and a pile of stale strings.
The sealed record answers what actually happened. Completed cross-organizational work, frozen as canonical JSON with its hash at the moment it resolved, published and re-verifiable offline by anyone. Not a log you are asked to trust; bytes that either hash to what was claimed or do not.
Publishing is not the same as being readable
A document at a fixed path is necessary and not sufficient. Two organizations can both serve valid handshakes and still be unable to work together, because the second half is agreement about vocabulary: the same word for the same capability, the same shape for the same claim, the same rule for when a fact goes stale.
That is why conformance is a level rather than a badge. Serving a valid handshake makes you discoverable. Publishing a charter that passes every static check makes you legible. Only the third level — the runtime facts about authorization, revocation and audit, read from a register rather than from you — makes you accountable, because those are the three questions no file can honestly answer about itself.
Why it matters more for agents than for people
A person evaluating an unfamiliar company reads its website, forms a judgement, and tolerates ambiguity. That process does not survive being run ten thousand times an hour by software with no capacity for the benefit of the doubt.
An agent asked to engage an organization it has never encountered needs the same four answers a procurement team needs, in a form it can parse: who this is, what they do, who is accountable, and what they have completed. Publish those and an agent can act. Withhold them and every interaction has to be brokered by a human, which returns the network to the centralized topology the mesh existed to remove.