[email protected] · (507) 208-0737 · linkedin.com/in/rshangle


This document describes two systems I designed and built independently. Both are production-operational. I am including this brief because technical success roles centered on AI adoption require more than a resume line — the design decisions here are the actual evidence.


Flatline Codex — Local-First AI Operations Kernel

A personal AI operations infrastructure built around a 105-table SQLite database (WAL mode) that functions as the canonical state for all system activity. The architecture prioritizes traceability and human-in-the-loop control above automation speed.

Key components:

JAUNT Intake Pipeline

Stage Description
Auto-Triage Incoming content classified by type, domain, and quality signal
Coordinate Canonical coordinates assigned (domain, structure, purpose, terrain)
Validate Frontmatter checked; schema enforced; malformed files routed to quarantine
Human Review Accept / Pass / Trash — nothing proceeds without explicit human decision
Custody Accepted files stamped, moved to active corpus, logged to custody chain

Why it's relevant: This is the operational pattern AI adoption in regulated environments requires — structured intake, human review gates, traceability at every layer, and a clear separation between "model suggested" and "human approved."


flowchart TB
	A["Flatline Codex<br>Local-First AI Operations Kernel"]:::title
	A --> B["Canonical state<br>SQLite (105 tables, WAL)"]:::core
	B --> C["PYTHIA<br>Tiered lookup router"]:::comp
	C --> D["JAUNT<br>Ingest pipeline"]:::comp
	D --> E["SENTINEL<br>Drift monitoring"]:::comp
	E --> F["Audit architecture<br>Message bus + ops run log"]:::comp

	C --> C1["In-memory cache"]:::tier
	C1 --> C2["Indexed DB lookup"]:::tier
	C2 --> C3["Full-text search"]:::tier
	C3 --> C4["Vector search<br>ChromaDB (1,571 chunks)"]:::tier
	C4 --> C5["Every tier logs source + latency<br>Misses classified + tracked"]:::note

	D --> D1["Auto-Triage"]:::stage
	D1 --> D2["Coordinate"]:::stage
	D2 --> D3["Validate"]:::stage
	D3 --> D4["Human Review<br>Accept / Pass / Trash"]:::gate
	D4 --> D5["Custody<br>Stamp + move + log"]:::stage

	E --> E1["Nightly checks (7)<br>schema drift • index staleness • orphans • stale worktrees"]:::stage
	E1 --> E2["Writes drift_report table<br>Scoped auto-remediation + alerts"]:::note

	classDef title fill:#0b1f3a,stroke:#0b1f3a,color:#ffffff;
	classDef core fill:#e8f0ff,stroke:#4c6fff,color:#0b1f3a;
	classDef comp fill:#f1f5f9,stroke:#94a3b8,color:#0f172a;
	classDef tier fill:#ffffff,stroke:#cbd5e1,color:#0f172a;
	classDef stage fill:#ffffff,stroke:#cbd5e1,color:#0f172a;
	classDef gate fill:#fff7ed,stroke:#fb923c,color:#7c2d12;
	classDef note fill:#f8fafc,stroke:#e2e8f0,color:#334155;

Dreadnaught — Modular Prompt Engineering System

A structured prompt assembly and evaluation system built to enforce reproducibility and source discipline.

Key design decisions: