How to Make a Servitor Without a Sigil
The sigil is a container, not a requirement. A servitor needs a handle and a contract; the handle can be a word, an object or a page.
Table of Contents
Why the sigil is optional
A sigil compresses a sentence into a form the conscious mind cannot read. That is useful for a desire, and useful for a servitor, but it is not the only way to give a construction a handle.
What a servitor actually needs is a unique reference, a defined task and a way to be fed and closed. A name does all three. The mark adds a visual anchor and a physical object to burn, bury or keep.
So the question is not whether you can skip the sigil. It is which container you will actually use consistently.
Container 1: the name
The simplest servitor is a name plus a written contract. You speak the name, state the task, and stop. The name is the handle; the page is the record.
This works well for internal tasks, where the construction is mostly a way to hold attention. It is weaker for tasks that need a physical anchor, because there is nothing to pick up or put away.
Container 2: the spoken formula
A short spoken formula can carry the servitor: a sentence with the name, the task and the end date. Say it at the feeding, in the same words.
The risk is drift. Spoken formulae change slightly each time, and a changing contract is not a contract. Write the exact words down and read them if you need to.
Container 3: the object
A stone, a bowl, a card or a piece of jewellery can hold the servitor as a feeding point. The object is the feeding point; the servitor lives in the contract.
This is the most durable container and the easiest to retire: put the object away and stop feeding. It is also the easiest to turn into a shrine you check compulsively.
Container 4: the drawing
A drawing that is not a sigil also works: a figure, a room plan, a diagram of the task. The requirement is that it points to one servitor and no other.
This is useful for spatial tasks, such as a ward for a room or a route. The drawing can be the map and the handle at once.
Container 5: the written contract
The page is the least magical and the most useful. One page: name, task, success condition, feeding rule, end date, exit method.
A servitor can live entirely on that page. Read it at the feeding, sign the closing entry at the end. This is the container I would recommend for a first servitor, because it makes the contract visible.
Choosing one
Pick the container that matches the task and the operator. Internal task: name or page. Spatial task: drawing or object. Public or shared task: page, because other people need to read it.
Do not use three containers for the same servitor unless you have a reason. Each container is another thing to maintain, and maintenance is where servitors turn into habits.
Moving between containers
Containers can change without changing the servitor, but the change should be written down. If you start with a name and later add an object, note the date and the reason. The name stays; the handle becomes physical.
The reverse is also common: an object that becomes inconvenient is put away, and the servitor continues on the page. That is a valid migration, provided the feeding rule is updated at the same time.
What you cannot do is run two containers with different contracts. A name with one task and an object with another is two servitors sharing a label, and the operator will not know which one is being fed.
A first servitor on one page is enough: name, task, success, feeding, end, exit. If the page is clear, the absence of a sigil is not a gap. If the page is vague, a beautiful sigil will not fix it.
A first servitor on one page
Write six lines: name, task, success condition, failure condition, feeding rule, end date. Add the exit method underneath. That page is the whole servitor; everything else is a container for it.
Read the page at each feeding. If you find yourself adding clauses during the week, stop and write them as a dated revision instead. A contract that grows silently is a contract you cannot close.
Practical checklist
- Choose one container and write it at the top of the page.
- Write the task as one sentence with a number and a date.
- Write the feeding rule and the exit method.
- Date the page and sign the closing entry when it ends.
- If you migrate containers, note the date and keep the name.
When the container is a place
A room can hold a servitor if the feeding happens in the same spot every time. The place is the handle: you enter it, you feed, you leave. The boundary of the room does the work a mark would do.
The risk is that the place becomes charged for everyone who uses it. Keep the feeding point small and explain it if someone asks. A whole room as a container is harder to close than a stone on a shelf.
FAQ
Is a servitor without a sigil weaker?
No. The sigil is a container, not a power source. A written contract with a name is a complete container.
Can I add a sigil later?
Yes, but treat it as a revision: same name, same task, new mark, with the date written down.
What is the minimum viable servitor?
A unique name, one task with a success condition, a feeding rule and an end date.
Can I keep the contract in a notes app?
Yes. The container is the page, digital or paper. Back it up and keep it out of shared folders.
Can I destroy the object and keep the servitor?
Only by moving the contract to another container first. The object is a handle; the page is the record.
References
- Carroll, P. J. Liber Null. 1978.
- Hine, P. Condensed Chaos. 1995.
- Fries, J. Visual Magick. 1998.