Every other course in this track explains a rule. This one is the shortest path to seeing the rules run: @magician-network/cli is a local-first terminal client over a private store, and the fastest way to understand consent, sealing and standing is to watch them happen on your own machine.
Three lessons: standing up the store, seeding a demo graph, and why that demo graph can never pass for a real one.
Trust as a Ledger, Not a Score and Consent Before Every Crossing are worth taking first — this walkthrough assumes you already know what the CLI is enforcing and why.
Lessons
01
Standing up a private store
You should be able to: Initialise a local Magician store and explain what "local-first" means for where your data lives.
`node packages/cli/dist/cli.js init --owner person/you` creates a private `.magician/` store on your own machine, owned by the identity you name. Local-first here is a real architectural choice, not a slogan: your relationship graph starts and stays on your own device unless you explicitly choose to publish or sync any part of it.
That matters because of the two absolute boundaries the whole system holds to: no training on private relationship data, by default and by design, and no telemetry or sync path into any model pipeline unless a person opts in per-graph, explicitly, revocably, with the opt-in itself logged as a consent event.
A local-first store is what makes that boundary enforceable rather than promised. Data that never leaves your machine by default cannot be trained on by accident — there is no pipeline to misconfigure, because there is no path out in the first place.
You should be able to: Populate a store with a demo graph and read the rules it demonstrates as you go.
`seed --demo` populates your fresh store with a fictional relationship graph — trust edges, a few intents, an introduction or two already sealed — so you can walk the CLI's commands against real-shaped data without needing a network of actual contacts first.
Every demo persona carries `demo: true` on its record. That is not incidental metadata: any interface rendering this data is expected to read that flag and make the fictional nature of the graph visible to whoever is looking at it, because a demo graph mistakable for a real one is a fabricated claim about real people's relationships.
Use the demo to explore: propose an introduction across two demo hops and watch it land `proposed`; try to consent on behalf of an edge you do not own and watch the state machine refuse; check a declined path and confirm it renders exactly like one that never existed. The rules from the earlier courses in this track are not abstract once you can run them.
03
Why the demo can never pass for real
You should be able to: State why no demo persona may ever carry a real name, and what test enforces it.
The rule is blunt: never seed real names into the demo. Every demo persona is fictional, and the `demo: true` flag is how every consumer of the graph — the CLI, the website's live demo, any future integration — knows to treat it as fiction rather than as a real relationship graph belonging to somebody.
This connects directly to the consent doctrine the rest of the track teaches. A relationship graph is exactly the kind of record that must never be published or implied without the people in it consenting — so a demo has to be constructed from nothing, not lightly anonymised from something real, because anonymisation is reversible in ways a reader cannot always detect and fabrication from scratch is not.
The practical habit this leaves you with, beyond Magician itself: when you build a demo for anything that touches real relationships, build it from names and edges that were never real in the first place. A demo that started real and got scrubbed is a liability waiting for the scrub to have missed something.
Frequently asked
What does "local-first" mean for a Magician store?
Your relationship graph is created and lives in a private .magician/ store on your own device by default — nothing syncs, trains a model, or leaves your machine unless you explicitly opt in per-graph, with that opt-in itself logged as a consent event.
What does seed --demo actually populate?
A fictional relationship graph — trust edges, intents, a sealed introduction or two — built from data that carries demo: true on every record, so any interface reading it can make its fictional nature visible rather than presenting it as real.
Why can a demo graph never use real names, even anonymised ones?
Because a relationship graph is exactly the kind of record that must never be published or implied without consent, and anonymisation is reversible in ways a reader cannot always detect. Building the demo from names that were never real avoids that risk entirely rather than trying to scrub it away.
