Frequently Asked Questions

Locking, unlocking, inspection and orgasm are each recorded with photo, note and assigned device. A live status shows the current wear time, complemented by a calendar heatmap, monthly overview and goal progress.

A chastity inspection is a keyholder request to verify by photo that the device is still locked. You receive an e-mail and push notification with a deadline (one hour by default, and it can be given in minutes) and, if the device requires one, a five-digit code. Before it expires, submit an inspection entry with a photo showing that code — this proves the photo is live and not reused. Whether a device requires a code at all is your keyholder's decision; with it off, the photo alone is enough. You may read the code off a screen, for instance from the push notification on a smartwatch; the seal number must still come from the seal itself. Inspections cover not only the chastity device but also wear categories such as plug, collar or cuffs, and one can run per category at a time. A missed deadline counts as an offense.

Lock periods are set as fixed or open-ended and define a minimum wear time and a required device. The application monitors compliance and reports deviations.

The system automatically detects offenses such as missed inspections or wear times falling short. The keyholder then rules in a loop and decides whether an offense is dismissed or penalized.

Yes. A task is an assignment with any number of conditions and a deadline: wear certain devices, stay locked. Where the keyholder sets it that way, the conditions must hold continuously until the deadline — which makes a task a monitored state over a period of time rather than a checkbox to tick off. Alongside the deadline there is a separate "Time to get ready": the point by which you must have started; miss it and the task counts as missed. Optionally a task requires a photo as proof, which the keyholder reviews and either accepts or rejects. What that looks like day to day is covered at length in the blog post on keyholder tasks.

A penalty task is a penalty from the penalty log issued as a task rather than as free text. "Task as penalty" leads straight into the task form, so task and verdict are created together 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 instead of staying open in the penalty log until someone remembers it; if the verdict is changed or withdrawn, the penalty task goes with it. A missed penalty task shows in the penalty log what it stood for, so it stays visible that one offense grew out of an earlier one. The AI keyholder can punish this way as well.

The sub records their weight via “New entry” → “Weight”, with a photo of the scale as evidence or, if that is not possible, a short note. One value counts per day. The keyholder defines weighing windows and a target weight and can add, correct or delete weigh-ins. The statistics show the history, the target weight and the BMI. Optionally a missed report counts as an offense, and the keyholder can tie the next orgasm to the 3-day average. The details are in the manual.

The keyholder does that, per sub: in the sub's “Settings” → “Weight” → “Weight tracking”. It is off by default, and until then the sub sees none of it. Weight, height and BMI are health data, which is why it remains opt-in per sub; the values are stored in the instance's database.

An AI assistant that reads the current state via MCP and issues directives within human-defined free-text rules. It serves a human keyholder as relief from the routine — or a sub without a keyholder as a virtual keyholder, connected under self-set rules. It reads the overall picture, sessions, devices, statistics, records, offenses, context, timeline and weight history; it orders lock periods, lock requirements, inspections, orgasm directives, verdicts, training goals, cleaning rules and weight settings; and it maintains notes, appointments and a health hold as context. Every writing action requires a reason and lands in the action log, and a preview shows in advance what a directive would change. The rules stay in human hands, and the function is opt-in and off by default.

Yes. Plug, collar, cuffs and other categories run in parallel, each with its own entries, goals and calendar. This keeps different wear dynamics cleanly separated.

The photo of a sealed key safe or code note is stored locked and stays hidden until the keyholder releases it. This stores an emergency code without it being visible ahead of time.

Yes. Keyholder relationships are each scoped to their own relationship, so data and directives stay separate per wearer.

There is no e-mail invitation: you create an account for her by hand, in the portal under Dashboard → your instance → Tracker users or inside the instance under Users → New user, and pass the credentials on to her. After that you have a choice: the role "user" plus an assignment as keyholder — she directs, you keep administering — or the role "admin" plus demoting yourself to "user", which puts the instance in her hands too. Which one fits when is covered in the blog post on inviting a keyholder.

Push and email notifications report due inspections, deadlines and directives, and can be toggled individually per event type. Push arrives as web push in the installed PWA; on iPhone and iPad this requires the site to have been installed via “Add to Home Screen”. The Technical section explains how the installation works.

In the inbox. It collects everything that was said to you: penalty texts with their reasoning, comments on inspections, messages about requirements and lock periods, reminders and automatic entries. The bell in the app header shows the number of unread messages (shown as "99+" from a hundred onwards), and the same counter appears as a badge on the app icon. Push and email only deliver — the inbox keeps, even when a mail goes unnoticed; that was felt most with penalty texts, because only the keyholder sees the penalty log. Messages that come from system texts appear in your own language, while free text typed by your keyholder stays unchanged. The dashboard banners remain for what needs doing now; the inbox is for what was said.

No. A keyholder can take on a pure keyholder role and does not have to wear a device. The "No own tracker" mode hides your own tracker area and sends the login straight to the keyholder overview. No data is deleted, and the switch is reversible at any time.