Asadullah Shafique

A timeout leaves a purchase outcome unknown. Retrying with a new operation key can duplicate a purchase while the controller still reports success.

Compare independent ledger checks, reconcile by intent before retrying, preserve a stable operation key, and enforce uniqueness at the tool boundary. Case 001 links to Agent Rehearsal for deeper offline controller evaluation.

30 tests passed with py -3 -X utf8 -m unittest discover -s tests (2026-10-19). The constructed fault produces two orders and AED 2,500 spent in the vulnerable run, versus one order and AED 1,250 in the repaired run. Deterministic, single-process SQLite simulation; no real purchases or production reliability claim.

Most 'clean architecture' demos import a web framework and an ORM on line one, which quietly makes the architecture untestable in isolation and the claim unfalsifiable. The interesting question is whether the layering actually holds when nothing external is propping it up.

Four layers with one direction of dependency: domain entities that validate themselves, an abstract repository interface, an in-memory implementation behind it, and a service layer holding the business rules. The console is a thin adapter injected at the composition root. Because storage is an interface rather than a database call, the whole application runs on the standard library alone - the dependency list is empty and that is the proof, not the marketing.

50 tests pass with no third-party runtime dependency. Auditing it surfaced two real defects the suite was already failing on: a task due today was rejected, because dates parse to midnight and were compared against the current time, so 'today' was in the past at every moment except midnight itself - while the error message claimed the present was allowed. And update parsed a due date but never validated it, so the rule enforced on create was silently skipped on update. Both are fixed, share one validation helper, and are pinned by regression tests computed relative to now() so they cannot rot the way a hardcoded date does.

Most agentic pilots in financial services die at the compliance review, not because the models are weak, but because a system that cannot show why it reached a conclusion cannot be signed off by a second line of defence. A control a model can argue its way past is not a control.

Three specialised agents, MarketAnalyst, ComplianceOfficer and WealthStrategist, on a fixed Plan-Act-Verify state machine rather than a conversation. Compliance is structural: no agent holds two of the three powers (market data, setting weights, rendering the verdict), and there is deliberately no graph edge from drafting a recommendation to approving one, so verification cannot be skipped under load or disabled by a flag. Shari'ah and regulatory principles live in a versioned constitution reviewed like code, and anything expressible as arithmetic is settled in Python with no model involved.

A full compliance screen runs in under 2ms with zero model calls, settling 8 of 14 principles by arithmetic, reproducible offline at no marginal cost. Every run writes a hash-chained, tamper-evident audit trail. 94 tests pass with no API key and no network, and the screening engine is deployed live and interactive, so every figure here can be checked in one click.

Agent teams usually let a model decide whether its own work is good enough to merge. A control a model can argue its way past is not a control.

Harness × Loop × Graph. Agents do the work: a spec-writer, a builder, four parallel reviewers (security, UX, UI, code) and an approver that writes a typed verdict.json. A deterministic router, board.py, applies the merge or rework rule from that verdict, not a model: its POLICY SEAM merges only when decision is merge, risk is low and tests_passed is literally true; anything missing, malformed or high-risk goes to rework or to a human. First app: neon-agent, a document-assistant backend on Neon (Postgres, Auth, Functions, Storage).

The security design was chosen by tests on a real database branch. Option A failed for a recorded reason: Neon refuses a non-owner role access to its auth schema, and the signing key cannot pass the connection pooler, so Option B shipped. Per-user isolation is enforced by Postgres itself through forced row-level security, every job branch gets its own credentials, and the old ones were proven rejected. As of 14 October 2026: 117 of 117 tests pass, the router's 14 of 14 pass, and a health API and a documents API are deployed to a development branch, checked with real sign-in tokens: a second user sees none of the first user's documents. The agent line itself is written but not yet run end-to-end.

AI chat and document ingestion on the documents API (embeddings, retrieval and cited answers). Nothing built yet.

Free AI and cloud learning programmes appear and expire quietly across many provider sites. A manual weekly check is easy to skip and hard to keep consistent.

Windows Task Scheduler fires a heartbeat every 7 days. A headless Claude Code agent searches the 10 tracked providers within a hard budget: at most 10 searches, 12 fetches and $2.50 per run. certloop.py then verifies the findings deterministically (every provider searched, at least 5 opportunities, all required fields, official https links, no duplicates) and rejects the run otherwise. A maker-checker pass drafts the week's README and enforces its structure, a plain professional tone and a 40-word sentence limit, for up to 6 rounds. Each week is appended to progress.md with every find tagged new or returning, then committed and pushed.

As of 14 October 2026 the loop has published 2 weekly runs (1 and 8 October 2026): 13 listings, 8 of them unique, both within budget (7 and 5 of 10 searches) and both passing the checker in 1 round. Providers with no official programme (xAI Grok, DeepSeek, Ollama) are recorded as such instead of being padded with third-party courses.

Local SMEs in Pakistan and the UAE have no unified digital storefront. Buyers juggle multiple platforms, vendors lack analytics, and enterprise clients need white-label flexibility, all three groups are underserved by existing solutions.

Bazaar unifies B2C retail (browse, cart, checkout, JazzCash, Easypaisa, Card) and B2B wholesale (RFQ engine, quantity-tier pricing, verified suppliers) into one platform. Architecture: multi-tenant Next.js 15 storefront, FastAPI microservices, Supabase BaaS for auth/realtime, local + Stripe payment gateways, vendor dashboard with analytics, and nightly recommendation jobs.

One codebase serves retail checkout and a wholesale RFQ engine. PKR-native, three languages (EN/UR/AR), local payment methods (JazzCash, Easypaisa) alongside cards. The live demo runs on seed data; there are no production sellers yet.

Pakistan's wholesalers run on stock registers, udhaar diaries and WhatsApp. The failures are specific: a sale noted but never deducted from stock, udhaar nobody chases until it is 90 days old, customers who keep buying on credit past any sensible limit, and corrections made by overwriting the page.

A bilingual (Urdu + English) inventory and khata platform where the database enforces the books. Every business sees only its own data, through one tenancy hook that scopes every query, write and AI tool. Sales and purchases post stock, weighted-average cost and khata in one transaction under a row lock. A double tap cannot post twice, mistakes are voided by reversal rather than edited, and udhaar sales stop at the customer's credit limit unless the owner approves. A collections desk ranks whom to chase, says why, and opens a Roman-Urdu WhatsApp reminder. Munshi AI, on the OpenAI Agents SDK, has five read-only tools and a deterministic constitution that blocks fake-invoice or tax-evasion requests before any model call.

142 backend tests, including two-business leak tests on every endpoint and PostgreSQL race tests: 12 concurrent sales of 5 units in stock sell exactly 5. These tests fail when the row lock or the tenancy filter is removed. Migrations round-trip on PostgreSQL in CI with no schema drift. The public demo costs nothing to host: the same UI serves the API from the browser on a port of the backend rules. No production customer yet; the backend is Docker-ready and deploys when one signs.

Fabric mills in Faisalabad, Gujranwala and Karachi run on Excel roll registers, paper yarn books and WhatsApp. The failures are specific: a roll issued twice, yarn stock that exists only on paper, an LC shipment accruing demurrage at Karachi port because nobody noticed it had cleared.

Module 1 digitises the roll register, yarn stock book and LC file on a multi-tenant FastAPI + PostgreSQL backend where the database, not staff discipline, enforces the rules. Tenant isolation is PostgreSQL row-level security, and the API runs as a role that cannot bypass it. Roll issues take a row lock, yarn stock moves only through an append-only ledger, weaving and knitting shifts post their yarn in the same transaction, and LC landed cost is computed server-side. Mill Pulse raises seven deterministic alerts (dead stock, yarn runway, port demurrage risk, loom quality drift), each showing the numbers that fired it.

42 backend tests run against real PostgreSQL as the least-privilege role, including a concurrent double-issue race that fails if the lock is removed. The public demo costs nothing to host: the same UI serves the API from the browser on a port of the backend rules, and produced identical figures to the real stack. No production customer yet; CMT billing, ledgers and financials are specced, not built.