PAIPersonal AI RuntimeEngineering case study
PUBLIC · LOCAL AI

Personal AI Runtime

A runnable reference implementation where memory, routing, policy, tools, workflows and orchestration remain explicit engineering boundaries.

PublicRunnable referenceLocal-only policyPython + SQLite

The problem

Why this project exists

Personal AI systems become difficult to trust when memory, provider routing, tools and workflows are implicit. This runtime makes those boundaries explicit and testable.

Verified capabilities

What is actually implemented

These capability descriptions are intentionally limited to the evidence-backed implementation surface.

01

Dual-form memory

SQLite provides indexed access while Markdown remains a human-readable source representation.

02

Workload routing

Chat, reasoning, embedding and vision workloads route through provider health checks.

03

Pre-call policy

A local-only route is rejected before a cloud provider adapter is invoked.

04

Scoped tools

Registered capabilities are checked against execution context before invocation.

05

Durable workflows

Lifecycle state is persisted so workflows can resume across process boundaries.

06

Bounded orchestration

Idempotency keys, bounded concurrency and retry classification make jobs explicit.

Architecture

How the system is structured

The diagram below represents the current verified architecture boundary; planned or environment-dependent components are described in the engineering notes rather than silently promoted.

HTTP / CLI
↓
Application Layer
↓
Policy Boundary
↓
Model Port
↓
Tool Registry
↓
SQLite + Markdown
↓
Workflow Store
BOUNDARY

Evidence and authority

Deterministic IDs and hashes connect database memory to its human-readable representation.

The provider port allows local, hosted or BYOK adapters without changing application policy.

Engineering deep dive

Decisions, trade-offs and boundaries

Technology names matter less than the engineering contracts they enforce.

E1

Deterministic IDs and hashes connect database memory to its human-readable representation.

E2

Policy is evaluated before provider invocation, not after the request has already crossed the boundary.

E3

Every job has an idempotency key and retries are limited to retryable failures.

E4

The provider port allows local, hosted or BYOK adapters without changing application policy.

Project status

Public · evidence-backed status

Runnable reference implementation with memory, routing, local-only policy, tools, workflows and orchestration covered by tests.

ClassificationPublic implementation
EvidenceRepository implementation, tests and project records cross-checked
ClaimsCurrent, planned and limitations kept separate
DeploymentNot changed by portfolio integration
PUBLIC IMPLEMENTATION

Inspect the implementation directly.

Public implementation — source and test suite are available.