> ## Documentation Index > Fetch the complete documentation index at: https://docs.tela.com/llms.txt > Use this file to discover all available pages before exploring further. # Validation rules and metrics > Expected and Wrong Answers, AI validation rules per attribute, how each run is validated automatically, and how the Accuracy Score is computed Reviewing every attribute of every Test Case by hand works for the first run. It does not work for the tenth version. Validations are how a Test Case remembers your verdicts: the examples you marked and the rules you wrote are applied to each new run, so most attributes arrive already reviewed and you only look at what is new. The metrics at the top of the **Test** experience then summarize those verdicts into numbers you can compare between versions. Both live on the Test Case, per attribute. The rule *The total must be a number without currency symbol* on `total_amount` of the two-currency invoice applies to every run of that Test Case, on every version, and to nothing else. ## Where validations live Open a Test Case, hover an attribute and click **Validations**. The badge on the button counts the examples and rules of that attribute. The popover has two tabs: * **Rules**: the plain-language rules for this attribute, numbered. Type a rule in the box (*Add rule...*) and click **Add** or press Enter. Hover a rule to delete it. * **Examples**: the **Expected Answers** and **Wrong Answers**. Choose **Right answer** or **Bad answer** in the selector, type the value (*Add example...*) and **Add**. Thumbs up and thumbs down on the result add examples here as well. ![Validations popover of the total\_amount attribute, Rules tab with two numbered rules, one of them in red as failed](https://mintcdn.com/meistrari/M2w7BduKZAFA1Sbx/images/test-cases/validations-popover.png?fit=max\&auto=format\&n=M2w7BduKZAFA1Sbx\&q=85\&s=7cab16b590885ff4bcdc5fa4652d3760) Lists and tables have **Rules** only at the level of the whole attribute; their items are compared individually against the examples of the parent. > [!NOTE] > > Rules and examples belong to one Test Case. There is no Canvas-wide rule set: a rule you want on every invoice has to be added to each Test Case, and a new Test Case starts with none. ## Expected and Wrong Answers An **Expected Answer** is a value that is right for this attribute on this Test Case; a **Wrong Answer** is a value that was produced once and is wrong. They come from three places: * your thumbs up (Expected) and thumbs down (Wrong) on a result; * a Workstation task turned into a Test Case: untouched values become Expected, edited values become Wrong (the original) and Expected (the correction); * the **Examples** tab, where you type them. An attribute can have several Expected Answers. For `category` of the clean invoice, `Office supplies` and `office-supplies` can both be right. Comparison ignores case and, for lists, order, so `["USD", "EUR"]` matches `["eur", "usd"]`. ## How a run is validated When a run finishes, Tela validates each attribute of the Output Format before you see it: **1. Exact match against the examples** A value equal to an Expected Answer is **Good** (*Matches a good answer exactly*). A value equal to a Wrong Answer is **Bad** (*Matches a bad answer exactly*). **2. No match, examples exist, no rules** When the attribute has Expected Answers, the value matches none of them and there are no rules, the value is **Bad** (*Does not match expected answers*). `due_date` = `2024-01-05` when the only Expected Answer is `2024-05-01` fails here. **3. Rules** Otherwise, when the attribute has rules, an AI judge receives the attribute, its value and all its rules at once and returns **Good** or **Bad** with a reasoning and a confidence. Below 50% confidence the verdict is inconclusive and the attribute stays pending for you. **4. Nothing applies** An empty value with no examples is flagged *Attribute is empty*. Any other value with no examples and no rules is left for you to review. Automatic verdicts show the **AUTO-REVIEWED** mark on the attribute. **View validations** opens the detail: **Exact Match** with the **Matched answer**, or **AI Rule** with the judge's reasoning, its **Confidence** and the **Failed rules**, which are also highlighted in red in the **Rules** tab. A verdict for the same value and the same rules is reused from a cache (**Cached validation result**) instead of calling the judge again; editing, adding or removing a rule invalidates it. You can override any automatic verdict with your own thumb. Your mark wins and is stored as an example, so the next run follows it. > [!TIP] > > Write rules the way you would brief a colleague, one condition per rule: *Must be a date in ISO format (YYYY-MM-DD)*, *Must be the amount after taxes*, *Must be one of: Office supplies, Services, Travel*. A rule that lists several conditions fails as a whole and tells you less. ### Choosing between examples and rules | Use | When | | - | - | | Expected Answers | The right value is fixed for this input: a supplier name, a date, a category | | Wrong Answers | A specific mistake keeps coming back and you want it flagged the moment it reappears | | Rules | Several values are acceptable, or the attribute is free text or a list: *must be in English*, *must mention the invoice number*, *must not include line items with zero quantity* | For the *Not an invoice* case, the right `total_amount` is empty. Mark the empty value **Good** so an empty result is an Expected Answer, and add the rule *Must be empty, this document is not an invoice* to catch a made-up total with an explanation. ## Metrics The summary card shows the metrics of the version you are viewing, computed from the last run of each Test Case on that version. Filters on the table (labels, user, date, status) restrict the metrics to the rows that match. ![Summary card with Accuracy Score 88%, Reliable coverage, Reviewed 5 of 6 and Attributes 92%](https://mintcdn.com/meistrari/M2w7BduKZAFA1Sbx/images/test-cases/summary-card.png?fit=max\&auto=format\&n=M2w7BduKZAFA1Sbx\&q=85\&s=b9357e35af0b146d186ba081e1d8945d) | Metric | What it measures | | - | - | | **Accuracy Score** | Among Test Cases where at least one attribute has a verdict: the attributes marked **Good**, divided by all attributes of those Test Cases. Shown as a percentage with a label: **No data**, **Poor** (up to 49), **Fair** (50 to 64), **Good** (65 to 79), **Very good** (80 to 89), **Excellent** (90 and above) | | **Reviewed** | How many Test Cases are **Completed**, out of the total: *5 of 6* | | **Attributes** | The share of attributes, across all runs, that have a verdict (Good or Bad). This is your coverage: **No coverage**, **Low coverage** (below 40%), **Medium coverage** (below 75%), **Reliable** (75% and above) | Read them together. An **Accuracy Score** of 100% with **Low coverage** means you reviewed a few attributes and they were right; it says little about the rest. The headline of the card changes with the pair, from *Start reviewing* to *Keep reviewing* to *Congrats, your system looks great!*, and the arc around the score stays grey until coverage reaches 40%. Per Test Case, the **Score** column shows the share of attributes marked Good on the last run, and hovering the name shows the counts of positive, negative and pending attributes. A Test Case whose run is older than the version you are viewing shows no score. > [!NOTE] > > Pending attributes count against the **Accuracy Score** of a Test Case that is partly reviewed: four attributes, two Good and two pending, give 50%. Finish the review, or use **Mark as reviewed**, before reading the number as a quality measure. ### In Agents Agent test cases show the same **Accuracy Score**, **Reviewed** and **Attributes**. Verdicts come from your thumbs and from the evaluator, which judges the whole result against the test case's **Rules** and the global **Configure reviewer** prompt, and **Criteria** group attributes into separate accuracies. See [Running them all](https://docs.tela.com/en/agent/testing.md#running-them-all). ### In Workflows The attributes counted are those of the Output Formats of the Workflow's AI steps, grouped by step. Steps without an Output Format add nothing to the metrics. See [In Test Cases](https://docs.tela.com/en/workflow/outputs-and-results.md#in-test-cases). ## Through the API Each Test Case returned by [`GET /test-case`](https://docs.tela.com/api-reference/test-case/get) carries its `answers` (an object keyed by attribute, with `good` and `bad` arrays) and, with `includeGenerations=true`, its runs with their `attributeFeedback` and `validations`. Rules are added with `POST /test-case/{id}/validation-rules/{attributeKey}` and a body `{ "description": "..." }`, and removed with `DELETE /test-case/{id}/validation-rules/{attributeKey}/{ruleId}`. ```sh cURL theme={null} curl -X POST https://api.tela.com/test-case/2a3b4c5d-6e7f-4a8b-9c0d-1e2f3a4b5c6d/validation-rules/total_amount \ -H 'Content-Type: application/json' \ -H "Authorization: Bearer $TELA_API_KEY" \ -d '{ "description": "Must be a number without currency symbol" }' ``` > [!NOTE] > > The validation-rules endpoints and the generation feedback endpoints are not part of the published API reference yet. Their shape is taken from the application and may change. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.