Search and graph

Finds by meaning and by exact term at once

Two searches run in parallel on the same query, one by meaning and one by literal term, and their results fuse into a single list. On top of that a graph shows which document links to which. All of it runs on your server.

  • Fused by rank
  • 1,024-dimension vectors
  • Zero credits per search

Two routes, one list

Search by meaning finds the note that talks about the same thing in different words. Search by literal term finds the contract code you typed exactly. They combine on the position each document held in its own list rather than on its score, so neither scale dominates the other. An exact match weighs slightly more on purpose: if you typed an unusual word, you meant it.

  • One result per document, with the 240-character passage that fits best
  • A note that came third in one list and was absent from the other can come out first
hybrid search

extended warranty master agreement

By meaning

  1. 1 service-agreement.md
  2. 2 after-sales-policy.md
  3. 3 andes-v2.md

By exact term

  1. 1 andes-v2.md
  2. 2 minutes-2026-03-11.md

Fused on rank in each list

  1. 1 andes-v2.md both
  2. 2 service-agreement.md meaning
  3. 3 minutes-2026-03-11.md exact term
The contract comes out first because both lists carry it, even though it topped neither.

Isolation lives inside the query

The company id sits in the where clause of both queries, not in a filter applied afterwards to the results. That matters more than it sounds: a post-filter that fails lets rows through, while a condition that is part of the query has no rows to let through. Underneath, the database also applies row-level security, with the id taken from the verified session and never from the request body.

the two legs of the query simplified

-- by meaning

WHERE "companyId" = $company

ORDER BY embedding <=> $vector

-- by exact term

WHERE "companyId" = $company

AND content %> $text

The query always travels as a parameter, never concatenated into the statement.

On top of this, PostgreSQL applies row-level security on every table holding company data.

Uploading your document history consumes no credit

The model that turns text into vectors runs on your own infrastructure. Indexing twenty years of minutes therefore costs machine time and zero credits, and searching does not bill either. Credit is spent when the agent works, and only there. That is the difference between uploading the whole archive at once and having to decide which documents are worth indexing.

  • 1,024-dimension multilingual vectors, with an input of up to 4,096 tokens
  • The same local model for Spanish and English, with nothing translated in between
what consumes credit
The agent works
consumes
Uploading and indexing documents
0 credits
Searching and browsing the graph
0 credits
Recalling past conversations
0 credits
People talking to people
0 credits
An agent turn costs 190 credits on average, measured rather than estimated.

How a document is cut before it is indexed

It splits on Markdown headings first, which is where the author already marked a change of subject. If a section runs long it is cut at 1,200 characters with 150 of overlap, so a sentence broken in the middle still turns up whole in one of the two chunks. And if the file has not changed it is not reindexed: the content hash is compared and the work is skipped.

  • Moving a note to another folder keeps its vectors if the content did not change
  • Calls to the model go in batches, with retries and a cache keyed on the content hash
  • Writing a thousand notes at once queues the work instead of taking the server down
cutting a note

## Discount policy

chunk 1 overlap chunk 2
Split first
on Markdown headings
Chunk ceiling
1,200 characters
Overlap
150 characters
The overlap is what stops a definition split in two from becoming unfindable.

The graph: neighbors, backlinks and subgraphs

Every note is a node and every bracketed link is an edge. From one note you can see what it points at, who points back at it, and the subgraph of its folder, which is the quick way to discover that a manual is orphaned or that three sets of minutes cover the same agreement. The graph namespace is keyed to the company id rather than to its name, so renaming the company does not orphan the graph.

  • The browser never sends queries to the graph: the server builds them
  • Before answering, the requested path is checked as belonging to your company; if it does not, it does not exist
department graph neighbors of andes-v2
andes-v2.md minutes-2026-03-11 service-agreement quito-proposal after-sales-policy signature-template
The links come from what you already wrote: the graph does not invent relationships.

What it does not do yet

There are no automatic connectors yet

The vault fills up by uploading files and folders, or by letting the agent write into it. There is no sync with Drive or SharePoint, so a large migration happens once, gets indexed, and from then on the work happens inside. For most companies that is a one-time event nobody thinks about again, but if your living documentation sits in another system it is worth saying so before you start.

What does help: indexing costs no credit, so the initial migration carries no AI cost however big it is.

Start free. Pay when it earns it.

Starter credit so you can try it against your own real documentation. No card and no sales call. If it works, you pick a plan.

  • Starter credit on the house
  • No credit card
  • Every feature included