01 / Flagship productIn progress
Workspine
A private desktop work-memory system that turns fragmented activity into a navigable timeline of context, decisions, and evidence.
Product architecture · Memory · PrivacyInspect ↗
AI systems architecture with consequences
Six system stories spanning private products, governed delivery, workflow reliability, migration, CRM operations, and resilient onboarding.
02 / Selected systemsArchitecture
Architecture
with consequences.
Six system stories spanning products, delivery infrastructure, migration, reliability, and cross-platform operations.
Every card declares maturity and confidentiality. No invented ROI. No client data.
02 / Delivery enginePrivate system
MANHAJ
A system factory and control plane for turning repeatable delivery knowledge into governed modules, agents, and releases.
System factory · GovernanceInspect ↗
03 / Client systemAnonymized
Enterprise OS
A layered operating model joining permissions, delivery, finance, state gates, and observability without exposing client internals.
Architecture · Controls · AuditInspect ↗
04 / Reliability systemPublic proof
Self Healing Automation
ErrorLens turns workflow failures into structured events. It classifies errors, retries safe cases, escalates with context, and records what needs fixing.
n8n · Observability · RecoveryInspect ↗
05 / Migration factoryDocumented scope
Make → n8n Factory
A migration program that classifies 108 workflow candidates into reusable families, then validates behavior instead of copying spaghetti.
108 candidates · Migration · QAInspect ↗
06 / Cross-platform operationsAnonymized
Resilient Onboarding
A checkpointed onboarding architecture spanning CRM, billing, calendars, messaging, and human handoffs. Recovery is part of the design.
CRM · Provisioning · StateInspect ↗
Public build log / verified on GitHub
Repos you can inspect.
Repos you can inspect.
Not claims you have to trust.
Small, focused systems that expose the architecture, the safety rails, and the real run path.
Explore every repository ↗01 / AI OPSPUBLIC
FlowSentry
Deterministic n8n failure detection with local LLM root cause analysis and Slack ready digests.
- Python
- n8n
- Ollama
02 / HUMAN IN LOOPPUBLIC
Ticket Triage AI
KB grounded ticket classification, priority, routing, and drafts with approval before customer delivery.
- FastAPI
- Streamlit
- SQLite
03 / DATA AGENTPUBLIC
SQL Analyst Agent
A schema aware, SELECT only analyst that reads errors, repairs its SQL, and makes every attempt visible.
- DuckDB
- Python
- Ollama
04 / RESEARCHPUBLIC
Paper Scout
New arXiv papers become a referenced briefing, comparison table, open questions, and interactive topic map.
- arXiv
- Plotly
- Local LLM
05 / VOICEPUBLIC
VoiceLine AI
A local voice receptionist that extracts intent, schedules an appointment, and returns a spoken confirmation.
- Whisper
- ICS
- Python
06 / DOCUMENT AIPUBLIC
Extractor Pipeline
Messy documents become validated records through schema checks, model repair, and explicit failure logs.
- Pydantic
- OCR
- SQLite
Have a system this messy?
Book a 25 min systems call ↗
Bring the workflow, the failure points, and the desired outcome. We will map the first useful move together.
How to read the evidence
A public demo proves only the behavior visible in that deployment. A public repository adds inspectable implementation and tests. An anonymized architecture record explains a pattern without proving a client result. A documented scope states what was planned or inventoried, while a private implementation remains uninspectable from this site. Each case keeps those evidence states separate.
Frequently asked questions
What counts as evidence in these AI system case studies?
Each record labels whether evidence is a public deployment, public repository, private implementation, anonymized architecture, documented project scope, or self-reported history. Those labels are not interchangeable.
Do the case studies claim client results?
Only when a result has an attributable source, measurement definition, method, and time window. Architecture records without that evidence describe the system pattern and its limits instead of presenting unverified ROI.
How should a similar system be evaluated?
Evaluate its state model, permissions, failure recovery, human handoff, observability, acceptance tests, ownership, and evidence—not only its happy-path demo.