Selected work

Case study 01 · Full-stack AI system

Ask JDP

A public career assistant that answers from a reviewed corpus. Its privacy rules, evidence limits, session ownership, and abuse controls are enforced in code.

  • Surface Public source + live app
  • Runtime React · Hono · Flue · SQLite
  • Verified CI and live recruiter path

01

Problem

I wanted employers to ask about my work in plain language, but I did not want to hand a model raw résumés, private claim ledgers, or an open-ended pool of sources. A polished answer also had to stay within what the reviewed evidence could support.

02

Constraints

  • Only reviewed, public-safe career evidence may reach the model.
  • Raw source documents, prompts, credentials, private identifiers, and prohibited details must remain undisclosed.
  • Anonymous users may access only server-issued conversations owned by their signed session.
  • The public endpoint needs bounded requests, rate limits, retention rules, and readiness checks without exposing provider credentials.

03

My decisions

I kept the reviewed corpus small and server-only. The agent contract requires qualified answers and a visible source label. The HTTP layer pairs opaque conversation IDs with signed HttpOnly, SameSite=Strict sessions. It also checks the request origin, caps body size, and rate-limits each session.

Known prompt-injection patterns are rejected before the model is called. SQLite stores conversations. On startup, cleanup deletes only settled records older than the configured cutoff and stops on schema or transaction errors.

04

Difficult tradeoffs

I kept the system narrow on purpose. It cannot browse, ingest arbitrary résumés, or answer outside the reviewed corpus. That leaves fewer questions it can answer, but the boundary is clear to both the user and the model.

GitHub Pages cannot run the full assistant. It needs a persistent Node process, SQLite storage, and a provider secret on the server. The static frontend is still useful for handoff and deployment packaging, but it is only the client.

05

Implementation

The single-screen React client shows the evidence scope and privacy warning before someone asks a question. It labels the composer, shows the live answer state, and gives recoverable errors. A Hono API handles security headers, sessions, body limits, rate limits, injection rejection, health checks, and the Flue agent router. The agent receives only the curated corpus and its response rules.

  • ClientReact · accessible composer · visible provenance
  • BoundaryHono · CSP · same-origin · signed sessions
  • AgentClosed corpus · bounded claims · refusal behavior
  • StateSQLite · ownership checks · bounded cleanup

06

Verification

The source tests cover cross-session isolation, opaque identifiers, CSP, cross-origin and injection rejection, claim qualifiers, UI provenance, expired-record cleanup, rollback, and missing-schema failure. CI passed on the published commit. On August 12, 2026, I also opened the public app and ran a representative employer question through the full browser flow.

Claim boundary

The evidence does not show zero hallucinations, security certification, adoption, or recruiter conversion. I keep networked model evaluations separate from deterministic checks because they cost money and can vary between runs.

07

Outcome

Ask JDP is public, live, and inspectable. The privacy and evidence rules described here appear in the interface, the code, the tests, and the running application. I do not have a defensible engagement metric, so I do not claim one.

Proof

Traceable evidence

Next case study

Tink