Matías Fernández
← All work

PUBLIC FLAGSHIP · ACTIVE PROJECT

AI Knowledge Platform

How I built a document knowledge platform around measured retrieval, verifiable citations, explicit failure states, tests, CI, and architecture decisions.

At a glance

Role
Sole author · product and engineering
Period
ACTIVE · PUBLIC REPOSITORY
Team
Independent project · one engineer
Stack
Python · FastAPI · Next.js · TypeScript · SQLite FTS5 · OpenAI Responses API
Source and demo
Public source, tests, CI, ADRs, evaluation sets, and a locally runnable product. No hosted demo yet.

01 / Overview

A document knowledge product built to make answer quality inspectable. It ingests PDFs, preserves page provenance, measures lexical retrieval, and returns grounded answers whose citations are resolved from trusted server-side evidence.

02 / The problem

The problem

Teams need answers from policies, contracts, runbooks, and research that readers can verify; fluent text without attributable evidence is not a trustworthy product outcome.

03 / My responsibility

My responsibility

  • Defined the product states and milestone sequence, then implemented each vertical slice across the Next.js frontend and FastAPI backend.
  • Designed ingestion, extraction, retrieval, answer generation, citations, evaluation sets, tests, CI, and architecture decision records.
  • Kept implementation status separate from live-provider acceptance and documented missing capabilities explicitly.

Constraints

Constraints

  • The first useful slice had to run locally without cloud infrastructure, background workers, or a hosted database.
  • Every answer citation had to resolve to a page and passage the server actually retrieved.
  • Provider credentials could not be assumed, so offline gates and live answer acceptance needed separate definitions.

04 / Architecture

Architecture

Current request path

The browser drives explicit upload, extraction, indexing, search, and answer states. The API owns validation and provenance; SQLite is a rebuildable lexical index; the model receives only bounded retrieved evidence.

  1. 01Product UINext.js · accessible states
  2. 02Application APIFastAPI · validation
  3. 03Evidence indexSQLite FTS5 · BM25
  4. 04Answer adapterStructured output · bounded evidence

05 / Key decisions

Key decisions

01

Model states as a contract

Context
A single “ready” flag would hide which step failed and what could be retried.
Decision
Use separate stored, processing, extracted, indexing, indexed, and explicit failure states.
Consequence
The UI can preserve completed work and offer the correct retry instead of restarting the whole flow.
02

Measure lexical retrieval first

Context
Adding embeddings early would introduce cost and complexity without proving the baseline was insufficient.
Decision
Use page-bounded chunks with SQLite FTS5/BM25 and enforce Recall@3 and MRR@3 in CI.
Consequence
Retrieval is reproducible and inexpensive, with an explicit point at which a semantic approach can be justified.
03

Resolve citations on the server

Context
Allowing a model to invent file or page metadata would make plausible citations untrustworthy.
Decision
Let the model reference request-local evidence IDs only; build document, page, chunk, and offsets from retrieval matches.
Consequence
A citation can be opened against the stored PDF, while unknown evidence IDs fail validation.

06 / Trade-offs

Trade-offs

Local files and embedded SQLite

What it enablesFast setup, inspectable data, deterministic tests, and no infrastructure dependency.

What it costsNo multi-process coordination, cloud durability, multi-tenancy, or horizontal scale.

Lexical retrieval before embeddings

What it enablesA measurable, keyless baseline with predictable cost and behavior.

What it costsSynonyms and semantically related wording can miss without token overlap.

Synchronous vertical slices

What it enablesA short request path and failures that are easy to reproduce locally.

What it costsLarge workloads will eventually require queues, workers, and progress persistence.

07 / Failure modes

Failure modes

  1. Rejected or interrupted uploads remove temporary artifacts, so partial files never appear stored.
  2. Extraction and indexing failures retain the last successful state and expose a targeted retry.
  3. Weak retrieval returns insufficient evidence instead of forcing a generated answer.
  4. Safety refusal and technical provider failure remain distinct outcomes in the API and interface.

08 / Results and evidence

Results and evidence

09 / Delivery state

Delivery state

  1. 01
    Accepted · PDF + metadata

    Trustworthy ingestion

    Streaming validation and atomic storage.

  2. 02
    Accepted · Text + coordinates

    Page provenance

    Extraction that preserves every source page.

  3. 03
    Accepted · Ranked evidence

    Measured retrieval

    Page-bounded chunks, FTS5/BM25, and CI thresholds.

  4. 04
    Implemented · acceptance pending · Answer + citations

    Grounded answers

    Implemented and offline-tested; live model quality is not accepted.

  5. 05
    Planned · Quality + operations

    Operational visibility

    Latency, token, cost, failure, and feedback surfaces.

10 / What I would improve next

What I would improve next

  1. Compare candidate model snapshots and record live answer-quality results before accepting milestone 4.
  2. Exercise and record one real answered browser flow, then publish a short demo.
  3. Plan observability only after the answer path has live-provider acceptance.

12 / Continue the conversation

Continue the conversation

The résumé provides the complete career context. For client-sensitive details, contact me and I can discuss the work at the appropriate disclosure level.

Contact me Open résumé