AI-Native Systems Architect

AI-Native Systems Architect

I build production systems
you can open today.

Commerce ERP across 15+ countries. eBPF kernel telemetry. ShardGuard supply-chain scanner. Urdu/Punjabi STT. PyTorch DataLoader. Free public Tax. Every project has a live URL or open repo.

Abdullah Hanif — SonarQube Cloud verified · 4/4 Passed · Security A ×4 · ~38k LOC Live scores ↓
See my work Get in touch
Abdullah Hanif

About

I left formal studies to ship real systems

Abdullah Hanif Xero Sphere AI Tax

I'm Abdullah Hanif — an AI-Native Systems Architect. No CS degree. I stopped sitting in classrooms so I could spend every hour designing, deploying, and keeping production up.

I built core systems for Xero Sphere AI — a commerce ERP for restaurants and pharmacies that runs multi-currency and multi-tax across 15+ countries. I also shipped a free public Tax engine, elite-ebpf-telemetry (kernel telemetry + sched_ext #1202), ShardGuard (supply-chain scanner), EchoVox (Urdu STT), fbloader (PyTorch DataLoader), cd-ub-hunter (CompDiff Contabo wrapper), and a WhatsApp order engine as my own separate product.

I work AI-native: agents accelerate the build. Architecture, schema, deploy, cost ceilings, and production behavior stay mine.

Systems architect

Schema to VPS — drove it to a live link.

Measured under load

1M products, 5 cashiers, p95 50ms on 1 vCPU.

SonarQube Cloud verified

Abdullah Hanif — ~38k LOC analyzed. Security A ×4, quality gates Passed. Live dashboard

Featured work

What I've shipped

Every project has a live URL. Click through — the proof is the product itself.

Flagship Live Multi-currency

Xero Sphere AI

Commerce ERP for restaurants and pharmacies — billing, inventory, CRM, loyalty, compliance, delivery, and public orders. Multi-currency and multi-tax across 15+ countries.

Marketing App demo Tax (free) CRM Loyalty

Problem

Shops ran disconnected POS, stock sheets, delivery apps, and tax tools that didn't share data — most stacks assumed a single currency and market.

What I built

Unified ERP on Node.js + SQLite WAL, custom web clients, bare-metal VPS deploy — multi-currency and multi-tax across 15+ countries.

My role

Lead developer. Solo-built v1 in under five months. Architecture, deploy, and production firefighting.

Proof

Live products you can click. Load-tested to 1M products; cold search p95 50ms with 5 parallel cashiers on 1 vCPU.

0 Countries
0 Products tested
0 p95 search
0 HTTP errors
Xero Sphere AI Marketing site Tax engine Tax (free)

Built inside the same stack

POS-linked
Customer CRM

One register inside the ERP — credit, visits, spend, invoice history. Every POS sale auto-updates the record.

Open CRM
Pairs with CRM
Loyalty Program

Points on every sale, earn/redeem at checkout, full ledger. Balance on the customer profile.

Open Loyalty
Free / public No account MIT

Xero Sphere AI Tax

Free multi-country tax engine — GST, VAT, sales tax across 16 country packs. OpenAPI quote, history verify, daily rates from a secure AI agent. No signup required.

Open Tax Docs Calculator

Open source sprint

Three production repos. One day. Verifiable proof.

I set a 24-hour goal: ship three open-source tools at production depth — not demos. I started with deep research (eBPF observability stacks, PyTorch data pipelines, Urdu/Punjabi STT gaps), picked the fastest path for each workload, then ran heavy test suites until assertion matrices passed. All three folders were created the same day, pushed to public GitHub under my name, and backed by reproducible benchmark scripts anyone can re-run.

PS> Get-Item 'flat buffer','stt','elite' | ft Name,CreationTime

Name         CreationTime
----         ------------
flat buffer  8/19/2026 8:37 AM   → fbloader
stt          8/19/2026 5:33 PM   → EchoVox
elite        8/19/2026 9:29 PM   → elite-ebpf-telemetry

My brand. My architecture. My benchmarks.

These repos ship under Abdullah Hanif — research direction, system design, test gates, deploy scripts, and what the assertion matrices prove are mine. That is not the same as rewriting every library from scratch.

elite-ebpf-telemetry builds on CO-RE eBPF and Go exporters. EchoVox patches whisper.cpp. fbloader extends PyTorch's DataLoader. AI agents accelerated drafting; I did not pretend to hand-write libc, the kernel, or Whisper from zero — and anyone who expects that in a one-day sprint is asking for something unrealistic.

elite-ebpf-telemetry · EchoVox · fbloader

Folder timestamps + public GitHub repos + open benchmark scripts — verifiable proof it's my work. Not a claim that I reinvented the stack.

Measured constraints — not excuses

Dell Latitude E7470 · Windows 10 · 8 GB RAM · often ~1.4 GB free with Cursor open. One laptop — no desktop build box. Queue / cheaper Cursor models; agents flop and hang; I kill processes or restart to reclaim RAM. This machine is a bad place for heavy local AI coding. That is the point: under those conditions I still cleared SonarQube Cloud on four public repos (4/4 Passed · Security A ×4 · ~38k LOC) and open assertion suites — three in a one-day sprint, cd-ub-hunter with its own Contabo gate. Engineers read that as process under pressure — not as a discount brand.

Third-party verification

Abdullah Hanif — SonarQube Cloud verified

These numbers are not self-reported. Per Sonar’s own docs, a quality gate answers one question on the main branch: “Can I release my code today?” Passed means the analysis met the gate conditions. Failed means do not push to the next step. There is no skip-scan checkbox. Badges below pull live from sonarcloud.io — refresh tomorrow and they update if anything regresses.

What Sonar says a Passed gate means

Ready for release (main) · Ready to merge (PR) · Sonar way: Security A · Reliability A · Maintainability A · hotspots reviewed

Sonar also publishes Sonar way for AI Code — AI-assisted drafts get the same independent engine, not a free pass. When assertion matrices + Sonar gates pass, the approach is no longer vibes — it’s a path a manual engineer or an AI-assisted engineer can re-run. Sonar does not care who typed the code. It cares whether the gate conditions hold. Trusted by 7M+ developers; enterprises use these gates as release blockers.

4/4Quality gates passed
ASecurity (all repos)
AReliability (all repos)
100%Hotspots reviewed
~38kLines analyzed

elite-ebpf-telemetry

31k LOC · Go, JSON
elite-ebpf-telemetry quality gate passed elite-ebpf-telemetry security rating elite-ebpf-telemetry reliability rating elite-ebpf-telemetry maintainability rating
MetricRatingIssues
SecurityA0
ReliabilityA0
MaintainabilityA36
Hotspots reviewed100%—
Duplications0.6%—

Last analysis: Aug 28, 2026, 9:22 PM

EchoVox

1.7k LOC · Python
EchoVox quality gate passed EchoVox security rating EchoVox reliability rating EchoVox maintainability rating
MetricRatingIssues
SecurityA0
ReliabilityA0
MaintainabilityA0
Hotspots reviewed100%—
Duplications0.0%—

Last analysis: Aug 20, 2026, 2:22 PM

fbloader

3.1k LOC · Python
fbloader quality gate passed fbloader security rating fbloader reliability rating fbloader maintainability rating
MetricRatingIssues
SecurityA0
ReliabilityA0
MaintainabilityA3
Hotspots reviewed100%—
Duplications0.0%—

Last analysis: Aug 20, 2026, 2:52 PM

cd-ub-hunter

2.7k LOC · Shell, Python
cd-ub-hunter quality gate passed cd-ub-hunter security A cd-ub-hunter reliability A cd-ub-hunter maintainability A
MetricRatingIssues
SecurityA0
ReliabilityA0
MaintainabilityA0
Hotspots reviewed100%—
Duplications0.0%—

Last analysis: Aug 28, 2026, 1:01 AM · Project section ↓

SonarQube Cloud dashboard — Abdullah Hanif org abdullahhanif-001, four projects all Passed with Security A
SonarQube Cloud — Abdullah Hanif (abdullahhanif-001). Four public repos Passed — sprint trio (Aug 19) plus cd-ub-hunter (Aug 27).

Open live SonarQube Cloud dashboard →

Open source eBPF K8s + bare metal Apache-2.0

elite-ebpf-telemetry

Zero-instrumentation kernel telemetry — one agent per node, under 1% CPU. CO-RE probes plus Phase B: forecaster policy syncs to a pinned BPF map and drives a custom XDP mitigator — kernel-level closed loop, not userspace-only JSON.

GitHub Benchmarks Chaos proof Phase B proof Sonar A SCX evidence Case study
Quality gate passed Security A Reliability A

Problem

Sidecars burn ~500m CPU per pod; log shippers add more overhead. Most observability stacks miss socket-level physics metrics.

What I built

CO-RE eBPF probes → Go exporter → Prometheus + OTLP. Phase B (Aug 28): SyncPolicyToBPFMap → /sys/fs/bpf/elite/policy → XDP mitigator. One-click ./install.sh or Contabo proof suite.

Proof

Aug 19: 50k TCP flood, PM2 131→131, RSS 124.7 MB. Aug 28 session: 4 commits, 32 new files, 38 Go unit tests pass, SPEED_PASS + closed-loop gates on VPS evidence.

Honest limits

Active work on sched_ext #1202 — upstream PR withdrawn, issue not closed. Public ./install.sh download de-emphasized until SCX ships. kernellatency probe excluded on kernel 6.8+ (symbol mismatch).

0 TCP flood test
0 PM2 restarts
124 MB Peak RSS

Current focus — sched_ext #1202 (Sep 2026)

RT tasks monopolize a CPU → sched_ext watchdog false-stalls and disables the BPF scheduler. Layer 3 scx_rt_guard fix verified on kernel 6.19-rc7 + CONFIG_SCHED_CLASS_EXT=y. Upstream merge pending — eBPF one-click install paused while SCX polish continues.

DeliverableEvidenceResult
RT-guard BPF interceptor (Layer 3)contrib/sched-ext/bpf/scx_rt_guard.bpf.hGates pass on 6.19-rc7
Matrix H1–H12docs/evidence/scx-1202/VERIFICATION_20260903-012848/12/12 PASS
Upstream PR #3780sched-ext/scxWithdrawn — dev continues
Public eBPF download./install.shPaused while SCX upstream polish

Source: SCX#1202 evidence · IMPLEMENTATION_STATUS.md

Comparison: Elite vs sidecar observability

Istio sidecarOBIRetinaElite
Per-pod overhead~500m CPU000
Socket physics metricsNoPartialPartialYes
One-click deployNoHelmHelm./install.sh
OTel nativeVia meshYesProm onlyYes

Source: BENCHMARKS.md · HARDENED_PROOF_REPORT.md

Phase B upgrade — 4-hour session (28 Aug 2026)

Same repo, not a new project. Folder update ebpf created 4:08 PM PKT → pushed to elite-ebpf-telemetry main. Userspace predict JSON upgraded to kernel BPF map + XDP closed loop.

PS> Get-Item 'update ebpf' | ft Name,CreationTime

Name         CreationTime
----         ------------
update ebpf  8/28/2026 4:08 PM   → elite-ebpf-telemetry Phase B
DeliverableEvidenceResult
4 commits / 32 new files+1,982 lines on mainShipped
XDP mitigator + policy BPF syncbpf/xdp_mitigator.c, policy_bpf_sync.goKernel closed loop
Go unit testspkg/forecaster/...38 PASS
Speed gates S0–S5Contabo VPSSPEED_PASS
Real closed-loop + H11Live predict metricsREAL_CLOSED_LOOP_PASS
eBPF X-Ray X1–X8Local proof artifacts8/8 PASS (see report)
Full VPS orchestrationContabo re-runDocumented — some gates pending full VPS replay

Source: PHASE_B_VPS_PROOF_REPORT.md · EBPF_XRAY_REPORT.md

Open source SAST Supply chain 12 languages Apache-2.0

ShardGuard

SCSP engine — multi-file obfuscation and hidden supply-chain scanner across twelve languages. Unfolds encoding chains, flags invisible unicode tricks, follows cross-file taint to exec sinks. Offline triage HTML report — no account, no hosted upload of your source.

GitHub Docs site Benchmarks Rice bounds Case study

Problem

Supply-chain attacks hide payloads across files — zero-width unicode, base64/zlib chains, shards assembled at runtime. String-match scanners miss them until the payload executes.

What I built

Zero-dep Python CLI (pipx install shardguard). Universal IR lift → cross-file taint → P0–P3 finding tiers with Z3 env-gate proofs. Outputs offline SECURITY_REPORT.html, SARIF, JSON, ZIP.

Proof

97.14% recall on 35 incident fixtures (Tiers A + H). 49 gate suites (shardguard gate g0…g48, world-beat, universal). Typical per-case scan ~220 ms.

Honest limits

Static analysis — VM obfuscators and dynamic import(expr) out of scope. Leaderboard run had Semgrep SKIP on all cases — not a live head-to-head yet. Sonar not configured on this repo.

0 Fixture recall
0 Incident cases
0 Languages
0 Gate suites

Capability: ShardGuard vs typical SAST

npm auditSemgrep (typical)ShardGuard
Cross-file obfuscation shardsNoPartialYes
Unicode / zero-width near sinksNoPartialYes
Encoding chain unfold (depth ≤3)NoLimitedYes
Offline HTML triage reportNoNoYes
Zero hosted uploadN/ACloud optionalYes (local)

Source: BENCHMARK_LEADERBOARD.json (2026-09-02) · Semgrep/npm_audit/trivy were SKIP in captured run — fixture corpus only

Gate attestation summary

GateThresholdVerify
G9 CampaignTier-H recall ≥95%, Tier-I FPR ≤2%shardguard gate g9
G12 Perfp95 scan <5s per caseshardguard gate g12
G14 OSS benignFalse-positive rate ≤1%shardguard gate g14
Universal suiteG17–G32 IR + taint + ASVSshardguard gate universal
Full matrixG0–G48 + world-beatshardguard gate all

Source: gates.py · RICE_BOUNDS.md

Open source Urdu/Punjabi STT whisper.cpp MIT

EchoVox

Production offline STT for Urdu, Punjabi (Shahmukhi), and Urdu-English code-switching — patched whisper.cpp with adversarial CI and field-tested acoustic patches.

GitHub Audit report Benchmark Sonar A Summary
Quality gate passed Security A Reliability A
0 Assertions
2.27% Latency CV
0 Gurmukhi leaks

Audit assertion matrix (Mythos ASR)

AssertionMeasuredGateResult
Gurmukhi Guard0 / 700PASS
Zero-Drop (short audio)0 empty / 700PASS
Latency CV (10K soak)2.27%< 2.5%PASS
Memory drift0.031%≤ 0.5%PASS
FD/handle drift0== 0PASS

Market RTF benchmarks: run benchmark_stt_market.py yourself — I don't paste simulator numbers here.

Open source PyPI MIT

fbload / fbloader

High-performance PyTorch DataLoader — WebDataset tar shards, optional DALI, uint8 batches until GPU normalization. Cross-platform, spawn-safe, drop-in.

GitHub PyPI Sonar A
Quality gate passed Security A Reliability A
0 Backends
0 Step soak
0 FD leaks

Benchmark: fbload vs stock PyTorch DataLoader

10k-step soak on real JPEG tar shards. Both loaders: pin_memory, persistent_workers, prefetch_factor=2.

MetricfbloadPyTorchGate
ThroughputHigher (uint8)Baselinefbload ≥ baseline
RSS drift≤ 0.05%Varies≤ 0.05%
FD leak00== 0
Throughput CV< 2.5%Not gated< 2.5%
Contiguity100%100%100%
Ctx-switch growth≤ 1.15×Not gated≤ 1.15×

Source: benchmark_soak.py · test_mythos_hardening.py

Security research deploy

cd-ub-hunter — CompDiff on Contabo. Verified, not vapor.

Production wrapper for compiler-differential UB hunting — pinned upstream CompDiff (ASPLOS'23), tarball packaging, and a formal Phase 1–3 verification matrix on a live Contabo VPS. Default speed-2 profile runs gcc -O0 vs clang -O3; I own the deploy pipeline, isolation gates, and test harness — not a greenfield fuzzer rewrite.

PS> Get-Item 'new hunter' | ft Name,CreationTime

Name         CreationTime
----         ------------
new hunter   8/27/2026 6:12 PM   → cd-ub-hunter

Folder proof · public GitHub · production scorecard

Local folder new hunter created 27 Aug 2026, pushed to abdullahhanif-001/cd-ub-hunter. Contabo verification recorded 2026-08-27 UTC: VERDICT=READY, MOCK_PCT=0, PM2 co-tenancy guard held at count=6.

SonarQube Cloud on the owned wrapper (~2.7k LOC, vendor excluded): Quality gate Passed · Security A · Reliability A · Maintainability A · 100% hotspots reviewed. Live badges pull from sonarcloud.io.

GitHub · Scorecard · Test plan · SonarCloud

Open source CompDiff speed-2 Contabo

cd-ub-hunter

One-click CompDiff wrapper for Contabo VPS — tarball deploy (cd-ub-<sha>.tar.gz), systemd caps (CPUQuota 50%, MemoryMax 2.5G), PM2 guard, and a three-phase test matrix with zero mock rate on production evidence.

GitHub Scorecard Contabo evidence Pack script Sonar A
Quality gate passed Security A Reliability A Maintainability A
READY Verdict
0% Mock rate
3/3 Phases PASS

speed-2 profile — dual-compiler differential oracle

CompilerFlagsRole
gcc-O0Baseline compile
clang-O3Optimized compile
Oracle outputR 12 11 10 vs R 10 11 12PROGRAM_UB

Source: speed-2.json · contabo-verification-2026-08-27.md

Pack & deploy — one tarball, one-click run

StepCommand / artifactGate
Packbash deploy/contabo/pack.sh → cd-ub-2b2cdd3fa31f.tar.gzPM2 mutate grep FAIL
Shipscp → install-from-tar.shWipe confirm required
Runbash scripts/oneclick/cdub-oneclick.shsystemd caps enforced

Source: pack.sh · README.md

Phase 1–3 verification scorecard (Contabo production)

PhaseCheckResult
1T1.1 dual-compile oraclePASS — PROGRAM_UB
2PM2 / nginx / mongo isolationPASS — guard count=6
2Resource capsPASS — MemoryMax 2.5G
3Independent oracle re-runPASS — differential reproduced
3Triage pipelineTRIAGE_OK

Source: SCORECARD.md · TEST_PLAN.md (15 formal checks)

SonarQube Cloud — cd-ub-hunter (owned wrapper only)

MetricRatingIssues
SecurityA0
ReliabilityA0
MaintainabilityA0
Hotspots reviewed100%—
Duplications0.0%—

Last analysis: Aug 28, 2026, 1:01 AM · Live dashboard →

Own product Not Xero Sphere Android

WhatsApp Order Engine

My own product — not client work, not part of Xero Sphere AI. Native Android stack for shop order-taking on WhatsApp without Meta Cloud API billing.

Case study

Process

How I work

Four phases before anything ships. Not a slogan — this is how Xero Sphere AI got built.

Precision under constraint

Limited hardware and a tight build budget are design requirements. Xero Sphere shipped in under four months on lean cloud spend. Unit economics matter: invoice-scan at ~$6 per 10k invoices, build spend ~$100 in tooling, production on a ~$6/4vCPU VPS sized for 30+ clients.

  1. 01

    Map every role before code

    Split into customer UI, manager dashboard, admin control. Walk end-to-end flows for each — what they click, what data they touch, where the loop can break. If the role map is wrong, everything downstream is expensive.

  2. 02

    Hunt competitor pain, cut token waste

    Read negative reviews on competing tools as if they were my outages. On AI features: zero wasted tokens — AI only on high-impact paths, local backend for the rest. Heavy fuzzy search stays off the POS hot path.

  3. 03

    Pick the stack for load, not trends

    Node.js for I/O-heavy APIs, SQLite WAL with real cache budget, custom web frontend. Android + NDK for the WhatsApp engine. C/Rust where a path must be fast. Tool for the load, not for the trend.

  4. 04

    Bare-metal deploy, then stress it

    Failure drills: bad inputs, mock API failures, bot hammering, prompt-injection abuse. Linux VPS via SSH, tarball releases. Then measure: Playwright + load scripts against 1M products on 1 vCPU. Target hit: cold search p95 ~50ms with five parallel cashiers.

Approach

Idea to live link

Give me a workable idea — I drive it to a public URL on real infrastructure. Not a deck. Not a Zap. A system you can open.

Why no n8n / Make / Zapier for SaaS

I know the no-code stack. For demos and one-off glue, it's fine. For JSON-heavy, long-lived products: workflows break silently, version poorly, and hide failure modes. Invoice lines, tenant scopes, tax modes — that's not a Zap. I write services, version them, and deploy under SSH.

VPS deploy. Hot paths in C or Rust.

Bare-metal habits: Linux VPS, process managers, tarball releases, measure under load. Node and Python for I/O-heavy and extraction. When a path must be fast — tight loops, parsing — I push toward C or Rust. Same rule: tool for the load.

AI-native by default

I build with AI agents as the default accelerator — draft, explore, refactor speed. Architecture, schema, deploy, cost ceilings, security boundaries, and production behavior stay mine. If it ships, I can explain and defend it.

Engineering notes

Case studies with numbers

Not marketing copy — measured results from production work.

WhatsApp orders without Meta Cloud API fees

My own product — not Xero Sphere AI, not client work. Separate codebase, separate ownership.

Usual path

Teams burn months on Meta Cloud API verification, then pay per-message for basic order flows. For a Pakistani restaurant on WhatsApp, that cost is real.

What I built

Native Android APK: Notification Listener, NDK on the hot path, voice STT, Order Mode vs Friend Mode, parallel chats. Orders push into the shop backend — a stack I own.

Result

Orders on ordinary Android hardware. No Meta verification gate. Message cost: $0. Independence from Meta's monetization for day-to-day orders.

Honest limits: Needs a dedicated shop phone, OS permissions, and ops discipline. I don't claim unlimited free WhatsApp — I claim a production order path without Meta Cloud billing on that pipeline.

Why SonarQube Cloud on a 24-hour sprint

Abdullah Hanif — SonarQube Cloud verified. Third-party static analysis — not my spreadsheet. Live org dashboard

Self-reported claims

Anyone can paste "production ready" in a README. No rules engine, no hotspot review gate, no public audit trail.

What Sonar says Passed means

Per Sonar docs: on main branch the gate answers “Can I release my code today?” Sonar way expects Security / Reliability / Maintainability A and reviewed hotspots. AI-assisted code is held to the same independent engine — Sonar way for AI Code exists because drafts don’t get a free pass.

My sprint result

4/4 Passed on SonarCloud. Security A on elite-ebpf-telemetry (31k), EchoVox (1.7k), fbloader (3.1k), and cd-ub-hunter (2.7k) — ~38k LOC total. Three sprint repos shipped in one day; cd-ub-hunter followed with its own Contabo verification gate. Engineers should verify — that's the point.

Honest limits: Sonar measures static code quality, not runtime chaos (see eBPF proof for that) or STT accuracy (see EchoVox audit). Coverage was not configured on these repos yet.

eBPF chaos engineering under 50k TCP flood

From elite-ebpf-telemetry — my own open-source kernel telemetry agent.

Usual path

Per-pod Istio sidecars (~500m CPU each), separate log shippers, partial socket metrics. Deploy complexity grows with every new service.

What I built

Single eBPF DaemonSet (or systemd service) per node. CO-RE probes for socket latency, softirq, packet loss, TCP summary. One-click ./install.sh.

Result

50k TCP connect flood @ 5,143/s. PM2 restarts unchanged (131→131). Peak RSS 124.7 MB under 160M cap. Zero kernel panics.

Chaos load

50,000 connection attempts, 200 worker threads, target closed port (no PM2 overlap). Rate: 5,143 conn/s over 9.72s.

Resource under flood

CPU avg 0.017 cores (below 5% quota). Event drop rate: 0% logged. Memory peak 124.7 MB — under 160M cgroup cap.

Honest limits: Under max chaos, CPU slightly above 0.01 idle target (0.017) — still below 5% cgroup quota. Phase B X-Ray/W4 full Contabo orchestration re-run is documented in-repo; local gate artifacts pass, VPS master verdict tracks pending items honestly. Active SCX #1202 work — public install paused; see evidence bundle. Full reports: HARDENED_PROOF_REPORT.md · Phase B proof.

ShardGuard — thirty seconds to an offline triage report

From ShardGuard — SCSP engine for multi-file obfuscation and hidden supply-chain payloads.

What plain scanners miss

Zero-width unicode inside sink tokens, base64→zlib encoding chains unfolded across files, minified one-liners after deobfuscation, shards assembled at lifecycle hooks.

What I built

pipx install shardguard → shardguard scan . --open. Single-file HTML with filters, keyboard nav, Print/PDF, SARIF/ZIP export. Runs on your machine — no account.

Result

97.14% recall on 35 frozen incident fixtures. P0 PROVEN tier uses sound taint + Z3 env-gate witnesses. 49 reproducible gate attestations anyone can re-run.

Reproduce: pipx install shardguard then shardguard gate universal or shardguard scan ./path --depth universal --open.

Honest limits: Rice's theorem — no scanner proves absence of all bugs. VM-based JS obfuscators without dynamic execution are OUT_OF_SCOPE. Leaderboard captured with Semgrep SKIP — run head_to_head.py locally for live comparison. Sonar not configured yet. Full bounds: RICE_BOUNDS.md · BENCHMARK_LEADERBOARD.json.

EchoVox — 14/14 assertions on Urdu/Punjabi STT

From EchoVox — patched whisper.cpp for field deployment in Pakistan and the UK.

70 acoustic tests (14 utterances × 5 degradation conditions) + 10,000-step soak + 50,000-step infrastructure audit. All assertions passed: Gurmukhi script guard, zero-drop on short audio, latency CV 2.27%, memory drift 0.031%, zero FD leaks.

Honest limits: Market RTF comparisons use a simulator — run benchmark_stt_market.py on your hardware. Full audit: AUDIT_REPORT.md.

Five cashiers, one million products, one vCPU

Date: 3 Jan 2025. Branch 901. SQLite WAL, 64MB cache, DB ~946.5MB on 1 vCPU / 1GB RAM.

PASSED 5 users @ 1M products on 1 vCPU
UserSamplesp50p95max
Cashier 1251ms44ms58ms
Cashier 2251ms47ms47ms
Cashier 3252ms75ms77ms
Cashier 4252ms55ms69ms
Cashier 5252ms40ms50ms
Aggregate—2ms50ms77ms

WAL stress

5 background writes while 5 cashiers search. Writes: 5 txns, 0 errors. Search p95 under load: 100ms (gate ≤150ms).

Live browser proof

Playwright against app.xero-sphere-ai.com. POS prefix + FTS: PASSED. CSV export ~3.2MB: 2225ms.

I claim

  • 5-10 POS terminals on 1 vCPU @ 1M products
  • Prefix + FTS typeahead on POS
  • 64MB SQLite cache in production

I do not claim

  • Thousands of simultaneous writers
  • Heavy fuzzy search on every keystroke
  • Default SQLite cache on a ~1GB DB

Contact

Let's talk

Open to engineering roles, collaborations, and product discussions.

Hiring, partnering, or curious about production systems — email me.

abdullahmalik33782@gmail.com LinkedIn GitHub xero-sphere-ai.com