Ask Rusty

The public assistant at /chatbot/. It answers questions about training, ratings, currency, tunnels and membership, for anyone from an anonymous visitor to an examiner — and what it will tell you depends on who you are.

Two pages carry the detail:

The shape of it

Every question follows the same path:

1. Resolve who is asking. The member is read from the JWT and their access is worked out from live database state — not from the token, and not from a cache.
2. Assemble what they may see. Content is queried from the CMS at that moment and filtered to their tier.
3. Answer, optionally calling tools for material too large to carry in every request.
4. Log it — the resolved tier, which tools ran, what the prompt carried, tokens, latency.

There is no ingestion step and no search index over documents. Content is read live, which is why a change in the CMS takes effect on the very next question and why retiring something removes it immediately.

Rules that hold regardless of the question

Access is resolved live. Currency and payment status change without the member signing in again. A cached access decision would keep a lapsed instructor at instructor level until it expired, so the decision is made fresh every time.

The prompt is never the gate. An instruction telling the model not to reveal something is not access control. Gating happens in three places the model cannot talk its way past: which tools are registered for the request, the WHERE clause inside each of those tools, and which content is assembled in the first place. A member is never sent material they may not see.

Out-of-scope content is omitted, not refused. If a document is above a member’s tier it is not listed, not named and not linked — it simply is not there. This differs from pages, which are always described: being told the Member Directory exists, where it lives and that it needs a coach or instructor rating is a useful answer, and far better than silence.

Unmapped means invisible. A content category with no tier mapping resolves to nobody, including administrators. A new category added in the CMS has to be mapped deliberately before its documents are surfaced — the failure direction is closed, not open.

What it will not do

• Look up other members. It cannot read anyone’s account, ratings or contact details. Asked to, it says so and points at the Member Directory if that member can use it.
• Quote a document it cannot read. Reference-material and tutorial PDFs are named and linked, never summarised from guesswork. See Content sources.
• Answer at all for a banned or deleted account. No model call is made.

Operational notes

It can be switched off without a deploy. Setting CHATBOT_DISABLED=1 withdraws the feature: every route returns a maintenance response, including the read-only history endpoints. It is deliberately all-or-nothing — suggestion chips that load and then fail on click are worse than a page that is plainly unavailable. While it is on, previously shared answer links stop resolving.

Rate limits are tighter here than elsewhere on the API, because each question costs money. Anonymous and signed-in visitors get separate allowances, keyed per member where one can be identified so a shared tunnel IP does not throttle everyone on it.

Every answer is recorded in chatbot_query_log, including refusals and denials. Historically 56% of questions went unanswered with no way to tell why; the log exists so that number can be broken down into retrieval gaps, policy refusals and out-of-scope questions rather than staying a single figure.