Manifest is the foundation the rest of the work runs on. It is a document intelligence engine: it takes unstructured content, makes it addressable, and returns sourced answers. Here is how it is put together, and why.
The shape of it
Manifest is a small, deliberate stack. The goal was never novelty for its own sake. It was a system I could operate, reason about, and demo to a stranger.
store PostgreSQL + pgvector
search vector similarity over embedded chunks
output sourced answers, with citations
FastAPI keeps the API surface clean and typed. PostgreSQL is the system of record. The
pgvector extension lets the same database that stores the documents also store and
search their embeddings, which keeps the architecture simple: one store, not a separate vector
database to keep in sync.
1 · Ingest
Everything starts with acquisition. Manifest accepts documents, URLs, and raw text. Each source is parsed into clean text, stripped of the noise that surrounds real content, and tagged with metadata so it can be tracked later. The unglamorous work here is most of the work: a retrieval system is only ever as good as what it ingested.
2 · Embed
Clean text is chunked into passages and each passage is embedded into a vector, then written to pgvector. This is the step that turns a pile of documents into something addressable by meaning. Two passages that say the same thing in different words land near each other in vector space, which is exactly what keyword search cannot do.
Chunking is a real design decision, not a detail. Too large and retrieval gets vague. Too small and you lose the context that makes a passage meaningful. The chunk is the unit of truth the rest of the system reasons over.
3 · Search
A query is embedded the same way the content was, and Manifest runs a vector similarity search to pull the passages closest to the question. The result is not a page of blue links. It is the specific set of passages most likely to contain the answer, ranked by relevance.
This is the difference between "find documents that mention this word" and "find the parts of my corpus that actually address this question." The second one is what makes the system feel like an analyst instead of a search box.
4 · Cite
This is the part I care most about. Manifest returns sourced output: the answer comes back attached to the passages and documents it was drawn from. You can follow any claim to its origin.
If you cannot trace an answer to a source, it is not intelligence. It is a guess with good grammar.
Sourcing is what makes the output safe to act on. It is also what separates an engine from a chatbot. A chatbot asks you to trust it. An engine shows its work.
One foundation, many verticals
Manifest is built so that vertical products live on top of the same core. Each vertical inherits ingestion, embeddings, search, and sourcing, and only adds what its domain actually needs. That is the leverage: the expensive, reusable machinery is solved once, and every new application starts from a foundation instead of a blank page.
The first vertical aims this stack at a specific market. It stays private until it is ready to show. The foundation, though, is the part worth explaining now, because it is the part that does not change from one vertical to the next.
Where it is going
The near-term target is a stranger-demoable intelligence engine: a polished interface, working vector search, sourced citations, and written architecture docs. Not a chatbot, and not a prototype that only its author can run. Something you can sit down in front of and understand.
That is the standard the whole system is being held to. Everything above is in service of it.