{
  "contract": "course-content/1",
  "slug": "the-attendants-one-rule",
  "title": "The Attendant's One Rule",
  "primitive": "The Attendant (Telegram) broadcast boundary",
  "audience": "Anyone designing a chat-native interface that touches real relationships",
  "summary": "How Magician's Telegram-native tier enforces a single structural rule — no cross-chat broadcast, ever, with exactly two consent-gated exceptions — and the two absolute boundaries (no reward-as-trust-input, no training on private data) that outrank everything else in the product.",
  "track": "magician-and-the-trust-mesh",
  "pin": {
    "source": "@magician-network/attendant — the Telegram-native tier: the broadcast rule, the ask-loop link, the two absolute boundaries",
    "ref": "magician:packages/attendant",
    "revision": "03f42daf31b037d028f2661a0764788b2422cd20",
    "state": "current"
  },
  "intro": [
    "The Attendant is Magician as a Telegram bot: a pure, tested handler, a per-member store, consent by button, and the receipt loop happening in-chat. Its most important property is not a feature — it is something it structurally cannot do.",
    "This track reads that boundary closely, because a chat-native interface to a private relationship graph is exactly the surface most tempted to leak — one message to the wrong chat and a private fact about who-knows-whom is out.",
    "Three lessons: the broadcast rule and its two exceptions, the ask loop that keeps requests off the wrong chat, and the two absolute boundaries the whole product will not cross regardless of what a future feature might want."
  ],
  "lessons": [
    {
      "n": "01",
      "title": "Every message goes back to the chat it came from — with exactly two exceptions",
      "outcome": "Name the Attendant's two cross-chat exceptions and what gates each of them.",
      "body": [
        "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": {
        "label": "Magician — the Attendant",
        "href": "https://magician.network/doctrine"
      }
    },
    {
      "n": "02",
      "title": "The ask loop hands the requester a link — it never messages the hop owner",
      "outcome": "Explain why the bot never contacts a hop owner directly during an introduction request.",
      "body": [
        "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."
      ]
    },
    {
      "n": "03",
      "title": "Two boundaries that outrank every future feature",
      "outcome": "State the two absolute boundaries and why they sit above ordinary product trade-offs.",
      "body": [
        "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."
      ]
    }
  ],
  "faqs": [
    {
      "q": "What are the Attendant's two exceptions to 'every message stays in its own chat'?",
      "a": "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). Both exist only downstream of an explicit button press by the person the message concerns. A decline sends nothing at all."
    },
    {
      "q": "Why does the bot hand the requester a link instead of messaging the hop owner directly?",
      "a": "So the ask travels on the requester's own existing relationship with that hop owner, not on the bot's authority to message someone cold. A non-member who taps the forwardable link onboards first and answers second, and nobody is pinged by a bot claiming to represent someone they may not even use Magician with."
    },
    {
      "q": "Could Magician ever add a reward for making introductions?",
      "a": "Not as an input to standing, routing, ranking or trust — that boundary is absolute and is what the standing-invariant test exists to enforce. Any future value mechanic would have to sit strictly after a sealed outcome, outside the reputation algorithm entirely."
    }
  ],
  "related": [
    {
      "label": "Trust as a Ledger, Not a Score",
      "href": "/academy/curriculum/trust-as-a-ledger-not-a-score"
    },
    {
      "label": "Non-Identifying Verification",
      "href": "/academy/curriculum/non-identifying-verification"
    },
    {
      "label": "Magician — doctrine",
      "href": "https://magician.network/doctrine"
    }
  ]
}