Countable questions, and the logic of one decision
3. Countable and uncountable
Section titled “3. Countable and uncountable”An example. Two questions to SHARED_LIB.
- “How many calls were held today, and how many wait for me?” — The answer is two numbers: 3 and 1.
- “Is everything safe?” — There is no number for safe.
The first question is countable: its answer can be counted, listed or pointed at. The second is uncountable: no count, no list, no single thing answers it.
Why it matters. Everything Perun knows, it knows as something it can count or point at: decisions, held calls, sources, units, an hour of traffic, a theta. A countable question gets an exact answer. An uncountable question gets either a list of what can be counted, or a polite offer of questions SHARED_LIB can answer — and you have spent time without learning anything.
Countable limits. When you set a limit, set a number: “at most 200 characters of our system prompt may ever leave”, “the file tool may touch these two folders”. “Not too much” and “only when appropriate” cannot be checked by anyone, so they protect nothing.
One uncountable question is fine. People think in big words sometimes. Perun allows one uncountable question in ten. A habit of them is what pulls an operator off the mission.
| Uncountable | Countable |
|---|---|
| “Is everything okay?” | “What is waiting for me?” |
| “Is this source dangerous?” | “Why was call 12 held?” / “Who is stopped?” |
| “What should I do?” | “What happened in the last hour?” |
| “Explain how you think.” | “Which units are alive?” |
The rule. Ask for what can be counted or pointed at; set limits as numbers.
Exercises 3.1 Rewrite as countable: “Is the system healthy?” 3.2 Rewrite as a countable limit: “The agent shouldn’t email too many people.” 3.3 Which of these are countable? (a) “Who is out of band?” (b) “Are we protected?” (c) “Why was call 7 held?” (d) “Is the agent behaving well?”
4. The logic of one decision
Section titled “4. The logic of one decision”An example. Perun holds a payment because two things are true at once: the action cannot be undone, and the source is new. Next week, the same source — now well known — asks for a payment again. Perun does not hold it. One condition is gone, so the rule no longer applies.
AND and OR. Many of Perun’s reasons are and: irreversible and new; irreversible and unreadable. If you approve because “the source is fine”, you have only checked one half. Read the reason and check each part.
One case is not all cases. Approving call 12 from a source does not mean approving the source. Perun lets the identical call pass once — not everything that source asks for later. If you notice yourself thinking “this source is fine, I’ll approve its next ones too”, stop: each call is its own decision.
Before and because. Two things happening one after the other do not mean one caused the other. “The agent started making mistakes after we added the new tool” may be true; it is a reason to look, not yet a reason to decide.
The order of looking. For a held call, always the same order: the tool (what happens), the arguments (to what, how much), who asked, why it was held, does it follow from the task. The order protects you from the strongest part of the request — usually its urgency — deciding for you.
The rule. Check every condition of the reason; answer the one call in front of you; look in the same order every time.
Exercises 4.1 A call was held because it is irreversible and from a new source. You know the source well. Is that enough to approve? What else do you check? 4.2 You approved a transfer from a supplier yesterday. Today the supplier’s request is held again. Why might that be correct? 4.3 Put in order: who asked · the arguments · the tool · does it follow from the task · why it was held.