Policies

A policy is a short document of standing rules for how Ronja should work. Ronja is given it at the start of every conversation, so a rule you write once applies to every answer after it — without you repeating it.

There are two, and every conversation carries both:

Policy	Who writes it	Who it applies to	Cap
Your policy	You	Your own conversations	10,000 characters
Organization policy	Admins	Every conversation and every automation in the organization	20,000 characters

Where the two disagree, the organization policy wins.

Your policy

Open the account menu and click Your policy. The page holds one document, yours alone: nobody else’s answers change because of it, and nobody else reads it.

The kinds of rule that belong here are the ones you would otherwise repeat in every chat:

Report amounts in SEK.
Prefer tables over charts unless I ask for a chart.
For revenue questions, read the revenue definitions note first.

Organization policy

Admins reach it in the admin sidebar under Data & Knowledge → Organization policy. It holds the rules that are true for the whole company:

The fiscal year runs January to December.
Exclude test accounts from every customer count.
For definitions of our revenue metrics, read the revenue definitions note first.

Only admins can edit it, and — unlike your own policy — it is applied to everyone’s conversations rather than shown to them in the app, so most people never read the rules their answers follow. Keep it short, keep it true, and prefer a rule that points at a document over a rule that tries to be the document.

From outside the app

The organization policy reaches work done from outside Ronja as well. ronja context — the command a coding agent runs after signing in with the Ronja CLI — prints it under Organization policy before anything else about the API, and the API serves the same document at GET /api/v2/policy/org to every member of the organization. So a rule you write here — “every table name starts with the source system” — is read by Claude Code, Codex or any other agent building against your organization from a terminal, not only by Ronja in a conversation.

An admin can also change it from there. ronja context includes the exact command in the policy section when you are signed in as an admin — a PUT /api/v2/policy/org that carries the version you read, so two people editing at once cannot overwrite each other (the later write is refused with the current text to re-apply against). It works with a personal access token — the kind ronja login creates — because that token acts as you; a token from the admin API Tokens page cannot write it, and neither can Ronja herself from a Saved Agent or an automation. A coding agent working under your token is told to change it only when you ask, and to show you the new text first — the History page then records the change as Edited by hand, by you. Every other member can read it and is told only an admin can change it.

Write rules, not notes

A policy holds rules for how to work. It is not the place to record what your data means or what happened in a conversation. Each line should be one of two things:

Unconditional — “Report amounts in SEK.”
A pointer — “For revenue questions, read the revenue definitions note first.”

What does not belong: what happened in a conversation, a number, a status, or anything that will be out of date next week. Every future conversation reads the whole document as the present, so a line about last quarter’s migration will be read as if the migration were happening now.

Knowledge itself lives elsewhere — in notes inside a feature, in the data dictionary, in a codex. A policy line names the place and says when to read it. See How Ronja learns for the whole picture.

Edit a policy

Click Edit.
Write your rules. Markdown is supported, and the counter under the box shows how much of the cap you have used — you cannot save over it.
To point at something in Ronja, click Insert reference, search for the note, table, feature or another resource by name, and pick it. The reference goes in as a link Ronja can open, and it keeps working when the resource is renamed.
Click Save (or press Cmd/Ctrl+Enter; Esc cancels).

Each save makes a new version, shown under the document as Version 3 and listed under History — when it was made, and whether it was written by Ronja or edited by hand. History shows the 20 most recent versions; click Restore on any of them to bring that version back as the newest one. The version you are on is marked Current rather than offered for restore, and the oldest entry — Empty — before anything was written — is how you take a document back to nothing. The last 50 versions are kept.

If the document changed while you had it open — because Ronja wrote to it, or another admin saved the organization policy — the save is refused rather than silently overwriting, and you are shown what is stored now alongside two choices: Keep my text writes yours over it, Load the stored version brings theirs into the editor and keeps your text below so you can merge by hand.

When Ronja writes it for you

Tell Ronja a lasting preference in a conversation — “always report in SEK”, “I prefer tables” — and she can add it to your policy herself. You see exactly what she did: a card in the chat reading Policy updated, with the lines she added or removed and an Undo button. Click it and the change is reversed, and the card reads Undone. If the policy has moved on since — you edited it, Ronja wrote again, or the change was already undone from another tab — Undo says so and links you to the document rather than wiping what is there.

A change to the organization policy is different: it stops and asks first. Ronja shows an approval request reading “Change the organization policy — every run in the organization is told this”, with the proposed document underneath — what changes is highlighted against the current text, and the character count after the change is shown against the cap — and nothing is written until an admin approves it. Ronja cannot change the organization policy from an automation, a Saved Agent run, an API token, or a Slack or Microsoft Teams channel at all — only with an admin’s approval, in a conversation in the app. An admin can also edit it directly: in the editor, or from outside the app. In Slack and Microsoft Teams she cannot change either policy: the ability is not there at all, so a preference you state in a bridged channel is not written down. Tell her in the app instead, and the rule then applies to your Slack and Teams conversations too.

Policies, Knowledge and personal memory

Before policies, standing rules accumulated in two places Ronja wrote for herself: Knowledge, the organization-wide base on the admin Knowledge page, and the Memory tab on your account page. Both are now frozen. Ronja still reads them in conversations, exactly as before — nothing about how she answers has changed — but she no longer adds to either one. New rules go in a policy, where a person wrote them and anyone who is allowed to see them can.

That leaves the two old surfaces worth a read rather than a clear-out. Knowledge is still correctable: an admin can open an entry, click Curate in chat and tell Ronja what is wrong, and she rewrites or retires it. Personal memory is still yours to edit under Account → Memory. See How Ronja learns and Curate Knowledge.

Your policy shows your personal memory below the editor, read-only, under What Ronja remembers about you — so you can copy anything worth keeping into a rule. Where lines from it have been offered as candidates, they appear above the editor under Suggested from your personal memory: click one to add it as a rule, or Dismiss the lot. Nothing is added to your policy until you click, and the panel only appears when there is something to show.