Casefile

Overview Schema Source Related Servers Discussions Admin

Add verdict

add_verdict

Records the outcome of one review check in the current pass, filing passed, partial, unverifiable, or failed results with evidence for task closure.

Instructions

Files the outcome of one review check, as run by the task's assignee within the current pass.

A pass starts with each entry into in_progress, a return after a wait in open included. Only verdicts of the current pass count for closing, and the latest verdict on a check replaces the earlier ones: a failed verdict is filed when it happens, like a passed one. Verdicts of earlier passes stay in the case without counting. close_task also takes verdicts, together with the closing.

Input Schema

TableJSON Schema

Name	Required	Description
`key`	Yes	Task key `PROJECT-N`, case-insensitive; a previous key of a moved task addresses it as well. An unknown key is refused with `task_not_found`
`outcome`	Yes	Outcome of the check: - `passed` — ran as written, expected result in full; evidence naming something not done, a substitute or a red run is not `passed`; - `partial` — ran as written, part of the expected result; `evidence` names the missing part; - `unverifiable` — cannot run as written (object or environment out of reach, requirements changed); `evidence` names why and what ran instead; - `failed` — ran as written, expected result absent. An empty `evidence` with `partial` or `unverifiable` is refused with `entry_fields_invalid`
`check_no`	Yes	Number of the review check in the task's list, from 1; a number outside the list is refused with `entry_fields_invalid`
`evidence`	No	What was run for the check as written and what it showed: the command, its output, a link to the material
`idempotency_key`	No	Retry key chosen by the caller, e.g. a UUID. A repeat with the same key and the same arguments returns the first result and creates nothing; the same key with other arguments is refused with `idempotency_key_reused`. A key is bound to the caller's token and kept for 24 hours

Output Schema

TableJSON Schema

Name	Required	Description
`no`	Yes	Entry number in the task's case; with the key it forms `TRK-42#12`
`seq`	Yes	Journal sequence number, usable as `after` of `wait_journal`
`title`	Yes	The title the tracker built, for entry types whose title is not sent (summary, answer, verdict, resolution, service entries); `null` when the caller sent the title
`author`	Yes
`task_key`	Yes
`created_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.10.1Oct 6, 2026

changedInput schema / properties / outcome / description

Previous value: -"Outcome of the check; there is no third state"New value: +"Outcome of the check:\n- `passed` — ran as written, expected result in full; evidence naming something not done, a substitute or a red run is not `passed`;\n- `partial` — ran as written, part of the expected result; `evidence` names the missing part;\n- `unverifiable` — cannot run as written (object or environment out of reach, requirements changed); `evidence` names why and what ran instead;\n- `failed` — ran as written, expected result absent.\nAn empty `evidence` with `partial` or `unverifiable` is refused with `entry_fields_invalid`"

changedInput schema / properties / outcome / enum

Previous value: -[
-  "passed",
-  "failed"
-]New value: +[
+  "passed",
+  "partial",
+  "unverifiable",
+  "failed"
+]

Changed22 schema fields changedv0.5.2Sep 25, 2026

removedInput schema / $defs

Removed value: -{
-  "VerdictOutcome": {
-    "description": "Исход обзорной проверки. Значений ровно два: третьего состояния у проверки нет.",
-    "enum": [
-      "passed",
-      "failed"
-    ],
-    "title": "VerdictOutcome",
-    "type": "string"
-  }
-}

changedInput schema / properties / check_no / description

Previous value: -"Номер обзорной проверки в списке задачи, с 1"New value: +"Number of the review check in the task's list, from 1; a number outside the list is refused with `entry_fields_invalid`"

removedInput schema / properties / check_no / examples
```
Removed value: -[
-  3
-]
```

changedInput schema / properties / evidence / description

Previous value: -"Доказательство исхода: что запустил, что увидел, ссылка на материал"New value: +"What was run for the check as written and what it showed: the command, its output, a link to the material"

removedInput schema / properties / evidence / examples

Removed value: -[
-  "docker compose run --rm test: 214 passed"
-]

changedInput schema / properties / idempotency_key / description

Previous value: -"Ключ повтора, который ты придумываешь сам (обычно UUID). Повтор вызова с тем же ключом и теми же аргументами отвечает первым результатом и второго объекта не заводит; тот же ключ с другими аргументами отклоняется. Ключ живёт в паре с твоим токеном и помнится 24 часа"New value: +"Retry key chosen by the caller, e.g. a UUID. A repeat with the same key and the same arguments returns the first result and creates nothing; the same key with other arguments is refused with `idempotency_key_reused`. A key is bound to the caller's token and kept for 24 hours"

changedInput schema / properties / key / description

Previous value: -"Ключ задачи, например `TRK-42`. Регистр не важен"New value: +"Task key `PROJECT-N`, case-insensitive; a previous key of a moved task addresses it as well. An unknown key is refused with `task_not_found`"

removedInput schema / properties / outcome / $ref
```
Removed value: -"#/$defs/VerdictOutcome"
```

changedInput schema / properties / outcome / description

Previous value: -"Исход проверки. Третьего состояния нет"New value: +"Outcome of the check; there is no third state"

addedInput schema / properties / outcome / enum
```
Added value: +[
+  "passed",
+  "failed"
+]
```
removedInput schema / properties / outcome / examples
```
Removed value: -[
-  "passed"
-]
```
addedInput schema / properties / outcome / type
```
Added value: +"string"
```

removedOutput schema / $defs / AuthorKind

Removed value: -{
-  "description": "Кто именно сделал действие.\n\n`tracker` — сам трекер: этим родом подписаны служебные записи дела и строки,\nзаведённые командой первичной инициализации. У него нет подписи, потому что\nназывать себя по имени ему незачем: трекер в установке один.",
-  "enum": [
-    "agent",
-    "human",
-    "tracker"
-  ],
-  "title": "AuthorKind",
-  "type": "string"
-}

changedOutput schema / $defs / AuthorView / description

Previous value: -"Кто сделал действие: род и подпись. У самого трекера подписи нет."New value: +"Who acted: kind and signature. The tracker itself has no signature."

removedOutput schema / $defs / AuthorView / properties / kind / $ref
```
Removed value: -"#/$defs/AuthorKind"
```

addedOutput schema / $defs / AuthorView / properties / kind / description

Added value: +"Kind of author. `tracker` signs the service entries the tracker files itself"

addedOutput schema / $defs / AuthorView / properties / kind / enum
```
Added value: +[
+  "agent",
+  "human",
+  "tracker"
+]
```
addedOutput schema / $defs / AuthorView / properties / kind / type
```
Added value: +"string"
```

changedOutput schema / description

Previous value: -"Ответ подшивающего инструмента: чем запись адресуют, без самой записи.\n\n`title` непуст только там, где заголовок собрал трекер: у сводки, ответа, вердикта и\nрезолюции его не принимают вовсе (`app/domain/case.py`, `TITLED_ENTRY_TYPES`). Где\nзаголовок прислал агент, здесь стоит `null` — «в описи ровно то, что ты прислал»."New value: +"A filed entry, by its address rather than its content; the entry in full is\nreturned by `read_entries`."

addedOutput schema / properties / no / description

Added value: +"Entry number in the task's case; with the key it forms `TRK-42#12`"

addedOutput schema / properties / seq / description

Added value: +"Journal sequence number, usable as `after` of `wait_journal`"

addedOutput schema / properties / title / description

Added value: +"The title the tracker built, for entry types whose title is not sent (summary, answer, verdict, resolution, service entries); `null` when the caller sent the title"

First observedSep 23, 2026

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare the safety profile (readOnly=false, destructive=false, openWorld=false, idempotent=false), but the description adds real behavior: the latest verdict on a check replaces earlier ones, earlier-pass verdicts persist without counting, and replacement happens for both passed and failed outcomes. Auth requirements and error/return behavior are left to the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence, with pass/replacement rules following. It is dense and the sentence about failed/passed filing is slightly convoluted, but no sentence is pure filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A mutation tool with a full output schema, so return values need not be explained, and annotations cover safety. The pass semantics and replacement behavior that an agent needs to avoid mis-filing verdicts are present; permission/token requirements are the main omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents key, outcome, check_no, evidence, and idempotency_key in depth. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Files the outcome of one review check', scoped to the task's current pass and its assignee. It also explicitly names the nearest overlapping sibling ('`close_task` also takes verdicts, together with the closing'), so an agent can separate filing a verdict from closing a task.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description establishes when a verdict counts (current pass only, latest replaces earlier) and implies the division of labor with close_task. It stops short of an explicit 'use this tool when / not when' rule and gives no prerequisites for calling it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.