I built a software-agent prototype that connects planning, code generation, executable verification, and recovery—with a place for the evidence behind a decision.
Qalib explored the machinery around that moment: which requirements belong to the task, which checks can run, what their outputs establish, and what happens when the result needs another attempt.
My contribution spans the workflow and its verification components: requirement tracking, a deterministic evidence matcher, structured findings, bounded repair, and evidence handoffs between services.
PythonFastAPIPostgreSQLRedisDockerpytest
01 / THE SYSTEM
A connected verification workflow.
Select a stage to see its role and the implemented components behind it.
Fartower
Match requirements to observable evidence.
Behavioral, regression, filesystem, and SQL paths produce evidence. A deterministic criterion matcher can return PASS, FAIL, or INCONCLUSIVE; unsupported criteria have an explicit unresolved state.
Architecture of the implemented prototype. Runtime activation and end-to-end reliability were not established for every path.
02 / THE DEVELOPMENT ARC
Five months of engineering decisions.
Reconstructed from the implementation and commit history, January–June 2026.
01
JAN 2026
Build a verifier beside the agent.
Fartower began with AI-assisted scenarios and behavioral evaluation. Python, browser, and HTTP testing expanded the kinds of generated software it could inspect.
02
FEB–MAR 2026
Connect the workflow. Bound the recovery.
I connected planning, task execution, QA reports, and project assessment. Repair deduplication, cycle caps, and a repair-of-repair guard made recovery an explicit part of orchestration.
03
APR 2026
Make expected behavior executable.
Behavioral contracts, subprocess execution, regression checks, and a validation gate brought commands, inputs, and outputs into the completion decision. Stored development runs created a record to inspect later.
04
MAY 2026
Track the requirement behind the verdict.
A deterministic matcher and requirement-provenance plumbing connected individual acceptance criteria to evidence. The matcher was implemented behind an activation flag that was off by default.
05
LATE MAY–JUN 2026
Carry evidence across services.
Filesystem and database checks added execution domains. Explicit per-criterion pass evidence gave Shield a way to consume Fartower results. A final local extension added a SQL assertion runtime using fresh SQLite databases.
The June 10 SQL extension is present in the inspected local commits; it was beyond the GitHub default branches checked on October 31.
03 / INSPECT THE EVIDENCE
Make the scope visible.
A retrospective component check and a replay of stored evidence, reproduced on October 31, 2026.
COMPONENT VALIDATION
41/41
Selected tests passed again.
Four targeted test files completed with zero failures, errors, or skips. Both frozen evidence fixtures reproduced their saved outputs.
These are component and replay results. Model accuracy, benchmark performance, and production reliability remain unmeasured.
All four selected criteria receive PASS from the matcher.
✓✓✓✓
4 PASS · 4 criteria in scope
Replays a recorded result. No live agent runs here. PASS is a matcher output, not an independent correctness label.
What the replay does—and what it establishes
The replay feeds saved execution evidence into the actual deterministic matcher. For fixture 4497, evaluating four selected requirements yields PASS; evaluating all nine provenance-required criteria yields INCONCLUSIVE. Fixture 3839 is INCONCLUSIVE under both scopes.
This illustrates how requirement coverage affects an aggregate verdict. It does not independently prove that each PASS establishes the entire requirement. A separate audit found matcher and repair edge cases, so the public claim is an implemented, tested prototype with an unfinished reliability evaluation.
WHAT I TAKE FORWARD
Verification is a systems problem.
Qalib gave me concrete experience building the contracts, execution paths, and recovery logic around AI-generated work. The lasting engineering question is how to carry requirements and evidence through the entire workflow without losing their meaning.
Project status
I paused development because LLM behavior was too unpredictable for the level of autonomy I wanted: unexpected decisions could cascade through the workflow and cause disruption. The prototype and its component results remain useful engineering work; full-loop reliability and comparative evaluation remained unfinished.