Configuring an intelligence and authoring platform to a corporate investigations firm's subject-check workflow, automating retrieval, triage, translation, and drafting while keeping every claim traceable to its source.
Corporate Intelligence Advisory Firm
8/1/2026
Analysts spent the bulk of a subject check on mechanical work: running the same searches across registries, litigation records, and news archives, translating non-English results, triaging what was relevant, and reformatting findings into the house report template.
A configured deployment that automates retrieval, screening, and drafting beneath the researcher, built on three design commitments established in discovery: every claim traceable to source, comprehensive coverage with a clean fallback to manual work, and the researcher in control of all final output.
Engagement
Design Standard
Status
Acceptance
A corporate intelligence firm runs subject checks: given a person or company, establish who they are, what they are connected to, and whether anything in the public record should concern the client. The judgment in that work is genuinely expert. Most of the hours are not.
Analysts spent their time running the same searches across corporate registries, litigation records, and licensed news archives, translating non-English results, deciding what was relevant, and reformatting the survivors into a house template. We were engaged to automate that layer without touching the judgment sitting on top of it.
Client: A corporate intelligence and advisory firm conducting cross-border subject checks.
Engagement: A phased engagement: a fixed-fee discovery producing a blueprint and scoped plan, followed by a build against real research subjects. Currently in build.
Diligence research looks like a retrieval problem and is not. Three properties make naive automation actively dangerous here:
The output is an assertion about a person. A summary that is 95% right is not 95% useful. A fabricated or mis-attributed claim in a diligence report is a liability, not an inconvenience.
Coverage cannot silently degrade. A researcher who does not find something needs to know whether it is not there or whether the tool did not look. A system that quietly returns less than it should is worse than no system, because it produces false confidence.
Sources are uneven. Registry data quality varies by jurisdiction, much of the source material is not in English, and some sources are licensed with terms that constrain how their contents may be processed.
Discovery produced three pillars that governed everything built afterward.
Verifiable. Every claim traces to its source, with an end-to-end audit trail. The researcher controls all final output. Nothing reaches a report because the system asserted it.
Comprehensive. Search scope is human-defined and deterministic rather than left to a model’s discretion, the agent framework is extensible as new checks are added, and there is a clean fallback to manual work at every step. The researcher can always see what was searched.
Ergonomic. Retrieval, triage, translation, and formatting happen underneath the researcher rather than in front of them. The system’s success condition is that the analyst spends their time on judgment.
The build is organized in priority tiers, so that core capability lands before anything speculative.
Core. A web-scan agent handling link collection, relevance pre-screening, human selection, and cited-fact extraction. A follow-up research agent that accepts researcher-specified queries and returns recorded sources with per-claim citations. A registry table generator producing correctly formatted tables for direct insertion into the firm’s report template. A prose composition tool that drafts in the firm’s house style from extracted facts.
Intended. Subject-match estimation and topic grouping for sharper link screening, registry search agents with API integrations where sources expose them, bespoke screening skills for a subset of the firm’s standard checks, and a formatting-review module checking output against the end client’s requirements.
Exploratory. Originality sorting of scan results, bespoke skills across the full set of standard checks, and a fact-checker for researcher-authored content.
Tiering the build this way meant that the questions we could not answer in advance, chiefly which sources would expose usable APIs, changed what got built rather than whether the engagement succeeded.
Discovery surfaced a set of questions that most retrieval projects discover late and painfully: whether subject data from certain jurisdictions may lawfully be processed by US-hosted models, how much of a licensed full-text source may be processed and retained, and which registries expose APIs rather than requiring scraping.
We treated these as gating conditions rather than implementation details. Each affected source is resolved before it enters the build. This is slower at the start and considerably faster than discovering mid-build that a core source cannot be used the way the architecture assumed.
The engagement is in build, working against real research subjects with demonstrations at fixed intervals and researcher feedback collected throughout. Acceptance rests on a measured before-and-after comparison of researcher time on the automated workflow against the manual process, which is the number that determines whether the firm proceeds to production deployment.
We proposed that measurement as the acceptance criterion. A time study that comes back unconvincing is a real possibility, and the client should have that information before committing to a deployment rather than after.
Client identity, data sources, and implementation specifics are withheld under confidentiality.
