THE PROBLEM
A list of businesses
is only the beginning.
Registry records, place matches and company websites tell different parts of a story. This tool keeps those sources connected while helping me investigate potential employers and consulting prospects.
Built for Connecticut and New York.
The goal is regional research into potential employers and consulting prospects, starting with Connecticut’s public business records. New York is a planned expansion area; it is not part of the current registry dataset.
Current coverage · ConnecticutPlanned expansion · New York
Current CT towns: Darien, Fairfield, New Canaan, New Haven, Norwalk, Stamford, Weston, Westport and Wilton.
A SNAPSHOT OF THE WORK SO FAR
68,243CT registry records in the current database
9Connecticut towns represented
2,222Registry records with captured website text
Those research results contain 6,419 captured text pages and 9,298 stored source quotations.
Measured November 11, 2026 · 2:11 p.m. ET (19:11 UTC). This is a saved snapshot, not a live counter.
These are source and research records, not verified businesses, job openings or sales leads.
How these figures are counted
Registry totals count the latest stored observation for each source record in the Connecticut Business Registry. Towns follow the source’s address fields; they do not prove an operating location. The database contains no New York registry records in this snapshot.
Website coverage counts current registry records with at least one captured page containing text. For each record, page and quotation totals use its newest research result with useful text, rather than adding every attempt or overlapping town snapshot. Pages and quotations are not claimed to be unique across different records.
Capturing text does not verify company identity, current hiring or consulting demand. Source matches and model assessments still require review.
HOW IT WORKS TODAY
Real research.
An imperfect workflow.
This is still an evolving research system. I use ChatGPT dot to coordinate and operate the local software: prepare town datasets, start the right research batch, check progress and investigate failures. The pieces work, but the path from a registry record to a credible opportunity still has gaps.
MY ROLEScope & judgment
I set the geography and research goals, approve changes in scope, and review identity matches, source conflicts and shortlists.
dotCoordination & operation
dot uses the existing commands and review screens, checks which town and run are active, and verifies prerequisites before advancing. It helps reconcile interrupted work with saved state before a retry.
LOCAL QWEN MODELPage research
Qwen runs through Ollama on my Mac. A .NET controller supplies captured text and observed links; the model proposes pages to inspect and drafts evidence-linked assessments.
The local Qwen model and dot have different roles. Website-research inference runs locally; dot coordinates the tools and the wider workflow.
↘
From a town to a reviewable result
Prepare one town
Combine public registry observations with Places candidates, licenses and name history. Save source snapshots and reconcile counts. Suggested matches remain unconfirmed.
Build the research queue
Check backups, town scope and existing run state before queueing eligible saved website candidates. Missing, unsupported or shared-site candidates are retained as skips.
Read bounded public pages
Validate saved URLs, capture static HTML and let local Qwen choose from observed links. The current worker allows up to five page attempts and eight minutes per company.
Keep the evidence and the failures
Store pages, timestamps, source quotations and model proposals. Completed, partial, failed and skipped outcomes stay distinct. Checkpoints make recovery possible without discarding earlier work.
Review before acting
Inspect the sources and separate employer and consulting priorities. I make shortlist, defer or exclude decisions. The software does not send outreach or automatically confirm company identity.
THE UNFINISHED PART
Where the workflow still falls short
Coverage drops quickly.
Many registry records have no usable website match. Similar names and shared domains leave identity unresolved. A source address may be a billing address rather than an operating location.
Static browsing misses things.
JavaScript content, external hiring systems and changed domains can fall outside the current fetcher’s reach. Access refusals remain visible. A blocked page is not evidence of an inactive business.
A quotation is only a starting point.
Exact-quote checks establish that words occurred in a captured page. They do not establish freshness or justify the interpretation. Stale templates and contradictory careers copy still require human checking; research scores are heuristics.
The operating loop is still fragmented.
The UI reviews results and controls existing runs, while new batches and town transitions still use separate tools. Mac sleep, unavailable services and interrupted model calls can stall progress. Saved state helps recovery, but does not guarantee continuous operation.
The useful result so far is a growing, inspectable evidence base. The ongoing engineering work is to improve coverage and make the operating workflow simpler, while keeping uncertainty visible.
Evidence is not certainty. Source quotations and research scores do not verify identity, hiring or buying intent. Candidate matches and AI interpretations need human review. No outreach is sent.
Business intelligence architecture & details
Source adapters→.NET + local Qwen→PostgreSQL + review UI
C#/.NET services, Python adapters and PostgreSQL support a local browser workspace. Bounded website research retains captured pages, source quotes, model assessments and attempt history. Human shortlist, defer and exclude decisions remain separate from model output.