> ## Documentation Index > Fetch the complete documentation index at: https://docs.basemode.ai/llms.txt > Use this file to discover all available pages before exploring further. # Querying the graph > Asking the graph a question in plain language, checking what it actually retrieved, and walking it node by node when you would rather see the structure than read a summary. Three ways to ask, in increasing order of how much you want to see the machinery. | You want | Use | | -------------------------------------- | ------------------------------------------ | | Hits matching a term | `base recall`, `base decision search` | | An answer assembled from several facts | `base graph query` | | The structure itself | `base graph get-node`, `neighbors`, `path` | ## Asking a question ```bash theme={"theme":{"light":"github-light","dark":"github-dark"}} base graph query "why do the docs deploy on a push to main" base graph query "why do the docs deploy on a push to main" --depth 4 --token-budget 4000 base graph query "why do the docs deploy on a push to main" --model haiku ``` **Why it works.** It matches your question against the graph, walks outward from what it found, keeps as much of the result as the token budget allows, and synthesizes an answer over that subgraph. Two knobs control the retrieval: `--depth` (default 3) is how far it walks, and `--token-budget` (default 2000) is how much it keeps. **The gotcha.** A thin answer is usually a retrieval problem, not a synthesis problem. Widen `--depth` before you rewrite the question. ## Checking what it actually found ```bash theme={"theme":{"light":"github-light","dark":"github-dark"}} base graph query "why do the docs deploy on a push to main" --raw ``` **Why it works.** `--raw` skips synthesis and prints the retrieved subgraph. If the facts you expected are not in there, no amount of rephrasing was going to produce a good answer, and you have just found out in one step instead of five. **Next rung.** `--raw` is often the better output even when the retrieval is good. Reasoning over the facts yourself beats trusting a summary of them, particularly when you are about to act on the answer. ## Walking it by hand ```bash theme={"theme":{"light":"github-light","dark":"github-dark"}} base graph get-node "billing-service" base graph neighbors "billing-service" --depth 2 base graph path "billing-service" "payment-provider" ``` All three take a label, a slug, or a substring unique enough to identify one node. * **`get-node`** shows one node in full: label, type, source, summary and edges. Start here when you want to know what base actually holds about something. * **`neighbors`** lists the neighbourhood as edge lines, expanded as many hops as you ask for. This is the map around a thing. * **`path`** finds the shortest route between two nodes, which answers "how are these two related at all" rather than "what is near this". **Why it works.** These are retrieval primitives rather than a query language, so you drive the traversal yourself: look at a node, pick an edge, follow it. That is slower than asking a question and considerably more reliable when the answer matters. **The gotcha.** `neighbors --depth 3` on a well-connected node returns a lot. Start at 1 and widen. ## Seeing the shape of the whole thing ```bash theme={"theme":{"light":"github-light","dark":"github-dark"}} base graph analyze base graph analyze --top-n 25 ``` This reports the nodes everything connects to, the clusters, and the connections you would not have predicted. It is worth running occasionally on a graph you have been feeding for a few months, because the god nodes it finds are usually either the real structure of your work or a sign that one domain has quietly become a dumping ground. ## Next Getting more into the graph so there is more to query. Every flag on every `base graph` verb.