Searching

It finds by meaning and connection, not keyword matching. `@` attribution, causal and time questions, and how to read a result.

AiAkiv's search is meaning plus connection, not keyword matching. Used well, it answers questions keywords can't.

The basic move: just ask in plain language

ak how did the combat system design change?

Search defaults to hybrid (events + entities, meaning-based), so it finds things even when no word overlaps. Each result carries:

  • reason: why this matched (similar embedding / shared entity / sequential link, and so on)
  • the link map (hint): which threads, entities, and topics tie the results together

Don't read the results flat: read the reason and the link map with them. When you ask for "latest" or "related", a similar-embedding marker often points at a synonym whose name changed; follow it and more turns up.

When the summary isn't enough, pull the original

Search gives you the event summary. A summary is LLM-generated, so it can occasionally be inaccurate. When you need the exact content, use fetch full text to pull the event's original.

Narrow by author or team with @

Who wrote a memory is stamped by the server at save time (it can't be forged). An @handle at the very start of the query is the attribution filter.

  • @[email protected]: browse that person's events, newest first
  • @[email protected] save bug: search within that person's scope
  • @teamname ... Filter to content attributed to that team

To see only the records left by an app connected to AiAkiv, put #appname at the very start. Apps are still being prepared, so there is no name to use yet; as apps are released, their names are added here (for example #plan once the plan app is out). Without a symbol, it is an ordinary search as usual.

An ordinary tag can't start with @, which is why "who wrote this" can't be forged by a client or an AI.

The questions keywords can't do: where AiAkiv earns its place

These are where AiAkiv shines, because keywords fail structurally.

  • Causal and temporal jumps: "which past decision caused this bug?" From the bug event, back along the causal link and the timeline to the earlier decision. (Tying the cause in at save time is what pays off here → Saving.)
  • Shared-entity connections: "why did inventory and save-files change together?" Through the entity the two events share.
  • Change history: "show me the history of balance tuning". Events on the same topic laid along a timeline.

Open-ended questions about the most recent thing work well too: "what's the latest bug and what caused it?": you don't have to name a specific bug; the graph brings back the recent event and its causes.

Asking by relationship: ak graph

When you want to fix the scope first and then ask, as in "only among memories where this name appears" or "only inside this tag", put ak graph in front. The AI translates the question into a graph query and runs it.

ak graph among memories where the save format appears, the ones that fixed a load bug
ak graph in the balance tag, the ones that changed enemy health
ak graph memories where both inventory and save format appear
  • The first picks, from the memories where "save format" appears, the ones closest in meaning to the sentence.
  • The second does the same inside a tag.
  • The third collects memories where both names appear together.

Names and tags are matched exactly as they were saved. If the spelling is uncertain, the AI checks it first.

Along with the answer, the AI shows the query it ran and what it means, in one line, so you can see what was actually looked up.

Query run: START a = events(entity: "save format", text: $q, k: 20) RETURN a, a.score ORDER BY a.score DESC, a.id (meaning: the 20 memories mentioning "save format" closest in meaning to "fixed a load bug")
  • Send ak graph on its own and the AI shows three example requests to copy.
  • Without ak graph, the AI can still use a graph query on its own when the question is about connections. ak graph is the way to call it directly.
  • "Could not confirm" is not "none". If a result has 0 items and the AI says it could not look through the whole scope, that means it was not confirmed this time, not that nothing exists. 0 items after the whole scope was covered is a real "none".
  • Some servers have this feature turned off. The AI then searches the best way it can and tells you it is off.

The whole grammar, how to read the response, and the limits are gathered in Asking by relationship.

The server decides the search scope

The search scope (domains, tags) is decided by the server from its access policy: a client cannot widen or narrow it through the query. The response's searched_scope tells you the scope actually applied. "What I can read within my team" is the ceiling. If you want only one domain, filter the results; don't put a domain filter in the query (that can silently drop data).

Next

Full index → Docs View as Markdown