---
title: "Rating GoClaw and improving results"
section: "Builder Guide"
canonical_url: "https://support.buildwithhq.com/builder-guide/goclaw-ratings.html"
reviewed_at: "2026-09-14"
authority: Official
---

# Rating GoClaw and improving results

Every action can be rated, every suggestion explains itself — so poor results can be diagnosed, not just endured.

## In brief

- **Explicit signal:** 1–5 rating + comment on any executed action
- **Implicit signal:** Every suggestion's fate is recorded
- **Diagnosis:** The AI's reasoning is stored, not discarded

An assistant you can't grade is an assistant you can't improve. GoClaw is built the other way around: every piece of work it does generates signals, every suggestion keeps a record of *why* it was made, and the path from “that was a bad draft” to “here's exactly what to change” is a read, not a guess.

## The signals, explicit and implicit

**Explicit ratings.** After an action executes, the user can rate it one to five, mark whether it was helpful, and leave a comment. Ratings attach to the specific execution — not to the assistant in general — so a 2-star is always a 2-star *on something inspectable*.

**Implicit responses.** Richer still: every suggestion the assistant makes records its fate — accepted, dismissed, ignored, or *modified and accepted* — along with where it ranked in the list and how confident the AI was at the time. Nobody has to remember to rate anything for this signal to accumulate; using the assistant normally produces it.

**Rejection reasons.** When an approver rejects a queued action they can say why, and the reason is stored on the action and in its event trail. A week of rejection reasons is a tuning brief written by your own users.

| Response | What it tells you |
| --- | --- |
| Accepted as-is | The draft was right. The baseline you're protecting. |
| Modified, then accepted | The most valuable signal there is: the *idea* was right, the *execution* needed polish. Read the edits — they're your users showing you the target. |
| Dismissed | Wrong action for the moment. If one action type is dismissed persistently, its triggering conditions are too broad. |
| Ignored | Not even engaged with. Chronic ignoring means suggestions are surfacing at the wrong time or place, not just with the wrong content. |

## Diagnosing a poor rating

What makes diagnosis possible is that the assistant's homework is retained. Each suggestion stores a **snapshot of the data it saw** at that moment and its **reasoning** — the factors it weighed, how heavily, and the alternative actions it considered with their scores. Each execution stores a **step-by-step trail**: every step's input, output, duration, and any error. So a bad outcome decomposes into one of three findings:

| Finding | You'll see it in | The fix lives in |
| --- | --- | --- |
| **It saw the wrong data** — the snapshot is missing or stale relative to reality | The context snapshot vs. the actual record at that time | Data quality and what context the action is fed — not the AI's behavior |
| **It reasoned poorly** — right data, wrong weighting or wrong alternative chosen | The reasoning's factors and the scores on alternatives it passed over | The behavior configuration: prompts, factor emphasis, and the conditions that trigger each action type |
| **It executed badly** — right decision, a step failed or produced a poor artifact | The execution steps: which one erred, how long it took, what it emitted | The specific step — a template, a connected channel, a timeout |

Tip

Start every diagnosis with the reasoning, not the output. “What did it think it was doing, and was that reasonable given what it saw?” separates a data problem from a judgment problem in about thirty seconds — and they have completely different fixes.

## Closing the loop

Diagnosis without a safe way to ship the fix just moves the frustration. The improvement loop here is deliberately gated:

1. **Read the signals** — ratings, response patterns, and rejection reasons, sliced by action type. One action type usually accounts for most of the pain.
2. **Diagnose with the stored evidence** — snapshot, reasoning, steps, as above.
3. **Adjust the behavior configuration** — the prompt, the triggering conditions, the context provided, or simply disabling an action type that isn't earning its place.
4. **Prove it before it ships** — run the candidate configuration through a [Harness Pack](harness-packs.html)  that includes scenarios built from the failures you just diagnosed. A fix that passes the scenarios that used to fail is a fix; anything else is a hope.
5. **Promote and watch the same metrics** — the ratings and response rates that flagged the problem are the same ones that confirm the cure.

Note

Feedback also works passively: user responses feed suggestion ranking over time, so consistently dismissed suggestions sink and consistently accepted ones surface earlier — the feed self-corrects between your deliberate tuning passes.

## The numbers worth watching

- **Acceptance rate by action type** — the headline. A type below your comfort line is a tuning candidate; a type near zero should be switched off until fixed.
- **Modified-and-accepted share** — high is actually encouraging early on (right ideas, improvable drafts); the goal is converting it into accepted-as-is by learning from the edits.
- **Rating trend across a configuration change** — the before/after that tells you whether a tuning pass worked in production, not just in the Harness Pack.
- **Ignore rate** — the placement-and-timing metric. Content fixes won't move it; where and when suggestions appear will.

---

Capability review: 2026-09-14. [View the canonical guide](https://support.buildwithhq.com/builder-guide/goclaw-ratings.html).