Problem observed from both sides
Origin in compliance and regulated operations
As part of my compliance work at BDT, I used World-Check and related sources to support reviews of existing and prospective relationships. The work included watchlist screening, adverse-news research, and documenting potential compliance or reputational concerns.
Years later, Apollo brought me back to a related workflow from the operator’s side. As the owner of an export-regulated manufacturer, I ran customer searches against the U.S. Consolidated Screening List, captured screenshots, and saved each record manually.
At BDT, I had seen the consequence of institutional review. At Apollo, I felt the friction of performing and documenting a recurring control myself.
From workflow knowledge to working software
The initial product concept was broad: a more usable research and screening tool that could eventually support compliance analysts and other investigative professionals. Building the application narrowed the problem. The difficult part is not simply returning names from lists; it is reducing the work between a possible result and a defensible decision.
I use AI-assisted development tools, including Codex and Claude Code, to translate that workflow knowledge into working software and tested behavior.
Matching and review workflow
Implementing name matching
Names do not behave like clean database keys. A useful system has to account for aliases, nicknames, transliteration, cultural differences in name order, incomplete biographical data, and small spelling variations without overwhelming the analyst with noise.
Working through those problems changed my understanding of the product and gave me a concrete appreciation for the technical depth hidden behind a familiar screening interface. Altira gives the user control over search behavior and source selection rather than treating every screening context as identical.
Designing around the analyst’s decision
Altira groups likely duplicate hits at runtime so an analyst does not have to review the same person repeatedly simply because several sources contain related records.
The Review surface turns unresolved work into a visible queue. An analyst can see what remains, continue where a prior session stopped, document the disposition, and open a durable decision record afterward.
ExpandThat is the part of screening I care most about. The result list is not the end product. The end product is a decision that another person can understand later.
ExpandProduct and system decisions
Product and technical development
My role spans product direction, domain-workflow design, interface and data-model decisions, and technical implementation.
Altira runs on Cloudflare Workers, D1, and R2. The architecture keeps its operating footprint small during product development while supporting matching, review queues, and durable decision records.
The product remains deliberately focused on the work between a possible match and a documented decision rather than treating every screening context as identical.
Current stage and external validation
Current stage
Altira is functional and in active development. It has not yet undergone external user testing or commercial validation; those are the next stage of work.
Structured demos with experienced practitioners will test whether the workflow reduces review burden, where matching still creates noise, and what evidence teams need to preserve. Those conversations will test product assumptions that internal development cannot.
Product decisions still being tested
Building Altira has required decisions about the initial user, the part of the workflow that deserves the most depth, and the boundary between a flexible platform and a focused product.
Those decisions are still in progress. External testing will determine which assumptions hold.