A platform that lets anyone route a request through a relationship they do not own has turned trust into a resource other people can spend. Magician refuses that by construction: consent belongs to the edge owner, always, and nothing shortcuts it.
This track is about the mechanics that hold that rule up, and the one it inherits from the rest of the estate: agents suggest, humans consent, at every stage of autonomy.
Three lessons. Trust as a Ledger, Not a Score is worth taking first — this track assumes you already have the edges these rules protect.
Lessons
01
Every request lands proposed, and nothing skips the queue
You should be able to: Explain why the system has no code path that constructs a consented hop directly.
When one person's path is requested to cross through a relationship somebody else owns, the request lands in a `proposed` state — never `consented`. There is no code path anywhere in the system that constructs a consented hop directly; consent is only ever the edge owner acting on a proposal that already exists.
That is a narrower guarantee than it sounds, and the narrowness is the point. It would be easy to build a fast path for 'obviously fine' requests that skips the owner entirely — a mutual connection, a low-risk ask, a request from someone already trusted. Magician has none of those exceptions, because every exception is a future case somebody discovers can be gamed.
The consequence for anyone building on top: you cannot construct a shortcut around this in your own integration either. The state machine is the only path from proposed to consented, and it always runs through the person whose relationship is actually being spent.
A decline is indistinguishable from a path that never existed
You should be able to: State what toRequesterView does, and why a decline and an absent path must render identically.
Private is the default tier, and a declined introduction renders to the REQUESTER exactly as a path that never existed. `toRequesterView` collapses both cases into one, and a test compares the two objects for deep equality — not similar output, identical output.
The reasoning is social, not just technical: if a decline looked different from 'no path found,' a requester could learn something about a relationship the owner chose not to expose — that it exists, that it was considered and refused, who was asked. Any of those is information the owner did not consent to share. Collapsing decline into absence is what makes 'no' genuinely private rather than private-with-a-tell.
This is the same doctrine the wider estate holds for organizations — a private org is indistinguishable from a missing one — applied to a person-to-person relationship instead of an org-to-org one. The shape of the guarantee does not change with the scale of who is protected by it.
03
A multi-hop introduction needs every hop's yes — never a partial one
You should be able to: Explain why an introduction across three relationships cannot proceed on two consents.
An introduction that crosses more than one relationship needs a yes from every hop owner along the path, not a majority, not the strongest link, not just the last one before the target. One refusal anywhere in the chain stops the whole introduction — there is no partial-yes state that lets a path proceed missing one consent.
This is the practical test of whether a system means 'consent-gated' or just says it. A system that lets a strong majority of hops override one holdout has built a voting system, not a consent system — and a person whose relationship gets overridden by the other hops has had their edge spent without actually agreeing to it.
Agents suggest; humans consent — this is inherited estate doctrine and it is never bent at any stage of autonomy, however capable the agent proposing the introduction becomes. An agent can draft the path and can even ask every hop owner on the human's behalf, but every yes in the chain has to be a real one.
Frequently asked
Can a request skip the owner's consent for a low-risk or obviously fine case?
No — there is no code path in the system that constructs a consented hop directly. Every request lands proposed, and the only way to `consented` is the edge owner acting on that proposal. There are no exceptions carved out for cases that look safe.
Why must a decline look identical to a path that never existed?
Because a decline that looked different would leak information the owner never agreed to share — that the relationship exists, that it was asked about, who asked. `toRequesterView` collapses both into one, verified by a deep-equality test, so "no" is genuinely private rather than private with a tell.
What happens to a multi-hop introduction if one hop owner declines?
The whole introduction stops. Every hop owner along the path has to consent — there is no partial-yes state, no majority override, no proceeding on the strongest links. One decline anywhere in the chain is enough to end it.
