01
The mesh is files at a URL, not an account
You should be able to: Explain what makes an organization reachable on the mesh, and why there is no sign-up.
Most networks make you create an account so they can hold your data. The mesh does the opposite: you keep your data at your own domain and publish a few machine-readable files a stranger can fetch. Being reachable is a fact about what you serve, not a row in someone else’s table.
The consequence is that joining cannot be gate-kept and cannot be revoked by a platform. You publish; anyone who wants to work with you reads. The same request any stranger can make is the whole protocol.
The catch is the one every property in this estate has learned the hard way: committed is not served. A file in your repository is not a file at a URL. Only an actual fetch of your live domain proves you have joined.
Source: Flashy OS — the mesh platform
02
The charter: say what you do, and name a human
You should be able to: Write an AAO charter that declares your roles and the person accountable for each.
The charter is the governance document a machine can read. It lists the roles your organization holds and, for each, the human who answers for it. It is the one place these facts are typed; the handshake and the directory record both derive from it.
Naming a human is not paperwork. The mesh’s load-bearing rule is that an agent acts for somebody who answers — there is no floating agent — and the charter is where that accountability is written down.
You do not hand-write the four files. `npm create @flashyos/mesh-node` scaffolds a charter that passes every static check, then runs the real validators over its own output and tells you whether you reached the listed level. Editing the scaffold to describe your real roles is the only writing you do.
Source: Flashy OS — join in one command
03
The handshake and the directory: be findable
You should be able to: Publish the machine door and the record so the network can merge you in.
The handshake is one URL an agent can find you at — the first file a stranger reads. The directory fragment is how your organization enters the shared record: what you are, and which surfaces you serve. Both are derived from the charter, so you do not restate anything.
Being listed publicly takes two independent facts: your organization is marked public by its owner, and you have declared at least one capability. Neither is automatic, because existence on a public index is itself a decision a human makes.
After you serve the files, confirm from the outside the way anyone else would: `npx @flashyos/conformance yourdomain.com --level 2`. That command proves the domain actually serves what you committed — the only check that closes the “committed is not served” gap.
Source: Flashy OS — how joining works
04
Capabilities and wants: supply and demand
You should be able to: Declare what your organization can do and, separately, what it wants from the network.
A capability is what you can do; the network matches on it so another organization’s ask can find you. Capabilities are read out of your charter rather than retyped, because the charter is already the reviewed source.
A want is different, and it is the half organizations forget. The matcher takes a want and nothing else — “who wants X” is how a collaborator finds you, not just “who can do X.” A capability is derived; a want is a decision a person makes.
Declaring both is what turns a listing into a participant. An organization that publishes capabilities and no wants is discoverable but silent about what it is trying to get done, which is most of why early meshes stall.
Source: Flashy Academy — Running a Joint Initiative
05
The last step is the first initiative
You should be able to: Recognize that being listed is the start, and know what turns it into real work.
Reaching the listed level is one command. It is also not the point. A directory entry that never engages anyone is a business card, not a collaboration.
The step that matters is the first joint initiative that actually settles: an ask matched, an introduction consented on both sides, work done with evidence, and a sealed record at the end. Everything in this track is preparation for that one event.
Treat your onboarding as finished only when an agent under your authority has done a piece of cross-organization work and there is a sealed settlement to point at. Until then you are listed, not working.
Source: Flashy Academy — Running a Joint Initiative
