What a task is in the tracker
A task is an assignment from the keyholder with any number of conditions and a deadline. The conditions — wearing certain devices, staying locked — must hold continuously until the deadline. That makes a task a monitored state over a period of time rather than a checkbox to tick off.
That is the difference from almost everything else running under this name. To-do lists work the same way: there is an item, and at some point someone ticks a box. What happened between the item being created and the box being ticked is unknown to the list. It never claimed to know — for shopping lists and work assignments that is perfectly sufficient.
Not a to-do: the state must hold
In a D/s dynamic it often is not. "Wear the plug this evening" is not an action you complete, it is a state you hold. The interesting part of the instruction lies exactly in the span the checkbox is silent about. Someone who only reports the end state reports the one second in which they pressed the button, not the two hours before it.
Unlike an inspection, a task does not check a moment but a span of time. The practical difference shows up when reporting. A task without continuous conditions can be reported as done at any time — you did it, you say so, done. With a task that has continuous conditions, the "Report as done" button only appears once the holding period has elapsed. Until then, the same spot shows the remaining time.
That is a small change in the interface with a larger effect on the experience. You cannot report in advance and get the thing off your plate. The only route to the button leads through the time itself, and while you wait, the card on the dashboard is a constant reminder of what currently applies. The task is not sitting in a list for later, it is running.
Conditions: wear the device, stay locked
The card does not just show a countdown either; it shows what is still missing and what to do next. Someone who receives three conditions and has met two of them does not have to reconstruct which one is open. That sounds trivial, but it is the difference between an instruction you understand and one you fail because you skimmed past half a sentence.
Conditions draw on what the tracker records anyway: which device is worn and whether it is locked. Anyone who tracks wear categories like plug or collar alongside the chastity device can require those in a task just as easily.
Two clocks: getting ready and the deadline
A task with continuous conditions raises a question a to-do item never has to answer: when does "continuously" start? If a task is set at 8 p.m. and ends at 10 p.m., but the conditions are only established at 9:50 p.m. — was it fulfilled?
The tracker answers that with a second clock. Alongside the deadline there is a separate "Time to get ready": the window within which the conditions must be established. If it runs out without them being in place, the task counts as missed, regardless of how much time would still be left until the deadline.
Together, the two clocks produce the actual minimum holding time. "Ends in two hours" with thirty minutes to set up means ninety minutes of real minimum holding time. Set up immediately and you wear it longer; use up the setup window and you wear the minimum. That is deliberately arranged this way round: dawdling costs your own comfort, not the task.
Hence the reading rule that matters here: the number of hours in a task is the deadline, not the wear time. This is exactly where misunderstandings appear when a keyholder means "two hours of plug" and enters "ends in two hours." Both values are shown in the form and on the card, so the difference does not have to live in the keyholder's head.
The deadline itself can be set in two ways, depending on how you think about it. "Ends in" takes a relative duration — convenient when the task applies from now on. Behind "Pick a fixed time" you can enter an absolute end instead — convenient when the end is tied to something that is fixed anyway, such as an appointment in the evening. The resulting end time is displayed in both cases, so nobody has to do the arithmetic.
Photo proof: accept or reject
A task can require a photo as proof. The keyholder reviews it and judges: accept or reject. Proof that has already been judged shows that judgement again on any later review, so you do not have to remember what you decided three days ago.
It is worth staying sober about what such a photo proves and what it does not. It shows a moment. It does not show the hour before it. No photo in the world establishes that a condition held continuously — it establishes that it held at the time of the shot, and even that only as far as the image is readable. If what you want is point-in-time evidence, automatic photo inspections are the right tool: they arrive with a code and random timing and check exactly that moment.
Even so, the proof is not mere decoration. It demands a deliberate act at a moment you did not choose yourself, and it puts the result in front of someone else. The combination of deadline and proof creates a bindingness that self-reporting alone does not have. Treating the proof as evidence overrates it; treating it as pointless underrates what an outside look does to an agreement.
Then there is traceability. A completed task disappears from the dashboard immediately, so that only what currently applies is shown there. Below it sits the full list: completed, missed and withdrawn tasks alike. Tapping an entry opens the whole task. The keyholder sees the same structure — active ones at the top, the full list below, with review and withdrawal directly on the card. And every status change also lands in the inbox: set, edited, withdrawn, completed, missed. Anyone who misses an email can read up on what was required instead of relying on memory.
Punishment tasks instead of free text
Until now, a penalty in the penalty log was free text. The keyholder wrote down what was required and later marked the penalty as done by hand. That worked, but it had two weaknesses: the penalty was phrased without any binding structure, and it stayed open until someone remembered to close it.
Now "Task as penalty" leads straight into the task form. Task and verdict are created together in one step, and the penalty inherits everything a task can do: conditions, a deadline, a time to get ready, a photo if wanted. "You will wear it longer tonight" becomes an assignment with an end that is fixed. How an offense reaches a verdict in the first place is covered in the post on the penalty log with verdict loop; this is about what happens afterwards.
The rest almost follows by itself. A completed penalty task closes the penalty on its own — the manual step you could forget disappears. If the verdict is changed or withdrawn, the penalty task goes with it, so no penalty is left standing whose basis no longer exists. And a missed penalty task shows in the penalty log what it stood for. That is the genuinely interesting part: you can see that one offense grew out of an earlier one instead of taking it as self-contained. Two entries side by side tell a different story than two entries where one points at the other.
In keeping with that, the button in the penalty log is now called "Punish" instead of "Mark as punished." The penalty counts as served only once it is marked as done afterwards — the button imposes, it does not settle.
When the AI keyholder assigns tasks
Anyone playing with an AI keyholder via MCP gets the same flow. The AI can set and withdraw tasks, and it can punish with one: task and verdict are written in a single go, referring to the offense it identified. Like every other writing action, that requires a justification and lands in the action log.
For solo players without a human keyholder, this is where AI guidance becomes concrete. A directive that only exists in the chat disappears with the conversation. A task sits on the dashboard, runs down, and gets recorded.
Negotiating before the first task runs
Tasks sharpen the dynamic, and that is their purpose. All the more reason to settle the frame beforehand: which conditions are acceptable at all, how long a holding period may be at most, what happens when something comes up, and how a task gets withdrawn if it turns out to be unrealistic.
The tracker deliberately makes withdrawal easy and reports it visibly. A task nobody wants any more should not keep running because calling it off would be awkward.
Where the proof photos live
Proof photos are images like any others in the tracker, and they live wherever the instance runs. Anyone running the tracker as a Docker container on their own server keeps them entirely in their own hands — with image recognition running locally if wanted, so no photo leaves that infrastructure.
Anyone getting an instance through the portal instead should know that this is something different: the portal is a free favour, and the instance runs isolated but on someone else's hardware. There is no guarantee of availability or continuation there, and no liability. That is not self-hosting, and it should not be called that.
An honest assessment
Tasks change nothing about the foundation this tool rests on. The tracker documents, it does not enforce. It checks conditions against the data it knows — against what is recorded as worn and locked. Recording something other than what you do does not outsmart the task, it leaves the agreement. No software helps with that.
The proof, too, is a human judgement, not a measurement. The keyholder looks at an image and decides. Whether the image is from today, whether it shows what it is supposed to show, whether it says anything meaningful at all — that remains an assessment, and it can be wrong.
And anyone self-hosting their instance has full access to the database. Tasks, verdicts and entries are records like any others, and records can be deleted. That is not a flaw in the design but a consequence of the software being yours. Bindingness here does not come from technical impossibility; it comes from two adults having agreed on something and both being able to see what applies. The task makes that agreement more precise: it states what applies, from when, for how long, and when it is over. Keeping to it is still up to you.
To see how tasks fit together with lock periods, inspections and the penalty log, browse all features in detail.