DEV Community: Sushant Singh Negi

SlothAuth: Autonomous Overnight Prior-Auth Prep with Local Gemma, LangGraph, and pgvector

Sushant Singh Negi — Sat, 24 Oct 2026 17:09:12 +0000

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

What I Built

The Burden: Why Modern Medicine Needs to Channel the Sloth

There is no creature on Earth that understands energy conservation quite like the sloth. The three-toed sloth moves at a deliberate 0.15 miles per hour, refusing to waste a single calorie on pointless exertion.

Now contrast that with the daily life of an American physician or hospital care coordinator.

Every single week, the average medical practice is forced to complete 39 prior authorizations (PA). That adds up to more than 13 hours of pure administrative drudgery per physician every week—nearly two full working days spent on paperwork rather than healing patients. For every single patient requiring an MRI or a biologic medication, a clinician or nurse must spend 35+ minutes:

Opening four different electronic health record (EHR) tabs to locate conservative therapy dates, physical therapy discharge summaries, and medication trials.
Manually digging through 80-page insurer policy bulletins to decipher arcane clinical guidelines.
Hunting for baseline safety lab dates (such as tuberculosis screenings or liver enzymes) so an insurance algorithm doesn't automatically reject the claim.
Typing a multi-page "Medical Necessity Justification Letter" from scratch.

This is the definition of pointless cognitive exhaustion. It fuels healthcare burnout, delays critical patient treatment by weeks, and turns brilliant medical minds into glorified data-entry clerks.

       ┌─────────────────────────────────────────────────────────────┐
       │             THE MORNING CLINICAL PARADOX                    │
       │                                                             │
       │  Traditional Workflow: 35+ Min / Patient                   │
       │  [EHR Tabs] ──> [Ctrl+F 80p PDF] ──> [Manual Typing]        │
       │                                                             │
       │  SlothAuth Workflow: 30 Sec / Patient                       │
       │  [Sleep 🦥] ──> [Overnight Local Agent] ──> [1-Click Sign]   │
       └─────────────────────────────────────────────────────────────┘

Enter SlothAuth: Radical Laziness as Burnout Prevention

For Hacktoberfest 2026 Week 3 ("Slow and Steady / Rewarding Laziness"), I built SlothAuth: an autonomous, 100% on-premise prior-authorization prep agent designed to do all the tedious, high-friction investigative chart work overnight while the clinician sleeps.

Powered by Google's open-weight Gemma model running locally via Docker Model Runner, LangGraph.js, PostgreSQL with pgvector, and Next.js 16, SlothAuth acts like a tireless, meticulous nocturnal medical fellow:

Overnight Intake: At 2:00 AM, SlothAuth scans the day's intake queue of pending procedure and medication requests.
Hybrid Semantic Policy Retrieval: It queries PostgreSQL using pgvector HNSW cosine similarity to fetch the exact sub-sections of payer clinical guidelines governing that procedure.
Point-by-Point Evidence Audit: Local Gemma cross-references the patient's longitudinal EHR timeline against every coverage rule, pulling verbatim chart quotes and dates.
Pre-Submission Gap Detection: It catches missing mandatory baseline labs before the insurance company can issue a denial (e.g., flagging an absent tuberculosis test before initiating an immunosuppressive biologic).
Automated Exception Justification: When step-therapy requirements cannot be met due to a severe adverse reaction or pharmacogenetic deficiency, it drafts a formal, citation-backed Step-Therapy Exception clause automatically.
The 9:00 AM Coffee-Break Sign-Off: When the care coordinator arrives at the clinic, 35 minutes of frantic detective work is already finished. They review a split-screen evidence map and pre-drafted letter in 30 seconds, click "Approve & Sign," and send the packet on its way.

Demo

Here is SlothAuth in action—handling the complete clinical prior-authorization lifecycle from real-time LangGraph execution to electronic clinician sign-off:

(Interactive Video Walkthrough: 4-Node LangGraph execution, real-time SSE streaming, and instant clinician resolution)

Key Dashboard Views

1. The "Morning Care Coordinator" Queue & Real-Time SSE Stepper

The dashboard displays live operational telemetry alongside the LangGraph execution stepper. As the batch runs, clinicians watch each node light up in real time with zero UI freezing:

Figure 1: The Care Coordinator dashboard featuring the "Lazy Payoff" KPI bar, patient roster, and live LangGraph SSE execution stepper.

2. Scenario 1 (`PT-2026-001` — Marcus Vance): 100% Policy Compliant

Marcus Vance needs a lumbar spine MRI (CPT-72148) for chronic radiculopathy. SlothAuth proves compliance with Aetna Policy #0016 by citing 12 sessions of physical therapy at Apex Sports & Spine, a failed 5-week trial of Naproxen, and preliminary plain X-rays:

Figure 2: Complete criteria alignment (98% confidence) with green verbatim evidence quotes and ready-to-submit status.

3. Scenario 2 (`PT-2026-002` — Elena Rostova): Catching Missing Labs Before Denial

Elena Rostova was prescribed Adalimumab (J0135) for rheumatoid arthritis. She meets diagnostic criteria and failed a 16-week Methotrexate trial. However, UnitedHealthcare requires a negative Tuberculosis screening within the past 6 months. SlothAuth catches the omission, injects a prominent warning banner into the letter, and offers a 1-click resolution action:

Figure 3: SlothAuth proactively prevents an insurance denial by flagging a missing QuantiFERON-TB Gold test.

4. Scenario 3 (`PT-2026-003` — David Chen): Automated Step-Therapy Exception

David Chen was prescribed Infliximab (J1745) for severe Crohn's disease without completing BlueCross BlueShield's mandatory 8-week Azathioprine trial. SlothAuth digs into his chart, spots that Azathioprine was halted on Day 5 due to acute drug-induced pancreatitis (lipase 980 U/L), correlates it with a low TPMT enzyme activity level (4.2 U/mL), and writes a formal contraindication justification:

Figure 4: Automated clinical justification for bypassing step-therapy due to documented life-threatening drug toxicity.

Code

https://github.com/NegiSushant/SlothAuth

The repository is organized into a clean, modular full-stack architecture:

sloth-auth/
├── Docker-Compose.yml                 # PostgreSQL 16 + pgvector container definition
├── package.json                       # Next.js 16, LangGraph.js, Prisma, pgvector
├── .env.example                       # Local DMR & PostgreSQL configuration
├── scripts/
│   ├── seed.ts                        # Local vector seeding (mxbai-embed-large + pgvector)
│   ├── test-agent.ts                  # CLI LangGraph workflow verification runner
│   └── test-api.ts                    # REST & SSE streaming test suite
└── src/
    ├── app/
    │   ├── api/prior-auth/
    │   │   ├── packet/[requestId]/    # PATCH: Save edits, resolve labs, clinician sign-off
    │   │   ├── prep/                  # POST: Single & batch runner with SSE streaming
    │   │   ├── queue/                 # GET: Live patient roster & telemetry
    │   │   └── reset/                 # POST: Reset simulation to PENDING_PREP
    │   ├── dashboard/page.tsx         # Split-screen Care Coordinator Dashboard
    │   └── page.tsx                   # Product landing page & architecture showcase
    ├── components/
    │   ├── AgentExecutionStepper.tsx  # Animated 4-node LangGraph execution tracker
    │   ├── PacketInspector.tsx        # Split-screen criteria checklist & markdown editor
    │   └── TelemetryFooter.tsx        # Fixed telemetry bar (0 Bytes PHI, $0.00 Cost)
    └── lib/
        ├── agent/
        │   ├── models.ts              # Docker Model Runner Gemma & Embeddings bindings
        │   ├── nodes.ts               # 4 deterministic LangGraph execution nodes
        │   ├── priorAuthGraph.ts      # StateGraph assembly & batch executor
        │   └── state.ts               # PriorAuthGraphState annotation definitions
        ├── prisma.ts                  # Database client with pgvector support
        ├── schema.sql                 # Reference SQL DDL with HNSW vector index
        └── seed-data.ts               # Synthetic policies & 3 patient clinical charts

How I Built It

SlothAuth is built on four decoupled, production-grade open-source pillars designed to operate without any external cloud dependencies.

flowchart TD
    subgraph UI["Frontend Layer (Next.js 16 App Router)"]
        Dashboard["Care Coordinator Dashboard"]
        SSEStream["Server-Sent Events (SSE) Stepper"]
        Inspector["Split-Screen Evidence & Letter Editor"]
    end

    subgraph API["API Router (/api/prior-auth)"]
        PrepRoute["/prep (Streaming LangGraph Runner)"]
        PacketRoute["/packet/[requestId] (Interactive Actions)"]
        QueueRoute["/queue (Telemetry & Records)"]
    end

    subgraph Orchestrator["Agent Layer (LangGraph.js)"]
        N1["Node 1: extractPatientContext"]
        N2["Node 2: retrievePolicyChunks"]
        N3["Node 3: auditClinicalCriteria"]
        N4["Node 4: draftJustificationAndSave"]
    end

    subgraph LocalInference["Local AI Runtime (Docker Model Runner :12434)"]
        GemmaModel["Gemma Open-Weight LLM\n(ai/gemma3)"]
        EmbeddingEngine["Local Vector Embeddings\n(ai/mxbai-embed-large)"]
    end

    subgraph DataStore["Vector Database (PostgreSQL 16 + pgvector)"]
        PoliciesTable[("payer_policies\nHNSW vector(1024)")]
        RequestsTable[("patient_requests\nJSONB clinical_notes")]
        PacketsTable[("prepped_packets\nChecklists & Letters")]
    end

    Dashboard --> PrepRoute
    Dashboard --> QueueRoute
    Inspector --> PacketRoute

    PrepRoute --> Orchestrator
    PrepRoute -. "SSE Real-Time Updates" .-> SSEStream

    N1 --> RequestsTable
    N2 --> EmbeddingEngine
    N2 --> PoliciesTable
    N3 --> GemmaModel
    N4 --> GemmaModel
    N4 --> PacketsTable
    N4 --> RequestsTable

1. Local AI Runtime: Docker Model Runner & Google Gemma

Medical applications cannot rely on public cloud APIs that risk Protected Health Information (PHI) egress. To keep all data strictly on-premise, SlothAuth leverages Docker Model Runner (DMR), Docker's native local model inference engine running on TCP port 12434.

We configure LangChain's @langchain/openai client to point directly to Docker Model Runner's local endpoint:

// src/lib/agent/models.ts
import "dotenv/config";
import { ChatOpenAI } from "@langchain/openai";

const baseURL = process.env.DOCKER_MODEL_BASE_URL || "http://localhost:12434/engines/llama.cpp/v1";
const llmModel = process.env.LLM_MODEL_NAME || "ai/gemma3:4B-F16";

/**
 * Local Gemma chat model running via Docker Model Runner.
 * Configured with a low temperature (0.1) for deterministic clinical criteria extraction.
 */
export const gemmaChatModel = new ChatOpenAI({
  model: llmModel,
  apiKey: "docker-model-runner-local", // Zero external API keys needed
  configuration: {
    baseURL,
  },
  temperature: 0.1,
});

For embeddings, SlothAuth connects to the local ai/mxbai-embed-large model to generate 1024-dimensional vectors on the fly with zero external network calls:

// src/lib/agent/models.ts
export async function generateQueryEmbedding(text: string): Promise<number[]> {
  const response = await fetch("http://localhost:12434/engines/llama.cpp/v1/embeddings", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      model: "ai/mxbai-embed-large",
      input: text,
    }),
  });
  const data = await response.json();
  return data.data[0].embedding;
}

2. Hybrid Policy RAG with PostgreSQL & `pgvector`

In healthcare, pure semantic vector search is dangerous. If a patient with BlueCross BlueShield is requesting Crohn's biologic therapy, returning a high-similarity chunk from an Aetna Lumbar MRI policy would corrupt the entire prior-auth packet.

To guarantee mathematical precision, SlothAuth implements Hybrid Filtered Vector Search in PostgreSQL using the pgvector extension:

Exact B-tree Metadata Filter: We filter by the exact insurer (payer_name) and clinical procedure code (procedure_code).
HNSW Cosine Vector Ranking: Within that exact policy partition, we use an HNSW index (vector_cosine_ops) to rank chunks by cosine distance against the clinical query embedding.

-- PostgreSQL pgvector Schema (src/lib/schema.sql)
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE payer_policies (
    id SERIAL PRIMARY KEY,
    payer_name VARCHAR(100) NOT NULL,
    procedure_code VARCHAR(50) NOT NULL,
    policy_number VARCHAR(50) NOT NULL,
    policy_title TEXT NOT NULL,
    section_name VARCHAR(150) NOT NULL,
    chunk_text TEXT NOT NULL,
    embedding vector(1024) NOT NULL
);

-- Fast HNSW cosine index
CREATE INDEX idx_payer_policies_embedding 
    ON payer_policies USING hnsw (embedding vector_cosine_ops);

-- Composite B-tree index for instantaneous hybrid filtering
CREATE INDEX idx_payer_policies_hybrid 
    ON payer_policies (payer_name, procedure_code);

When Node 2 (retrievePolicyChunks) executes, it issues this parameterized query:

// src/lib/agent/nodes.ts
const rows = await prisma.$queryRawUnsafe<Array<{
  id: number;
  policy_number: string;
  policy_title: string;
  section_name: string;
  chunk_text: string;
  similarity: number;
}>>(
  `SELECT id, policy_number, policy_title, section_name, chunk_text,
          (1 - (embedding <=> $3::vector)) AS similarity
   FROM payer_policies
   WHERE payer_name = $1 AND procedure_code = $2
   ORDER BY embedding <=> $3::vector ASC
   LIMIT 5;`,
  payerName,
  procedureCode,
  vectorString
);

3. Deterministic 4-Node LangGraph.js Orchestration

Monolithic LLM prompts fail when tasked with multi-step clinical audits. A single prompt trying to read 5 pages of chart notes, memorize an insurance policy, evaluate criteria, and draft a legal letter often hallucinates dates, forgets negative lab tests, or invents compliance.

SlothAuth solves this with LangGraph.js (@langchain/langgraph), enforcing a deterministic state transition pipeline:

// src/lib/agent/priorAuthGraph.ts
import { StateGraph, START, END } from "@langchain/langgraph";
import { PriorAuthGraphState } from "./state";
import {
  extractPatientContext,
  retrievePolicyChunks,
  auditClinicalCriteria,
  draftJustificationAndSave,
} from "./nodes";

const workflow = new StateGraph(PriorAuthGraphState)
  .addNode("extractPatientContext", extractPatientContext)
  .addNode("retrievePolicyChunks", retrievePolicyChunks)
  .addNode("auditClinicalCriteria", auditClinicalCriteria)
  .addNode("draftJustificationAndSave", draftJustificationAndSave)
  .addEdge(START, "extractPatientContext")
  .addEdge("extractPatientContext", "retrievePolicyChunks")
  .addEdge("retrievePolicyChunks", "auditClinicalCriteria")
  .addEdge("auditClinicalCriteria", "draftJustificationAndSave")
  .addEdge("draftJustificationAndSave", END);

export const priorAuthWorkflow = workflow.compile();

How the 4 Nodes Work:

Node 1 (extractPatientContext): Queries patient_requests in PostgreSQL. It extracts medications, conservative physical therapy dates, imaging studies, and lab panels from JSONB EHR notes, assembling a unified chronological timeline markdown string.
Node 2 (retrievePolicyChunks): Computes the clinical intent vector and performs the hybrid pgvector retrieval against payer_policies, injecting the top 5 relevant insurance clauses into graph state.
Node 3 (auditClinicalCriteria): Uses Gemma to audit each policy rule against the patient timeline. To guarantee system reliability, the node strips any <think> reasoning artifacts and parses structured JSON via Zod, tagging each criterion with a strict clinical status:
- MET: Backed by verbatim chart quotes and documented dates.
- MISSING: Identifies required screenings not found in the chart.
- EXCEPTION_JUSTIFIED: Correlates contraindications or life-threatening adverse reactions to bypass standard step-therapy.
Node 4 (draftJustificationAndSave): Synthesizes a formal Medical Necessity Letter. If gaps exist, it prepends a prominent ⚠️ CLINICIAN ACTION REQUIRED alert. If step therapy was bypassed, it inserts a formal contraindication clause citing clinical lab values and timestamps. Finally, it upserts the packet into prepped_packets and marks the patient status as PREPPED.

4. Real-Time Server-Sent Events (SSE) Streaming

Rather than making the clinician stare at a static spinner while multiple local models execute, POST /api/prior-auth/prep streams live LangGraph lifecycle events over a lightweight SSE connection:

// src/app/api/prior-auth/prep/route.ts
const eventStream = await priorAuthWorkflow.stream(
  { requestId: patient.id },
  { streamMode: "updates" }
);

for await (const update of eventStream) {
  const nodeName = Object.keys(update)[0];
  const nodeData = update[nodeName];

  sendEvent({
    type: "node_complete",
    requestId: patient.id,
    nodeName,
    step: NODE_METADATA[nodeName].step,
    stepLabel: NODE_METADATA[nodeName].label,
    logs: nodeData?.executionLogs || [],
    readinessVerdict: nodeData?.readinessVerdict,
  });
}

The React frontend listens via a native EventSource / fetch reader, lighting up each stage in AgentExecutionStepper.tsx as Gemma evaluates chart criteria.

Why Does Open Innovation Matter?

Healthcare technology is currently facing a critical fork in the road: centralized black-box cloud APIs versus transparent, on-premise open-weight AI.

When developing software for healthcare providers, this is not an academic debate—it is a legal, operational, and financial necessity. Here is why the open-source architecture behind SlothAuth is the only viable path forward for clinical automation:

┌──────────────────────────────────────────────────────────────────────────────────┐
│                   CLOSED CLOUD APIS vs. OPEN-SOURCE SLOTH STACK                 │
├──────────────────────────┬────────────────────────────┬──────────────────────────┤
│ Architectural Dimension  │ Closed Cloud APIs          │ SlothAuth (Gemma Stack)  │
├──────────────────────────┼────────────────────────────┼──────────────────────────┤
│ PHI / HIPAA Data Egress  │ ⚠️ High Risk (Public Cloud)│ 🛡️ ZERO BYTES Egress     │
│ Overnight Batch Cost     │ 💸 Compounding Token Fees  │ 🆓 $0.00 In API Fees     │
│ Offline / Air-Gapped     │ ❌ Impossible              │ ⚡ 100% Intranet-Native  │
│ Model Weight Pinning     │ ❓ Silent Upstream Drift   │ 🔍 Fully Deterministic   │
│ Vector Search Control    │ 🔒 Proprietary Indices     │ 📐 PostgreSQL pgvector   │
└──────────────────────────┴────────────────────────────┴──────────────────────────┘

1. Strict PHI Privacy & Zero Data Egress (The HIPAA Reality)

Under HIPAA, transmitting Protected Health Information (PHI)—including patient names, diagnostic ICD-10 codes, narrative clinical progress notes, and genomic lab values—to external third-party multi-tenant APIs requires complex Business Associate Agreements (BAAs), enterprise subscriptions, and continuous security auditing.

With open-weight Gemma and Docker Model Runner, SlothAuth processes patient data entirely inside the hospital's local network or workstation. Zero bytes of PHI ever leave the local machine.

2. $0.00 Marginal Cost for Continuous Overnight Batching

Prior authorization preparation is a high-volume background batch workload. Running multi-page clinical records and 80-page insurance policy chunks through commercial cloud LLMs every single night costs serious money.

By building on open-weight models, SlothAuth turns marginal inference cost into $0.00. A clinic can process 10, 100, or 1,000 prior authorizations every night on commodity local hardware without watching an API billing meter run up.

3. Model Weight Pinning & Clinical Reproducibility

When a closed commercial model provider updates its API endpoints, prompt responses drift. In healthcare, an unannounced model update that alters criteria evaluation could cause an insurance denial for a life-saving drug.

With open-weight models, hospital IT teams pin the exact model artifact (e.g., ai/gemma3:4B-F16), lock the temperature to 0.1, and maintain a 100% reproducible audit trail for medical compliance.

My Agent Session

Building SlothAuth required coordinating local containerized databases, vector embeddings, LangGraph state machine logic, and responsive UI components. I used an AI coding assistant in an iterative, five-phase architecture session:

Phase 1: Local Infrastructure & Model Serving: Establishing Docker Model Runner bindings on port 12434 and configuring the pgvector/pgvector:pg16 database in Docker-Compose.yml.
Phase 2: Synthetic Healthcare Data Engineering: Writing src/lib/seed-data.ts to construct realistic clinical cases with nuanced edge conditions (plain radiograph requirements, missing interferon-gamma release assays, and pharmacogenetic contraindications).
Phase 3: LangGraph State Machine Architecture: Structuring the 4-node directed graph in src/lib/agent/ to ensure clean separation of concerns between patient timeline parsing, vector retrieval, criteria evaluation, and justification drafting.
Phase 4: Real-Time SSE Streaming: Building the streaming response handler in src/app/api/prior-auth/prep/route.ts to stream LangGraph lifecycle updates without blocking the Next.js runtime.
Phase 5: Morning Care Coordinator UI: Developing the split-screen reviewer in src/components/PacketInspector.tsx, giving clinicians a point-by-point evidence map on the left and an editable justification letter on the right.

Agent Transcript: You can inspect the complete step-by-step engineering trajectory and architecture logs in the SlothAuth Agent Session Transcript.

The Lazy Payoff

Let's look at the numbers. How much time and cognitive energy does SlothAuth actually save?

┌──────────────────────────────────────────────────────────────────────────────────┐
│                           THE "LAZY PAYOFF" AUDIT                                │
├───────────────────────────────────┬──────────────────────┬───────────────────────┤
│ Clinical Case                     │ Manual Workflow      │ SlothAuth Workflow    │
├───────────────────────────────────┼──────────────────────┼───────────────────────┤
│ Marcus Vance (Lumbar Spine MRI)   │ 35 minutes           │ 15 seconds (1-click)  │
│ Elena Rostova (Adalimumab RA)     │ 40 minutes + denial  │ 30 seconds (1-click)  │
│ David Chen (Infliximab Crohn's)   │ 45 minutes of appeal │ 45 seconds (1-click)  │
├───────────────────────────────────┼──────────────────────┼───────────────────────┤
│ TOTAL TIME INVESTED               │ 2 Hours, 0 Minutes   │ 1 Minute, 30 Seconds  │
└───────────────────────────────────┴──────────────────────┴───────────────────────┘

Here is how SlothAuth transformed the three clinical test cases we ran through the system:

Case 1: Marcus Vance (`PT-2026-001`) — Lumbar Spine MRI (`CPT-72148`)

The Manual Nightmare: Hunting through 2 months of progress notes to find the exact dates of his 12 physical therapy sessions, verifying that he completed 5 weeks of Naproxen, and checking that a lumbar X-ray was performed first.
The SlothAuth Payoff: SlothAuth ingested the chart overnight, matched Aetna Policy #0016, pulled verbatim evidence quotes from Apex Sports & Spine, and assigned a 100% READY_TO_SUBMIT verdict with 98% confidence. The clinician verified the green checkmarks and clicked "Approve & Sign" in 15 seconds.

Case 2: Elena Rostova (`PT-2026-002`) — Adalimumab Biologic (`J0135`)

The Manual Nightmare: The care coordinator misses that UnitedHealthcare requires a baseline Tuberculosis screening (QuantiFERON-TB Gold) within 6 months. They submit the packet, wait 14 days, receive an insurance denial, and must file an appeal.
The SlothAuth Payoff: SlothAuth caught the omission at 2:00 AM. It generated an alert banner: ⚠️ CLINICIAN ACTION REQUIRED: Missing QuantiFERON-TB Gold Screening. When the clinician logged in at 9:00 AM, they clicked "Resolve & Attach Lab," which updated the criteria checklist in PostgreSQL and generated the signed letter instantly. Potential 2-week treatment delay avoided.

Case 3: David Chen (`PT-2026-003`) — Infliximab Infusion (`J1745`)

The Manual Nightmare: BlueCross BlueShield requires patients to fail an 8-week trial of generic Azathioprine before approving Infliximab. David took Azathioprine for only 5 days. A human reviewer would have to spend 45 minutes manually drafting a complex Step-Therapy Exception letter.
The SlothAuth Payoff: SlothAuth identified that Azathioprine was discontinued because David developed acute drug-induced pancreatitis (lipase 980 U/L) and correlated it with a severe TPMT enzyme deficiency (4.2 U/mL). SlothAuth drafted the formal exception clause automatically, citing the exact medical hazards. Clinician saved 45 minutes of manual legal-clinical drafting.

Prize Categories

🌟 Best Use of Gemma

SlothAuth relies on Google's open-weight Gemma model as its core clinical reasoning engine. Running locally via Docker Model Runner at temperature: 0.1, Gemma performs the critical intellectual work of the entire platform:

Parsing complex, unstructured electronic health record timelines.
Evaluating nuanced insurer medical necessity criteria point-by-point.
Detecting clinical safety contraindications and pharmacogenetic enzyme risks.
Drafting professional, citation-backed Medical Necessity Letters.

By using Gemma locally, SlothAuth achieves full clinical reasoning capability with 0 bytes of Protected Health Information (PHI) egress and $0.00 in marginal API costs.

🐯 Best Use of Tiger Data

SlothAuth leverages PostgreSQL with the pgvector extension as its unified vector and relational data layer:

HNSW Vector Indexing: Employs an HNSW index (embedding vector_cosine_ops) over 1024-dimensional embeddings generated by ai/mxbai-embed-large for sub-millisecond semantic retrieval.
Hybrid Filtered Search: Executes combined B-tree metadata filtering (payer_name and procedure_code) with cosine distance vector ranking, ensuring 100% policy-matching accuracy.
Transactional State Management: Manages patient charts (patient_requests), policy chunks (payer_policies), and generated justification packets (prepped_packets) inside an ACID-compliant PostgreSQL database managed through Prisma 7.

Conclusion: Embrace Your Inner Sloth

In nature, the sloth's slow pace is an evolutionary superpower: by moving deliberately and eliminating wasted energy, the sloth thrives where others burn out.

In healthcare, we have spent decades forcing our most skilled doctors and nurses to sprint on an administrative hamster wheel—wasting thousands of hours on manual prior authorization paperwork.

SlothAuth proves that when open-weight models like Gemma run locally on modern open-source stacks, we don't have to sprint anymore. We can let the agent do the tedious overnight work, so clinicians can walk in, have their coffee, click "Approve," and get back to what matters most: caring for patients.

🦥 Slow and steady wins the race.

ResumeForge: A Privacy-First AI Resume Analyzer Built with Local Open-Weight Models

Sushant Singh Negi — Sat, 17 Oct 2026 18:29:30 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Every time someone applies for a job today, they are handed the same advice: "Tailor your resume to the job description." But behind that simple advice is a frustrating dilemma.

Existing commercial resume optimization tools charge $20 to $40 a month. Worse, they demand that you upload your entire professional life—phone numbers, employment history, company names, side projects, references, and education—onto their remote servers. Once uploaded, your career data is fed through third-party proprietary APIs, stored in external databases, and often retained for downstream model training.

For developers, privacy-conscious professionals, freelancers, and students on tight budgets, this is an unacceptable trade-off.

I built ResumeForge to solve this.

ResumeForge is an AI-powered resume analysis and tailoring platform that runs 100% locally on your machine using open-weight models. No cloud AI inference. No subscriptions. Zero data leaving your computer.

What it does:

Upload & Parse: You upload your existing resume (.pdf or .docx) and paste any target Job Description (JD).
Local AI Engine: ResumeForge extracts the content, parses the role requirements, and feeds them directly to an on-device open-weight model through Docker Model Runner.
Rigorous Calibrated Analysis:
- Fit Score (0–100): A realistic, calibrated score with an honest 1–2 sentence justification (no false inflation or polite cheerleading).
- Matching vs. Missing Skills: Side-by-side gap analysis pinpointing hard skills, frameworks, and domain knowledge from the JD that are absent in your resume.
- Strengths & Candid Gaps: Concrete, experience-backed highlights contrasted with critical areas of concern.
- Targeted Section-by-Section Edits: Granular, actionable suggestions mapped directly to your resume sections (Experience, Summary, Projects, Skills).
- High-Priority ATS Keywords: Exact phrases and acronyms from the JD to help navigate Applicant Tracking Systems.
Side-by-Side PDF Inspection & History: View your original resume PDF rendered inline directly alongside your AI audit, with full authentication and persistent session history.

Who would pay for it?

Privacy-Sensitive Tech Workers & Executives: Engineers, defense/health contractors, and leaders whose work history includes confidential projects, proprietary IP, or non-disclosure constraints.
Bootcamp Grads & Career Changers: Job seekers needing rapid, iteration-heavy feedback across 50+ job applications without paying per-token or per-month cloud API fees.
Freelance Recruiters & Career Coaches: Consultants who want a private, white-label, zero-marginal-cost audit workstation to review client materials locally without data compliance liabilities.

As a side-hustle product, ResumeForge can be delivered as a packaged local-first desktop app, a self-hosted workspace for recruiting agencies, or a freemium desktop utility with premium local workflow templates.

Demo

Check out the project demo:

Live Demo Vedio: Live Demo
Demo Preview:

Landing & Auth	Analysis Engine	Full Audit Results

Code

The entire codebase is open-source and ready to clone:

NegiSushant / ResumeForge

🔒 ResumeForge

AI-Powered Resume Analysis — Completely On Your Machine

A privacy-first, open-weight AI tool that matches your resume to any job description — no cloud, no data sharing, no subscription.

📸 Screenshots

Demo Screenshots

Landing Page	Analyze Page	Results View

History Page	Resume PDF Viewer

✨ Features

🧠 Intelligent Analysis

Fit Score (0–100) with strict scoring rubric and honest rationale — the AI is calibrated to never blindly inflate scores
Score Explanation — a 1–2 sentence justification of exactly why that score was given
Matching Skills — skills that appear in both your resume and the job description
Missing Skills — critical requirements from the JD that are absent from your resume
Key Strengths — concrete, experience-backed strengths relevant to the role
Areas of Concern — candid gaps and red flags — no sugarcoating
Targeted Section Improvements — actionable edits referencing real resume sections (Experience, Skills, Summary, Projects, Certifications)
…

View on GitHub

GitHub Repository: https://github.com/NegiSushant/ResumeForge

How I Built It

ResumeForge is architected around the premise that commodity consumer hardware is now capable of running production-grade AI analysis if prompt design, parsing pipelines, and local inference orchestration are done right.

┌────────────────────────────────────────────────────────┐
│                      Next.js 16                        │
│             App Router + Tailwind CSS                  │
└───────────────▲────────────────────────▲───────────────┘
                │                        │
       Upload & Parse Stream      Session & History
                │                        │
┌───────────────▼──────────────┐ ┌───────▼───────────────┐
│ pdfjs-dist / mammoth         │ │ MongoDB Atlas / Local │
│ (Client / Server Extractors) │ │ (Mongoose + NextAuth) │
└───────────────┬──────────────┘ └───────────────────────┘
                │
         Extracted Text
                │
┌───────────────▼────────────────────────────────────────┐
│ OpenAI SDK (BaseURL: http://localhost:11434/v1)        │
└───────────────┬────────────────────────────────────────┘
                │
┌───────────────▼────────────────────────────────────────┐
│ Docker Model Runner (DMR)                              │
│ └── ai/gemma3:1b-q4_K_M (Open-Weight Gemma 3 1B)       │
└────────────────────────────────────────────────────────┘

1. The Open-Source AI Core: Gemma 3 (1B) & Docker Model Runner

Instead of piping text to remote proprietary endpoints, ResumeForge delegates inference to Google's open-weight Gemma 3 (1B) (ai/gemma3:1b-q4_K_M), quantized at 4-bit precision.

Inference is managed via Docker Model Runner (DMR). This allowed me to:

Expose an OpenAI-compatible local HTTP endpoint (http://localhost:11434/v1 or native DMR port) with zero external setup friction.
Decouple model life-cycle and GPU/CPU acceleration from the Node.js runtime.
Use the standard openai Node SDK inside Next.js route handlers simply by pointing baseURL to the local Docker daemon.

2. Engineering Around a 1B Parameter Model: Honest Lessons

Working with a lightweight 1-billion parameter model taught me a huge amount about constraint-driven AI engineering.

A 1B model is lightning fast and runs with a negligible memory footprint (~1.2 GB RAM), but it can easily wander or drop structured fields if given ambiguous instructions. To get deterministic, publication-grade resume evaluations out of Gemma 3 1B:

Strict JSON-Only Guardrails: I engineered an exacting system prompt that forces raw JSON output wrapped in a single code block, complete with an explicit scoring rubric (e.g., 70–84: Strong candidate, minor gaps; 50–69: Moderate fit, notable missing skills).
Anti-Sycophancy Calibration: Small models tend to be agreeable and hand out 95% scores. I explicitly calibrated the rubric to penalize missing prerequisites and prioritize brutal honesty.
Robust Schema Parsing & Fallbacks: Responses pass through a regex-assisted JSON cleaner and Zod schema validation to handle edge-case markdown formatting quirks before hitting the frontend.

3. Full-Stack Data & Authentication Pipeline

Next.js 16 (App Router) & TypeScript: High-performance server actions and API route handlers for document ingestion.
Document Extractors: pdfjs-dist for raw text and structure parsing from PDFs, and mammoth for parsing .docx resumes cleanly.
MongoDB & NextAuth.js v5: Handles secure credential authentication (bcrypt-hashed) and persists resume metadata, extracted content, fit scores, and historical audits so users can track improvements across multiple versions of their CV.

Why Does Open Innovation Matter?

Open innovation is not just an alternative deployment model; for an application like ResumeForge, it is the only model that aligns with user ethics and long-term viability.

1. Privacy Is Not a Feature—It Is the Product

Career data is intimate. Resumes reveal your identity, residential address, compensation progression, side ventures, and clearances.

When you use proprietary SaaS resume checkers powered by closed APIs, you are forced to trust a chain of third parties not to log, leak, or train on your identity. Open innovation means the model weights live on your disk, the inference executes inside your memory, and the network cable could literally be unplugged while your resume is analyzed.

2. Eliminating the "API Tax" on Side Hustles

Building an AI side hustle on closed APIs creates an existential vulnerability: variable marginal cost. Every time a user uploads a 4-page resume and a long JD, you pay token costs. If a user tests 20 resumes, your margins evaporate.

With open-weight models like Gemma 3 running locally or self-hosted:

Marginal inference cost is $0.00.
There are no surprise cloud bills at the end of the month.
Builders can price their product as a one-time purchase or lifetime license instead of forcing users into recurring subscriptions.

3. Democratizing Career Advancement

A student in an emerging market or an unemployed worker should not have to pay $30/month just to understand why their resume is failing ATS filters. Open-weight models level the playing field, making world-class career analysis accessible to anyone with a modest laptop.

My Agent Session

During development, agentic pair programming helped scaffold the Next.js 16 App Router endpoints, optimize the Docker Model Runner configurations, and iterate through prompt calibrations for Gemma 3's output parsing.

Prize Categories

I am entering ResumeForge into the following categories:

Best Use of Gemma: Built directly around Google's open-weight Gemma 3 (1B) model (ai/gemma3:1b-q4_K_M), pushing the limits of what a compact 1B model can achieve through calibrated system prompts and structured JSON enforcement.
Best Use of MongoDB Atlas: Utilizing MongoDB (Mongoose ODM) to power secure user authentication, resume metadata storage, and persistent historical resume-to-job matching audits.
Best Use of Docker / Local Inference: Containerized local AI orchestration through Docker Model Runner, creating a seamless, zero-cloud bridge between open-weight models and web runtimes.
Overall / Side Hustle Track: A complete, privacy-respecting product concept addressing a massive consumer pain point with zero marginal inference costs.

CodeWeaver: Giving AI Agents Real Context with a Codebase Knowledge Graph

Sushant Singh Negi — Sat, 17 Oct 2026 17:41:59 +0000

Beyond Vector Search: Building a Graph-Native Codebase Intelligence Agent with FalkorDB

Why vector embeddings fail at understanding software architecture, and how we built an explainable ReAct agent that navigates code as a living graph.

1. Introduction

Every software engineer knows the sinking feeling of opening a new, massive repository for the first time.

You look at dozens of directories, hundreds of source files, implicit architectural layers, and complex dependency webs. You open your favorite AI coding assistant and ask:

"If I refactor our authentication service, what downstream agent nodes and API routes will break?"

The assistant pauses, scans your repository with vector similarity search, and responds with a confident, beautifully formatted hallucination. It lists files that don't depend on your service, misses the actual orchestrator three directories over, and leaves you to dig through the call stack manually.

During the FalkorDB Graph Hacks 2026, we set out to fix this fundamental breakdown. We built CodeWeaver — a graph-powered codebase intelligence agent that treats code not as disconnected text chunks, but as what it actually is: a directed, typed, multi-dimensional graph.

Here is the story of why we abandoned vanilla vector RAG for codebase intelligence, how we modeled a real-world enterprise codebase in FalkorDB, and what we learned building an autonomous agent with a 100% explainable reasoning path.

Demo

Check out the project demo:

** Demo Vedio:** Live Demo
Demo Preview: Repo link

2. The Real Problem: Why Vector Search Fails at Code

The modern AI stack is obsessed with semantic embeddings. For general knowledge retrieval, vector search works wonders. But software code is not natural language prose — code is strict, deterministic topology.

When you chunk a codebase into 500-token text slices and embed them into a vector space, you destroy the exact information that makes software function:

Topological Blindness: Embedding vectors capture semantic similarity, not causal connectivity. A function named handleAuthError might be semantically identical to logAuthFailure, but if only one of them is invoked by the mission-critical state machine, vector search treats them as interchangeable.
The Multi-Hop Horizon: Real codebase questions are multi-hop by definition: $$\text{Repository} \longrightarrow \text{Domain Service} \longrightarrow \text{State Machine Node} \longrightarrow \text{API Route}$$ Vector retrieval cannot jump across four deterministic references. It retrieves chunks that "sound" like the query, completely missing the transitive chain.
Zero Verifiability: When a traditional LLM answers an architectural question, you have no way to verify how it reached its conclusion. You are left trusting a black box with your production deployment.

3. The Insight: Code is a Graph, Not a Bag of Tokens

Compilers have understood this for half a century: code represents an Abstract Syntax Tree (AST), a call graph, and an import dependency graph.

When an experienced engineer investigates a codebase, they don't do vector similarity in their heads. They trace references:

"Who calls this function?"
"Which architectural layer does this file belong to?"
"What high-level business feature does this module implement?"
"Who owns this domain?"

These questions are textbook graph traversals. By representing the codebase as a native property graph, we can leverage Cypher queries to answer structural, multi-hop questions with mathematical certainty. The LLM shouldn't guess connections; it should navigate verified graph relations.

4. What We Built: CodeWeaver

CodeWeaver is an autonomous codebase intelligence platform built on top of FalkorDB, Next.js 16, LangChain, and PostgreSQL.

Instead of guessing from isolated snippets, CodeWeaver equips an autonomous ReAct agent with specialized tools that execute Cypher queries against FalkorDB in real time.

Core Capabilities:

Architectural Discovery: Understands clean architecture layers, modules, and file distributions.
Blast Radius & Impact Analysis: Calculates multi-hop downstream dependencies when files or functions change.
Feature-to-Code Mapping: Bridges the gap between high-level business features (e.g., ReAct Agent Loop, Human-in-the-Loop Validation, Policy RAG) and the exact classes and files that implement them.
Explainable Reasoning Paths: Every answer returned by the agent includes the exact internal FalkorDB node IDs traversed. Users can click a single button to inspect the visual subgraph that grounded the response.
Interactive Knowledge Graph Canvas: A dedicated, interactive force-directed graph page (/graph) with category filtering, node inspection, and real-time search.

5. How We Modeled the Codebase as a Graph

To test CodeWeaver against a realistic, non-trivial system, we ingested the complete repository of an Autonomous Healthcare Prior Authorization Agent — a system featuring Next.js 16, LangGraph state machines, domain services, and Prisma persistence.

We designed a property graph schema that captures both low-level code syntax and high-level architectural intent:

(Person)-[:OWNED_BY]-(File|Module)
(File)-[:BELONGS_TO]->(Module)
(File)-[:IMPLEMENTS]->(Feature)
(Function|Class)-[:BELONGS_TO]->(File)
(Function)-[:CALLS]->(Function)
(Class|File)-[:USES]->(Class|File)

The Node Types:

Module: Architectural layers (Agent Core, Agent Tools, Services, Repository, UI Components).
Feature: Functional product capabilities (ReAct Loop, Prior Authorization Flow, Clinical Guideline RAG).
File: Source files across the repository.
Function & Class: Discrete AST-extracted symbols, methods, and declarations.
Person: Domain owners and maintainers responsible for specific modules.

The Relationship Topology:

BELONGS_TO: Structural encapsulation (functions in files; files in modules).
IMPLEMENTS: Semantic grounding linking low-level code directly to high-level product features.
CALLS & USES: AST invocation chains and import dependencies.
OWNED_BY: Accountability and team ownership mapping.

Our ingestion engine parsed the codebase into 228 nodes and 306 relationships, creating a complete structural digital twin inside FalkorDB.

6. How the Agent Reasons: Cypher-Powered Tools & Explainability

We built CodeWeaver using LangChain and LangGraph to implement a structured ReAct (Reason-Act-Reflect) loop.

Rather than giving the LLM raw Cypher execution privileges (which often produces invalid syntax and security risks), we provided the agent with four deterministic graph tools:

getArchitectureOverview: Traverses high-level Module nodes and their file counts.
getFeatureImplementation: Finds all files and classes linked to a feature via IMPLEMENTS.
analyzeDependencies: Executes 1-to-3 hop traversals (<-[:CALLS|USES*1..3]-) to compute the blast radius of a component.
getOwnershipInfo: Resolves code ownership through OWNED_BY relationships.

User Prompt
    │
    ▼
LangChain ReAct Agent (Azure OpenAI GPT-4o)
    │
    ├─► Step 1: Select Graph Tool (e.g., analyzeDependencies)
    │
    ├─► Step 2: Query FalkorDB via Redis Protocol
    │           MATCH (n)<-[:CALLS|USES*1..2]-(dep)
    │           RETURN ID(n), ID(dep), n.name, dep.name
    │
    ├─► Step 3: FalkorDB responds in 1.4ms
    │
    ▼
Synthesize Answer + Collect Reasoning Node IDs: [42, 88, 104, 115]
    │
    ▼
Client: Render Answer + Interactive Reasoning Path Subgraph

The Power of the Reasoning Path

Whenever the agent queries FalkorDB, our Cypher queries explicitly project the internal graph node IDs: RETURN ID(n) AS nodeId.

The agent collects these IDs throughout its reasoning trajectory and returns them alongside the markdown answer. In the UI, the user sees an interactive Reasoning Path badge. Clicking it opens a focused modal containing only the nodes and relationships the agent touched.

There is zero black-box mystery: developers can verify every claim against the actual graph topology.

7. Architecture Decisions

1. In-Memory Graph Processing with FalkorDB

Agentic workflows require multiple tool calls per turn. If graph queries take 500ms, an agent that needs 3 hops feels sluggish and unresponsive. FalkorDB runs in-memory with C-level graph algorithms over Redis protocol, consistently returning multi-hop queries in under 2 milliseconds. This sub-millisecond latency makes iterative graph reasoning feel instantaneous.

2. Separation of Playground (`/chat`) and Explorer (`/graph`)

A common mistake in AI developer tools is cramming an enormous canvas into the chat interface. We maintained a strict separation:

The Playground focuses on focused conversational Q&A with lightweight, contextual subgraph previews.
The Knowledge Graph Page provides an expansive, full-viewport canvas with category filtering, real-time node search, and full property inspection.

3. Persistent Grok-Style Chat Sessions

Codebase investigations are iterative. We paired PostgreSQL and Prisma with our FalkorDB backend to persist chat sessions, conversation histories, and associated reasoning node IDs across browser sessions.

8. Challenges We Faced & How We Solved Them

Challenge 1: The "Visual Hairball" Effect

Our first attempt at visualizing 200+ nodes and 300+ relationships on an HTML canvas resulted in an unreadable green blob. Text labels overlapped, and users couldn't isolate relevant components.

Solution: We introduced adaptive scale-based label rendering and category filtering. In GraphViewer.tsx, high-level entities (Module, Feature) display bold labels at all zoom levels, while granular labels (Function, Class) only render when the user zooms in past 1.05x scale. We also added canvas outline stroke rendering (ctx.strokeText) to ensure contrast across both light and dark themes.

Challenge 2: Hallucination-Free Reasoning Nodes

Initially, we experimented with asking the LLM to output which nodes it referenced. The result? The LLM occasionally invented node IDs that didn't exist in FalkorDB.

Solution: We eliminated LLM discretion entirely. The graph tools themselves extract and accumulate the exact FalkorDB ID(node) integers directly from the Cypher query result records. The frontend receives mathematically grounded node IDs straight from the database engine.

9. What We Learned

Graph databases turn RAG from probabilistic guessing into deterministic retrieval. When an LLM cites a structural path derived from a graph database, its hallucinations on architectural boundaries drop to near zero.
Explainability is the missing pillar in developer tooling. Developers don't distrust AI because it's imperfect; they distrust AI because it doesn't show its work. Providing an interactive subgraph showing the exact nodes used in reasoning builds immediate trust.
Graph schema design requires intentional abstraction. Including every single variable or line of code creates unusable noise. Focusing on high-impact abstractions (Module, Feature, File, Function, Class) provides the sweet spot for agentic reasoning.

10. Why FalkorDB Was Critical

CodeWeaver simply could not exist without a purpose-built graph database:

Expressive OpenCypher: Modeling queries like MATCH (f:File)-[:IMPLEMENTS]->(feat:Feature {name: "ReAct Agent Loop"}) requires clean, standardized graph query language semantics.
Unbeatable Speed: FalkorDB’s in-memory execution meant our agent’s multi-step ReAct loop ran without latency penalties.
Effortless Docker Deployment: Deploying FalkorDB alongside Postgres in a single docker compose up -d made local setup seamless.

FalkorDB isn't a secondary cache in CodeWeaver — it is the intelligence engine that powers every single answer our agent produces.

11. Conclusion

Software systems will only grow larger, more complex, and more distributed. As AI agents take on larger roles in software engineering, feeding them flattened text chunks through vector search is a dead end.

By anchoring AI reasoning in a native graph database like FalkorDB, we can build agents that truly understand software architecture — agents that trace dependencies across multiple hops, respect module boundaries, and show their work with complete transparency.

CodeWeaver proves that when code is modeled as connected knowledge, AI stops guessing and starts understanding.

Check out the CodeWeaver GitHub Repository to explore the code, run the ingestion pipeline, and try the graph-powered agent yourself.

I Built OutSideQuest: An AI That Wants You to Stop Using It 🌿

Sushant Singh Negi — Sat, 10 Oct 2026 06:51:42 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

SideQuest — Outside Quest

Less scrolling. More living.

An open-weight AI micro-adventure generator that gives you a reason to put your phone down and go outside.

What I Built

Most modern consumer AI is engineered to maximize screen time, message volume, and session retention. We chat with assistants, scroll generated text, and stay tethered to our desks.

I built SideQuest (OutsideQuest) with the opposite philosophy: the AI interaction should be the shortest part of the user experience.

SideQuest is a minimalist, privacy-first web application that uses a local, open-weight language model to generate bite-sized, real-world outdoor missions. It gives you an immediate, structured reason to step away from your screen and interact with the physical world.

How It Gets People Off the Screen and Into the World

Under 60 Seconds on Screen: You choose how much time you have (from 15 minutes to 2 hours), select your current mood (11 curated vibes or a custom note), and pick your immediate environment (park, city sidewalk, backyard, neighborhood).
Anti-Screen Prompt Engineering: The underlying AI model is strictly instructed never to suggest anything involving phones, photography, internet searches, apps, or social media. Missions are built entirely around sensory awareness — noticing seasonal leaf transitions, identifying quiet corners, tracing textured bark or stone, or listening for overlooked sounds.
The Lock-and-Step Loop: When you tap Start Quest, a fullscreen 3-2-1 countdown sequence begins, followed by an active timer and a clear prompt: "Put your phone away. See you in X minutes." You lock your screen, pocket your phone, and head outdoors.
Post-Quest Reflection: When you return, SideQuest calculates your minutes outside from start timestamps, records how your mood shifted before and after the quest, and saves your thoughts in a private local journal.
Focus Guard: You can never have more than 2 ongoing quests active at once, discouraging quest hoarding and keeping your focus on completing real-world activities.

Who It Is For

Developers & Remote Workers: Desk-bound professionals suffering from screen fatigue and decision paralysis during short breaks.
Students: Anyone trapped in an infinite social media loop between study sessions.
Everyday Explorers: People who want to take a walk but want a novel observational lens rather than an aimless wander.

Demo

Live Demo Walkthrough: [https://youtu.be/ffJ03snJw5s]
GitHug Submission: [https://github.com/NegiSushant/OutsideQuest]

Key Screens & Experience

Quest Customization (/start): Granular time presets (15m, 30m, 45m, 60m, 120m, or custom minutes), 11 moods (Relax, Explore, Calm, Nature, Move, Create, Curious, Adventurous, Reflective, Anxious, Bored), and 8 environments (Outdoors, Park, City/Urban, Home/Yard, Nature, Quiet Spot, Mixed, Anywhere). Includes a one-click Surprise Me mode.
Mission View (/quest): Displays mission title, duration, tags, purpose, and ordered physical tasks.
Interactive Launch Modal: 3-2-1 animated launch sequence transitioning into an active countdown timer with pause and resume controls.
Reflection Journal (/reflect): Full-context review of initial parameters and tasks, mood-before (pre-filled) vs. mood-after tracker, outside time counter, and personal reflection notes.
Quest History (/journal): Filterable log (All, Not started, Ongoing, Completed) with live running countdown badges and detail inspection modals.

Code

NegiSushant / OutsideQuest

SideQuest — Outside Quest

Less scrolling. More living. An AI that gives you a reason to put your phone down and go outside.

🌱 What is SideQuest?

SideQuest (OutsideQuest) is an outdoor micro-adventure generator powered by a local, open-weight language model.

Instead of keeping you engaged in prolonged conversational dialogue, SideQuest is designed to do the opposite: take under a minute of your time, generate a small physical mission in your immediate environment, and tell you to put your phone away.

Who it is for

Anyone experiencing digital fatigue from extended screen sessions.
Remote workers and students needing a structured reason to take a short break outdoors.
Anyone who wants to step outside but gets stuck deciding where to go or what to do.

The problem it addresses

Most outdoor and fitness applications demand continuous screen engagement — watching live maps, managing GPS routes, logging stats mid-walk, or photographing scenery…

View on GitHub

GitHub Repository: https://github.com/NegiSushant/OutsideQuest

The project is completely open-source and built using Next.js 16 (App Router), React 19, Tailwind CSS v4, Bun, and Docker Desktop Model Runner.

How I Built It

SideQuest was built from the ground up around local open-weight AI, ensuring zero external API dependencies, zero tracking, and true offline capability.

1. Open-Weight Model & Local Inference

Model: Google’s Gemma 3 1B (ai/gemma3:1b-q4_K_M), 4-bit medium quantized instruction-tuned model.
Local Serving Engine: Docker Desktop Model Runner, exposing an OpenAI-compatible REST endpoint at http://localhost:12434/engines/v1.
Hardware Efficiency: At under 1.5 GB of RAM/VRAM, Gemma 3 1B runs easily on standard consumer laptops without specialized GPU hardware. Early attempts to run 4B models triggered Out-Of-Memory allocation errors on local hardware, making the 1B variant the ideal balance of speed (under 3 seconds per quest), reliability, and lightweight footprint.

2. Guardrailed System Prompting

The system prompt (src/lib/prompts.ts) turns generative AI into an intentional departure tool:

Enforces exact requested durations.
Strictly forbids screen-based tasks: "Never suggest taking photos, browsing online, or social sharing."
Focuses on sensory observation: "Focus on noticing, sensing, walking, sitting, comparing, or finding."
Respects user physical constraints (e.g., knee fatigue, quiet preferences).
Guarantees clean, deterministic JSON output.

3. A Real Example from the Application Logs

Here is an authentic test generation stored in quest-test-logs.json:

{
  "preferences": {
    "availableTime": 15,
    "mood": "relax",
    "environment": "park",
    "notes": "Keep it quiet, i have knee problem"
  },
  "quest": {
    "title": "Stroll Through the Park's Hidden Corner",
    "duration": 15,
    "goal": "Find a serene spot to sit and observe the surroundings",
    "tasks": [
      {
        "id": "task-1",
        "description": "Walk slowly to a quiet area of the park, avoiding main paths"
      },
      {
        "id": "task-2",
        "description": "Find a bench or a tree with a flat surface to sit on, and sit down"
      },
      {
        "id": "task-3",
        "description": "Observe the types of leaves and flowers around you, noticing any changes in the season"
      },
      {
        "id": "task-4",
        "description": "Listen to the sounds of nature, focusing on the quietest sounds, such as the rustling of leaves or the chirping of birds"
      }
    ],
    "tags": ["relaxation", "nature", "observation"],
    "status": "completed"
  }
}

4. Full-Stack Web Architecture

Frontend: Next.js 16 App Router with React 19, styled using Tailwind CSS v4 and next-themes for responsive dark and light modes.
Server Handlers: Server-side route handlers (/api/generate, /api/latest-quest, /api/update-quest-progress, /api/complete-quest) format prompts, validate JSON structures, and manage session lifecycles.
Zero-Setup Local Persistence: Data persists to local JSON files (quest-test-logs.json and final-quest.json) alongside browser localStorage, eliminating the need to set up remote databases.

Why Does Open Innovation Matter?

During early experimentation, I hit a cloud provider error recorded directly in my project logs:

"Failed to perform inference: You have no remaining credits. Purchase pre-paid credits to continue..."

That moment underscored why open innovation and local open-weight models are crucial for products like SideQuest:

Intimate Privacy by Default: SideQuest asks users to log daily emotional states (e.g., feeling anxious, bored, or reflective), personal physical limitations (e.g., knee issues), and neighborhood locations. Streaming raw emotional reflections and habits to closed commercial cloud APIs is an unnecessary privacy risk. With local open-weight AI, zero bytes leave the host machine.
Freedom from Paywalls & Artificial Scarcity: Closed APIs require subscription models, token metering, and credit card barriers. Open-weight models empower developers to build free, perpetual utility software that anyone with a laptop can run forever without paying per token.
Resilience & Offline Independence: If you take your laptop to a cabin, a park bench with spotty mobile data, or travel without Wi-Fi, SideQuest still generates mindful quests on demand.
Focused Utility: Gemma 3 1B demonstrates that open models don't need to be massive 70B parameter giants to deliver meaningful human impact. A lightweight 1B model running on local hardware is all it takes to help someone step away from their desk and reset their mind.

My Agent Session

Throughout the development of SideQuest, I utilized pair-programming agent workflows to iterate rapidly on system prompt edge cases, dynamic reverse timers, JSON database handlers, and responsive dark-mode UI tokens.

The entire development history, architectural decisions, and setup instructions are documented transparently in the repository's commit history and README.md.

Prize Categories

Primary Category: Hacktoberfest 2026 Week 1 Challenge — “Touch Grass”
Track: Local & Open-Weight AI (Google Gemma 3 via Docker Model Runner)

Less scrolling. More living. Put your phone away and go touch grass! 🌱

Echoes of an Era: Building a Grounded AI Time Capsule from My Grandfather’s Voice

Sushant Singh Negi — Sun, 04 Oct 2026 12:49:55 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

Echoes of an Era is an open-source, retrieval-grounded AI voice memory capsule built specifically for my grandfather. It preserves, organizes, indexes, and makes searchable his authentic life stories and oral history without turning the AI into a fictionalized, hallucinatory avatar of him.

The Problem It Solves

My grandfather lived through a world that no longer exists—growing up in the 1950s, communicating via weekly inland letters, experiencing the transformation of traditional family customs, and observing decades of societal change. Our family captured hours of his stories on voice recorders, but like most personal audio archives:

Voice recordings are unsearchable: Audio files are linear and opaque. You cannot Ctrl+F a voice recording.
Stories lose context over time: Unlabelled files sitting in folders become difficult for future generations to explore.
The AI Hallucination Trap: Generic cloud chatbots are trained to be helpful, which often means they fabricate heartwarming but entirely fake personal memories when asked questions they don't know the answer to.

The Core Philosophy

"AI interprets the memories. It does not create the memories."

This application is not an AI pretending to be my grandfather. It is an AI-powered interface to my grandfather's authentic, recorded voice. His original voice recordings remain the single source of truth.

Key Features

🎙️ Audio Memory Vaulting: Upload and store raw voice recordings (.mp3, .wav) up to 10MB per file with automatic PyAV audio metadata decoding.
📝 Timestamped Speech-to-Text: Verbatim transcription using faster-whisper with voice activity detection (VAD) and auto-detected language support (Hindi, Hinglish, English).
🧠 Structured Memory Extraction: Automatically extracts titles, summaries, historical eras, locations, people mentioned, emotions, verbatim quotes, and life advice using gemma3:1B-Q4_K_M running locally through Docker Model Runner.
⚡ 1024-Dimensional Vector Search: High-density semantic indexing using local BAAI/bge-m3 via SentenceTransformers stored in PostgreSQL with pgvector HNSW vector indexes.
🔍 Hybrid Retrieval Engine: Combines dense vector similarity with keyword/lexical field scoring re-ranked via Reciprocal Rank Fusion (RRF).
💬 Grounded Q&A ("Ask Grandfather"): Answers user questions strictly using retrieved memory context, refusing to fabricate answers when evidence is insufficient.
🎧 Interactive Audio Player & Timestamps: Direct, range-supported HTTP audio streaming (206 Partial Content) that jump-cuts to the exact second where grandfather spoke the retrieved memory.
📜 Chronological Era Timeline: Explore memories grouped chronologically across eras (1940s to present) and filter by thematic categories.
⏳ "Then vs Now" Reflections: Compare historical experiences described by grandfather (THEN) against modern realities (NOW), generating generational reflection questions and enduring values.

Screenshots

Home Page Dashboard & Audio Memory Vault

Grounded Q&A Interface ("Ask Grandfather")

Signature "Then vs Now" Historical Reflections Engine

Decade-based Memory Categorization

Demo

Video Demo: [https://youtu.be/73hLP9b_y4M]

Code

GitHub Repository: [https://github.com/NegiSushant/Echoes-of-an-Era]

git clone https://github.com/NegiSushant/Echoes-of-an-Era.git

How I Built It

Architecture & System Flow

graph TB
    subgraph Frontend Client Layer
        React[React 18 UI - Tailwind CSS]
        Player[Docked Audio Player Component]
        SDK[Client API Layer - api.js]
    end

    subgraph Backend Layer FastAPI
        API[FastAPI Core Application]
        STT[TranscriptionService - faster-whisper]
        Embed[EmbeddingService - BAAI/bge-m3]
        Extract[MemoryExtractorService]
        Retriever[RetrievalService - Hybrid Engine]
        RAG[RAGService - Grounded QA]
        Comp[ComparisonService - Then vs Now]
    end

    subgraph Local LLM Engine
        DMR[Docker Model Runner]
        Gemma[Gemma 3 1B Q4_K_M]
    end

    subgraph Storage & Database Layer
        PG[(PostgreSQL 16)]
        PGVector[pgvector Extension - Vector 1024]
        HNSW[HNSW Vector Index]
        AudioStore[File Storage ./uploads/audio]
    end

    React --> SDK
    React --> Player
    SDK -->|REST API| API

    API --> STT
    API --> Extract
    API --> Embed
    API --> Retriever
    API --> RAG
    API --> Comp

    RAG -->|Grounded Context| DMR
    Extract -->|Extraction Prompt| DMR
    Comp -->|Comparison Prompt| DMR
    DMR --> Gemma

    Retriever --> Embed
    Retriever -->|Vector + Lexical Query| PGVector
    Embed -->|1024-dim Vector| PGVector
    PGVector --> HNSW
    Postgres --> PGVector

    Player -->|HTTP Range Stream| API
    API -->|Read Audio Bytes| AudioStore
    STT -->|Read Audio| AudioStore

1. Gemma 3: Local Reasoning & Memory Extraction

Model: gemma3:1B-Q4_K_M (Gemma 3 1B 4-bit quantized).
Runtime: Gemma 3 1B Q4_K_M running locally through Docker Model Runner (docker model run gemma3:1B-Q4_K_M) on port 12434.
Purpose: Structured JSON memory extraction (temperature: 0.1), grounded RAG answer generation (temperature: 0.2), and "Then vs Now" historical comparison synthesis.

2. BGE-M3: 1024-Dimensional Local Vector Indexing

Model: BAAI/bge-m3 via local SentenceTransformers (EMBEDDING_LOCAL_ONLY=true).
Dimensions: 1024-dimensional normalized dense vectors.
Composite Text Schema: Encodes TITLE + SUMMARY + TOPICS + TRANSCRIPT together so semantic queries like "school days" or "travelling by train" map directly to relevant memories.

3. Speech-to-Text (STT)

Model: faster-whisper (large-v3-turbo model default) with PyAV and CTranslate2.
Execution: Local transcription with Voice Activity Detection (vad_filter=True) and precise segment timestamps (start_time, end_time).

4. PostgreSQL + pgvector Hybrid Retrieval

Database: PostgreSQL 16 image (pgvector/pgvector:pg16) with pgvector extension and HNSW vector index (Vector(1024)).
Hybrid Fusion: Combines cosine vector similarity (1.0 - cosine_distance) with multi-field lexical keyword matching re-ranked via Reciprocal Rank Fusion (RRF $k=60$) blended with linear score weighting (65% vector, 35% keyword).

5. Evidence-Grounded Refusal Guardrail

If no retrieved memory candidate meets the confidence floor ($\ge 0.20$), the system refuses to guess and outputs:

"Grandfather has not spoken about this in his recorded memories."

Technology Stack Table

Layer	Technology	Purpose
Frontend	React 18, Vite, Tailwind CSS, Lucide Icons	Modern Web UI & docked audio player
Backend	FastAPI, Python 3.10+, PyAV, Pydantic	REST API & media streaming server
Database	PostgreSQL 16	Relational storage for memories, transcripts, & eras
Vector Index	`pgvector` (0.2.5+)	1024-dim HNSW vector similarity search
LLM Model	Gemma 3 1B Q4_K_M (`gemma3:1B-Q4_K_M`)	Local memory extraction, grounded QA, Then vs Now
LLM Runtime	Docker Model Runner (`docker model`)	Local LLM inference engine (port 12434)
Embeddings	`BAAI/bge-m3` (SentenceTransformers)	1024-dimensional normalized dense vectors
Speech-to-Text	`faster-whisper` (`large-v3-turbo`)	Local transcription & timestamp extraction
Containerization	Docker & Docker Compose	Containerized database and vector engine setup

Why Does Open Innovation Matter?

Open-weight models (Gemma 3, BGE-M3, faster-whisper) and open-source infrastructure (PostgreSQL + pgvector) are essential for personal family archives:

Privacy & Data Sovereignty: Personal family history, private transcripts, and voice audio remain strictly on local hardware rather than being transmitted to third-party public LLM cloud providers.
Long-Term Longevity: Closed cloud APIs can change terms of service, adjust pricing, or sunset models. Open-weight models running on standard host hardware guarantee that the family time capsule will remain accessible 10 or 20 years from now.
Full Transparency & Control: Open infrastructure allows us to inspect and customize prompt templates, tune retrieval thresholds, and manage vector indices directly without relying on proprietary black-box pipelines.

Prize Categories

Build for a Friend: Built specifically for my grandfather to preserve his living oral history and share his recorded memories with our family.
Best Use of Gemma: Uses Gemma 3 1B Q4_K_M running locally through Docker Model Runner for structured memory extraction, evidence-grounded Q&A generation, and historical "Then vs Now" reflections.

DEV Community: Sushant Singh Negi

SlothAuth: Autonomous Overnight Prior-Auth Prep with Local Gemma, LangGraph, and pgvector

What I Built

The Burden: Why Modern Medicine Needs to Channel the Sloth

Enter SlothAuth: Radical Laziness as Burnout Prevention

Demo

Key Dashboard Views

1. The "Morning Care Coordinator" Queue & Real-Time SSE Stepper

2. Scenario 1 (PT-2026-001 — Marcus Vance): 100% Policy Compliant

3. Scenario 2 (PT-2026-002 — Elena Rostova): Catching Missing Labs Before Denial

4. Scenario 3 (PT-2026-003 — David Chen): Automated Step-Therapy Exception

Code

How I Built It

1. Local AI Runtime: Docker Model Runner & Google Gemma

2. Hybrid Policy RAG with PostgreSQL & pgvector

3. Deterministic 4-Node LangGraph.js Orchestration

How the 4 Nodes Work:

4. Real-Time Server-Sent Events (SSE) Streaming

Why Does Open Innovation Matter?

1. Strict PHI Privacy & Zero Data Egress (The HIPAA Reality)

2. $0.00 Marginal Cost for Continuous Overnight Batching

3. Model Weight Pinning & Clinical Reproducibility

My Agent Session

The Lazy Payoff

Case 1: Marcus Vance (PT-2026-001) — Lumbar Spine MRI (CPT-72148)

Case 2: Elena Rostova (PT-2026-002) — Adalimumab Biologic (J0135)

Case 3: David Chen (PT-2026-003) — Infliximab Infusion (J1745)

Prize Categories

🌟 Best Use of Gemma

🐯 Best Use of Tiger Data

Conclusion: Embrace Your Inner Sloth

ResumeForge: A Privacy-First AI Resume Analyzer Built with Local Open-Weight Models

What I Built

What it does:

Who would pay for it?

Demo

Code

NegiSushant / ResumeForge

🔒 ResumeForge

AI-Powered Resume Analysis — Completely On Your Machine

📸 Screenshots

✨ Features

🧠 Intelligent Analysis

How I Built It

1. The Open-Source AI Core: Gemma 3 (1B) & Docker Model Runner

2. Engineering Around a 1B Parameter Model: Honest Lessons

3. Full-Stack Data & Authentication Pipeline

Why Does Open Innovation Matter?

1. Privacy Is Not a Feature—It Is the Product

2. Eliminating the "API Tax" on Side Hustles

3. Democratizing Career Advancement

My Agent Session

Prize Categories

CodeWeaver: Giving AI Agents Real Context with a Codebase Knowledge Graph

Beyond Vector Search: Building a Graph-Native Codebase Intelligence Agent with FalkorDB

1. Introduction

Demo

2. The Real Problem: Why Vector Search Fails at Code

3. The Insight: Code is a Graph, Not a Bag of Tokens

4. What We Built: CodeWeaver

Core Capabilities:

5. How We Modeled the Codebase as a Graph

The Node Types:

The Relationship Topology:

6. How the Agent Reasons: Cypher-Powered Tools & Explainability

The Power of the Reasoning Path

7. Architecture Decisions

1. In-Memory Graph Processing with FalkorDB

2. Separation of Playground (/chat) and Explorer (/graph)

3. Persistent Grok-Style Chat Sessions

8. Challenges We Faced & How We Solved Them

Challenge 1: The "Visual Hairball" Effect

Challenge 2: Hallucination-Free Reasoning Nodes

9. What We Learned

10. Why FalkorDB Was Critical

11. Conclusion

I Built OutSideQuest: An AI That Wants You to Stop Using It 🌿

SideQuest — Outside Quest

What I Built

How It Gets People Off the Screen and Into the World

2. Scenario 1 (`PT-2026-001` — Marcus Vance): 100% Policy Compliant

3. Scenario 2 (`PT-2026-002` — Elena Rostova): Catching Missing Labs Before Denial

4. Scenario 3 (`PT-2026-003` — David Chen): Automated Step-Therapy Exception

2. Hybrid Policy RAG with PostgreSQL & `pgvector`

Case 1: Marcus Vance (`PT-2026-001`) — Lumbar Spine MRI (`CPT-72148`)

Case 2: Elena Rostova (`PT-2026-002`) — Adalimumab Biologic (`J0135`)

Case 3: David Chen (`PT-2026-003`) — Infliximab Infusion (`J1745`)

2. Separation of Playground (`/chat`) and Explorer (`/graph`)