Between the two of us, we have more than forty years in law enforcement. Sean served more than twenty years and retired as a senior detective, twelve of those years in a tactical detective unit conducting covert investigations, surveillance and intelligence gathering. He later led corporate investigations across Europe, Asia, Central America and South America. Ron spent twenty years with the Herndon Police Department, six of them specializing in cybercrime and digital forensics, including an assignment to the U.S. Secret Service Cyber Fraud Task Force.
Different paths, same lesson: a finding is only as good as your ability to show where it came from. In ODIAN, that principle takes a practical form. Every finding carries its source, and every report includes the methodology behind the work.
Two perspectives at the same table
We bring different experience to this work, and ODIAN is better for it. Sean oversees Global Traveler's investigations and complex security programs, so he sees the work from the client's side: what someone needs in hand to make a decision, and what they'll ask before they trust it. Ron designed and built ODIAN, so he sees it from the evidence side: how information is collected, verified and protected.
A good example of how that works is a concept paper Sean wrote, laying out how a law enforcement investigations unit could put ODIAN to work. He handed it to Ron with a simple ask: decide what stays, refine it, and work out the technical framework. That gave us a concrete use case to build against instead of an abstract one.
The problem worth solving
Finding information is only part of the job. The harder question is whether it supports the decision the client actually has to make, and whether you can answer when someone asks, "How do you know that?"
We didn't want to build a system that hands people a pile of search results. We wanted ODIAN to deliver a finished report: what we found, where each finding came from, why it matters, and what to do next. That became the core design rule, and almost every hard decision since has come back to it.
Bringing it to life
Sean's concept prompted development work on link analysis and timelines, ways to see how people, companies and events connect rather than just collecting them. Those are ideas we're still developing, not capabilities we'd promise a client today. When we prepared to meet with an agency, Sean also put together the questions we expected about records reviews, personal information, health information and around-the-clock coverage. Questions like those are worth answering before a client has to ask them.
Sean has also used ODIAN on real casework himself, and he wrote client materials for it, including an overview of ODIAN's security, staffing and integration. Having the person who runs our investigations use the platform and explain it to clients keeps us honest about what it does well and where it still needs work.
Check the tool before you trust the result
One lesson came straight out of forensics. Before you interpret an unexpected result, check whether the tool, rather than the source, explains it. A timeout or an access error does not, by itself, support any conclusion about the subject. It tells you about the collection attempt, not about the person or company you're researching.
So ODIAN is built to keep those two things apart. It distinguishes a failed page request from a finding, and when a page can't be reached directly, it can fall back to an archived copy. It sounds like a small detail. In an intelligence product, it's the difference between reporting what the evidence shows and reporting what went wrong with your own software.
AI output still needs evidence
ODIAN uses AI to help analyze findings and draft reports. That's a real advantage when you're working through a large volume of material. But a confident, well-written sentence is not a substitute for supporting evidence, and in due diligence that distinction matters a great deal.
So the reporting is built around the evidence, not the prose. Findings are collected in a register, every finding carries its source, and the report writer is instructed to ground its statements in that register. Each report includes its methodology and a list of sources, so a reader can trace a conclusion back to the material behind it.
We also had to protect the AI itself. A web page can hide instructions meant to trick an AI that reads it into doing something it shouldn't. So we built one checkpoint, and every request ODIAN's investigation platform sends to its AI has to pass through it. The checkpoint does two jobs. First, it scans the web content for hidden instructions like these. Second, it checks what we're about to send for sensitive details, such as Social Security numbers, card numbers and passwords. And because we believe a system like this needs one, there is also an emergency stop that can halt AI analysis across the whole platform.
Treating sensitive data like it matters
Investigations involve real people, and information that can hurt them if it ends up in the wrong place. Both of us have spent careers handling that kind of information, and we designed ODIAN on the assumption that the security around the data has to be as serious as the analysis.
Account and organization data is separated in the database itself, and case files are protected by server-side ownership checks. An automated weekly probe checks that the application's database role cannot bypass client isolation. Case records and reports are encrypted under a key dedicated to each client organization, and if encryption of a generated report fails, the plaintext is deleted and the report is withheld; publishing a client report is refused if it can't be encrypted. Case actions go into a hash-chained audit trail. Users must enroll an authenticator app for multi-factor sign-in before they can access data, and API access uses revocable tokens.
We also test our own assumptions through periodic internal security reviews. We track what they find and re-verify the fixes. Those reviews have taught us something about evidence, too. In one of them, a finding that looked serious on paper turned out not to exist when we tested it against the live system. A plausible concern still has to be tested before you call it a finding. That's true in a forensic exam, it's true in an investigation, and it turns out it's true when you're auditing your own software.
Sources change, and the platform has to change with them
Sources don't stand still. Government lists get reorganized, websites change their structure, and every source comes with its own availability and licensing requirements. Maintaining ODIAN includes repairing source integrations when those things change. It isn't glamorous work, but a lot of the value in a platform like this lives there.
People stay in the loop
For all the automation, ODIAN doesn't replace investigators. It gives them a much stronger starting point. Reports are released to clients only by Global Traveler staff, and the people behind Global Traveler bring backgrounds that span intelligence, federal law enforcement, investigations and security.
Holding ourselves to the same standard
When we rebuilt this website, we did something we'd recommend to any company that sells technology. On October 17, 2026, we checked the ODIAN claims we wanted to publish against the live system, and narrowed them to what that review supported. Where something wasn't fully accurate yet, we rewrote it or left it out, and put the work to close the gap on our list. It made the marketing a little less flashy. We're comfortable with that.
It's the standard both of us worked to for our whole careers, and it's the one we built ODIAN around: if you can't show where it came from, you don't get to call it a finding.
What's next
We're continuing to harden the platform, preparing for an independent SOC 2 audit, and extending the same thinking to individuals and families through ODIAN Shield Services, now open to a limited number of early clients. If you'd like to see what a sourced, decision-ready report looks like, request a briefing or read more on the ODIAN page.
Sean L. McManus is the Chief Executive Officer of Global Traveler LLC. Ronald H. Eicke Jr. is its Chief Technology & AI Officer, and designed and built ODIAN.