Research
The place to put what you have figured out, while you are still figuring it out. A tagged investigation log stored with your cix account rather than in chat history.
Use it for bug investigations, architectural analysis, performance and security review, incidents, and open-ended exploration.
Why not just the conversation
Chat history is a bad memory. It's long, unsearchable, ordered by time rather than by topic, and it's gone when the session ends.
An investigation recorded here is still readable next week, from another machine, or by an agent session that never saw the original conversation.
The tags
Every entry is classified when you write it, which is what makes the log readable later instead of being a wall of bullets.
| Tag | For |
|---|---|
fact | Something observed and verified, with a citation |
hypothesis | A proposed explanation, not yet confirmed |
question | An unresolved gap |
dead-end | A path investigated and rejected |
map | How something is structured |
next | A concrete follow-up the investigation surfaced |
Facts are not explanations
The distinction that matters most is between fact and hypothesis.
- A fact is observed: "the worker's heartbeat pauses for 12–15 seconds after reconnecting."
- A hypothesis explains: "the reconnect timing is probably blocking recovery."
Writing the second as though it were the first is how an investigation ends up building on something nobody checked. Record both — just not under the same tag.
Dead ends are worth writing down
A rejected path is one of the most valuable things in the log, and the most commonly skipped. Record why it failed, which assumption turned out wrong, and what evidence closed it.
The cost is asymmetric: writing it takes a minute, and the next session re-walking it can take hours.
Note — an investigation with no dead ends after real work is a little suspicious. It usually means the trail wasn't recorded, not that the first guess was right.
Writing entries that survive
The test for every entry: could someone read this cold, with no access to the conversation that produced it?
- Name the thing rather than referring to "the issue we discussed".
- Cite the evidence inline — a file and line, a query, a log line, a commit.
- Be explicit about confidence. "Verified on commit abc123" beats "verified".
One topic, one question
A topic answers one question, and its name is that question — search-misses-renamed-symbols, not search. A topic named after a whole system area tends to accumulate contradictory conclusions from three different investigations.
When a topic starts branching, split it.
Where it goes next
An investigation that reaches a conclusion becomes one of three things: a small fix planned directly, a design when the change affects architecture or data, or more investigation because it isn't actually settled yet.
Choosing between them is the point. Promoting an unfinished investigation silently converts uncertainty into implementation work.
Next: Design.