Every call to the model starts from a prompt: a system message that says who the model is, the rules it follows and the JSON shape it must reply in, and a user message that carries the facts for this call and what to do with them. This tab shows each one and lets an admin change it. What you see here is exactly what the model receives. The text lives in the database and nowhere else: there is no hidden default that a call falls back to, so when you are debugging a reply you are always reading the prompt that produced it.

​
Seeding

The code carries a catalogue of prompts with seed text for each. On a new deployment the table is empty and every prompt shows a missing badge; the job that needs one fails with a message naming it until it is seeded. Choose Seed missing prompts at the top of the tab, or from a terminal:
Seeding writes only the rows that do not exist. When a release adds a new prompt, the same button or command adds its row and leaves your edits to the others alone.

​
Editing a prompt

Each prompt is a panel with the two messages and a max tokens budget. A badge says whether the stored text is the same as seed or has been edited, with the date it was stored. Save writes your version; it applies to the next call. Restore seed text copies the catalogue text from the code over your edit, and only when you ask: a missing prompt opens with the seed text filled in for review, and Save and seed writes it. Every save, seed and restore is recorded in the audit log. Placeholders in double braces, such as {{owner.name}}, are listed above the editor for each prompt. The job that sends the prompt fills them in; an unknown placeholder renders empty rather than failing. Lists the engine owns, such as the allowed outcomes, document keys and step actions, arrive through placeholders too, so an edited prompt stays current when a new one is added in code. Keep the instruction about replying with a JSON object and the shape that follows it: the app validates the reply against that shape and drops anything it does not recognise.

​
Executor Kit

Drafts the signed letter naming the executor and authorising them to access, close or memorialise online accounts. Sees the client’s name, executors, account inventory, vault locations, existing text and notes.
Turns the client’s vault entries into a route for the executor: where each thing is and who holds any physical key. The vault stores locations, never secrets, so the model never sees a password.
Drafts what should happen to each account, critical accounts first, following any wish the client states in their notes exactly.

​
Knowledge base research

These are the four jobs described under AI research. Each receives the provider brief: the provider record’s current summary, policy, outcomes, documents and contact channels.
Sees the crawler’s candidate pages (URL, title, matched terms, emails, forms, snippet) and picks the policy page, the help page, up to six pages worth reading in full and the contact channels, using only URLs and addresses from the list.
Sees the fetched source pages and any pasted terms, plus the allowed outcomes and document keys, and returns the summary, death policy, outcomes, documents, contact channels, turnaround, jurisdiction notes, confidence, citations and open questions.
Sees the outcome to reach, the reference pages, the managed action types and the template placeholders, and returns named steps in the engine’s format. The result is validated before it can be saved as a draft playbook.
Sees the recorded death policy (in the brief) and the current page text, and reports what changed, which outcomes are affected and what an operator should do.