// about

Amar Jaleel

Software Engineer

I am a software engineer and a computer science student at Sukkur IBA University. I got tired of projects that look finished in a screenshot and started building ones that have to keep working after the demo — which turns out to be a completely different job, and the one I find interesting.

Most of my work sits where implementation quality decides whether something is real: a field-reporting platform an organisation depends on daily, a security tool that refuses to call a fix verified until it has re-run the scanner inside a container, a controlled study that ended up publishing a correction against its own headline result, and a mesh protocol whose page says plainly which parts have run on a phone and which have only run in a simulator.

I would rather show the gap than hide it. Every project on this site carries the status it has actually reached, the evidence behind it, and what it does not do — and the build fails if any of those references stop resolving.

Studying
Bachelor of Computer Science — Sukkur IBA University
Since
Aug 2023 - Jun 2027
Based in
Pakistan · remote-friendly
Upstream
6 merged pull requests across 6 repositories
Amar Jaleel
Open to Work

// how i work

Problems where implementation quality is the whole problem

Each of these points at work you can open and disagree with. That is the test I would want applied to anyone else's version of this section.

  1. Decide where trust stops, then enforce it structurally

    The most useful thing in a system is usually a line: what is trusted, what is not, and what is allowed to cross. Drawn well, that line is enforced by the architecture rather than by everyone remembering — a language model that cannot raise a verification level no matter what it says, a preview path that never executes the scene it is rendering, a role hierarchy that lives in the data model instead of in the client.

  2. Treat a fix as a hypothesis until something checks it

    A dependency bump is not a proven fix, a passing simulation is not hardware behaviour, and a scanner finding is not an exploit. The interesting engineering is in producing the evidence: re-running the scanner inside a container after applying the change, tracing data flow rather than matching a pattern, or freezing an analysis script before the first result row exists so the number means something.

  3. Design for the failure mode, not the happy path

    Offline messaging is a scheduling problem, not a request. Automated remediation has to survive a package that breaks the build. Field staff lose signal mid-report. Getting these right means deciding in advance what the system does when the assumption behind it stops holding, and then saying so in the interface rather than quietly showing success.

  4. Make results reproducible, including the inconvenient ones

    Methods frozen before the run, an analysis script committed before the first result, a reproduction that re-derives every number from frozen artifacts at a named commit. That discipline is what let a forensic re-analysis overturn my own headline finding and publish the correction against the original rather than quietly editing it.

  5. Shipping is part of the engineering, not a step after it

    A tool that only runs on the author's machine has not been finished. Packaging a CLI for npm, keeping a scanner adapter honest about the tools it needs, running content validation and a production build on every push — the deployment path and the maintenance story shape the design, so they are decided with it rather than bolted on.

// judgement

Four decisions, with what they cost

Read from the case studies rather than written for this page. A decision without its trade-off is a feature list, so the cost is the part in amber.

CortexWard

A model is never allowed to be the evidence

Decision
Language models participate in the pipeline as a source of hypotheses, but model judgement cannot raise a finding's verification rung. Only concrete analysis — graph reachability, taint tracing, sandboxed execution — can.
Why
A fluent, confident and wrong explanation is the characteristic failure of model-assisted security tooling. Making the ladder structurally unreachable by a model means that failure cannot silently become a verdict.

What it cost

The tool is far more conservative than an LLM reviewer and will leave findings at a low rung that a model would happily call exploitable.

KnowledgeGuard

Freeze the analysis before the first result existed

Decision
Methods were written and the analysis script — including its out-of-sample action-selection rule — was committed before the first result row was produced.
Why
In-sample selection of the best action guarantees a positive headroom even under a true null. Fixing the rule in advance is the only way the number means anything.

What it cost

A pre-registered analysis cannot be improved after seeing the data, so a better test that becomes obvious later has to be reported as exploratory.

Emergency Mesh

Label the in-app mesh demo as a simulation

Decision
The application includes a demo screen that replays a simulator run as an animated topology, explicitly labelled as simulation, and it drives the same routing code the real path uses.
Why
A demo that looks like live mesh traffic when it is not would misrepresent the project to exactly the people most likely to be impressed by it.

What it cost

The most visually convincing screen in the app is the one that carries a disclaimer.

VeriPatch

Refuse to verify yarn and pnpm projects rather than guess

Decision
Scanning supports npm, yarn classic, yarn berry and pnpm lockfiles, but verify and update replay fixes with npm only. Yarn and pnpm projects are explicitly refused instead of being attempted.
Why
Replaying an npm fix into a yarn or pnpm lockfile risks corrupting it. Refusing is honest about the tool's reach; attempting it would trade a clear limitation for a silent one.

What it cost

A large share of real projects can be scanned but not verified, which is tracked as open work rather than presented as solved.

// right now

What I am actually working on

Derived from project and research status, so nothing stays here because a paragraph went stale.

  • CortexWard

    Pre-alpha — verification loop running

    Can an agent pipeline confirm that a reported security finding is real, and that a proposed fix removes it, instead of emitting unverified findings?

  • Emergency Mesh

    Active development — transport and protocol built and tested

    Can phones relay messages for each other over BLE reliably enough to be useful when there is no internet, no cell service and no server?

  • SCAR-OS

    Current FYP — Research & Architecture Stage

    How should voice and intent-driven interaction be integrated into a developer-oriented operating environment?

  • SceneForge

    Active development

    Turns a JSON manifest of HTML/CSS/JS scenes into a single MP4, scene by scene. Headless Chrome renders frames, FFmpeg composes them, and a React/Monaco editor drives it. Runs entirely locally — no cloud APIs, no uploads.

  • CS Learning by Game

    Active development

    AI-powered computer science education engine — an interactive automata theory (DFA/NFA) visualizer with step-by-step simulation and gamified mission progression.

  • Portfolio

    Active development

    This site. A content layer with an integrity gate that fails the build on a bad reference, a WebGL engineering core that degrades to a real 2D fallback, and a Supabase-backed client enquiry flow.

Education

Education & Training

Academic Journey

Aug 2023 - Jun 2027

Bachelor of Computer Science

Sukkur IBA University

Focus on software engineering, security and applied AI

Apr 2020 - Oct 2022

Intermediate (Pre-Engineering)

Government Degree College Thari Mir Wah

Pre-Engineering with Science subjects

Grade: A

// working with others

Upstream, and in the open

Open-source collaboration

6 merged pull requests into codebases maintained by other people, across 6 repositories, with 1 still open. Reading an unfamiliar codebase well enough to change it safely — under someone else's review and standards — is the part that transfers directly to a team.

See every contribution →

Research and the final-year project

One completed controlled study that published a correction against its own headline result, plus research-driven engineering and systems experiments at earlier stages. SCAR-OS, my final-year project, is at the research and architecture stage — a proposal, not an implementation, and the research page says so.

Read the research →

// supporting evidence

Selected credentials

11 in total — 9 Google, 2 Udemy. They are supporting evidence, not the argument; the engineering above is what I would rather be judged on.

  • Google Cybersecurity Professional

    Google · Nov 2025

    Verify ↗

  • Google Data Analytics Professional

    Google · 2025

    Verify ↗

  • Google AI Essentials

    Google · Aug 2025

    Verify ↗

  • Python Bootcamp: Master Python with Real-World Projects

    Udemy · Jun 2025

    Verify ↗
All 11 credentials →

// get in touch

What I am open to

  • Software engineering roles and internships

    Product, backend, mobile or tooling work where correctness and maintenance matter as much as the first release.

  • Security and developer tooling

    Static analysis, verification pipelines, CLIs and anything where the job is making an unclear signal trustworthy.

  • Applied AI and research engineering

    Retrieval systems, evaluation harnesses and experiment design — including the unglamorous half, which is making a result hold up.

  • Open-source collaboration

    Reading an unfamiliar codebase well enough to change it safely, under someone else's review and standards.

Start a conversationbanbhanamarjalil@gmail.comGitHubLinkedIn
Product · AI · Security · Systems