Commercial data is only useful when it fits the mission, the workflow, and the environment where analysts operate. Casey Fallin draws on experience supporting special operations forces and joint government teams to help Grist Mill customers translate complex mission problems into data requirements they can act on.
In this Q&A, Casey discusses how to evaluate commercial data, why technical fit matters as much as the content itself, and what government buyers often miss when funding analytics and artificial intelligence programs.
You have supported analysts and operators in special operations and joint environments. How does that experience shape the way you approach customer problems and evaluate the usefulness of commercial data?
It was a privilege to work alongside special operations forces early in my career. That experience taught me two foundational lessons: become an expert at the basics, and execute the mission creatively as a team. I bring both lessons to my work at Grist Mill when approaching customers’ problems.
The most rewarding part of my job is seeing commercial data deliver a useful insight in a joint operational environment while still meeting the analytic standards and rigor analysts expect. If teams can use that data at operational speed, at an unclassified level, and share the resulting analysis with partner organizations and allied forces, we have demonstrated real mission value.
Government customers do not always arrive with a neat data requirement. How do you translate a broad or messy mission problem into the data that could help answer it?
I start with the reality that time and money are finite. Government teams have complex missions and limited resources, so the goal is not to assemble the longest possible list of datasets. It is to define the problem clearly enough to identify the capabilities that could change the outcome.
That requires us to work backward from the mission. What decision is the customer trying to make? What information is missing? Where does the current workflow break down? What could the team realistically acquire, integrate, and use with the people, systems, and budget it already has?
I also think in ranges. If the customer could acquire only one new data capability, which one could have the greatest effect? If the team could acquire three, how would they complement one another? Would a broader mix of data create useful corroboration, or simply add noise? Those questions turn a broad problem into a practical data strategy.
What separates an interesting dataset from one that will hold up in a real mission workflow?
Designing actionable commercial data solutions for mission workflows requires both an understanding of the customer’s technical capacity for data and their system’s ability to ingest and integrate data types into their workflows. One cannot have success without the other.
Raw sensor data in Parquet or JSON creates a very different burden from a curated analytical dataset delivered as a CSV. Both are different from an API that supports targeted queries against a large database. None of those options is inherently better. The right choice depends on the mission and the customer’s ability to ingest, store, process, and analyze the data.
I look at whether the team has data science and engineering support, whether noise needs to be reduced before delivery, how much storage is available, and whether files or an API make more sense. A dataset is actionable when the customer can absorb it into the mission workflow without creating a larger technical problem than the one the data is supposed to solve.
Understanding the customer’s data environment is non-negotiable. Data that cannot be integrated, interpreted, or sustained is not useful, regardless of how interesting it looks in a sample.
Where do commercial data vendors most often misunderstand the analyst’s job?
Analysts already have data. They already have established workflows, production standards, and evidentiary requirements. They are not looking for another data source simply because it’s new or different.
When an analytic team comes to Grist Mill looking to acquire commercial data, they want confidence that a dataset will fill a gap, help answer a real question, and improve the resulting analysis. That means vendors have to understand more than the content of their data. They need to understand how customers will evaluate it, how it can enter an existing workflow, and what an analyst must be able to explain about the source and methodology.
The vendors that do this well adapt their business and delivery practices to government workflows rather than expecting government teams to rebuild those workflows around a commercial product.
Your background spans intelligence analysis, cyber operations, and emerging technology. How do you think about trust, provenance, and uncertainty when commercial data informs consequential decisions?
Trust starts with knowing where the data came from, how it was collected, and where it agrees or conflicts with other sources. No single dataset should be treated as self-validating.
Grist Mill maintains breadth and redundancy across data sources so our customers can meet their data quality requirements for using commercial data to inform leaders or commanders in consequential decision-making. Our curation team works to ensure Grist Mill can offer multi-source and multi-domain data verification to establish trust of data quality. A financial record, geospatial observation, or other commercial source becomes more useful when a team can compare it with independent information from another source or domain.
Provenance is also especially important. First-party collection can be a strong indicator of reliability, but customers still need to understand the collection method, coverage, limitations, and potential gaps. Knowing how the data was produced helps analysts decide how much weight to place on it.
The goal is not to eliminate uncertainty, it’s to mitigate it. You do that by making uncertainty visible, testing assumptions against multiple sources, and giving analysts enough context to make a defensible judgment.
What recurring customer problem would you write about if you had a blank page tomorrow?
I continue to see three related problems. Government systems are operating with irrelevant or outdated data. Artificial intelligence and machine learning contracts are being awarded to vendors without a data budget to support the work. And organizations are spending their budgets on analytical platforms, only to find that they have no funding left for the data needed to populate the pipelines.
If I could write directly to contracting offices, I would make one recommendation. Contracts for analytical platforms and artificial intelligence modeling should be required to include dedicated data budgets that are delegated to end-user groups.