> ## Documentation Index > Fetch the complete documentation index at: https://docs.ewake.ai/llms.txt > Use this file to discover all available pages before exploring further. # Giving Feedback > How to judge an ewake investigation and leave a 👍 or 👎 that teaches it the right lesson. **What you'll get:** a shared standard for rating investigations, so the skills ewake writes from your feedback are ones you would have written yourself. Feedback is not a satisfaction score. Every rating you submit in Slack is read back against the run it rated, and can **create or rewrite a [skill](/working-with-ewake/skills) that takes effect on the next investigation**. A careless 👎 teaches a careless rule. *** ## Where feedback comes from | Surface | What it does | | --------------------------------------------------- | ------------------------------------------------------------------------------------- | | **👍 / 👎 buttons** under an ewake answer in Slack | The only feedback that teaches ewake. Opens the feedback form. | | **Emoji reactions** on an ewake message | Recorded as engagement only. No polarity is read from them, and nothing is learned. | | **Ratings on the Evaluation page** in the dashboard | Recorded next to the replayed run so you can score a batch. They do not write skills. | Reacting with :thumbsup: is not feedback. Use the buttons under the message. *** ## What happens after you submit A form opens: **Help us improve Ewake**. On a 👎 at least one dimension is required. On a 👍 the dimensions are optional. The **Additional Details** box is always optional — but it is the part that carries the lesson. You see *"Thanks! We've flagged this for the team."* — that is the save, not the learning. In the background, ewake replays the transcript of the run you rated, your selected dimensions, your comment, and the catalog of **active** skills. It decides whether the run teaches a lesson worth keeping. If there is a lesson, the curator either rewrites an existing skill's body or writes a new skill. Both are **activated immediately**, with your feedback recorded as the reason for the change. This is by design — a correction you give today applies to tomorrow's alert without anyone having to promote it. It is also why the wording of your feedback matters: nothing sits in a review queue between you and the next investigation. *"Thanks for the feedback — we learned from it. • New skill: …"* Silence means the curator judged that the run added nothing worth carrying forward — which is a valid outcome, not a failure. *** ## What the curator can and cannot see It reads a **condensed transcript** of the investigation: * the messages of the run, each truncated at \~2,000 characters * the **names** of the tools the agent called, in order, and whether a call failed * at most 60 messages — a long run keeps its opening and its conclusion, and says so in the middle It does **not** see tool arguments, raw tool output, your dashboards, the ticket, the Slack conversation that happened elsewhere, or what turned out to be true afterwards. Assume the curator knows what ewake looked at, not what it found, and nothing about the world outside the run. Anything you leave implicit is lost. *** ## Choosing the right dimension The dimension tells ewake *which kind* of mistake or success it was. Picking the wrong one sends the lesson to the wrong place. | Dimension | 👎 means | 👍 means | | ------------------------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------- | | **Missed the Mark 🎯** / **Spot On 🎯** | Wrong issue, wrong service, wrong data source, wrong timeframe | It investigated the thing that actually mattered | | **Inaccurate / Unsupported ✖️** / **Solid Evidence 📚** | A claim contradicts the data, or is not backed by it | Every claim was tied to evidence that supports it | | **Lacked Insight 📉** / **Helpful Insight 💡** | Technically right, but told you only what you already knew | It surfaced something you would have missed | | **Not Actionable 🧱** / **Highly Actionable 🚀** | Correct but too vague to act on | It gave a clear next step or a fix | | **Hard to Read 📝** / **Clean & Clear ✨** | Cluttered, too long, hard to scan under pressure | Well structured, scannable at a glance | | **Other** | Anything the five above do not cover — explain in the details | | Diagnosis and presentation are separate judgements. An answer that found the right root cause but buried it is **Hard to Read**, not **Missed the Mark**. Flagging it as the latter teaches ewake to investigate differently when the investigation was fine. *** ## Writing the comment The comment is the only place you can say what the *right* answer was. A good one contains three things: 1. **What ewake concluded** — briefly, so the lesson is anchored. 2. **What was actually true**, and how you knew. 3. **The rule a future run should follow**, stated so it generalises beyond today. ```text Good 👎 theme={null} Blamed the checkout deploy. The 500s were upstream in auth-api — its p99 went past 2s four minutes before checkout errored. When two services error in the same window, check the dependency direction in the service map before naming the one that alerted. ``` ```text Good 👍 theme={null} Correctly ignored the deploy and went straight to the RDS connection count, which is what settled it. Keep checking pool saturation before deploy timing on payments-api — its deploys are noisy and almost never the cause. ``` ```text Too vague theme={null} wrong ``` ```text Too vague theme={null} Good job, very helpful! ``` ```text Unusable — no rule, no evidence theme={null} This is not how we do things here. ``` **Rules of thumb** * **Name services, metrics and thresholds.** "auth-api p99 over 2s" teaches; "the upstream service was slow" does not. * **Write the rule, not the incident.** The curator is told never to mention your run in the skill body — so give it something that still makes sense next month. * **One lesson per rating.** Two unrelated complaints in one comment tend to produce one muddled skill. * **Do not write instructions to a person.** The skill body is read by the agent as prior knowledge to weigh against its own evidence, not as an order to obey. * **Leave out links and ticket ids.** They are stripped when a skill is written, so they cost you space and teach nothing. *** ## Praise is training too A 👍 goes through exactly the same curation as a 👎. Rating a genuinely good investigation is how the ordering that worked becomes the ordering ewake reaches for next time. Rate 👍 when the run changed what you did next. Do not rate 👍 as a thank-you for a run you did not read — it is treated as a lesson either way. *** ## When not to leave feedback * **The gap is a missing integration, not a mistake.** If ewake could not see the data, no skill fixes that. Connect the source instead. * **You are asking for a product change.** Send it to [support@ewake.ai](/support) — the curator can only write skills. * **Someone already rated the same run for the same reason.** Each submission starts its own curation pass; two people making the same point can produce two overlapping skills. * **You have not read the answer.** A reflex rating is indistinguishable from a considered one. *** ## Reviewing what your feedback taught Everything the curator writes is visible and reversible in the dashboard under **[Skills](/working-with-ewake/skills)**: * The skill's **version history** shows each change, who made it, and a per-field explanation of *why* it changed, ending with the feedback it came from. * **Activate this version** puts a previous version back in service. * The **status toggle** disables a skill without deleting it; **Archive** retires it. Worth doing weekly for the first month: open Skills, read what was written from the week's feedback, and disable anything that reads like one team's preference rather than a rule about your production system. *** ## A short checklist Before you submit: * [ ] I read the answer and know what it got wrong or right. * [ ] My dimension matches the *kind* of problem (diagnosis vs. evidence vs. presentation). * [ ] My comment names the correct answer and how I know. * [ ] My comment states a rule that will still be true next month. * [ ] I would be happy for this rule to apply to the next investigation, unreviewed. *** Need help? Contact [support@ewake.ai](/support).