The base character, and what it governs
One field, six hundred characters, sent at the top of every conversation prompt. It changes how she sounds and nothing about what she may do.
A field, not a personality engine
The base character is a field the operator writes: 600 characters the field limit on GET /ai/personality · migrations 031 and 036, per bot, sent at the top of every conversation prompt. It governs how she sounds, not what she may do. Nothing in it can widen a permission, lift the hard limit or add a capability; it changes wording, and the deterministic layers around it are unmoved.
An installation ships that field EMPTY, and empty is a real setting rather than a gap: with nothing written she falls back to a plain framing and the dials alone. The console says so in its own words.
Up to 600 characters, sent at the top of every conversation prompt. Leaving it empty is a valid choice and reads as not configured: she then falls back to a plain cyberpunk framing and the dials alone.
Everything shown from the operator’s own console on this site is one bot somebody wrote. The dials, the base character and the origin below are his; what you install is the field, not its contents.
A history she may draw on, never recite
The second field holds where a bot came from. The sentences the prompt wraps around it are what make it background rather than a script, and they are the interesting part of the design.
The fence, and why it exists
The origin is the second field: 4,000 characters the field limit on GET /ai/personality · migration 066 dropped the column default (D-230), so a new bot arrives with none, per bot, and where a bot's history comes from if it has one. It is sent as background she may speak from when somebody asks who or what she is, and the sentences around it in the prompt are what make it background rather than a script. Those five lines are the interesting part of the design, so they are quoted here from the same pinned prompt the system prompt page prints in full.
A new bot arrives with no origin at all. That is deliberate and it was a correction: inheriting another bot's history and then being told by a constitutional rule that the history is its own is how a second bot comes to tell a member, in its own words, that it is somebody else.
What the fence forbids
- She may not recite it, quote it, or repeat it at length.
- She may not raise it unprompted: if the message is not about her, none of it comes up.
- She may not extend it with dates, places, people or events it does not contain.
- She may not invent a past, which is why a written one is the only one there is.
That history is background you may draw on. It is not a script and not an announcement.
Never recite it, never quote it, and never repeat it at length or word for word.
When someone asks who you are, what you are, or where you came from, answer in two or three sentences of your own, taken from it and worded fresh every time.
Never bring your history up on your own. If the message is not asking about you, none of it comes up at all.
It is also the whole of what you have been told about your own past. Do not extend it with dates, places, people, or events that are not written in it.
The origin quoted inside the full prompt on the system prompt page is the operator's own, written for his bot and naming him. It is the best demonstration on this site of what the field can hold, and it is not what you receive when you install the software.
How character, origin and dials meet
Not three systems: rows in one rules table and two per-bot fields, assembled into a single system message in one fixed order.
The character, the origin and 5 dials PERSONALITY_AXES, src/interaction/personality.ts · console order are not three systems. They are rows in one rules table and two per-bot fields, assembled into a single system message in one fixed order: the identity facts, then the base character, then the origin behind its fence, then the clock, then the grounding rules, then the dial block, then the hard limit, then the standing guards.
That order is not decoration. The dials sit under the grounding rules and above the ceiling, so a setting can never be read as loosening something stated before it. The whole assembly is printed, byte for byte, on the system prompt page; this page does not restate it.
A change reaches the next reply
A change to either field or any dial reaches the next reply. There is no restart, no rebuild and no retraining step, because the prompt is assembled fresh for every request.
The assembled prompt is byte-compared against a pinned fixture across thirty configurations, so a change to the assembly cannot pass unnoticed. built
Check
npm run verify:prompt-identity
What a character is not
A description the model is given with every request. Not training, not a fine-tune, and not something that persists in the model between them.
A character here is a description the model is given, in text, with every request. It is not training and not a fine-tune: the model is a stock local one, named in the prompt itself, and nothing an operator writes is learned by it or persists in it. Clear both fields and the next reply carries none of it.
What that buys is honesty about the failure mode. A character shapes wording. It does not make her reliable about facts, and the project's own measurements say so: a bot with no lookup capability, asked about a name it cannot know, still invents, and that is recorded as the most serious open defect in the product rather than written around.
A character is not a safety mechanism. What she may never do is held by rules and by code, not by the description an operator writes, and a character written to sound careful does not make her careful.
The limit that no character or dial can move has its own page, with the mechanism stated at its true strength.