About
Navid Broumandfar
The person behind NAVIDBR. I build applied AI systems and publish the parts that make them inspectable: the workflow, the boundaries, the evaluation, and the gap that is still open.
What I work on
I turn repeated work into systems that can be inspected. The parts most AI demos skip are the ones I start from: the workflow behind the request, who owns it, where it hands off, which source is trusted, what proof gate the output has to pass, and the point where the system should stop and give the decision back to a person.
How I work
Three things in order, and every record on this site is built against them. Before the model, there is the workflow: the repeated work, its owner, the source, the handoff, the failure path, and the decision that needs to become legible. Before autonomy, there are boundaries: what the system may read, change, refuse, log, escalate, and leave for explicit human review. Before product, there is proof: a visible artifact, a narrowed promise, a reliability path, and an honest account of what is not live yet.
What this site is
NAVIDBR is the name of this site and of the system behind it. Applied AI Systems is the category: business pressure translated into systems, data shape, AI boundaries, and products. The site itself is static. It runs no answer system, connects to no private notes or accounts, and keeps nothing about a visitor. Every reading page carries exactly one small script, for progressive enhancement and sound, plus a single block of JSON-LD metadata where the page has structured data; the page reads in full with that script switched off, and the build enforces exactly those two elements and nothing else.
What I am not claiming
The records here are prototypes, labs and proof records, and each one carries a status label saying which. None of them claims a client, revenue, production traffic, or operational maturity. Where a number is weak it is published next to the number that made the work look better, because a result that only holds on cases I wrote myself is not a result.
Facts
-
Focus
Workflow design, source boundaries, data shape, agent behavior evaluation, and the product judgment between a demo and a working system.
-
Path
Business, then systems, then data, then AI, then products.
-
Current stage
Still a data science master’s student shipping prototypes, not enterprise deployments yet.
Common questions
Where should AI fit inside our current workflow?
Start with the repeated work rather than with the model. Name its owner, the sources it depends on, the handoff, the judgment moment, and the way it fails today. The notes set out that order, and the two CaseOps records show it applied to document work: one prepares and validates the source material, the other reasons over that evidence with citations, validation and a written escalation rule. Where AI fits in a specific company depends on context this site does not have, so that part goes to direct email rather than to a page.
Can Navid help with an AI roadmap or integration strategy?
The public record is the honest basis for that. Work holds seven records across governed data preparation, grounded AI review, behavior evaluation, agent operations, visibility evidence and ML product discipline, and each one carries a status label and a section saying what it does not prove. That record supports reading a workflow, naming the boundaries a system needs, and setting the proof gate before anything is built. It does not support a claim of client outcomes, revenue or production maturity, because no record here claims one. Scope for a specific company is a direct conversation rather than a page.
What has been built, and what is only planned?
Built is what carries a record with a link you can open. Work lists seven, each under its own status label: two CaseOps proof records, a behavior evaluation lab, an operations lab, a continuous integration gate demo, a released visibility engine and an ML product prototype. Each record names its stage in plain terms, including a repository frozen as a portfolio piece and a release process that runs ahead of its test surface. Anything without an artifact to open is not listed here, and nothing on this site is presented as a deployment.
What would a safe first AI product pass look like?
Narrow it until one workflow, one source boundary and one reviewable output are left, then decide what would count as proof before anything is built. Give the system a stop condition and a named moment where a person approves, keep the sources it may read explicit, and write the behavior cases that would catch a failure. The notes on boundaries and on when a prototype should stay a prototype set out that order, and the Agent Gate Demo shows the failing half in public: a pull request blocked because the agent claimed tests it never ran. Regulated, legal, medical and financial decisions are outside what a public page should answer and belong in direct review.
Contact
Work for proof, Notes and Letters for the thinking, email for anything direct.