← All posts
Week seventeen · September 3, 2026

Selected Files, Additional Doubt

This week I implemented two new Toolforest toolkits. One connects selected files in Google Drive. The other retrieves prediction-market data from Rothera.

This week I implemented two new Toolforest toolkits. They have almost nothing else in common.

The first connects Google Drive. The second retrieves prediction-market data from Rothera.

One helps me collaborate across several Google accounts without opening those accounts to general exploration. The other gives my forecasting process another source of probabilities to question. In both cases, the limits are part of the feature.

Google Drive, but only the parts I selected

I collaborate with several people across a few different projects. Each project has its own Google Workspace, shared by everyone working on it. The files are already organized where they belong: each project’s documents live with that project.

The complication is that I work across all of them. A specification for one project may live in one Google Workspace, while a research memo for another lives in a different one. The files do not need to be moved between projects, but I do need to be able to work with all of them.

Most chat clients make this awkward because their bundled Google Drive connectors generally connect to a single Google account or request broad access to that account. Neither fits the way I work.

The Toolforest Drive toolkit lets me connect the Google account I use for each project and specify which account an operation should use. Codex or Claude Code can create or read a file in the appropriate project’s Google Workspace. A file created through Toolforest remains within Toolforest’s permitted set, so I can return to it later from another supported client without moving it into my personal Drive or out of the project’s shared environment.

If the file is a Google Doc, Sheet, or Slides presentation, the existing Toolforest Docs, Sheets, and Slides toolkits can work with it directly. Those toolkits also support multiple Google accounts, so I can perform the format-specific work in whichever project’s Google Workspace contains the file.

More importantly, access is picker-scoped.

Connecting an account does not give Toolforest permission to search the entire Drive. The user selects particular files or folders through Google’s file picker. Toolforest can then work with those selected files, files created through Toolforest, and folders approved as destinations.

Approving a folder as a destination also does not make its existing contents available for inspection merely because they are nearby.

This was the distinction I cared about. I wanted the convenience of working across accounts. I did not want the model to treat every file in them as assigned reading.

A model writing a project specification needs the source notes, the current specification, and somewhere to save the result. It does not also need access to every spreadsheet, employment document, and mysteriously named PDF accumulated in Google Drive since 2018.

The account is explicit. The accessible files are explicit. The destination is explicit.

This is boring infrastructure, which is usually the kind that ends up being useful.

Rothera, or one more reason to move a forecast by two points

I have also added a Rothera toolkit.

I have become a bit of a forecasting centaur on Metaculus, or at least I believe that is what we now call a human working alongside an LLM. In my case, the other half mostly lives inside ChatGPT. Through Toolforest, ChatGPT retrieves the question and its resolution rules, draws on other toolkits for evidence, and helps me construct the forecast. For continuous questions, I express my view as ordinary percentiles. The Metaculus toolkit converts them into the cumulative probability distribution the platform expects and submits it.

The judgment is still mine, and so is the score. ChatGPT helps test the assumptions and assemble a coherent distribution; Toolforest handles the translation and entry. This leaves me more time to be wrong about the future rather than the API.

A prediction-market price is not the answer to a forecasting question. The contract may resolve differently. The closing date may be different. The participants may have different information, incentives, or legal constraints. Occasionally the market is simply quiet.

It is still evidence. More precisely, it is a compact expression of other people’s beliefs under a particular contract, with money attached.

Rothera gives the models another place to look. The toolkit can search its markets, retrieve market details and histories, identify recent movers, inspect trading activity, and retrieve contract terms.

When I checked the feed on September 2, it contained 252 active political contracts, including state and individual congressional-district races. One contract on Republicans winning Pennsylvania’s 8th congressional district had moved from 0.41 to 0.31 across two stored daily observations.

That is not enough evidence to lower a forecast by ten percentage points. It is enough evidence to ask what happened.

The distinction matters because the Rothera data consists of end-of-day settlement marks, not a live order book. Volume and open interest matter. A price of 0.50 might reflect a real mark on a day without trading, or it might represent a contract with no market at all. The surrounding fields tell the difference.

Missing data and genuine uncertainty should not be treated as the same thing merely because both can appear as 0.50.

The interesting question now is whether Rothera contains contracts that are not available from the other prediction-market sources I use. A new source is not necessarily new information. Frequently it is the same event wearing a different URL.

But its coverage of state and district races suggests that a systematic comparison may turn up useful differences. I want to compare catalogs, contract terms, liquidity, and price histories before calling any market genuinely unique.

For a Metaculus question, the resulting process might look like this:

  1. Find the closest contracts across the available venues.
  2. Read the contract terms rather than relying on similar titles.
  3. Record the price, timestamp, volume, and open interest.
  4. Compare the market’s resolution rule with the Metaculus rule.
  5. Ask why the venues or other evidence disagree.
  6. Only then decide whether my forecast should move.

The models help conduct the investigation. They do not get to average several vaguely related prices and call the result calibrated.

Two toolkits, one preference

Google Drive and Rothera initially look like unrelated additions. One deals with collaborative documents and the other with election probabilities.

Underneath, they reflect the same design preference: context should be explicit and inspectable.

For Drive, that means knowing which account, file, and folder a model can access.

For Rothera, it means knowing which contract produced a probability, when the price was recorded, what kind of price it was, and whether anyone was actually trading.

Neither toolkit should merely announce that it found something relevant.

Toolkits are supposed to remove API plumbing without laundering away the underlying ambiguity. A file permission remains a permission. A market price remains a price under a particular contract. The model can reason over both, but it should not be allowed to forget what they are.

I am not trying to build an assistant with access to everything. Everything is mostly irrelevant and occasionally confidential.

I am trying to make the few relevant things easy to select, easy to use across models, and difficult to confuse with the truth.

The Drive and Rothera toolkits are now available in Toolforest. I expect the most useful feedback will concern the edge cases, particularly the ones that become obvious immediately after something breaks.

As always, ideas and suggestions are welcome at gerrit@toolforest.io.