AI application · Live
YapOS
Inspectable personal AI with approved memory and selective response evaluation.
A full-stack AI workspace combining mode-specific conversations, approval-gated memory, document workflows, tasks, saved insights, and inspectable execution decisions.
- Role
- Product direction, full-stack architecture, AI orchestration, interface design, testing, and release verification.
- Year
- 2026
- Status
- Live
- Stack
- React · TypeScript · Fastify · PostgreSQL · Prisma · OpenAI API · Zod · Playwright
Overview
YapOS is a full-stack personal AI workspace centered on Yap-A-Tron. It combines conversations, approved memory, uploaded files, grounded document questions, tasks, saved insights, preferences, and execution traces.
The system is designed to make context construction, review behavior, and user ownership visible and bounded.
Problem
Many AI applications send a transcript to a model and display the output without clearly controlling context, memory, review behavior, user ownership, provider cost, or failure handling.
Solution
YapOS introduces a provider-independent orchestration layer that selects mode-specific strategies, builds bounded context, selectively evaluates higher-risk responses, and persists user-owned workflows through Fastify, Prisma, and PostgreSQL.
Feature evidence
Mode-specific assistance
General, Study, Career, and Finance modes shape deterministic context and behavior.
Bounded context
Recent history, rolling summaries, approved memory, and lexical document retrieval limit what enters each request.
Selective review
Higher-risk responses enter an evaluator and revision lifecycle with an explicit safe fallback.
User-owned workspace
Tasks, files, memories, insights, preferences, and conversations remain scoped to authenticated users.
System layers
A React client consumes shared Zod contracts through a Fastify boundary. The assistant core selects a mode strategy, calls a provider adapter, and persists completed workflows through Prisma.
- 01
React client
Conversations, tools, traces, and responsive Webcore interface.
- 02
Shared contracts
Zod validation shared across client and API boundaries.
- 03
Fastify API
Authenticated routes, ownership checks, and workflow coordination.
- 04
Assistant core
Deterministic strategy selection, context building, evaluation, and fallback.
- 05
PostgreSQL + files
Prisma records and a local file-storage adapter.
- 06
OpenAI adapter
Provider-specific Responses API integration behind an internal boundary.
Where the engineering concentrates.
Bounded context with useful continuity
The system balances recent turns, summaries, approved memory, and retrieved document text without treating all history as equally relevant.
Inspectable response review
Selective evaluation adds a revision path without pretending every response requires or survives a second model call.
Choices and tradeoffs.
Deterministic routing
Mode and request signals select an explicit strategy.
Tradeoff: Less emergent routing behavior in exchange for cost and execution predictability.
Approval before inferred memory
Inferred candidates remain inactive until the user accepts them.
Tradeoff: Adds a workflow step while preserving user control.
Lexical retrieval first
Bounded text retrieval ships before vector infrastructure.
Tradeoff: Transparent and practical for the current scope, but not semantic search.
Provider calls outside transactions
Slow network work does not hold database transactions open.
Security, accessibility, and testing.
Security
- Opaque session tokens stored as HMAC hashes
- User-owned record boundaries
- Rate, concurrency, and timeout controls
- Validated document and request payloads
Accessibility
- Keyboard-operable responsive interface
- Clear execution and approval states
- Visible status text independent of color
- Reduced-motion-aware interaction
Testing
- Vitest coverage for orchestration and contracts
- Playwright coverage for critical user workflows
- Provider-failure and invalid-evaluator fallback checks
- Build and release verification
Current boundaries
The current product has a deliberate scope. These boundaries define what it does not claim.
- Authenticated workflows require a real account; the public landing page explains the implemented system without demo credentials
- Local file storage requires persistent server storage
- Rate and concurrency controls are process-local
- Retrieval is lexical, not semantic
- No OCR or response streaming
- No autonomous agents or multi-agent system
The next credible steps.
- 01Replace local storage with an S3-compatible adapter for multi-instance deployment
- 02Move process-local rate and concurrency state to a shared store only when horizontal scaling is required
- 03Add OCR if scanned PDFs become an explicitly supported input
- 04Add richer database-backed integration fixtures around a disposable PostgreSQL test database
Verified product views
Genuine captures from the implemented product across core workflows and responsive layouts.
Authenticated workspace dashboard Product landing page 
Document workspace and grounded-question flow 
Approval-gated memory workspace 
Populated conversation on mobile
What the implementation clarified.
- 01
Deterministic routing makes provider cost, context assembly, and fallback behavior easier to inspect and test.
- 02
Approval-gated memory changes persistence from a hidden side effect into a user-controlled workflow.
- 03
Keeping provider calls outside database transactions reduces lock duration and contains network failure.