DEV Community: SidakSethi-Singh

SlothClerk: a sloth that reads your contracts offline with Gemma

SidakSethi-Singh — Sat, 24 Oct 2026 08:32:28 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

I avoid reading contracts. Rent agreements, NDAs and service terms are long, and the one clause that hurts is always buried in the middle.

So I built SlothClerk, a lazy person's contract reader that runs entirely on my laptop. I upload a PDF or DOCX, and about a minute later I get:

a plain-language summary
key dates, money amounts and obligations
red flags (jury waivers, auto-renewals, one-sided repossession, penalties), each with a one-sentence explanation of what it could cost me
an action checklist
a chat box for follow-up questions

Every item links back to the sentence it came from. I click [chunk_1] ✓ and see the exact source text highlighted, so I never have to just trust the model.

Demo

Watch the demo, recorded with Wi-Fi off: SlothClerk demo video

In the video: upload a contract, get results in about a minute, click a citation to see the source sentence, and ask a follow-up question in the chat.

Code

SidakSethi-Singh / slothclerk

SlothClerk 🦥📄

100% Offline, Privacy-First Document Assistant

SlothClerk processes sensitive documents (contracts, NDAs, leases, MSAs) locally with zero external cloud API requests, telemetry disabled, and strictly grounded citations verified against the source text.

🌟 Key Features

100% Offline & Private: Powered by local Ollama models (gemma3:4b and nomic-embed-text) with ChromaDB telemetry completely disabled.
Verifiable Citations: Every claim, date, obligation, and red flag is linked to a source chunk and verified verbatim against the document text.
Deterministic Clause Scanner: Pre-scans high-signal legal clauses (e.g. repossession, waivers of jury trial, automatic renewal, liquidated damages, penalties) before LLM synthesis (~69,000+ chars/sec).
📊 Cloud vs Local Benchmark Suite: Quantitative performance and cost comparison against OpenAI GPT-4o, Claude 3.5 Sonnet, and GPT-4o-mini (python benchmark.py, cli.py --benchmark, or GET /api/benchmark).
🎙️ ElevenLabs Voice Executive Briefing: Spoken audio briefings of contract summaries and critical red…

View on GitHub

How I Built It

Model: Gemma (gemma3:4b) running locally through Ollama
Search and chat: nomic-embed-text embeddings with ChromaDB (telemetry off) for the RAG chat
Backend: FastAPI, with one analysis pipeline shared by the CLI and the web app
Frontend: a single-page UI with progress stages, result cards and a citation popover
Extraction: pypdf and python-docx, with sentence-aware chunking

The pipeline works in two layers, which I only arrived at after things broke:

Rules find, the model explains. A regex scanner finds high-signal clauses ("jury", "waive", "automatically renew", "late charge", "without refund") and uses the sentence itself as the quote. Gemma then writes the title, severity and a one-sentence consequence.
Nothing ships unchecked. Quotes are matched against the source text, deadlines must appear in the cited sentence, and duplicates and headings are filtered out.

Why Does Open Innovation Matter?

Contracts are exactly the documents I don't want to upload to someone else's server.

Privacy: the document never leaves my machine. No account, no API key, no retention policy to read.
Offline: the demo video is recorded with Wi-Fi off.
Cost: $0 per document. Running it on a hundred leases costs the same as running it on one.
Control: I could set temperature to 0, constrain the output with a JSON schema, inspect every prompt, and swap models by editing one line in .env. With a closed API I would have been guessing why an answer changed.

To be honest, a large closed model would probably read these contracts better. What open weights gave me was a tool I can trust with private documents, and the freedom to build verification around the model instead of hoping it behaves.

The Lazy Payoff

About 35 to 70 seconds per document on my laptop, with a 4B model
NDA test: 12/12 citations found verbatim in the source text
A first pass over a 7-page lease in about a minute, instead of reading it line by line
$0 to run

What Went Wrong (the honest part)

"Verified" didn't mean "correct." My first version checked that each quote existed in the document, and 19/19 passed, yet the model still invented deadlines ("within 3 days", "Finance Department") that the contract never mentioned. I added a grounding check: a deadline must appear in the cited sentence, or it is dropped.
A 4B model missed clauses on long documents. On a 7-page lease it flagged one issue and skipped the jury waiver and the late fee. That is why I added the rule-based scanner.
The model hallucinated a renewal from the phrase "terminates promptly" and called it "implied." I now reject flags that contradict their own quote.
My web app ran an older pipeline than my CLI, so browser results differed from terminal results. I merged them and added a test that both paths return identical counts.
My C: drive had 95 MB free while I installed Ollama, and my laptop shut off mid-build. I moved the models to another drive and now commit often.

Limits

English only. No scanned images (OCR was cut for time).
The sample contracts are synthetic. I have not tested real contracts.
A 4B model's wording is sometimes awkward, and some flags overlap.
Not legal advice.

Prize Categories

Best Use of Gemma: Gemma 3 4B is the core of the project, running locally.

Why Vector RAG Fails AI Agents: Building an Autonomous SRE Swarm with FalkorDB

SidakSethi-Singh — Sun, 18 Oct 2026 15:29:23 +0000

Large Language Models depend on the context they are given. In the year the usual way to give context has been Vector RAG (embeddings plus cosine similarity).. In real production settings especially for enterprise microservices and site reliability engineering Vector RAG fails completely.

When an incident hits a distributed system an AI agent does not need text similarity. It must know:

What breaks three hops if this database goes down?
Which recent code. Pull request touched this service’s connection pool?
What past incident had this exact failure signature. How was it resolved?
Who owns this service. Who is on call right now?

Embeddings cannot answer multi‑hop causal questions. Graphs can.

That is why we created FalkorSynapse for the WeMakeDevs Graph Hacks 2026 Hackathon.

Why FalkorDB? Solving the Latency Bottleneck

graph databases such as Neo4j use pointer‑chasing traversal algorithms. These are powerful for batch queries. They are too slow to run inside an AI agent’s active step‑by‑step reasoning loop.

FalkorDB is different. It represents graphs as ** adjacency matrices powered by GraphBLAS linear algebra in C*. Multi‑hop traversals and graph algorithms do not walk pointers; they perform matrix multiplications in **sub‑milliseconds (<1 ms)*.

This architectural breakthrough let us make FalkorDB the active central nervous system of a multi‑agent swarm.

The Architecture: 3 Agents, 1 Synaptic Mesh

FalkorSynapse models an enterprise FinTech platform (Services, PostgreSQL, Kafka, Redis, Engineers, Pull Requests and Incident Runbooks) as a graph orchestrated by three specialized agents:

1. The Topology Sentinel (Track 01: Acting on Connected Data)

When an anomaly appears the Topology Sentinel runs OpenCypher traversals to calculate the downstream blast radius across multiple hops:


MATCH path = (root {id: $target_id})-[:ROUTES_THROUGH|FORWARD_CALL|PUBLISHES_EVENT|WRITES_TRANSACTIONS*1..3]->(downstream)

RETURN downstream.id, downstream.name, length(path) as depth

ORDER, BY depth ASC;

It calls FalkorDB's native PageRank algorithm to determine system vulnerability and correlates recent git deployments to identify the root cause.

2. The Episodic Memory Coordinator (Track 02: Agent Memory)
Instead of dumping chat transcripts into an LLM context window, FalkorSynapse stores episodic incident graphs (:PastIncident) and validated procedural runbooks (:Runbook) in FalkorDB. When an alert fires, it recalls how past failures were resolved, fetches the highest-confidence automated runbook, and coordinates inter-agent state handoffs via immutable graph tokens (:AgentHandoff).

3. The Enterprise Brain (Track 03: Company Brain)
Institutional knowledge is usually fragmented across Slack channels and stale docs. FalkorSynapse maps structural ownership:

cypher
MATCH (e:Engineer)-[r:PRIMARY_ARCHITECT|SCHEMA_OWNER|MAINTAINER]->(target {id: $target_id})
RETURN e.name, e.role, e.slack, e.on_call, type(r) AS relation;
It instantly identifies the system architect, checks the active on-call rotation, and correlates git author provenance.

Autonomous Healing in Action
With one click, FalkorSynapse executes the verified runbook, updates the live graph back to healthy, and writes the mitigation into FalkorDB's persistent memory. The swarm actually learns from every incident.

Engineers can also talk directly to the architecture using our GraphRAG Natural Language Agent—translating plain English questions like "Who owns Payments Core and who is on call?" into OpenCypher queries executed in under 0.1ms.

Key Takeaways
Context is not decoration: If you remove the graph database from an agentic system and the system still works, you built a toy. In FalkorSynapse, FalkorDB is the engine.
GraphBLAS changes the game: Sub-millisecond graph queries make it possible to run graph algorithms inside the inner reasoning loop of AI agents without latency penalties.
The future of SRE is graph-native: Connecting code commits, services, teams, and runbooks into a single graph is the only way autonomous agents can reason safely in production.

Check out the project:

🐙 GitHub Repository: https://github.com/SidakSethi-Singh/falkorsynapse
⚡ Built for: WeMakeDevs × FalkorDB Graph Hacks 2026