FAQ
Honest answers to the questions that come up most — especially the "why did it do that?" kind about the Knowledge layer. Graphium's design goal here is that every number you run into is either a cost you decided or a value measured from your corpus, never a hidden quality filter. Click a question to expand its answer.
Why am I getting few Insights?
Insights are abstractions: the model reads your Claims and tries to factor out a rule that would survive outside its original context (the "portability test"). When few appear, check these in order:
- Do your Claims converge? A collection of one-off facts has no recurring pattern to abstract. The model is explicitly told that an empty list beats a forced Insight, so zero can be the honest answer for a young or scattered corpus. Insights start appearing when several Claims circle the same rule.
- Which model is doing the abstracting? Insight generation uses the Insight model from the Insight discovery section in Settings (falls back to the chat model, then the default, when unset). Abstraction is the hardest step in the pipeline, and smaller local models often return empty lists or mere restatements where a stronger model finds real patterns. We recommend a frontier-tier model here (for example Claude Opus or Claude Sonnet) — being "reasoning-capable" or merely large is not always enough; see the guide table in Setting up AI. If Insights are rare, try assigning a stronger model and running discovery again — same corpus, one variable changed. If a strong model still finds nothing new, the material (not the software) is the limit.
- Are new candidates reinforcing instead of creating? A candidate that embedding-matches an existing Insight is not automatically folded in — embedding similarity only narrows down a candidate pair; the AI then judges whether it's really the same claim, a contradiction, or actually different. Same becomes reinforcement (the result panel counts these as reinforced); contradiction keeps both Insights and flags them in the Check tab; only genuinely different candidates create a new page. If you see reinforcements, discovery is working; your existing Insights are getting stronger rather than multiplying.
- Has everything actually been looked at? Scans report their measured coverage as covered n/m — how many of your Claims were in view at least once. Ingest-time scans are budgeted (see the next question), so a large corpus is only partially covered per ingest by design. To sweep everything, run Discover Insights from Claims in Settings → Knowledge: it shows the measured number of LLM calls needed for full coverage before running, and reports the coverage it reached.
Does Graphium secretly limit how many Insights or Claims are created?
No. There are no quality-based silent drops: the model's confidence score is recorded and shown, never used to discard a candidate, and there is no minimum or maximum count a scan must produce. Claims work the same way — the extractor is told to harvest every distinct transferable point, with no fixed cap.
The numbers that do exist fall into three categories, and each has a reason you can check:
| Number | What it is | Why it exists |
|---|---|---|
| Scans per ingest (default 3) | A user setting in Settings → AI. Each scan is one LLM call over one cluster of Claims | Cost control — yours to decide. Set 0 to skip scanning at ingest entirely; the result always reports the measured coverage so you know what was and wasn't looked at |
| Calls needed for full coverage | Shown in the confirm dialog of Discover Insights from Claims | Measured, not configured. Computed from how your Claims cluster; scanning runs until every Claim has been in view at least once |
| ~50 Claims per LLM call, previews truncated | Internal slice size | Context-window protection — more would silently overflow the model's input |
| Chat context budget (2,000 chars of knowledge, 1,600 of notes/assets, 700 per passage) | How much retrieved text the AI chat reads as grounding | Context-window protection — not a quality line that says "nothing beyond this counts", but a budget so the model's input doesn't silently overflow. It caps characters, not how many pages can contribute |
| When Let the AI search again on its own is on: each search the AI runs uses the same budget as above, a page it opens is read up to 6,000 characters, the AI is asked to stop at about 3 tool calls per question, and a tool call that gets no answer from the app in 30 seconds is skipped | The experimental agentic search in AI chat (Settings → AI → Experimental features, off by default) | Context-window and wait-time protection. The extra searches use the same index and the same ranking as the first one, so they can't reach anything the first search couldn't — they only let the AI ask again in other words or read a whole page. The answer is still decided by the model, and nothing is written |
The knowledge overview (<wiki-index>) AI chat reads lists titles only; Summaries (legacy) are excluded | How the full-vault page list is built | Context-window protection. Adding a body preview per page blew up the input on large vaults (measured: ~130k tokens on 892 pages). Every page is still listed, nothing is hidden — preview-level detail comes from the retrieved passages instead |
| 20 candidates into the rank fusion | The candidate pool where lexical and embedding results are merged | A cost cap on assembling the pool. Both searches still look at everything; narrowing here drops nothing from the search itself, and what finally reaches the model is decided by the character budget above |
| Embedding queries truncated at 1,000 chars | The question text sent to the embedding model | A physical limit — multilingual-e5-large takes 512 tokens, so a long quote pasted into the question is cut from the front rather than failing the whole search |
| Duplicate threshold (embedding similarity) | Narrows candidates down to a "possible match" shortlist against existing Insights | This is candidate-finding, not the verdict. Embedding similarity is blind to negation and direction (a Claim that a value "decreases" reads as near-identical to one where it "increases"), so the AI judges each shortlisted pair as same / contradiction / different before anything is merged: same → reinforcement (existing Insight gains the new supporting Claims); contradiction → both Insights are kept and flagged as a contradiction in the Check tab (open both to compare); different → a new page. Without an embedding model this check passes everything through as new (no shortlist, no AI judgment needed) |
| A note is read whole — step contents, nested items and tables included | The text Claim extraction, the Topic stage and source check take from a note | No filter — every block is read. A step's contents follow its title, nested items are indented under their parent, and a table is read row by row (cells separated by a vertical bar) however long it is, so a note holding a long table takes more windows and AI calls than its prose alone suggests. Earlier versions left step contents, nested items and tables out of this text: knowledge made from such a note before the fix stays as it was until you add the note again with the Add to Knowledge chip in its header (a multi-note batch skips notes unchanged since they were last added) |
| A long source is read in 4,000-character windows, overlapping by 400 | Splitting a source before the Topic stage reads it | A context-window guard, not a limit on what gets read. A source that fits in one window is read in one pass, exactly as before; a longer one is cut at the nearest sentence end and every window is read, so nothing past a cut-off is skipped. Each window is routed and revised on its own, so a long source costs AI calls roughly in proportion to its length — the progress toast counts the windows (window 5 of 32) and Stop takes effect at the next window boundary. More windows can also mean more Topics: that is granularity, not a filter, and near-duplicates are surfaced by Organize topics / the Check tab rather than merged behind your back. Within one window, the revisions it triggers (one per Topic the router named) run up to 4 at a time — that changes how long you wait, not what gets read |
| Topic routing | Decides which existing Topic(s) an ingested source updates, and which new Topic(s) it creates | No threshold at all. The AI reads the source's text (one window at a time for a long source) plus an index of existing Topics (title + one-line definition) and judges "same concept or new" itself — no embedding similarity, no title-normalization matching. Near-duplicate Topics that slip through are caught later by Organize topics / the Check tab, not filtered at routing time |
| Calls needed to rebuild a Topic from its sources | Shown in the confirm dialog before any "Rebuild from sources" action (a Topic page's own Regenerate, Upkeep's legacy-Topics section, or a Missing-source issue's fix) | Measured, not configured — one call per source the Topic cites, computed before anything runs; never triggered on its own, always a button you press |
| 0–8 candidates per call, up to 3 relations per Insight | Prompt-side ranges | Anti-runaway guards on LLM output verbosity, not caps on your knowledge — repeated scans keep adding what they find |
| At least 2 Claims before scanning | Run precondition | Cross-Claim patterns need something to cross; with a single Claim there is nothing to scan against yet |
| Unknown source IDs dropped | Parser guard | Hallucination defense — a candidate citing a Claim that doesn't exist is discarded rather than saved with a broken reference |
| Check has no day-count or overlap-percentage threshold | Knowledge upkeep's Check tab, Stale and Redundant issues | Judged, not thresholded. Stale requires the AI to name a specific newer page or note that supersedes the old one — elapsed time alone never triggers it. Redundant requires the two pages to assert the same specific claim, wording and granularity aside — topic overlap alone never triggers it |
| Full check trims what it sends the model | Building the input for Full (AI analysis), before it judges issues and what's worth investigating | Cut by structure, not by a numeric threshold. It drops the discontinued "summary" kind entirely, and sends Claims as title-only (a Claim's title already is the proposition, so its body preview would be a duplicate) — Topics, Q&A, and Insights still get a body preview as before. On real-world corpus sizes (~900 pages) this took the model's input from ~157k tokens to ~60k. |
| Full check is split into parts of about 72,000 tokens | Sending Full (AI analysis) to the model, once the knowledge is too large for one call | Every page is still checked — nothing is dropped. A large knowledge base (a few thousand pages can reach 300k+ tokens) is split into parts of about 72,000 tokens (the same budget as ingest, by Graphium's estimate) and sent one after another, so it also works on 128K-context models. A topic and its claims always go into the same part, so duplicates are only missed across the edge of two parts. If a part fails, the results from the other parts are still shown, along with how many parts failed |
| No cap on how many "Worth investigating" questions can appear | The questions a Full check proposes alongside issues, in Knowledge upkeep | Judged by quality, not counted down to a limit. Only questions whose answer would actually revise an existing page's claim or require a new page make the list — general background questions and things already written on a page don't qualify. No extra AI call is spent — it rides along in the Full check's existing call (one per part when the check is split) |
| Log fed to a Full check: the last 7 days | The recent activity log (ingests, Q&A pages created, and so on) a Full check reads to prioritize questions worth investigating | Cut by time, not by a count limit. 7 days is a natural unit ("the last week") — older log entries aren't sent. The log is only used to prioritize questions, never to decide issues. Quick checks (mechanical only) never send it |
| Source check has no numeric limit of its own | The judge-call count shown before running a check | Measured, not configured — it's the number of sources involved, computed the same way as the Insight-discovery call count above, and can come out lower than shown once unreadable sources are skipped |
| No size cap on the text a source check re-reads | Re-reading a note, PDF, Word file, or URL to check a citation | The whole document — source check adds no limit of its own and reads the PDF in full, the same text the Topic stage reads window by window |
| PDF text is capped at 80,000 characters where the whole text goes to the model in one call | Claim extraction, the PROV importer, regenerating a page from several sources at once, and the per-source summary page | Context-window protection for the paths that don't window. Roughly 60–90 pages; those four features are told how much they read, and the summary page says so in its last sentence. Topics, source check and the search index are not capped — they read the document in full |
| Automatic source check is off by default and only calls the AI when it runs | Auto-check sources toggle in Settings | Opt-in, not a background default. Turning it on checks new/updated Claims and Topics one source at a time, same model call as a manual check — it never runs unless you switch it on |
| A note, URL, PDF, Word file or chat with no real text ends as "Not enough content" without calling the AI | Every Add to Knowledge entry point | The only content gate, and it's mechanical, not a quality judgment. Text that is empty, only whitespace, or only invisible formatting characters (zero-width space and similar) counts as empty — a note, URL or chat with any other character always reaches the AI |
| A PDF or Word file is not used when fewer than 50 characters could be read from it | Add to Knowledge for PDF and Word files, and regenerating a page by re-reading its sources (PDF and URL sources) | A floor that tells apart files no text could be read from (an image-only PDF, for example). Invisible formatting characters are not counted. With 50 characters or more, the file reaches the AI whatever it says |
| A Claim's structure (decision / rule / observation frame) keeps only quotes found verbatim in the source; quotes shorter than 6 characters (after normalization) are too short to verify and are dropped | Claim extraction at ingest. an optional "Rebuild claim structure" for existing pages (started by you from the "…" menu of the Claims list; the body is never changed and a version is taken first) | Anti-invention guard, not a quality filter. A quoted field (the action, the rationale, the mechanism, the cited passage) that cannot be found in your text is dropped — the Claim itself is never dropped, and the number dropped is shown when the ingest finishes. Items, values and units must appear inside their cited passage. The direction of a change (up / down and the like) cannot be matched against text, so it is accepted as extracted: check it yourself |
| A source is read up to 40,000 characters per source in "Rebuild claim structure" | The source text sent to the model when you run "Rebuild claim structure" on existing Claims ("…" menu of the Claims list) | Context-window protection, and it is shown to you. A longer source is cut at 40,000 characters; the sources that were cut are listed in the result dialog ("View last result" in the same menu). A quote that sits in the cut-off part cannot be found verbatim, so it is dropped rather than guessed — the Claim itself is never dropped. Claims in the trash or archive are not rebuilt |
| When extracting Claims from a source, the list of existing Claims shown to the AI fits a budget (about 72,000 estimated tokens for instructions + list + source together) | Which existing Claims the AI can choose to merge new Claims into | Context-window protection, and it is shown to you. Only Claims are listed (Topics are routed in their own step), each with a short number instead of its long id. Every Claim is listed while it fits; when the list would overflow the model's input, the Claims most related to the source (shared wording with its text) are listed first and the rest are left out. The number left out is shown when the ingest finishes. A Claim that was left out is not merged into — a near-duplicate created this way is caught later by the Check tab |
| Copies kept for undoing upkeep operations are deleted after 365 days | Undoing an upkeep operation (merge, Organize topics, rebuild from sources, archive, restore a version) | So storage doesn't grow forever. A copy is a full copy of each page the operation rewrote, and 365 days is how long it is kept. Once the copy is removed, the operation disappears from the list and can no longer be undone |
| Meeting transcription reads windows of about 20 seconds, cut at a pause | Transcribing a recording while it is made (a recording started from a Voice note), and transcribing a recording afterwards | A pacing choice, not a limit on what is transcribed. Each window is transcribed on its own as it fills, so the text keeps up with the meeting; the rest is finished after you stop. Once 20 seconds have built up, the window is cut in the middle of the last pause (at least 0.3 seconds of quiet) after its first 10 seconds, so a sentence is not split in the middle (splitting one garbled the words on both sides of the cut). If nobody pauses, it waits up to 40 seconds and then cuts at the quietest moment. If the computer can't keep up, it processes what has piled up together, up to 180 seconds at a time. No stretch of audio is skipped. With language set to Auto, the window is cut into pieces at pauses in the conversation (silence; each piece is at most 20 seconds and at least 2 seconds), and the language is detected for each piece. Mixing languages inside a single piece can drop the minority language's speech. Auto detection picks either Japanese or English; a piece that can be judged as neither is merged into an adjacent judged piece if it is short (under 5 seconds), and otherwise discarded as noise — if you know the meeting's language, fix it in Settings |
| A window is sent to the speech model only if its loudest one-second level (RMS) reaches the larger of 0.004 (about -48 dBFS) and 4 times (+12 dB) that track's noise floor (the lowest 10% of its one-second levels so far, counting the window being judged) | Meeting transcription, per track (other side / you) | A hallucination guard. On silence, the speech model invents lines (a stock "thanks for watching" was observed on a silent other-side track). A window whose loudest level is at or above -34 dBFS (RMS 0.02) is always passed on, whatever the floor; the relative threshold (floor × 4) only applies to windows quieter than that. Room noise at the floor is not passed through, while quiet speech is, as long as it is well above that floor. The speech model's context is reset for every window, so one window's output never carries over into the next. If a nearly silent piece yields only a known stock phrase (Thank you / thanks for watching, and the like), it is dropped; if it was spoken clearly, it is kept |
| Only the sounding part of a piece goes to the speech model, with 1 second of margin on each side; a sentence repeated word for word on the same side is kept once; with language on Auto, a piece shorter than 6 seconds takes the meeting's language | Meeting transcription, per piece | Hallucination guards. Handing the model one second of sound inside twenty seconds of near-silence made it repeat an invented sentence four times on a nearly silent microphone, and six seconds of silence before the first words turned them into "thanks for watching". Repeats are only dropped for sentences of 4 characters or more, so a repeated "yes" stays. A short reply such as "はい" was often heard as English ("Hello.", "Okay."), so a piece under 6 seconds is transcribed in the meeting's language once at least 15 seconds of longer pieces have been judged and one language makes up 70% or more of them. Each side uses its own count once it has 15 seconds; until then it uses the count of both sides together, since you may hardly speak. So a meeting where the other side speaks English and you speak Japanese keeps each side's language. Longer pieces keep their own judgment, so a real English remark in a Japanese meeting stays English |
| A voice note's Clean up sends the transcript to your AI model in parts of at most 120 lines and about 5,000 characters, one part after another | Clean up in a voice note block | A size choice, not a filter. Every line is sent; a long meeting simply takes several requests, and the progress shows as N / M. The model is asked to drop fillers and pure backchannel ("um", "うん"), fix words that are clearly misheard in context, and split the text into short paragraphs of one speaker — never to summarize, add or translate, and to leave a word alone when it already makes sense. What you wrote in the note around the block (agenda, memos — up to 2,000 characters, not the block itself or what it added) goes along as hints too, and the model lists every word it changed so you can check it. The note's title and your Frequent terms go along as hints, up to 300 characters (if they are longer, the end — your terms — is kept and the start of the title is dropped). Nothing is written into your note until you choose Write out, and the Transcript tab keeps what was heard. With a model on this computer (LM Studio and the like), each part may write at most three times its input plus 12,288 tokens (plus 1,024 once a part shows the model does not think), so a model repeating itself stops early; a part cut off at that limit is tried once more at temperature 0.3, and if it is cut off again, that part keeps its original utterances — or, when names are hidden, is left out with a note — instead of failing the whole clean copy |
| With Hide names and contact details on, the clean copy and summary have names, organizations, contact details and ID numbers replaced, and only those can be added to the note | A voice note block with the box ticked | A privacy choice you make per meeting, not a filter on your notes. The model is asked to replace the details with placeholders; then Graphium replaces your Always hide these words (up to 300 characters), email addresses and phone numbers itself. Nothing else is removed, and the full transcript stays with the recording on this computer. See Hiding names and contact details |
| A transcribed stretch (up to 30 seconds) whose no-speech probability is above 0.6 is dropped | Meeting transcription, after the speech model has run | Anti-invention guard, not a quality filter. The model rates each stretch (up to 30 seconds) on how likely it is that nobody is speaking; above 0.6 the stretch is treated as made up and left out. The saved transcript keeps each stretch's value |
| Three models: large-v3-turbo (574 MB, recommended), small (488 MB) and base (148 MB), downloaded the first time | Settings → AI → Voice notes | Size against accuracy, your choice. large-v3-turbo is the most accurate and, in our measurement on Apple Silicon, faster than small (3.4 s against 11.1 s for a 25-second recording, with fewer mistakes); small and base are lighter for modest computers. The model is fetched once and kept on this computer; you can delete it there |
| Transcription runs on this computer and nothing leaves it | Meeting transcription | Not a limit but a promise. Audio and text stay in your Graphium data; the only network use is the one-time model download |
| Topic types are assigned 50 topics per AI call, from the title and one-line definition only | Assign topic types in Settings → Knowledge (and the same type given to a new Topic when it is routed on ingest) | A batch size, not a filter. Every untyped topic is sent; the count of calls is shown before you confirm. The type (concept / material / method / agent / place) only drives the Type column and the global graph's display toggles — it never changes what gets written on the page, and you can change it on the page banner at any time |
If you ever see behavior that looks like a hidden filter and isn't explained by this table, that's a bug worth reporting.
How do I tell whether it's Graphium or my model?
Run one controlled experiment: open Settings → Knowledge → Discover Insights from Claims, and note the result line — created, reinforced, and covered n/m. Full coverage with reinforcements but no new Insights means the pipeline looked at everything and your existing abstractions already cover the patterns present. Then assign a stronger Insight model and run it once more. If the stronger model creates Insights the smaller one didn't, the model was the bottleneck; if not, your Claims genuinely don't hold new recurring patterns yet — write more notes and let them converge.
What's the difference between Claims and Insights?
A Claim is one proposition taken from your notes or documents; an Insight is a relationship pattern taken from Claims and written to hold in other fields. They form the narrow waist of the hourglass: notes → claims → insights. See the Knowledge layer page for the full picture.
Claims and Insights are a Graphium-specific extension on top of Topics (which are built directly from your source material and are always on). You can turn the extension off entirely with Use claims in Settings → AI (inside the collapsed Experimental features group) — off by default the first time you use Graphium, on if you've used it before. Turning it off stops claim extraction on ingest (the Topic stage still runs from the same source text) and turns Insights off too, since Insights are built from Claims; pages you already made are kept and stay visible as long as at least one exists.
Can I manage tasks or projects in Graphium?
Not as a task manager, and that is a line rather than a gap. Graphium records what happened; a task manager tracks what should happen next, which is state you have to keep updating — due dates, owners, priorities, progress. Graphium stores none of it, because state that stops being updated turns into a lie, while a record only has to be true once.
What it does keep is the record-side of planning, and that may already cover what you need:
| You want to | What Graphium has |
|---|---|
| Jot down what is still to do | A checklist inside the note (/checklist). One bit per item: checked or not |
| See decisions and TODOs from a meeting | The summary of a voice note lists them, each linked to the line it came from |
| Plan a project and break it into pieces | A plan note (a note in the "plan" folder) with an index table; each row becomes a process note, and planned hand-offs are drawn as dotted lines next to what actually happened — see folders |
| See the open items across all notes | Ask an assistant over MCP: list_todos returns every unchecked item with its note and block |
What it will not do: give an item a due date, an owner or a priority, tick it off from outside, or draw a progress dashboard. If you keep tasks in a tool that also speaks MCP, connect both to the same assistant — "turn the open items in this note into tasks" works today, and Graphium does not need to know which tool is on the other side.