> ## Documentation Index > Fetch the complete documentation index at: https://docs.signalmd.dev/llms.txt > Use this file to discover all available pages before exploring further. # Lanes > The five places a defect can live: Hearing, Understanding, Flow and state, Speaking and Integrations, and who usually owns each fix. A voice agent is often described in three parts: speech to text, a model, and text to speech. Real defects do not divide that way. Signal places the cause of every defect in one of five lanes, and two of them, Flow and state and Integrations, are where many production defects turn out to live. The lane tells you who owns the fix. A fix aimed at the wrong lane can move a number without helping anyone. ## The five lanes | Lane | What it covers | Usually fixed in | | - | - | - | | Hearing | What the caller said compared with what was recorded | Speech recognition settings and vocabulary, or a read-back in the flow | | Understanding | What the model did with what it received | The step's prompt, the global prompt, or the knowledge base | | Flow and state | What your configured flow did with what was understood | Flow design: transitions, their conditions, and when values are captured | | Speaking | What the caller heard, and when they heard it | The model choice, prompt length, voice and responsiveness settings | | Integrations | Tools and knowledge bases | The tool, the system behind it, or the order tools run in | ### Hearing What the caller said compared with what the system recorded: a misrecognised value, a dropped "not", a caller cut off mid-sentence. For example, a street name transcribed as a common word, and the agent repeating the wrong word back. Usually fixed by adding the words to your speech recognition keywords for those questions, reading back values that are easy to confuse, or adjusting how long the agent waits before deciding the caller has finished. Signal does not measure recognition accuracy directly yet. The **Hearing** section of the overview board says so, and recognition time is shown under **Speaking**. ### Understanding What the model did with what it received: instructions not followed, a question misread, an answer invented, content the knowledge base does not support. For example, the agent says it does not have information that its prompt or knowledge base holds. Usually fixed in the prompt for that step, the global prompt, or the knowledge base. ### Flow and state What your configured flow did with what was understood: asked again, skipped a question, looped, stored an answer against the wrong question, or kept an old value. For example, a caller said "ten", then changed it to "nine thirty", and the booking kept ten. The transcript was right and the model understood. The flow was wrong. Usually fixed in the flow design: which transition a condition leads to, and when a variable is set and reset. ### Speaking What the caller heard: a long wait before a reply, the agent talking over the caller, turns that run long, wording. For example, the agent interrupting a caller who had not finished. Usually fixed by a faster model, a shorter prompt, or the agent's responsiveness, interruption and voice settings. ### Integrations Tools and knowledge bases: a lookup that fails, hangs, returns nothing, or returns something the flow cannot use. For example, callers wait several seconds in silence while tools run one after another. Usually fixed in the tool or the system behind it, or by changing which tools run and in what order. This lane usually needs its own owner, typically a backend engineer. ## Why the right lane matters Suppose callers sit through 7 seconds of silence at one step. Adding "one moment while I check that" to the prompt is a Speaking change. It shortens the silence the board measures, so a number improves. But the lookup still takes 7 seconds and the caller still waits for it, because the cause was in Integrations: three tools running one after another. Check the lane on an issue before you decide who should work on it. See [Fix an issue](/guides/fix-an-issue). ## What is not a lane Some calls go badly for reasons no change to your agent would fix: a caller who never speaks, stops answering, or hangs up in the opening seconds. Signal does not list these as issues, because no setting in your agent moves them. They still count in the call outcomes, such as **Caller never spoke**. A bad line or a voicemail is not a defect of your agent either, and has no lane. ## Where you see lanes * **On the overview board.** There is a section per lane, and **What went wrong, by lane** splits calls that went badly by lane. Calls without an established cause are shown as cause not established. * **On issues.** Many issues show their lane under the title. Every issue also carries a **Kind** tag: **Technical** (a tool, latency or platform defect, usually for an engineer), **Flow** (routing, loops, confirmation handling) or **Content** (what the agent knows and says). **Issues** lets you filter **To fix** by Kind. Kind is not a lane, and neither is **Fix** or **Improve**, which say whether an issue is a defect or a change you control. **Technical** holds both a misheard word (Hearing) and a failing lookup (Integrations), so read the place and the cause before you decide who owns the fix. * **In tests.** The lane decides whether a fix can be tested before it ships. Understanding, Flow and state, and Integrations issues can be tested in text simulations. Hearing and Speaking depend on audio and timing, which need a real phone call. Signal does not run phone tests yet, so those issues are not offered for tests, and the reason is shown when you try. See [Test a fix](/guides/test-a-fix). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.