> ## Documentation Index > Fetch the complete documentation index at: https://docs.plastics.com/llms.txt > Use this file to discover all available pages before exploring further. # Lessons learned overview > What a lesson is, where it comes from, and the review, testing, and release steps every lesson passes through before Herman uses it. A lesson is a short piece of guidance for one step of Herman's answer pipeline. It records a correction a reviewer verified in an evaluation, in a form Herman can apply to future answers that match the same situation. Each lesson has two parts: * **Guidance**: what Herman should do, written as an instruction. For example: "When a comparison uses estimated values, label them as estimates and do not rank grades on them." * **When it applies**: a rule over the inputs that step can see. For example: apply when estimated values were used, except when the comparison fell back to a simpler method. Lessons change how Herman reasons and presents an answer. They never hold product data. Grade properties, certifications, prices, inventory, and lead times always come from your catalog and other systems of record. > **[Build a lesson from an evaluation](https://docs.plastics.com/lessons/build-from-evaluation.md)** > > Step-by-step: from an approved evaluation to a lesson waiting for review. > **[Build an evaluation dataset](https://docs.plastics.com/evaluations/dataset-json.md)** > > Prepare the questions and reference answers that evaluations score against. ## Where lessons come from Every lesson starts from a verified correction. A reviewer looks at one of Herman's saved answers, writes what the answer should have said, and cites the source document, revision, and location that supports the correction. A second person independently checks that correction against the source. Only an approved review case can produce lessons. This requirement keeps lessons traceable. Each lesson links back to the evaluation it came from, so anyone reviewing it can see the original question, the correction, and the source. ## The lifecycle of a lesson **1. Verify a correction** A saved answer is added to the review queue, rated, corrected with a cited source, and approved by an independent reviewer. **2. Write the lesson** From the approved case, write the guidance, its limit, the rule for when it applies, and examples. You can start from an AI draft. Saving creates a candidate version marked **Needs review**. **3. Approve or reject** Someone other than the author and the person who wrote the correction reviews the candidate and approves or rejects it. **4. Test** Rule tests check the lesson against the current step contract and its own examples. Quality gates compare answers with and without the lesson on approved datasets. **5. Release** Release is a separate, deliberate step. Approving or testing a lesson does not turn it on. > [!NOTE] > > Release is not yet available. Every lesson currently shows **Not released**, and Herman does not apply any lesson to live answers. ## Statuses | Status | Meaning | | - | - | | Needs review | A saved candidate version waiting for an independent decision. | | Approved | A reviewer approved this version. It still needs testing and release before Herman uses it. | | Rejected | A reviewer rejected this version. Edit it as a new version to try again. | | Not released | Herman does not apply this version to answers. Every version starts here. | Lessons are versioned. Editing a lesson creates a new version with its own status and history. Earlier versions keep their decisions and test results. ## The Lessons Learned page Open **Lessons Learned** from the side navigation. The page lists every lesson version in your workspace. * **Tabs** filter by status and show how many lessons each status holds. * **Search** matches the guidance text. * Each row shows the guidance, the step, the kind of lesson, its lifecycle, the version, and the date. Select a lesson to open its record: | Section | What it shows | | - | - | | Header | Version, status, release state, the guidance, and its limit. **Review and decide** appears when you can approve it; otherwise **Edit as new version**. | | When it applies | The rule in plain language, including exclusions. | | Step, Kind, Priority, Lifecycle | How the lesson is classified. See [the fields](https://docs.plastics.com/lessons/build-from-evaluation.md#the-lesson-fields). | | Source evaluation | The original question and the verified correction, with a link back to the evaluation. | | Tests | Rule test results for this version. | | Gate records | Quality gate runs for this version, with outcomes and a link to each run in Evaluations. | | History | Every version of this lesson with its status and date. | ## Testing ### Rule tests Rule tests run in seconds and cost nothing. They check that: * the lesson's step is still registered and the lesson matches the step's current input contract * every example gives the outcome it claims: **Applies**, **Does not apply**, or **Unknown** Select **Run tests** in the record. A passing result reads **Ready for release, not released**. If the step's contract changes later, the same lesson fails with "Lesson uses a stale step contract"; edit it as a new version. ### Quality gates A quality gate measures whether the lesson helps. It answers every case in one or more approved evaluation datasets twice, once with the lesson and once without, and scores both answers with the same judge used in Evaluations. You choose the datasets, the number of trials, and the margin. The setup shows how many answers the run generates and its cost cap before you start. A gate run needs passing rule tests for the same version. Each gate ends with one outcome: | Outcome | Meaning | | - | - | | Proven lift | Answers with the lesson scored higher, beyond chance. | | Non-inferior | Answers with the lesson scored no worse than the margin allows. | | Inconclusive | The results don't support either conclusion. Add cases or trials. | | Regression | Answers with the lesson scored worse than the margin allows. | Proven lift and non-inferior count as passing. Open a gate record with **View in Evaluations** to compare both answers case by case. A case that got worse can be added as a counterexample to a new version of the lesson. > [!WARNING] > > Gate results are indicative. Both answers are generated without Herman's document retrieval, and the lesson is applied to every case rather than only where its rule matches. Treat a gate as a check on the guidance itself, not a measurement of production behavior. Quality gates appear only in workspaces with benchmark runs turned on and at least one approved evaluation dataset. ## What a lesson must not contain Approvers confirm that a lesson contains none of the following. Herman must get these from systems of record, never from a lesson: * grade properties or test values * certification or compliance facts * prices * inventory or availability * lead times If a correction was about a wrong value, fix the data source instead. Write a lesson only when the problem was in how Herman used or presented the information. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.