Manual for Keyholders
As a keyholder you are assigned to one or more subs and control their directives, inspections, and consequences. Your access is clearly scoped to the data, photos, and notifications of your assigned subs. This section explains the directives available to you. If you are also an in-app admin, the user-management rights from the admin section are added on top.
Keyholder overview
After login you land on the keyholder overview with one tile per assigned sub. Each tile shows the current status, active directives, and quick actions.
From here you open a sub's detail view or trigger common actions directly. If you keep several subs, this lets you stay on top of things without switching into each profile individually.
Request inspections
An inspection asks the sub to submit a photo within a deadline — with a handwritten five-digit code, if the device requires one. The deadline defaults to one hour and can be given in minutes. Inspections cover not only the chastity device but also wear categories such as plug, collar or cuffs — optionally targeting one specific device. One inspection can run per category, so the overlap protection against duplicate requests from a human, the AI, and automation applies per category rather than per sub, and the chastity device counts as its own.
Whether a code is required is up to you per device, via the "Require inspection code" switch; the sub can see it but not operate it. With it off, the photo alone is enough and a self-recorded inspection also satisfies an open request — a request that was issued with a code, by contrast, still requires it. Optionally you enable a two-stage escalation (off by default): first a reminder, then an automatic mark as "not fulfilled" via a system entry that lands in the offence record. If an uploaded photo is not confirmed, you see the reason, such as a missing code, different digits recognised, or a wrong seal number.
Automatic inspections
Instead of triggering every inspection by hand, you can enable automatic inspections. These are distributed randomly across the day, within a waking window you can configure. Optionally you narrow the distribution further to a fixed trigger window, that is, a span of hours. If you change anything about the distribution, the current day is re-rolled — inspections already sent stand and still count.
This keeps inspections unpredictable without waking the sub at night. The overlap protection applies here too, per category: while an inspection is running on one category, no second one is issued for it. A re-lock that ends a cleaning break is additionally followed by an automatic inspection 15 to 45 minutes later, or after just 5 to 15 within the sleep window. It takes the place of the next inspection of the daily plan that has not been delivered yet, so the total stays the same; if none was left for the rest of the day, it comes on top. The rule is fixed, has no setting of its own and depends on the master switch for automatic inspections.
Lock periods and lock requirements
With a lock requirement you set a minimum wear time, a mandatory device, and the "cleaning permitted" flag. The sub then sees a countdown until the earliest possible opening.
If a mandatory device is set, wearing a different device is detected. Hard, system-side enforcement of a wrong device is an admin function (see the admin section); as a plain keyholder you specify the device as a requirement.
Scheduled directives
You can schedule directives with a delay or for a fixed point in time. Until it triggers, a scheduled directive stays invisible to the sub so they cannot anticipate it.
As long as it has not fired yet, you can cancel a scheduled directive in advance. This suits surprise locks or staggered directives spread across several days.
Orgasm requirements and training goals
An orgasm requirement defines a time window, optionally a mandatory type, and whether an opening is permitted for it. The sub fulfils it by logging a matching entry within the window.
With training goals you set a minimum wear time per day, week, or month. The sub sees their progress in the statistics, and you can tell early if they are falling behind the target.
Set a task
In the form, define the conditions — which devices are to be worn and whether the sub must stay locked — and set the deadline as a duration via "Ends in" or, behind "Pick a fixed time", as an absolute point in time; the resulting end time is displayed. "Time to get ready" is set separately and comes off the deadline: "ends in two hours" with thirty minutes to get ready leaves ninety minutes of minimum holding time. The stated hours are the deadline, not the wear time — both are shown in the form and on the card.
If you require a photo as proof, it appears for review after the task is reported, and you accept or reject it; proof that has already been judged shows that judgement again on any later review. Active tasks, the full list, review and withdrawal are all in the keyholder overview. Every status change — set, edited, withdrawn, completed, missed — also goes to the sub's inbox.
Keep the offence record
Offences — whether logged by you or generated automatically by missed inspections — land in the offence record. Through the judgement loop you assess an entry and set the consequence.
The sub can view their own offence record, so directives and consequences stay transparent for both sides.
Punish with a task
In the offence record, choose "Task as penalty" when passing judgement — you go straight into the task form, and task and verdict are created in one step. The penalty inherits everything a task can do: conditions, a deadline, a time to get ready and, if wanted, a photo as proof.
A completed penalty task closes the penalty by itself, so you no longer have to mark it as done by hand. If you change or withdraw the verdict, the penalty task goes with it; a missed penalty task stays visible in the record and shows what it stood for. Note the renamed button: "Punish" imposes the penalty, and it only counts as served once it is marked as done afterwards. The AI keyholder can punish this way as well.
Manage and personalise subs
You can set a sub's account language — useful when a sub receives German mail but prefers English; the language controls both the interface and notifications. Per user you adjust the selection lists, such as the orgasm types or the opening reasons.
The start page after login is configurable. If you are a pure keyholder without your own chastity practice, use the "no own tracker" mode to hide your own green tracker.
Advanced options
Two functions are opt-in: via MCP you can integrate an AI keyholder as a virtual keyholder that acts by the configured rules — see the dedicated MCP part of the manual for details. With the Heimdall hardware key box you enforce a lock period physically instead of only agreeing to it digitally.
Both functions are off by default and enabled deliberately. Broader rights such as user management require the admin role — described in the admin section.
Connecting the AI keyholder
The AI keyholder has to be unlocked on the instance first — if you run the server yourself that happens through two environment variables (see self-hosting). If your instance runs on the portal, request it by email to info@trublue.ch, naming the subdomain and the user to be directed. How to tell what is missing: without the unlock the address answers with 404 and your assistant never connects at all. With it set but no sub configured, it connects and every access reports "Server misconfigured". One server always directs exactly one sub.
Then set up a connector in your assistant pointing at https://your-instance/api/mcp and give consent while signed in as an admin — not as the sub. The consent page tells you where you stand: "no write access" means you are not currently signed in as an admin. The AI may then read, but every directive is rejected. If it happened anyway, disconnect the connector, sign in as an admin and connect again.
Setting rules and following along
Before the AI acts, give it rules: admin area → users → settings → "AI keyholder rules (MCP)". The field only appears on an unlocked instance. The "View template" button shows a ready-made rulebook at any time; while your field is empty you take it from there with "Insert template" and adapt it. Existing rules are never overwritten. Without rules the AI acts without guardrails.
The AI does not work on its own in the background — it acts when you ask it to in a chat; a connected connector alone changes nothing. What it does stays visible: lock periods and inspections appear just like ones you set yourself, while verdicts are labelled explicitly — "(AI)" in the discipline ledger and "AI keyholder" as the sender in your sub's inbox. Every executed directive is also recorded with its reasoning — ask your assistant for the action log when you want to know what happened since you last looked, and why.