Skip to content
Milad ShaddelanAll work ↗

QALIB / PERSONAL ENGINEERING PROJECT / 2026

From requirements
to evidence.

I built a software-agent prototype that connects planning, code generation, executable verification, and recovery—with a place for the evidence behind a decision.

Explore the system Agent verification & recovery prototype
FartowerTask verification
ShieldProject assessment
41 / 41Selected component tests passed
2 replaysStored-evidence results reproduced

THE ENGINEERING QUESTION

What should happen after an agent says “done”?

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Read the evidence summary

STORED-EVIDENCE REPLAY / FIXTURE 4497

Same evidence. A fuller set of requirements.

MATCHER OUTPUTPASS

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.