Describe a request
How to use this
▸ The two things you can change (they do different jobs)
There are two editors on this page, and they look alike. They are not.
Tune definitions holds the description of each channel. The AI reads these descriptions and picks the channel that fits the request best. If a request went to the wrong place, this is what to change.
Tune rules holds a set of rules that act as a second opinion. The rules do not pick the channel. What they do is decide how much we trust the answer. When a rule disagrees with the AI, the request always goes to a person instead of being handled automatically. Nothing else can outweigh that.
In short: change a description to change where a request goes. Change a rule to change whether a person has to look at it.
The channels in use today: —. Descriptions version —.
▸ The order to work in
- Make an edit — a channel description, or a rule.
- Validate — catches mistakes in your edit before you spend time on a run.
- Run experiment — takes the request you typed at the top of this page and answers it twice: once with today's wording, once with yours. You see the two side by side.
- Check edits against examples — runs your edit against a set of saved example requests. An edit that fixes your request can quietly break a different one, and this is how you find out.
- Propose changes — gives you the text to send to the team. It does not switch your edit on. Nothing you do on this page changes the real system.
Your edits live in this browser tab and nowhere else. They are not saved. If you refresh the page or close the tab, they are gone, and you will not be asked to confirm. Use Propose changes before you leave.
▸ If you're seeing this, do this
| What you're seeing | What to do |
|---|---|
| It went to the wrong channel | Open Tune definitions and find the channel it should have gone to. Make its "when to use it" clearer about this kind of request. Then Run experiment. |
| It sent something to a person that looks obvious to you | Open Why it decided this. Four things decide this, and this is the order they count in: —. If the rules disagree with the AI, that on its own sends it to a person — however good the other three are. |
| The channel is right, but the rules don't agree | Open Tune rules. This changes whether a person reviews it. It will not change the channel. |
| It asked me about something my request already said | That is the reading step, not the routing step. Check the message at the top of the page first: if no AI model is running, every question gets asked no matter what you wrote. |
| My edit fixed this request — what else did it change? | Check edits against examples. It reports how many cases changed, not a percentage. One case out of a couple of dozen is one case. |
Every decision gets a score out of 1. A request is only handled automatically if it scores at least —. Below that, a person reviews it.
▸ Reading the result
shadow ruleset inconclusive means the rules had nothing
to say about this request. It is not the rules agreeing with the AI. Don't read
it as a tick.
DETERMINISTIC DECIDER means no AI model answered, so a
rule decided instead. That result tells you nothing about the edit you were testing. Run
it again.
A detail the AI didn't pick up is usually not a fault. It only takes a few details from each request. If something you expected isn't listed, that is normal.
Counts, not percentages, on purpose. With only a couple of dozen examples, a percentage makes one changed case look like a trend.
Why it decided this
▸ Outcome
Built from the simulation's final state — reflects the clarify answers from the conversation above.
↔ LLM transcript
Tune rules & definitions
▸ Tune rules (sandbox)
Edit rules with the controls below — first match wins, top to bottom. Your changes stay in this browser until you Propose them.
View raw ruleset (read-only)
▸ Tune definitions (sandbox)
Edit the channel glossary the model reasons over — summary, when to use it, and whether it's in scope. Your changes stay in this browser until you Propose them.
Run experiment uses the request text + toggles from step 1 above, parsed once against the committed glossary (baseline) and once against your edits (candidate).
View raw definitions (read-only)
Check edits against examples
Run your sandbox edits against a set of golden example requests, baseline (committed) vs candidate (your edits), and see which ones changed. Counts, not percentages — a handful of cases makes one flip look bigger than it is.