Method: The futures library

People trying to think seriously about the future are stuck choosing between breathless hype and academic papers nobody has time to read. The futures library is our attempt at a third option: a plain-language, honestly-scored account of what credible foresight work actually says about where things are heading — checked against real track records, never presented as this project's own predictions or opinions.

What it produces

A set of subject files — artificial intelligence, climate, democracy and governance, and further areas beyond those — each written so someone with no background in futures studies can follow it. Alongside the subject files sits a companion guide to the actual toolkit of futures studies itself: the named methods (things like structured expert forecasting, scenario planning, working backward from a target future, and other established techniques), each one checked against how it's actually been used in practice, not just how it's popularly described.

How it works, step by step

Each subject file is written and extended by a person doing careful reading and judgment, not by an automated tool — this is close-reading work, not something we run mechanically. Every claim in every file is checked against a live source before it's written down: who originated the idea, what institution stands behind it, and at least one real-world case where it's actually been applied.

Every entry in every file carries a tag describing what kind of thing it is: a method usable right now (or by some future public process), a real institution worth potentially partnering with, a primer worth reading, or a living project or public figure worth tracking over time. The usable-method tag is the most common by design — the library favours things a reader can actually do something with over things that are merely interesting to know.

Each file keeps its own running log of verdicts on its own claims: cleared as checked and accurate, corrected with the old and new value both recorded, or still standing as an open question with a dated reason why. Beyond checking new material as it's added, the library periodically runs a full pass back over everything already written — not just spot checks — to make sure older entries haven't gone stale or been missed the first time around.

Every landed version of a file is preserved, so nothing is silently overwritten and changes can always be compared against what came before. And for the handful of entries that track a number that moves over time — things like a live forecasting-platform estimate or an official population projection — there's a maintenance schedule (some checked monthly, some yearly, some only when a specific triggering event happens) that has to be consulted before that number is ever used in a dated public statement. A live-moving figure is never cited from an old, unchecked date-stamp.

The library itself stays neutral research — it doesn't get turned into plain-language public material until that's a deliberate, separate publishing decision, and any citizen-facing companion built from it is a distinct downstream piece of work, not something authored inside the research files themselves.

How it's checked

The core gate is simple to state and expensive to run: nothing gets written into a subject file until it's been checked against a live source — who came up with it, what institution backs it, and a real applied case. Nothing sits un-triaged in the verdict log either; every claim ends up cleared, corrected with the change on record, or explicitly marked as still standing with a dated reason, never left in limbo. On top of ordinary review, the library runs whole-corpus re-verification passes rather than relying only on spot checks — one pass, for example, worked every claim across the original set of files to a final verdict (43 cleared, 10 corrected, 13 still standing, on a named date), and a later pass independently re-verified the most fast-moving subject files while giving newer files their first full pass. And no fast-moving figure — the kind that changes month to month or year to year — goes into a dated public citation without being checked against its own maintenance schedule first.

What it honestly costs

This is judgment work from start to finish — writing, tagging, and verifying every entry all require a person reading and deciding, not a script running in the background. As one data point: a single working session combining one lead reviewer and five independent verification passes completed a full check of the fastest-moving subject files plus a first full pass on several newer ones, all in the same session. That's one precedent from one session, not a standing rate you should expect every time.

The person ultimately responsible has to weigh in when the library's scope expands to new subject areas and before anything moves from internal research to public-facing material. Day-to-day verdict logging on individual claims doesn't require that same level of attention.

Known limits

The maintenance schedule for fast-moving figures is exactly that — a schedule, not an automatic alarm. Nothing proactively flags a stale figure; whoever picks up a file next is responsible for checking it against the schedule themselves before using it. A meaningful batch of newer entries were verified once at the point they were added, and while some have since had a second independent pass, there's no written rule yet for exactly when a second pass is required before an entry should be treated as being on equal footing with material that's already been checked twice. In short: some entries in this library have only been checked once. Live, fast-moving figures should always be re-checked against their current source before being cited anywhere, rather than trusted from an old date-stamp. And the same archive-at-capture discipline we use for the government atlas isn't fully wired up for the futures library yet — a batch of source links was staged for permanent archiving, but as of the library's own status notes, that archiving work hadn't yet been confirmed complete.

What stays internal, and why

The subject files and their verdict logs are themselves meant to be read by the public — they're already written in plain language as the actual intended output, not an internal draft of something else. What stays internal is the bookkeeping underneath them: the versioning mechanics that track every past snapshot of a file, and the working list of open gaps and loose ends we keep for our own audit discipline. Those are useful for us to manage the library honestly, but they're not something an outside reader or another municipality's project needs to reproduce. A plain-language public companion piece built from this library is its own separate, downstream project — not part of the research method itself.

Want to run this in your own municipality? Start here: Run this in your municipality. See how we check other kinds of claims across the whole site: How we verify.

— The Unknown Soldier · uniteTOlove · Toronto