The Servitor Journal: What to Record and Why Memory Lies
You will remember the hits. The journal exists to keep the misses.
Table of Contents
Why a log
Memory is a reconstruction, not a recording. It favours the vivid event and drops the uneventful weeks, which is exactly the bias a practice needs to resist.
A log does two things: it makes the task testable and it makes the contract visible. When you close a servitor, the log tells you whether the task was real or a mood.
The tradition's own literature is inconsistent about records; the operators who keep them tend to be the ones who improve.
What to write
Date, name, task sentence, feeding method, end date. That is the minimum.
Then one line per feeding: what you did, and anything observable that happened. Not interpretations; observations. "Client replied" is an observation. "The servitor is working" is not.
At the end, one closing entry: success, failure or interruption, and what you would change next time.
Format and fields
Paper is the most durable and the least distracting. A notes app works if you will actually open it; a shared document does not, because the servitor contract is private.
Use the same fields every time. A consistent format lets you compare servitors; a free-form diary does not.
If you use the free servitor design journal, export or copy the entries at closing. A tool can disappear; your log should not.
Review cadence
Review at the feeding, briefly, and at the end date, properly. Do not review daily; daily review turns the log into a worry diary.
At the end date, read the whole log before deciding. The decision is success, failure or interruption, and it should be written before you build the next servitor.
Once a quarter, read the last three closed servitors together. Patterns show up across experiments: tasks that were too vague, feeding that was too frequent, ends that were never set.
Recording failure
A failed servitor is a successful experiment if the failure is recorded. Write what did not happen, what you did, and any external event that explains it.
Do not rewrite the task after the fact to make it fit. That is the one move that destroys the value of the log.
If you cannot face writing the failure, write one line: "closed, no result, reason unknown". Even that is better than a silent deletion.
Privacy
The log contains names, tasks and sometimes personal details. Keep it out of shared drives and do not publish it.
If you write about other people, use initials. The log is for you, not for an audience.
Back it up if it is digital. A practice that loses its records every year cannot learn across years.
What a good entry looks like
A useful entry is short and specific: date, feeding done, one observation, one decision. "7 Nov, fed, no reply from the two proposals, keep schedule" is enough. It takes thirty seconds and it survives a busy week.
The observation column is where discipline matters. Write what happened, not what it meant. "The client replied" is an observation. "The servitor opened a channel" is an interpretation that belongs in a separate column, if at all.
At closing, write four lines: task, result, explanation, change. The explanation is allowed to be speculative; the change should be concrete. That is how a log becomes a design tool rather than a diary.
Comparing two servitors is easier when the fields match. If one log has dates and the other has paragraphs, you will compare feelings instead of outcomes.
The quarterly review
At each quarterly review, answer four questions about the last three closed servitors: which tasks were measurable, which feeding schedules were kept, which ends were respected, and which results were explained after the fact.
The answers change the next design more than any single result. A practitioner who notices that every task was too vague will write a better sentence; one who only remembers the hits will repeat the same vagueness with a new name.
Practical checklist
- Date, feeding, one observation, one decision.
- Never write an interpretation in the observation column.
- Review at closing, not every day.
- Read three closed logs together once a quarter.
- Redact names before sharing anything.
A one-page template
Name. Task sentence. Success condition. Failure condition. Feeding rule. End date. Exit method. Those seven lines are the contract, and they go at the top of the page.
Below them, one line per feeding: date, what you did, one observation. At the end, four closing lines: result, explanation, change, date closed.
The template matters because it makes comparison possible. Two servitors recorded with the same fields can teach you something; two diaries cannot.
FAQ
Do I need a special notebook?
No. A cheap notebook with dated entries is better than an expensive grimoire you are afraid to write in.
Should I log every feeding?
One line per feeding is enough. The end-date review is where the detail matters.
What if I forget to log for a week?
Write the gap. Gaps are data: they show you which feeding schedules you actually keep.
Can I share my log?
You can, but redact names and personal details. The value of the log comes from honesty, and honesty needs privacy.
Should I log the feeding words?
Only if they change. The exact formula matters when you revise the contract; otherwise the date and the fact of feeding are enough.
How do I close a log?
Write four lines: result, explanation, change, date closed. Then archive the page; do not keep adding entries to a closed contract.
Should the log be digital?
Either works. Digital is easier to back up; paper is harder to lose focus with. Choose the one you will actually open.
Can the log cover a group servitor?
Yes, but the contract belongs to the group. Keep one page, name the people who agreed to it, and record who fed it on which date. A shared log without names is a rumour.
References
- Hine, P. Condensed Chaos. 1995.
- Carroll, P. J. Psychonaut. 1987.
- Fries, J. Visual Magick. 1998.