01
Every message goes back to the chat it came from — with exactly two exceptions
You should be able to: Name the Attendant's two cross-chat exceptions and what gates each of them.
Every action the Telegram handler emits addresses the chat its update came from. That is the default, and the codebase treats deviating from it as a decision requiring a specific, named justification — not a place where 'it would be convenient to also notify X' gets waved through.
There are exactly two exceptions, and both exist only DOWNSTREAM of an explicit button press by the person the message is about: receipt delivery to the inviter, because the joiner chose to be known by joining; and the consent-YES notification to the requester, because a yes IS consent to be known. A decline sends nothing, ever — the requester reads `unavailable`, the same collapse-to-absence rule the core consent machine enforces.
A test walks every flow in the handler and fails on any OTHER cross-chat message. That is a strong claim to make about a chat bot — most messaging products accumulate notification paths over time — and it is enforced structurally rather than by review discipline, because review discipline is exactly the thing that erodes under feature pressure.
Source: Magician — the Attendant
02
The ask loop hands the requester a link — it never messages the hop owner
You should be able to: Explain why the bot never contacts a hop owner directly during an introduction request.
When an introduction needs a hop owner's consent, the bot does not message that owner directly. Instead it hands the REQUESTER a forwardable, single-use `a_`-prefixed link, and the ask travels on the requester's OWN relationship with that hop owner — not on the bot's authority to reach into someone else's chat.
That single design choice avoids a whole category of failure: a non-member who taps the link onboards first and answers second, so nobody outside the system is ever pinged cold by a bot claiming to represent someone they may not even use Magician with. The relationship carrying the ask is a real, existing one — the requester's — not a synthetic one the bot manufactures for the occasion.
It also keeps the Attendant's own reach honest: the conversational layer's tool roster IS its reach. No tool exists that can address a person the bot was not already talking to, so there is no code path — however cleverly an agent might be prompted — that lets an LLM-driven flow discover a way to message someone outside the rule.
03
Two boundaries that outrank every future feature
You should be able to: State the two absolute boundaries and why they sit above ordinary product trade-offs.
No token, reward, or incentive mechanic may ever be an input to standing, routing, ranking, or trust. "Make an introduction, earn a reward" would manufacture exactly the activity the standing invariant (from Trust as a Ledger, Not a Score) exists to refuse — so any future value mechanic sits strictly AFTER a sealed outcome, outside the reputation algorithm, bounded and reversible. The standing invariant test is the tripwire: a reward input would have to break a named test to ship.
No training on private relationship data, by default and by design. No telemetry, no sync, no export path into any model pipeline. A future opt-in is per-graph, explicit, revocable, and logged as a consent event — never a default, never inferred from continued use.
These are called boundaries rather than principles for a reason: a principle is something a team weighs against other considerations, and these two are not weighed. They are the two places a good feature idea gets refused on structural grounds alone, regardless of how much value it might otherwise add — because the product's entire value proposition is that these two things do not happen, ever, to anyone.
