Projects / Synapse

Solo product design & engineering

Synapse

A multi-tenant research workspace that turns document collections into grounded answers, inspectable evidence, and reusable visual artefacts.

00 / Overview

Research software should show its work.

Synapse ingests PDFs and Google Drive libraries, understands layout and visual regions, and answers across one or many documents with page-level evidence. The system was built end to end—from the Next.js product and tenant model to the FastAPI orchestration layer, GPU workers, retrieval pipeline, and evaluation harness.

Role
Solo builder
Surface
Web application + GPU backend
Focus
Grounding, traceability, collaboration

01 / Product walkthrough

One workspace, from source to cited answer.

01/15

Product promise screen in Synapse
01
Product promise

A research workspace built around verifiable answers.

How it works screen in Synapse
02
How it works

The product story connects ingestion, reasoning, and cited output.

Research libraries screen in Synapse
03
Research libraries

Documents become scoped knowledge bases with visible processing state.

Grounded chat screen in Synapse
04
Grounded chat

Answers remain connected to their source chunks, pages, figures, and tables.

Team chat screen in Synapse
05
Team chat

Shared conversations can search approved libraries across organizations.

Tenant controls screen in Synapse
06
Tenant controls

Members, roles, invitations, and library access are explicit.

Agent mode screen in Synapse
07
Agent mode

A goal can become a structured visual or research artefact.

Traceable execution screen in Synapse
08
Traceable execution

Planning, data acquisition, construction, and validation stay visible.

Saved evidence screen in Synapse
09
Saved evidence

Important source material can be kept beside the conversation.

Saved visuals screen in Synapse
10
Saved visuals

Generated and retrieved visuals remain reusable.

Visual generation screen in Synapse
11
Visual generation

Agent output extends from prose into charts and diagrams.

Graph generation screen in Synapse
12
Graph generation

Entities and relationships are extracted from selected knowledge.

Knowledge graph screen in Synapse
13
Knowledge graph

A navigable representation exposes how concepts connect.

Usage visibility screen in Synapse
14
Usage visibility

Consumption and processing are surfaced instead of hidden.

Operational detail screen in Synapse
15
Operational detail

The workspace keeps its infrastructure legible to the user.

02 / System

Three planes, one traceable path.

The product separates the edge experience, GPU execution, and shared state so ingestion and chat workloads can scale without blurring tenant boundaries.

System architectureSynapse / System map
At the edgeGPU application serverShared state & models
Web applicationNext.js 16 · React 19
Cloudflare WorkerOpenNext host · API proxy
FastAPI layerchat · agent · graph · pipeline
Worker poolsync · layout · OCR/VLM · chunk · embed · cluster
Retrieval & reasoningcorrective multi-agent loop
Model APIsOpenAI · OpenRouter
Embedding & rerankBGE encoder · cross-encoder
Supabase + pgvectortenants · jobs · vectors · chat
Cloudflare R2documents · derived artefacts
Next.js at the edge, a FastAPI/GPU execution plane, and durable shared state remain independently scalable.
Edge

Fast product surface

Next.js 16 and React 19 are deployed through OpenNext on Cloudflare Workers, with API proxying and object delivery at the edge.

Compute

Demand-driven workers

FastAPI coordinates queue-backed stages. The worker pool scales against pending work and packs model processes to the available VRAM budget.

State

Durable and tenant-aware

Supabase holds organizations, membership, conversations, jobs, and pgvector embeddings; R2 stores source and derived artefacts.

03 / Multi-agent retrieval

Reasoning is a controlled loop, not one prompt.

Query classes route work differently. Spotlight questions stay narrow; comparison, aggregation, multi-hop, and multi-entity requests widen retrieval and can run bounded gap-filling passes before synthesis.

Grounded chatSynapse / System map
QuestionCorrective retrievalGrounded outcome
User questionplain-language request
Plannerclassify · rewrite · decompose
Hybrid retrievalvector + keyword search · RRF
Rerank passagescross-encoder selects top evidence
Grade evidencerelevant and sufficient?
Compose answercitation per supported claim
or
Abstain / retrieve againnever force an unsupported answer
Weak evidence loops back through retrieval; sufficient evidence advances to a cited answer.
  1. 01

    Planner

    Classifies intent, rewrites the query, and decomposes complex requests.

  2. 02

    Retriever

    Fans out dense and lexical search, expands neighbours, then reranks evidence.

  3. 03

    Extractor

    Turns retrieved passages into concise notes that retain chunk and page attribution.

  4. 04

    Retrieval grader

    Checks relevance and sufficiency before the answer is allowed to proceed.

  5. 05

    Gap finder

    Runs bounded critique rounds and creates focused searches for missing evidence.

  6. 06

    Synthesizer

    Builds the final answer from the consolidated evidence and available visuals.

  7. 07

    Faithfulness verifier

    Flags unsupported claims and triggers a correction pass when required.

04 / Document intelligence

Documents become structured, searchable evidence.

A queue-driven seven-stage pipeline synchronizes files, detects layout, extracts text and visual regions, chunks the resulting representation, embeds it, and builds topical clusters. Text extraction and image captioning can run in parallel after layout.

Document ingestionSynapse / System map
SourceStructure & extractionSearch representation
Syncfetch files from source
Layout parserDocLayout-YOLO regions
Text extractionborn-digital + scanned
Image captioningfigures & tables via VLM
Chunkingbuild text IR
EmbeddingBGE vectors to pgvector
Clusteringtopical groups
Artefacts persisted → Cloudflare R2 + Supabase / pgvector
Queue-driven stages persist text, layout, visual artefacts, embeddings, and clusters as work advances.

Model roster

Specialists where structure matters.

Layout
DocLayout-YOLO · DocStructBench weights
OCR
Surya OCR, with optional GLM-OCR fallback
Visual understanding
Qwen2.5-VL-72B via OpenRouter · Qwen2-VL-2B local fallback
Embeddings
BAAI/bge-large-en-v1.5 · 1024-dimensional vectors
Reranking
BGE reranker v2-m3 inline · BGE reranker base in worker mode
Agent reasoning
OpenAI GPT family · configurable independently for each role

05 / Agent artefacts

Answers can become usable outputs.

A separate agent mode can plan a visual task, acquire data, build a Vega-Lite or Mermaid specification, validate it, render it, and narrate assumptions. Data values remain bound in code so the model does not invent the chart’s numbers.

Agent modeSynapse / System map
GoalBuildValidateDeliver
User goallibraries · file · request
Planintent · data · artefact
Acquire dataexact re-parse + retrieval
Build the specVega-Lite or Mermaid
Validate & repairschema checks · one repair pass
Renderinteractive + downloadable
Narrateresult · assumptions · sources
Data values are bound in code rather than authored by the model, keeping visuals tied to source evidence.
Knowledge-graph constructionSynapse / System map
EvidenceEntity pipelineInteractive graph
Processed librarychunks + captions
Extractentities & relations per chunk
Resolvemerge duplicates · normalize names
Build graphnodes · edges · confidence
Serveinteractive graph in the web app
Provenance retained → graph node / edge → source passage
Every node and edge retains provenance back to the source chunk stored with the graph in Supabase.

06 / Platform foundation

Collaboration without collapsing boundaries.

Organizations own their libraries. Membership, invitations, sharing, and team-chat access are modeled explicitly, while the processing plane keeps jobs recoverable and auditable.

Core data modelSynapse / System map
TenantKnowledgeConversation & graph
organizationtenant boundary
usermember of an organization
libraryconnected collection
documentfile + processing status
chunk_embeddingtext chunk + vector
chat_threadqueries a library
chat_messageanswer + citations
graph_node / edgeentities + relationships
Rows are scoped to an organization and protected with row-level security.
Deployment viewSynapse / System map
BrowserCloudflareGCP GPU VM
Userweb browser
Cloudflare
synapse-webNext.js via OpenNext
R2 bucketdocuments + artefacts
GCP · NVIDIA L4
FastAPI servicechat · agent · graph · pipeline
Pipeline workerslayout · OCR/VLM · embed · cluster
Local modelsBGE encoder + reranker
The edge application talks to a dedicated GPU service while R2 and Supabase provide durable shared state.

07 / Evaluation design

The evaluation path is designed before the scorecard.

The repository includes a DOUBLE-BENCH-oriented harness for page/document retrieval, dual-judge answer review, RAGAS, citation accuracy, honesty, latency, and throughput. The system map explains the measurement path, followed by the supplied retrieval and dual-judge benchmark snapshots.

Evaluation designSynapse / System map
DatasetRetrievalAnswersOperations
DOUBLE-BENCHsingle-hop + multi-hop documents
Retrieval passhit@1 · hit@3 · hit@5
Deep answer passbounded agentic queries
Dual judgesanswer correctness review
RAGAS + citationsgrounding · honesty · recall
Efficiencylatency · throughput · spend
The harness defines the dataset, retrieval, answer-quality, grounding, and operational measurements shown in the result snapshots below.

Benchmark snapshots

Retrieval and answer-quality results

Retrieval quality

Document-level hit@5

0.839Overall
1.0001-hop
1.0002-hop
0.7733-hop
0.857Born-digital
0.824Scanned
Document-level hit@5
Exact supplied results: 0.839 overall, perfect 1-hop and 2-hop retrieval, 0.773 for 3-hop, 0.857 for born-digital documents, and 0.824 for scans.

Answer quality

Dual-judge result distribution

CorrectPartially correctIncorrect
Judge B
70%12%18%
Judge A
80%14%6%
Judge A: 80% correct, 14% partially correct, 6% incorrect. Judge B: 70% correct, 12% partially correct, 18% incorrect.