I build autonomous software systems that survive contact with reality. Then I publish the evidence.

My work focuses on the control layer around AI-native software production: specs, execution loops, audits, remediation, and evidence trails that make agentic work inspectable.

Technical receipts: routes, tests, migrations, code volume, docs, and surface area.

Open Millrace

STRONGEST PROOF status: in use

The Journey OS

Real church operations SaaS product with an actual customer path.

This is the applied product proof: real workflows, church operators, permissions, data changes, and production deployment pressure.

Product evidence includes Planning Center-oriented direction, a deployed customer path, 141 API routes, 140 test files, 44 database migrations, and roughly 68k effective lines of code.

status: in use
routes: 141
test files: 140
migrations: 44
effective_loc: ~68k

Open product ->

PROOF

Claims, receipts, and limits stay together.

This pane keeps the evidence visible without making the first screen carry every artifact.

Third-party evaluation, generated artifacts, product proof, evidence links, limitations, and follow-up work stay attached to each claim.

THIRD PARTY EVALUATION

TalentBoard AI fluency evaluation

TalentBoard, backed by Nate B. Jones credibility, manually validated Tim as 9/10 "AI Transformative" for overall AI Fluency.

Claim tested: TalentBoard identifies Tim as 9/10 "AI Transformative" for overall AI Fluency after third-party manual validation backed by Nate B. Jones credibility. Limitations: This is an external evaluation signal, not a substitute for inspecting shipped product surfaces, code, artifacts, and limitations.

Open evidence ->

Game artifact stream

Autonomous game artifact stream

Live experiment started. The archive should be read as an opening public evidence stream, not a mature proof corpus.

Claim tested: Games are the first public artifact class because they are visible, playable, interactive, and useful for exposing real implementation issues. Limitations: All-game artifacts are too narrow to prove general-purpose production SaaS or integration capability by themselves.

Open evidence ->

Evidence archive

The Journey OS applied product surface

The public TJOS site presents a system of progress for church teams, Planning Center alignment, action queues, nonlinear discipleship pipelines, and demo access.

Claim tested: The operator story is not only infrastructure theory. TJOS is an applied product surface for church teams. Limitations: Public proof should deepen over time with customer stories, product walkthroughs, and implementation artifacts.

Open evidence ->

Limitations

The public proof layer is intentionally not overclaiming. Third-party evaluation and game artifacts are evidence, not universal proof.

The next proof depth should include logs, rubrics, prompts/specs, screenshots, output histories, product walkthroughs, and postmortems.

Open full evidence archive ->

MILLRACE

Runtime layer for governed agentic software production.

Millrace is the operating layer I use to keep autonomous software work from becoming a black box.

Filesystem-backed Python runtime with execution and research planes, durable state snapshots, diagnostics, restart-safe control, spec queues, audit/remediation flow, and evidence artifacts.

Runtime thesis

Agent work needs an operating surface.

Long-horizon autonomous work needs more than a chat transcript. It needs state, constraints, review loops, and recoverable execution.

Core runtime concerns: spec state, task queue state, execution logs, audit records, remediation loops, failure recovery, and public evidence trails.

Product surface

millrace.ai

Product thesis, architecture, docs, package direction, comparisons, and release path.

Public surface for runtime architecture, package/docs direction, agent-control claims, release path, and technical comparison material.

Open Millrace ->

TJOS

The applied product proof.

The Journey OS shows the work applied to a real customer domain, not just infrastructure theory.

Production-facing SaaS surface with Planning Center-oriented workflows, progress/action data models, permissions/user flows, API surface, migrations, and test coverage.

What exists

Real church operations SaaS product with an actual customer path.

Progress tracking, Planning Center alignment, action queues, nonlinear discipleship pipelines, and ministry-operator workflows.

Evidence surface includes 141 API routes, 140 test files, 44 database migrations, approximately 68k effective lines of code, and deployed product/demo paths.

What it proves

Applied systems survive real workflow pressure.

Users, permissions, records, database migrations, operational flows, deployment, and a warmer customer-facing product surface.

Technical proof is not only UI polish: it includes auth/roles, relational state changes, operational workflow modeling, integration-oriented product direction, and testable server routes.

STRONGEST PROOF status: in use

The Journey OS

Real church operations SaaS product with an actual customer path.

This is the applied product proof: real workflows, church operators, permissions, data changes, and production deployment pressure.

Product evidence includes Planning Center-oriented direction, a deployed customer path, 141 API routes, 140 test files, 44 database migrations, and roughly 68k effective lines of code.

status: in use
routes: 141
test files: 140
migrations: 44
effective_loc: ~68k

Open product ->

RESUME

Conventional view for faster evaluation.

Founder and agentic systems builder focused on autonomous software delivery, runtime control surfaces, and applied AI products. Current work centers on Millrace and The Journey OS.

Highlights

Built Millrace, an agent-native Python runtime for autonomous software delivery.
Uses Millrace and Codex to build and ship custom church software through The Journey OS.
TalentBoard profile lists a 9/10 AI fluency assessment and public proof-of-work context.
Works across spec engineering, system architecture, orchestration, QA, and product direction.

Skills

Agentic engineeringAgent-native infrastructureSpec engineeringSystem architectureAutonomous orchestrationContext engineeringWorkflow engineeringPythonPydanticPytestTyperWatchdogCodex CLI

Open TalentBoard ->

CONTACT

Pick the route that matches the decision.

Contact routing lives here only, so the homepage stays focused.

Strategic collaboration / investment

Send the context, what leverage you bring, and the decision you want to make.

Open route ->

Applied systems consulting

For AI-native workflows, automation architecture, and agentic systems that need to be inspectable and durable.

Open route ->

TJOS inquiry

For churches and ministry operators who want a clearer action layer on top of existing records.

Open route ->

Hiring / conventional review

Use the plain resume path or external TalentBoard profile for faster evaluation.

Open route ->