From scattered information to decisions: how I built Frontier Grid

Reconstruct what the documents keep separate

Following projects meant working through announcements, presentations, regulatory filings and statements from their participants. Each document served a different purpose. An announcement described the eventual size; a regulatory filing, requested or authorized capacity; a contract, certain obligations. Sharing a unit of measurement did not make those figures equivalent.

Dates changed meaning too. First delivery, the start of operations and completion of every phase could appear close together while describing different events. Before calculating a delay or comparing two projects, I had to reconstruct exactly what was being promised and by when.

My main background is software development. I recognized a familiar difficulty: several components can be well described individually and still fail at their connections. Here, the interfaces included permits, supply rights, equipment, capital and responsible parties. The information needed to examine those connections was distributed.

I started by changing the unit of research. Rather than trying to understand an entire industry before acting, I bounded a question: whether a project could deliver its first phase, which condition still needed evidence or which document would support the next decision. That question helped select sources and stop searches that were no longer adding anything.

Build a working memory that can be reviewed

I began separating observations, candidates for investigation and reviewed records. A news item could open a lead; keeping it as a finding required reading the document, identifying the change and comparing it with what we already knew. The same company or project needed to retain its identity between reviews.

The record needed more than a URL and a summary. We kept the entity, asset, date, relevant passage, scope of the claim and state of the evidence. A fact confirmed by a source, our own inference, an unknown and two conflicting accounts needed different treatment.

Data analysis often began with small operations: reconcile units, separate final capacity from initial capacity, compare schedules and make assumptions explicit. When a figure was missing, we left a gap. Filling a table with an unmarked estimate would have made it easier to read and less reliable for a decision.

I developed pieces to preserve that structure: records and data models, a separate place for research before accepting changes, generated artifacts and tools for inspecting the material. Sources could support a case, a comparison or a brief. Human review determined what entered the durable record.

AI models help discover sources, read material, propose connections and prepare text. Software provides persistence, states and controls. Judgment still enters when framing the question, recognizing an invalid comparison or deciding that the evidence does not yet support moving forward. Each part needs a different kind of review.

The result was a set of coordinated capabilities for keeping questions, evidence and next steps. Some connections are automated; others require intervention. Keeping that distinction visible prevents us from attributing to the whole system something that only works inside one of its parts.

Kilby: turn an announced figure into a testable question

For Project Kilby, we fixed the question: could the fuel and generation path serve a first phase of the Microsoft campus within the announced 2028 window? The published brief has an evidence cutoff of July 28, 2026. I use it here to explain the work performed; its classification is not a new assessment of the project.

The first task was to separate three figures. Microsoft described approximately 2 GW of campus capacity over five to seven years. The commercial generation project was described as roughly 2.67 GW in phases. The permit application covered approximately 2.869 GW. A gigawatt measures power; these figures described different scopes.

That distinction affected the entire investigation. Treating 2 GW as the full demand at the first delivery date would have created a requirement different from the announcement. We had to define the first block that actually needed to operate and examine its conditions, keeping later expansion separate.

We then translated power into a fuel requirement. The model allowed us to vary plant consumption and additional headroom. Under the published assumptions — 8 MMBtu per MWh, 1.03 MMBtu per Mcf and a 10% allowance — a hypothetical firm supply of 300 million cubic feet a day would support approximately 1.46 GW. The units describe the conversion; the practical question is how much can run on the fuel that can be secured.

That was a calculated scenario. It did not establish that anyone had contracted the volume, that a pipeline could carry it or that the gas would arrive at the necessary pressure. The model helped size a phase; contracts and infrastructure had to demonstrate that the phase could receive the fuel.

The research followed that chain: supplier and route, transportation rights, pressure, the final connection, equipment, permits and commissioning. Proximity to a region with abundant gas helped explain physical plausibility. A project conclusion required specific checks that the public documents we reviewed did not resolve.

The result was Investigate. The package contained a brief, calculations with assumptions, a dependency map and a specific document request: selected route, firm rights, pressure study, connection schedule, equipment deliveries and the customer’s first phase. Those artifacts made it possible to continue diligence with precise questions. We have no evidence that the sponsor used the work or changed a decision because of it.

Keep the work moving between reviews

An assessment like Kilby leaves open questions. The next day, a permit, contract or statement may change only one part. Starting the investigation again consumes attention and can erase distinctions we have already established. Continuity became another product problem.

Vera is the agent and working environment we have developed on CLX, a dedicated machine. Its Runner preserves state and artifacts, executes bounded assignments and can review sources or follow a reply within delegated scope. That lets some work continue between sessions without relying on me to remember every pending item.

The useful unit is a case with a question, initial sources and a pending decision. The report must preserve findings, uncertainty and a next step. A sent inquiry needs to remain distinct from a received reply; a prepared draft, from a completed action. Those differences also belong in the software.

Integration remains partial. Vera’s social workflow does not automatically read our ChatGPT agenda or every current article. Changes in direction need to be incorporated into its context. Having an active agent does not mean every component always shares the same version of what we know.

How we allocate attention changed as well. Watches look for changes frequently; on Saturdays we concentrate decisions about what to investigate, hold or drop. Publishing became one possible output. A day without a sufficient finding can end without a post, and a week without a material change can leave a case on hold.

What building and using it taught me

The first lesson was to start with the decision. Many sources are of little use if we cannot say which difference would change the next step. At Kilby, defining the first phase kept the eventual campus size separate from its initial fuel requirement. It also made the information request more specific.

The second was to preserve differences between states. Filing an application, receiving authorization, contracting equipment and operating are different events. That discipline helps both infrastructure analysis and automation: preparing an email does not establish that it was sent, and recording it as sent does not establish commercial interest.

The third was to let failures change the process. The editorial workflow began requiring a commercial decision in every observation. That produced writing that was too compressed and contractual. We adjusted it to allow useful connections and early signals while keeping factual support. Publishing an observation and recommending a capital commitment need different thresholds.

I also learned to separate what tests establish from what needs use and judgment. We can test persistence, duplicates, retries and execution limits. Determining whether an interpretation matters, whether a decisive dependency is missing or whether a reader can use the result requires another review. More software controls do not automatically answer those questions.

What remains open

The research capability is better demonstrated than its commercial demand. We have produced cases, articles and tools; we are still validating which buyer needs that outside synthesis and when they would pay for it. Contacting someone or receiving public attention does not resolve the question. A specific request and use of the result would provide a different quality of evidence.

I do not work inside the energy industry or live in one of its centers. My technical background helps structure problems, but I have less everyday access to operating knowledge, relationships and informal conversations. A practitioner may immediately recognize a practice the documents never explain. The work needs that kind of scrutiny.

Public-source research has an important limit: the least documented condition may already be resolved privately. Identifying what a researcher needs to check does not, by itself, establish what is blocking a project. For Kilby, the requested private documents could change the classification; their absence from the reviewed record had to remain an uncertainty.

We have not defensibly measured hours saved, improved accuracy or an economic return for the complete system. Nor is everything integrated. Those remain evaluation and development tasks. Publishing this case shows how the work was done and what it produced while keeping visible the questions that need different users, data or access.

Where this work can help another business

The transferable part begins when a team returns regularly to a decision and has to reconstruct context to make it. They may be comparing suppliers, evaluating a location or tracking conditions in a contract. The difficulty appears when documents, conversations and updates do not keep what has already been checked together.

An engagement would start by choosing one of those decisions and examining how the team makes it today. What information they use, where they keep it, who checks it and what happens when it changes. That helps determine what should be connected, what needs a data model and where a person should continue reviewing.

The first result can be small and usable: an evidence file for one question, a comparison with explicit assumptions or a workflow that preserves state and next action. AI can help read and prepare proposals. The system should make it possible to return to the source and revise the interpretation when new information appears.

We can then test whether the result helps the team complete its review, notice a relevant condition or know what to ask next. Those observations would guide the next integration. At FG, developing the system and using it on specific cases revealed both its possibilities and the work still required.