Reimagining Chicago's Thompson Center for the Next Generation

Reimagining Chicago's Thompson Center for the Next Generation

On 16 September 2026, Google published a design announcement titled Reimagining Chicago's Thompson Center for the next generation. The only source this article relies on for factual background is that announcement page, available at https://blog.google/company-news/inside-google/company-announcements/chicago-thompson-center-designs.

That constraint shapes everything below. A single company announcement can tell you what a project's sponsor wants the public to see. It cannot tell you the construction schedule, the budget, the preservation scope, the leasing strategy, or how the design will perform in practice. Those questions require separate, verifiable documentation. So this article does two things: it reads the announcement for what it actually says, and it walks through a reproducible workflow any technical team can use to capture, track, and publish a civic project's public record without drifting into speculation.

What the announcement establishes

The verified facts are narrow and worth stating plainly:

• The announcement exists, is publicly accessible, and was published on 16 September 2026.
• Its subject is a reimagining of Chicago's Thompson Center.
• Its framing is generational — the phrase "for the next generation" signals a long-horizon claim rather than a near-term construction update.

Everything else is interpretation. The source does not, on its own, confirm square footage, cost, delivery dates, occupancy, or the treatment of any specific architectural feature. If you are writing about this project, that distinction matters. A design announcement is a primary source, but it is also a self-interested one: it exists to communicate intent and momentum. Treating it as a complete project record is the most common and most avoidable error in civic technology writing.

Three ways to read a design announcement

As a real-estate signal. A company committing to a landmark building in a central business district is making a statement about where it expects its workforce to be. That is a strategic claim, and it is the kind of claim that can be evaluated over time against hiring, occupancy, and investment data.

As a design claim. "Reimagining" implies intervention — renovation, adaptive reuse, or partial rebuilding. Which of those applies is not established by the announcement. Any technical or architectural commentary that skips this question is guessing.

As a public-record artifact. This is the reading that technical teams are best positioned to act on. The announcement is a dated, citable document. It has a URL, a publication timestamp, and a stable identifier (a content hash, if you compute one). It can be archived, compared against future revisions, and referenced without ambiguity.

The third reading is where automation earns its keep. Below is a complete, minimal pipeline for turning an announcement page into a tracked, reproducible archive.

Requirements

Before you start, confirm you have the following:

• Python 3.10 or newer. The scripts use modern type syntax and pathlib throughout.
• `pip` and the `venv` module. Both ship with standard CPython distributions on macOS, Linux, and the official Windows installer.
• Network access to `blog.google`. No API key or authentication is required for a public announcement page.
• About 200 MB of disk space. The virtual environment and the MkDocs site are small; the archived HTML is typically under a megabyte.
• A terminal. All commands below are POSIX-style. Windows users should run them in PowerShell or WSL and substitute .venv\Scripts\activate for the activation step.

One operational note before you write any fetching code: check the site's crawl policy. A single polite request per day is well within normal expectations, but you should verify rather than assume. The command below prints the site's robots.txt so you can read the current rules.

curl -sS -A "civic-archive/1.0 (+contact: your-team@example.org)" https://blog.google/robots.txt

Step-by-step installation

Step 1 — Create the project directory

This command creates a working directory and moves you into it. Keeping the archive in its own folder makes the virtual environment and the generated site easy to remove later.

mkdir -p ~/projects/thompson-center-archive && cd ~/projects/thompson-center-archive

Step 2 — Create and activate a virtual environment

This isolates the project's dependencies from your system Python. On Windows, replace the activation line with .venv\Scripts\activate.

python3 -m venv .venv
source .venv/bin/activate

Step 3 — Upgrade pip and install dependencies

This installs the four libraries the pipeline needs: requests for retrieval, beautifulsoup4 for parsing, and mkdocs plus mkdocs-material for rendering a static site.

python -m pip install --upgrade pip
pip install requests beautifulsoup4 mkdocs mkdocs-material

Step 4 — Freeze the dependency set

This writes the exact installed versions to requirements.txt, so the archive can be rebuilt identically on another machine or in CI.

pip freeze > requirements.txt

Step 5 — Write the archival script

Create a file named archive.py in the project root. It fetches the announcement, computes a SHA-256 digest of the response body, extracts the page's own title and description metadata, and writes both the raw HTML and a small record file to data/.

"""Fetch and archive a public announcement page as a verifiable record."""
from __future__ import annotations

import hashlib
import json
import pathlib
from datetime import datetime, timezone

import requests
from bs4 import BeautifulSoup

SOURCE_URL = (
    "https://blog.google/company-news/inside-google/company-announcements/"
    "chicago-thompson-center-designs"
)
HEADERS = {"User-Agent": "civic-archive/1.0 (+contact: your-team@example.org)"}
OUT_DIR = pathlib.Path("data")
OUT_DIR.mkdir(exist_ok=True)

response = requests.get(SOURCE_URL, headers=HEADERS, timeout=30)
response.raise_for_status()
html = response.text

# A content hash makes silent edits to the source page detectable later.
digest = hashlib.sha256(html.encode("utf-8")).hexdigest()

soup = BeautifulSoup(html, "html.parser")
title = soup.title.string.strip() if soup.title and soup.title.string else ""

description = ""
meta = soup.find("meta", attrs={"name": "description"})
if meta and meta.get("content"):
    description = meta["content"].strip()

record = {
    "url": SOURCE_URL,
    "retrieved_at": datetime.now(timezone.utc).isoformat(timespec="seconds"),
    "sha256": digest,
    "title": title,
    "description": description,
}

(OUT_DIR / "announcement.html").write_text(html, encoding="utf-8")
(OUT_DIR / "announcement.json").write_text(
    json.dumps(record, indent=2, ensure_ascii=False), encoding="utf-8"
)
print(json.dumps(record, indent=2, ensure_ascii=False))

The digest is the important part. Without it, you have a copy of a page. With it, you have evidence that the page has not changed since you captured it — or, if it has, a precise signal that your citations may now be out of date.

Step 6 — Write the change-detection script

Create verify.py. It re-fetches the stored URL and exits with status code 1 if the content hash differs, which makes it usable as a cron job or a CI check.

"""Re-fetch the archived URL and report whether its content has changed."""
from __future__ import annotations

import hashlib
import json
import pathlib
import sys

import requests

HEADERS = {"User-Agent": "civic-archive/1.0 (+contact: your-team@example.org)"}
RECORD = pathlib.Path("data/announcement.json")

if not RECORD.exists():
    sys.exit("No stored record found. Run archive.py first.")

stored = json.loads(RECORD.read_text(encoding="utf-8"))
response = requests.get(stored["url"], headers=HEADERS, timeout=30)
response.raise_for_status()
current = hashlib.sha256(response.text.encode("utf-8")).hexdigest()

if current == stored["sha256"]:
    print("Unchanged:", stored["url"])
    sys.exit(0)

print(f"CHANGED since {stored['retrieved_at']}", file=sys.stderr)
print("  stored :", stored["sha256"], file=sys.stderr)
print("  current:", current, file=sys.stderr)
sys.exit(1)

Step 7 — Scaffold the static site

This creates a MkDocs project in a site/ subdirectory with its own configuration and docs/ folder. A static site is the right delivery format here: it is fast, diffable in version control, and trivial to host.

mkdocs new site

Step 8 — Configure the site

Open site/mkdocs.yml and replace its contents with the configuration below. It sets the site name, switches to the Material theme, and enables tables and admonitions for the record pages you will generate.

site_name: Thompson Center Archive
site_description: A tracked public record of the Thompson Center design announcement
docs_dir: docs
theme:
  name: material
nav:
  - Home: index.md
  - Source record: source.md
markdown_extensions:
  - admonition
  - tables

Usage examples

Example 1 — Capture the announcement

Run the archival script once to create the baseline record. The printed output confirms the URL, the retrieval timestamp, and the content hash.

python archive.py

Example 2 — Inspect the stored record

This command uses jq to print the three fields you will cite most often: when the record was captured, what the page calls itself, and the digest. If jq is not installed, python -m json.tool data/announcement.json produces readable output without it.

jq -r '.retrieved_at, .title, .sha256' data/announcement.json

Example 3 — Verify that the source has not changed

Run this before publishing anything that cites the announcement. A zero exit code means your citations still match the live page; a non-zero exit code means someone edited the source and you should re-read it.

python verify.py; echo "exit code: $?"

Example 4 — Generate a citable source page

This snippet renders the stored record into site/docs/source.md. Run it from the project root after archive.py has completed.

"""Render the stored record as a Markdown page for the static site."""
import json
import pathlib

record = json.loads(pathlib.Path("data/announcement.json").read_text(encoding="utf-8"))

markdown = f"""# Source record

- **URL:** <{record['url']}>
- **Retrieved:** {record['retrieved_at']}
- **SHA-256:** `{record['sha256']}`

> {record['description']}
"""

out = pathlib.Path("site/docs/source.md")
out.write_text(markdown, encoding="utf-8")
print(f"Wrote {out}")

Example 5 — Build and serve the site

The --strict flag turns broken internal links and missing pages into build failures, which is exactly what you want for a citation-driven site. The second command serves it locally for review.

mkdocs build -f site/mkdocs.yml --strict
mkdocs serve -f site/mkdocs.yml -a 127.0.0.1:8000

Example 6 — Schedule daily verification

This appends a daily 06:00 verification job to your crontab without opening an editor. Output is appended to verify.log so you have a dated trail of every check.

(crontab -l 2>/dev/null; echo "0 6 * * * cd $HOME/projects/thompson-center-archive && .venv/bin/python verify.py >> $HOME/projects/thompson-center-archive/verify.log 2>&1") | crontab -

What this workflow buys you

Three things, all of which matter more than the tooling itself.

Reproducibility. Anyone with the repository and requirements.txt can rebuild the record and confirm the hash. That converts a casual citation into a checkable one.

Change detection. Announcements get edited — a paragraph softened, a date added, a partner removed. Without hashing, those edits pass unnoticed and your article quietly becomes wrong. With hashing, you get a timestamped signal the moment the page shifts.

Separation of evidence from interpretation. Once verified facts live in a generated page with a hash and a retrieval date, everything else you write is clearly commentary. That is the discipline the Thompson Center project — like any long-horizon civic redevelopment — will require from anyone covering it for years rather than weeks.

Open questions the source does not answer

These remain genuinely unresolved on the available evidence, and no amount of tooling will fix that:

• What is the delivery timeline, and what phases is it divided into?
• What is the budget, and who is funding which portions?
• How is the building's existing fabric being treated — preserved, replaced, or something in between?
• What is the occupancy model, and how does it relate to transit access in the surrounding district?
• How will the design be evaluated after completion?

Each of these requires a different primary source: a planning document, a permit filing, a council record, a lease, a post-occupancy study. Treating the announcement as an answer to any of them would be a category error.

Conclusion

The announcement that Google published on 16 September 2026 establishes one durable fact: that a reimagining of Chicago's Thompson Center is being presented to the public under a generational framing. Everything beyond that — scope, cost, schedule, outcome — is a question still waiting for documentation.

For technical teams, the useful response is not to speculate but to build the apparatus for following the story accurately. A virtual environment, two short Python scripts, a content hash, and a static site are enough to turn a press announcement into a tracked public record that survives revisions, citations, and time. The commands above take about fifteen minutes to run end to end. The record they produce will stay useful for as long as the project itself does.

Start with requirements.txt, keep the hashes, and let the verified facts do the work that adjectives cannot.