Personalities are TOML, not code

DEINO has five sisters — analyst, contrarian, disruptor, historian, institutionalist — and each is a personality loaded at runtime from a TOML file under backend/crates/deino-sisters/personalities/*.toml. There is no sister in code. The engine that takes a personality and produces a SisterOutput is code; the personality itself is a file you can edit in a text editor, save, and the next run picks up. No recompile, no rebuild, no redeploy. The lens is data.

Five lenses, one engine

The five sisters are not five random seeds of the same model. They are five deliberately different lenses, each with its own prompt framing, its own emphasis, its own way of reading the same NodeVersions. What makes them an ensemble rather than five separate answers is that they all reason over the same versioned GNL world model — they disagree about interpretation, not about the facts. The engine — the code that loads a TOML, builds the prompt, calls the provider, parses the output — is shared and fixed. The personality is the part that changes, and it changes without touching the engine.

Why TOML and not code

The choice of TOML is the choice of a boundary. A personality expressed in code drifts: someone adds a helper, the helper grows a branch, the branch becomes a policy, and six months later the lens is an engine in disguise. TOML is deliberately dumb. It holds the prompt template, the framing, the model preference, and a version string — and it refuses to hold anything else. What it cannot express, it cannot accumulate. The format enforces the separation; the engine stays clean because the data cannot reach into it.

The lens is data; the engine is fixed. The format enforces the separation — what TOML cannot express, it cannot accumulate.

The prompt version is stamped, not implied

Every personality TOML carries a prompt version, and that version is stamped on every run. The ensemble that produced an output is reconstructable — the prompt is part of provenance, not an implementation detail. When an auditor replays a decision, they see not just which model and which inputs, but which lens and which version of that lens. A personality edit is a version bump, and the bump is in the manifest.

• Personalities are TOML files, not code — edit a lens without recompiling or redeploying.
• The engine is shared and fixed — five sisters, one loader, no branching on which sister is running.
• Prompt version is stamped per run — the lens version is part of the manifest, part of provenance.
• The format enforces the boundary — TOML refuses to hold logic, so the lens cannot quietly become an engine.

What this buys and what it does not

What it buys is velocity. A new lens — say, a regulator-reading sister — is a new TOML file, not a new crate. What it does not buy is accuracy. A personality is a bias, and a bias is a choice, not a calibration. The sisters produce distributions; the Oracle normalizes them in exactly one place (deino-oracle, INV-1), and whether those distributions are any good is a question for the calibration loop, not for the personality file. We are pre-revenue, building the POC; the personalities run, and the calibration that would earn the word probability is gated (Gate 1b) until it is filled.

A personality is a bias, deliberately chosen. The engine applies it; the calibration loop decides whether the bias was useful. Those are separate projects, and only one of them is editable in a text editor.

— deino-sisters design note

Engine fixed, lenses editable

The separation is the point. A fixed engine means the reproducibility substrate is stable — the code that ran yesterday is the code that runs today, and an auditor replaying a run sees the same logic. Editable lenses mean the ensemble is alive — a new reading of the world is a file save away, not a quarter of refactoring. The personality is the part that should change; the engine is the part that should not. TOML is how we tell them apart.