01
One command, four files, a page
You should be able to: Run the on-ramp and know what each file it writes is for.
The whole on-ramp is one command:
npm create @flashyos/mesh-node -- yourdomain.com --email you@org.com
It writes the four documents a node publishes, plus a page that explains them: flashyos.roles.json (your AAO charter — the thing that reaches L2), public/.well-known/flashyos.json (your flashyos/1 handshake — the first file a stranger reads), directory.fragment.json (your directory/1 fragment — how your org enters the record), and .github/workflows/mesh.yml (a workflow that re-checks L2 on every push, gated to your default branch). MESH_NODE.md records what was written and what is left to do.
Source: Flashy OS — @flashyos/create-mesh-node
02
It runs the real validators on its own output
You should be able to: Explain why the scaffolder verifies rather than just generates.
A scaffolder usually only promises that its output is correct. This one checks: it runs the real validators — validateCharter, every static conformance check, and validateHandshake — over the files it just wrote, and prints whether you reached L2. "The claim is checked, not asserted." You see the verdict, not a hope:
✓ L2 reached — the charter passes every static check and the handshake is valid.
This matters because it applies the estate's own rule to your first step: a claim about conformance is verified, not declared. You do not leave the on-ramp wondering whether your charter is valid — the tool has already run the same checks a stranger will.
Source: Flashy Academy — Machine-Readable, and Why It Matters
03
No account, nothing published — the two steps that are yours
You should be able to: Serve the files at your domain and confirm L2 from the outside.
The on-ramp writes files into your repository and verifies them locally. It "never phones home, mints a credential, or publishes anything." That is deliberate — your presence in the mesh is your own domain serving your own files, not a row in someone's database. Which means two steps are yours, and only yours.
First, serve the two files at your domain, so a stranger can fetch them: https://yourdomain.com/.well-known/flashyos.json and https://yourdomain.com/flashyos.roles.json. This is the committed-is-not-served rule in action — the files being correct in your repo is not the same as them being live at your URL.
Second, confirm it from the outside, the same way anyone else can: npx @flashyos/conformance yourdomain.com --level 2. If it passes against your live domain, you are on the mesh at L2 — verified by a fetch, not by your own say-so. That external confirmation is the whole difference between claiming membership and holding it.
Source: Flashy Academy — The Verifiable Record
04
The floor, not the ceiling
You should be able to: Describe what to do after L2 to grow your AAO in the mesh.
L2 is a floor, not a finish line. The scaffolded charter passes from the first line so you are not blocked, but it is a starting point you edit as your organization takes shape — real roles, real thresholds, the accountable human who is actually accountable. The Writing Your Charter course is how you take it from passing to true.
From L2, the mesh opens up. You can open a front door that says which lanes your organization accepts and what a rung costs (Opening a Front Door), enter the record so settled work with other organizations appears (Entering the Record), and build agents that act for your organization under the SDK (Building a Mesh Agent). Each is a file or a package away, because you are already readable.
That is the shape of joining: one command to become readable and reach the floor, then a series of small, verifiable steps to become a full participant. You are not applying to a platform — you are publishing an organization the mesh can read, and growing what you publish.
Source: Flashy Academy — Opening a Front Door
