What three very different AI projects had in common

Picture three rooms. In one, editors are trying to make sense of a constant stream of public records. In another, researchers are comparing what a government agency was authorized to spend with what the public can actually trace. In the third, an executive team is deciding where artificial intelligence belongs in its work and where it does not.

At first glance, these look like three different assignments. One is a publishing platform. One is a public-data product. One is an executive workshop. But underneath the different formats, each project presented the same challenge: how do you use AI to expand what a team can do without weakening the judgment, sourcing and accountability that make the work credible?

That question has shaped much of our recent work at 3rd Space Project. The answer is not just better software; it is a better operating model.

Turning a firehose into a publishing system

The first project began with a familiar problem for anyone working around government or public policy. Important information was technically public, but it arrived through agendas, meeting records, attachments, fiscal documents and votes scattered across systems that were never designed for ordinary readers.

The goal was to build a publishing system that could collect that material, help an editorial team identify what mattered and present it to the public without turning AI into an unsupervised editor.

The resulting platform connects automated collection with a human newsroom. It gathers official records, organizes them for review and helps editors draft briefs from the underlying documents. Editors can comment, revise, approve or send work back before anything reaches the public. Source material remains attached to the editorial process, and consequential decisions leave an audit trail.

This distinction matters. AI can shorten the distance between a large pile of documents and a useful first draft. It cannot decide which facts deserve emphasis, whether a framing is fair or whether a claim is ready to publish. Those responsibilities remain with the people whose names and reputations are attached to the work.

The system was also designed for the less glamorous parts of publishing: subscriber consent, access controls, maintenance checks and safeguards that stop distribution when key services cannot be verified. These features rarely appear in an AI demo. They are also the features that determine whether a product can be trusted after the demo ends.

Following public money without pretending the data is complete

The second project started with a deceptively simple question: what was a public agency authorized to spend, and how much of that spending could be traced through information already available to the public?

It is tempting to begin with a government checkbook because the payments look concrete. However, a payment database tells only part of the story. It shows visible transactions, not the full structure of an agency's legal spending authority or every way money moves through a public program.

The project therefore began with appropriations rather than payments. Budget authority established the map. Public transactions, contracts, program records and other sources were then used to show which parts of that map could be documented and which remained obscured.

That approach produced more than a website. It created a repeatable research method. Before requesting additional records, the team can now work through a defined ladder of public sources, document what each source can support and narrow any remaining request to the information that is genuinely missing.

This is not just about saving time. A broad request for data often produces delay, confusion or a warehouse of files nobody is prepared to use. A precise request, built around a known gap and a prepared data structure, is much more likely to produce something useful.

Moving an executive team beyond the tool tour

The third project took place in a conference room rather than a codebase. A research organization wanted its staff to understand how AI could support serious analytical work without compromising accuracy.

Most AI workshops begin with a parade of products. Here is the chatbot. Here is the image generator. Here is the application that promises to summarize every meeting you have ever regretted attending. The problem with that format is that people leave knowing more product names but not necessarily knowing what to do on Monday morning.

This workshop began with the work itself. The examples came from documents, questions and research problems the team already understood. Participants examined how AI could help retrieve information, compare sources, analyze material and produce a first draft. They also examined where the tools fail, how errors accumulate across multi-step tasks and why polished language should never be confused with verified analysis.

The objective was not universal adoption. It was to give the organization a practical way to decide which uses were appropriate, which required additional review and which should remain off-limits. In that setting, governance was not a compliance appendix. It was the foundation for useful experimentation.

The common operating model

Across all three projects, the technology changed. The operating model did not.

First, begin with a real workflow rather than a tool looking for a purpose. The publishing platform began with the editor's need to move from official records to a defensible public brief. The financial tool began with the researcher's need to reconcile legal authority with visible spending. The workshop began with the executive team's need to evaluate risk and usefulness across the organization.

Second, preserve the source material. Every summary, classification and draft should lead back to the document or data that supports it. This allows a reviewer to check the work and makes it possible to improve the system without quietly rewriting history.

Third, keep human judgment at the point of consequence. AI may gather, organize and draft. People decide what matters, what is fair and what is ready to leave the building.

Finally, design for the day after launch. Access controls, audit trails, maintenance checks and clear ownership may not make for an exciting demonstration. They are what allow the system to keep working when the novelty wears off and the responsibility remains.

Beyond the AI demo

AI adoption is no longer limited by a lack of impressive tools. The harder problem is turning those tools into reliable systems that reflect how an organization actually works.

That requires more than selecting a model or buying seats. It requires understanding the source material, the decision points and the consequences of getting the work wrong. It also requires enough technical range to connect research, editorial judgment, software and organizational practice into one working system.

The three projects described here began in different places and produced different results. Their common lesson is straightforward: the most useful AI work does not begin with AI. It begins with a real problem, a clear standard of evidence and a team willing to remain responsible for what it produces.

That is the work we are building at 3rd Space Project.