Who runs this

Operated by TOKUMA Foundation, and presented with the Cambridge Citywide Coalition.

TOKUMA Foundation operates 360citi and is responsible for what it publishes. The Cambridge Citywide Coalition is a named partner: it presents this dashboard with us. The Cambridge Redevelopment Tracker, which the map shows as a dated copy with credit, is maintained by Councillor Zusy’s office.

TOKUMA Foundation is a nonprofit organisation working to strengthen resilient communities through education, civic participation, the circular economy, and the sustainable use of natural and human resources.

Independent civic platform — not a City of Cambridge service. Nothing here is an official determination, a permit decision, or legal advice. The City’s own zoning map, ordinance text and permit records are the authority. This dashboard reads them and shows its work.

How to read every number here

Every figure on every surface declares which of four kinds of information it is, and carries the tag with it. If a number has no tag, treat that as a bug and report it below.

• observeda recorded fact — parcels, sales, permits, Tracker counts; each source carries its own date.
• testeda pre-registered statistical test on that data — direction stated before the test; value, n and p ride on the card.
• modeled / predictedan engine output — capacity, Δ-tax, shadow, alert scores; labeled with baseline, scope and method.
• illustrativea shape shown for orientation, not a claim — e.g. legal-max massing, never the real design.

What this dashboard cannot tell you

Stated plainly, because this output goes to City Council.

• Canopy is 2018. The newest tree-canopy layer Cambridge publishes predates Ord 2025-1 by seven years. These layers cannot show canopy under the current rezoning and are never captioned as current. The tree-removal permit record begins in 2019; together the two bracket the gap, and neither closes it.
• Impervious surface is April 2010. Fifteen years before the ordinance. It is the baseline the rezoning starts from, never a result of it.
• Heat cannot be correlated with income. The heat service is tiles-only — no query, no identify — and its 72.6–92.3 °F range is the service’s own published symbology stretch, not a validated measurement range for a date. The two layers are shown together and the analysis stops there. Co-location is not causation.
• Demographics carry sampling error. ACS 5-year estimates are least reliable for small neighborhoods and small categories, and family incomes of $200,000 may be top-coded. Life expectancy is a decade old, at tract resolution, mapped provisionally to neighborhoods; three neighborhoods have partial tract coverage and say so wherever the figure appears.
• The equity correlations are not significant. They are reported with their p-values and their leave-one-out ranges rather than withheld or rounded into a claim.
• Contours are modeled, not a flow model. The low-points layer is contour-derived and DEM-validated; bad source patches that fabricate convincing hollows were dropped, and every survivor carries its DEM elevation so it stays checkable.
• The pre-ordinance rules column is a secondary, unverified estimate aggregated across the districts C-1 replaced. It is labelled as such on the card and is not used in any calculation.
• Model flags are predictions, not events. They are drawn as hollow rings, never as solid dots, the parcel model block is left empty for the parcels the model did not flag, and the flagged list is frozen at its prediction date so it can be scored later against real filings.
• Some zoning colours are ours. Corridor districts added to the City’s GIS after the February 2025 map was printed, and districts published with no fill, are drawn with dashed swatch borders to mark them as our choice rather than the City’s.
• Trees, greencover and listings are display layers. The tree points carry no attributes, greencover is 96 generalised polygons of major green space rather than parcel-level canopy, and the listings are one browser session captured on a single day — a snapshot, not a market feed.
• How many homes a permit contains. ISD permit records carry the applicant, the declared cost, gross square footage, storeys and height — and no dwelling-unit count. So this dashboard can tell you how many permits were issued and cannot tell you how many homes they add. The unit counts we do hold come from the community tracker, for the 140 sites it maps. Added 2026-09-02, after a reviewer was asked how many homes were permitted last year and there was no honest way to answer.
• “Permits” means two different things, and we say which. permits.json holds a 7,190-record series for substantial work and a 6,149-filing series for everything including small alterations. They differ in scope and in time — the record series reaches back to 2018, the filing series begins in 2023 — so for 2025 they read 823 and 1,732. Every chart names the one it is on. Neither is wrong; a page that showed both under one word was.
• Which board hears a particular lot. The meeting calendar marks the bodies that decide what gets built, and stops there. Nothing in our data maps a parcel to the board that will hear it, and inventing that mapping would be exactly the kind of confident wrong answer the rest of this page exists to avoid.
• Whether the City’s calendar has changed since our snapshot. The meeting list is a dated copy, refreshed on a schedule, and it prints its own date. Where it is empty it says our snapshot is empty — never that the City has nothing scheduled, which we have no way to know.
• An employment rate for a neighborhood. As of 2026-09-04 this dashboard does hold journey-to-work mode per neighborhood, from the City’s own ACS extract — that topic used to read “not held” and turned out to be published all along. What is still missing is different: the share of residents who are employed. The City publishes an unemployment rate citywide and annually, at a geography that is not the thirteen neighborhoods, and it is not merged in here. Commute shares are shares of commuters and sum to 100% however many residents work — they are not a substitute.

Data sources — each with its own date

• City of Cambridge FY2026 Assessing databaseJan 1 2026
• GIS buildings (BASEMAP), with roof heightsJun 2026
• CDD zoning districtsJun 2026
• CDD conservation / historic districtsJun 2026
• Ordinance 2025-1 · multifamily citywideFeb 10 2025
• City housing dataset 6nxj-uqfe · net units2015–2026
• HUD income limits · 4-person AMI $164,600eff. Jun 1 2026
• ISD permit filings, joined by map-block-lot2016 onward
• Neighborhood demographics · ACS 5-year2020–2024
• Life expectancy · CDC USALEEP, by tract2010–2015
• Tree canopy · UVM SAL with CDD and USDA FS2018
• Impervious surfaceApr 14 2010
• Redevelopment Tracker (community)snapshot

Methodology

Envelopes. Modeled legal capacity from the ordinance text: height, setbacks, open-space minimum and lot eligibility are applied per parcel from zoning-rules.json, which carries the verified Ord 2025-1 standards. The 3D volume is illustrative massing, never a design. Back-test: a typical project builds about 52% of the modeled maximum, so headroom is a legal ceiling and not a forecast of built area.

Δ-tax. buildable_SF × $725 × 6.67 / 1000, carried with a ±25% band that combines construction-cost variance, assessor lag and financing sensitivity. A heuristic order of magnitude at full build-out — not a confidence interval, and not an assessment.

Shadow. Cast from the City’s GIS roof heights, per building in view, on a flat ground plane. Each cast is the convex hull of the footprint and its translated copy, which slightly over-states the shadow in the concavity of an L-shaped or courtyard building. No self-shadowing, no inter-reflection, no facade climb, and a disclosed cap of 1,100 buildings per pass, nearest first.

Tested findings. Pre-registered: each hypothesis states its direction before the test, and null results are reported rather than re-cut. Every test’s claim, n, rate, p-value and verdict — including the inconclusive ones — is published as data/cambridge/hypothesis-tests.json.

Runoff. Coefficients, assumptions and uncertainty are documented end to end in docs/runoff-method.md, which is written to be attacked. Impervious area is observed; runoff volume is modeled; the dollar figure is modeled on top of a model and is therefore only ever printed as a range. Cambridge does not bill stormwater — that figure is a policy counterfactual priced at a real published tariff, never a bill anyone receives.

The Redevelopment Tracker — attribution

The redevelopment projects on this map come from the Cambridge Redevelopment Tracker, maintained by Councillor Zusy’s office. The map shows a dated copy, with credit. 360citi does not own the tracker and does not edit it.

At the snapshot below the tracker holds 144 tracked projects, of which 140 are mapped here. Those are different numbers on purpose, and the difference is named rather than quietly dropped:

• SourceCouncillor Zusy’s office
• Retrievedsnapshot
• Methodread from the tracker’s public sheet, geocoded to parcels
• Published snapshotprojects.json
• The tracker itselfcambridge-redev-tracker.pages.dev

No synchronisation is promised. This dashboard shows a dated snapshot, not a live mirror. The tracker updates on its own cadence and may already differ from what is shown here; where the two diverge, the tracker is the source of record and this page is the dated copy. Nothing here refreshes it automatically, and no agreement to keep them in step exists. The snapshot date is printed on every tracker-derived figure in the product, and the app warns in the console once it is more than seven days old.

It is a community list, not a census. It is not a complete record of redevelopment or demolition in Cambridge. Most tracked sites carry no permit date, so they cannot be attributed to either zoning regime and are drawn as unknown rather than as post-ordinance. Some neighborhoods have no tracked sites at all and are therefore absent from every tracker-derived chart.

What we count

We count page views, and which of this dashboard’s views a visit opens — nothing else. No cookies, no clicks, no searches, and never the parcel or address you looked at: those are removed from the address before anything is sent.

Corrections

If a figure here is wrong, we want to know, and we would rather hear it from you than from a hearing. TOKUMA Foundation is accountable for what this dashboard publishes, and reviews every correction sent to support@360citi.org or through the contact page.

We do not publish a response time, because we have not committed to one, and a promise we cannot keep would be worse than none.

This opens the contact page on www.360citi.org in a new tab. Tell us where you saw the figure, what it says now, what it should say, and a source we can check it against. If you would rather email, write to support@360citi.org.

Accessibility

This dashboard is built to WCAG 2.1 AA as its target. What is implemented and verified:

• A visible focus ring on every interactive element, and no keyboard trap: focus can always be moved on.
• Colour is never the only carrier of meaning: every legend swatch, status chip and provenance tag is paired with a text label.
• The map has a full table view — the Map / Table switch in the left rail — and that table, not the canvas, is the screen-reader path to every parcel.
• Every view in the top bar is reachable and operable from the keyboard, with Enter or Space, and dialogs close on Escape and return focus to what opened them.
• prefers-reduced-motion is honoured; the theme cross-fade and the map’s animated transitions stand down.
• Light and dark themes are both maintained, and the contrast commitments apply to both.

What is not yet verified, stated because an untested claim of accessibility is worth nothing:

• Type size. The prose on this page is set at 14.4 px. The dense instrument surfaces — the parcel card, the layer dock, the legends — are set smaller than the 14 px floor our own design system commits to. Bringing them up is open work, not a settled decision.
• The full audit has not been run. Contrast, touch-target size and the responsive tiers have not been checked end to end, and no evidence of such an audit exists in this repository. Treat all three as open.
• The map canvas is not screen-reader navigable. That is why the table view exists, and why it is the supported path rather than a fallback.