How it works
How an answer gets made.
Two pipelines: one that puts material into the bank, one that gets an answer back out of it. Both are described here as they are actually built, not as they are planned.
The flow
From a conversation to an answer, live.
Sources
- Meetings and recordings
- Calls, interviews and voice notes
- Mail and calendar
- Google Drive and Docs
- SharePoint and OneDrive
- News, market data and your own systems via API
Skientia
- 1Ingestion: internal and external sources
- 2Transcription of meetings and calls
- 3Voiceprint: who said what
- 4Sorted by topic, team and customer
- 5Sentiment analysis of meetings and sources
- 6Knowledge graph with decisions and tasks
Access control: source, role, team
What comes out
- Decisions
- Tasks
- Topics
- Sentiment
- People
- Companies
- People and teams
- Leadership
- AI assistants and agents
- Slack, Jira and notifications
Real time, both ways
Agents read and write to the same memory, under the same permissions.
Getting material in
Indexing runs in background workers, never in a request handler. A slow source can make itself late; it cannot make the app slow.
1
Detect the change
A source changes: a meeting finishes processing, a document is edited, a connector reports new material.
2
Build stable chunks
Content is split with a deterministic index, so the same source always produces the same chunks in the same order. Re-running the pipeline is idempotent.
3
Hash the content
Each chunk carries a content hash. Unchanged text is recognised and skipped rather than re-embedded, which is what keeps reindexing affordable.
4
Generate embeddings
Embeddings are produced outside the request path and stored alongside the chunk with the model and dimensions used, so a future model change is a migration rather than a rewrite.
5
Attach access rules
The source's permissions are written with the chunk and replaced wholesale on each sync, fail-closed, so a permission that disappears upstream disappears here.
Getting an answer out
Every question is scoped to one organization before anything else happens. Nothing crosses that boundary at any stage.
1
Scope to the asker
Access rules are applied to the candidate set before retrieval ranks anything. Material the asker cannot open is not ranked, not counted, and not mentioned.
2
Two independent searches
A full-text search over Postgres and a cosine-similarity search over vector embeddings run as separate ranked lists. Exact phrasing and paraphrase are different failure modes, and one method does not catch both.
3
Reciprocal-rank fusion
The two lists are merged so that a result ranked highly by either method survives into the final set, rather than being averaged away by the method that missed it.
4
Ground the answer
Chunk ids and source metadata are passed to the model with the content, so the answer is generated against retrieved material and every claim can name the chunk it rests on.
5
Keep the trace
The retrieved chunk ids and model usage are stored with the answer. An answer that turns out to be wrong can be investigated rather than argued about.
The stack
Built on the stack behind Uber, Google and Netflix.
Skientia runs on the same open technologies that carry some of the world's largest services, chosen for speed, type safety and staying power.
Go
Created at Google and the backbone of Uber's services. Our API, workers and CLI are one fast, typed Go codebase.
Protocol Buffers and gRPC
Google's contract format, also used across Netflix. Web, iPhone and the CLI all speak the same typed API.
PostgreSQL with vector search
Full-text and vector search in one database, so retrieval stays fast and every access rule is enforced in one place.
React and Next.js
The interface library Meta and Netflix build on, rendered on the server for fast first loads.
Cloudflare and Google Cloud
The web app runs at the edge, close to your team. The API and workers run in Google Cloud in the EU.
Swift and Kotlin
Native apps, not wrapped websites, built on the same generated API clients.
What we don't claim
Retrieval quality depends on what you connect; a bank with one meeting in it answers one meeting's worth of questions. Inferred conclusions are labelled as inferred because they can be wrong, and the interface is built so you can check them rather than trust them. And only connectors you can switch on today are shown anywhere on this site.