Focused architecture, reliability, and security reviews for teams using AI-assisted development. We define a clear scope, trace system-level effects, and deliver prioritized findings, a remediation plan, and—when included—a reviewable pull request.
Early access · Scoped repo access · NDA on request · Team-controlled merge
A change can satisfy the immediate request and pass the available tests while still weakening an ownership boundary, duplicating lifecycle logic, or complicating cleanup and recovery. These are ordinary software risks; faster delivery makes careful system-level review more important.
Each coding session has limited context about the decisions and changes that came before it.
The workflow that produced a change may not reveal effects beyond its immediate scope.
Ad Actum adds a focused review of those system-level effects.
Each engagement begins with a defined scope. Findings are tied to the code and documented with their impact and limitations. When implementation is included, changes are delivered as a reviewable pull request.
Relevant paths, observed behavior, impact, and limitations. Each finding is supported by evidence in the code.
Confirmed findings become concrete next steps with acceptance criteria and a clearly defined implementation boundary.
Implementation can be included in the scope. Your team reviews the resulting pull request and decides what to merge.
A focused architecture and lifecycle review covering ownership, coupling, module boundaries, dead code, and structural hotspots.
A focused investigation of active bugs, races, stale state, data integrity, cleanup, and recovery behavior.
A focused review of authorization, trust boundaries, secret handling, fail-open controls, and concrete attack paths.
These representative examples show how a finding connects observed behavior, impact, and a bounded remediation path. Identifiers and scope are illustrative.
The record had no project or change-request identifier, so the canonical cleanup path could not reach it. Completed analysis runs left orphaned records behind.
Example remediation: add ownership fields and include the collection in canonical cleanup.
Parent resources enforced ownership, but child-resource queries used bare IDs without project scope. An authenticated user could reach data outside their project through multiple endpoints.
Example remediation: centralize ownership validation and scope service queries by project.
A shared-secret handler rejected query-parameter tokens while a privileged media endpoint accepted them. Tokens could leak through browser history, proxy logs, or referrer headers.
Example remediation: use Bearer authentication and reject tokens in query parameters.
Tell us about the repository, subsystem, change, or risk area you want reviewed.
Agree on one bounded area, the required access, and the questions the review should answer.
Trace the relevant behavior through the code, document findings, and record material limitations.
Receive the findings and remediation plan. If implementation is included, your team reviews the pull request and decides what to merge.
Repository access is limited to the agreed scope, secrets stay out unless explicitly required, and your team retains control over every change.
I started Ad Actum from a simple premise: generating a change faster does not make its consequences easier to understand.
Ad Actum reviews a defined part of a codebase, documents the risks that can be supported by evidence, and proposes concrete next steps. When implementation is part of the scope, the work is delivered as a pull request for the team to review.
The goal is not to replace engineering judgment. It is to make difficult changes easier to understand and review.
Tell us what changed or what has become difficult to reason about. We will define a narrow review scope before work begins.
Early access · scoped after review. NDA available. Secrets excluded unless explicitly in scope.