Agentic SQA
Verification that shows its work
Agentic SQA investigates pull requests in C codebases, finds likely defects and reports each one with evidence: the suspected failure mode, the affected code and the next step. Delivered through Foundry Verify in GitHub, with local verification through the uok CLI.
Security and data handlingAnatomy of a finding
Every finding answers four questions. What part of the change is risky. How it is likely to fail. Exactly which code is affected. And the evidence for it, claim by claim, tied to the exact lines.
Where investigation ends and verification begins
The agent investigates every change probabilistically. It reads the diff in the context of your codebase, its structure and its history, then forms a hypothesis about what could fail. That part is judgment, and we treat it as judgment: every finding carries its reasoning and its exact scope, so a maintainer can accept or reject it on the merits.
Generic review bots stop there. A general model can produce a plausible remark about any code, but the tools generating the code cannot credibly referee their own output. Plausible is not the bar in systems code.
That is why the next layer is deterministic. uok takes eligible claims from a review and checks them against the exact revision in the developer's own environment. Not every claim can be mechanically decided. When one can, uok returns PROVEN or REFUTED with supporting evidence. When one cannot, the verdict is NOT PROVABLE.
And when nothing clears the bar, the product says nothing. Calibrated silence is a design decision. Noise is a tax and we do not charge it.
What's live and what's next
Pull request
Your C change
Agent review
Reads the diff and context
Finding
Risk, failure mode, next steps
Local verification
Checks eligible claims with uok
Live todayLive today: agentic investigation, findings with evidence, check-run statuses, PR commands and local verification of eligible claims through the uok CLI.
Verify locally with uok
uok is the Agentic SQA command-line tool for checking concrete review claims against the exact code revision in your own environment. Run it from a developer checkout, CI job or coding-agent workflow and get PROVEN, REFUTED or NOT PROVABLE verdicts with supporting evidence.
curl -LsSf https://get.irlabs.ai/uok/install.sh | shLinux x86-64 and arm64, with Docker for other platforms. The CLI docs have the full matrix.
Manage it from one place
Every workspace includes a management console. Watch usage in real time, enable and disable repositories without touching GitHub, manage billing through Stripe and reach support directly. Reviews respect your plan limits and tell you when they pause.
Made for the hard layer
Kernel modules, device drivers, firmware, embedded targets and the C libraries everything else stands on. If your world has hardware targets, real-time constraints or a kernel tree in it, this was built for you.
Connect a repository in minutes. Reviews start on your next pull request.
Foundry Verify — updated for commit
1974591Caution
This change likely introduces a bug. If it does, the bug would be reachable now.
Summary
The change introduces an off-by-one bounds check in the
rocketpower_profilesysfs handler. A write ofprofilevalue3passesprofile > ARRAY_SIZE(rocket_power_profiles)and then indexesrocket_power_profiles[3], even though the array has valid indices0through2. This can read out of bounds when applying theprofileand can leave an invalidprofilestored for later show or core-init consumers if execution continues.What would trigger it
rocketdevice successfully initializes and exposes its device sysfs attributes.3to thepower_profilesysfs attribute.Evidence and checks
3.15-28definerocket_power_profileswith valid indices0, 1, and2, butprofilevalue3equalsARRAY_SIZE(rocket_power_profiles)and passes before indexingrocket_power_profiles[profile].rocket_sysfs.c:15-28profileindices exclude3.41-52define the invariantprofile < ARRAY_SIZE(rocket_power_profiles), soARRAY_SIZE(rocket_power_profiles)is not a validpower_profileindex.rocket_sysfs.c:41-5270-87parse unsignedpower_profileinput and pass it torocket_power_profile_apply, so writing"3"reachescfg = &rocket_power_profiles[3].rocket_sysfs.c:70-87Have feedback? Put it in a reply.