Nine open-source connectors that let an AI assistant query the City's own systems while you watch. Every claim resolves to something you can open in a browser and check.
Free · MIT licensed · No vendor · Every figure on these slides dated and sourced
Know your room before slide 2. Agency data staff want the Socrata act. Program and budget staff want Checkbook. Communications and operations staff want the last three slides, which are about how BetaNYC runs itself. Ask at the top and reorder.
Runs ~30 minutes at full length. Cuttable, in order: slide 16, then slide 6. Do not cut slide 15, the automations.
Everything numeric on these slides was verified live on 2026-08-04. Checkbook and the 311 aggregate were run from this machine that morning. If you present more than a week out, re-run them.
You have a system of record and it is better than this. These connectors read published data. If the question is about your own caseload this week, ask your own database.
A determination, a filing, a figure going into testimony. Go to the source document. This is a research accelerator, not a system of record, and Checkbook itself says the same.
If you have the contract number, open Checkbook in a browser. A tab beats a query. Do not let a tool add a step.
What is left is the part that actually costs you: a question that crosses systems, or crosses agencies, where no one page anywhere holds the answer.
Lead by conceding and mean it. This room has been pitched a lot of civic tech. The fastest way to lose them is to claim the tool is good at everything, and the fastest way to earn the next twenty minutes is to name the cases where it is the wrong choice.
The first card matters most here and is the one that differs from every other version of this deck. Do not tell agency staff that a public dataset beats their own system. It does not, and they know it.
That table did not exist until the question was asked. It was computed, against live rows, by a database that grouped and counted on request. A search engine indexes documents that already exist. This one does not exist yet.
This is the thesis of the whole chapter, so do not rush it. The distinction is not "the AI is smarter than Google." It is that a search engine can only return a document somebody already wrote, and an aggregate over live rows is not a document.
Verified live 2026-08-04 against erm2-nwe9, created_date > 2026-07-01, borough = BROOKLYN. Re-run it before you present. The numbers move daily and quoting a stale count on the slide about freshness would be an unforced error.
If someone asks why Illegal Parking dominates: do not theorize. Say you do not know and that the honest next query is a breakdown by agency and resolution status. The demo's job is to get you to the next question, not to answer this one.
An article, a dashboard, a PDF summary. All of them are somebody's reading of the rows at some past moment. None of them are the rows.
Count, group, sum, filter by date range, join two columns. A search index does none of that. It matches text against documents.
A highly-ranked page may be four years stale, and nothing on it tells you. The portal reports when the dataset was last updated, as a field.
A language model with no connector will produce a confident, plausible, and sometimes invented dataset ID. Nothing in the answer tells you which.
The fourth is the one worth dwelling on with this room. The dangerous failure is not an error message. It is a plausible answer to a question you did not ask, delivered in the same tone as a correct one.
Card 4 is the reason this project exists. A four-by-four dataset ID like erm2-nwe9 is exactly the shape of string a language model will happily fabricate, and it looks identical to a real one.
If you want a live demonstration and have the nerve: ask an assistant with no connectors for the dataset ID of some obscure NYC dataset, then check it. Do not promise this will fail on cue. Sometimes it gets it right, which is itself the point: you cannot tell from the answer.
borough when it is called boro.SELECT complaint_type, count(*) WHERE created_date > ... GROUP BY complaint_type.
The arithmetic happens on the City's server, not in the model.Step 3 is the one that matters. The model is not doing the counting. It is writing a query, and a database is doing the counting. The AI is the interface, not the arithmetic.
Say the last line in those words. "The AI is the interface, not the arithmetic." In a government room it is the sentence that decides whether the rest of the meeting is about capability or about risk.
If the room is technical, offer the corollary: this is also why the failure modes are boring and checkable. A wrong filter returns a wrong number that you can see the filter for. That is a much better class of error than a confident sentence with no provenance.
Step 2 is a real distinction and worth naming. Column names in NYC Open Data are not consistent across datasets, so schema-read-before-query is not ceremony.
data.cityofnewyork.us is the City's catalog. data.ny.gov is the State's.
Both run on Socrata, so the same three tools reach both. You change one parameter.
That means a question that spans jurisdictions is two queries, not two projects.
The two catalogs publish overlapping subjects at different granularity, with different geography and different identifiers. Matching is manual, on address or facility name or county.
Nothing about running the same tool against both portals makes their records line up. Do not let the convenience imply a join that is not there.
Neither portal requires an API key to read. Registration exists only to lift anonymous rate limits. There is nothing to procure to start using this.
The right-hand card is the honest half and the reason this slide is not just a feature list. Cross-jurisdiction reconciliation is real work and the tool does not do it for you.
The pre-wired config for switching between the two portals is in the repo at mcp-configs/socrata-nyc-nys.mcp.json. Point people at it rather than reading it aloud.
Cuttable if short on time, unless the room includes State agency staff, in which case it is the slide they came for.
A dataset can be published, indexed, findable, and superseded. Nothing in a result row says "this stopped being maintained in 2021." Check the update date as a matter of course, not as a spot check.
NYC's Broadband Adoption by State Senate District dataset (9bjg-n96a) has 26 rows, all
created 2020-06-19, and does not contain District 59. The file predates the current
district lines. It answers cleanly and it answers for the wrong map.
Every one of these tools caps what it returns. A result of exactly N rows against a limit of N is indistinguishable from a complete result of N rows. Treat that case as truncated until you have checked.
None of these produce an error. All three produce a number you could put in a memo. That is precisely what makes them worth knowing.
The middle card is verified and it is the most useful one for a government room, because it is not a data-quality complaint. The dataset is fine. It is answering for a map that no longer exists, and a digital-equity analysis built on it would be quietly wrong for a third of the city's senate districts.
The third card is not hypothetical for us. We have shipped a truncated total ourselves, in an earlier deck, by trusting a result that looked complete. Know that if someone asks how we know the trap is real. Do not volunteer the whole story or you will lose the thread.
49 checks · $14,482,518.24, spread across roughly two dozen agencies: NYPD, OTI, DEP, DSS, Finance, FDNY, Health, ACS, DYCD, DCAS, Law, Parks, HPD, Sanitation, Probation, City Planning, the Comptroller, CUNY, and the School Construction Authority.
"What did the City pay Microsoft in FY2026, and which agencies paid it?"
Run this query
Any one agency can see its own payments. No agency can see the other twenty-one. The citywide view exists in the Comptroller's published data and nowhere in an agency's own system.
Same question, same shape, for any vendor you actually care about. It is one parameter.
This is not oversight material. It is the view your own procurement colleagues would like to have and cannot get without asking twenty-two counterparts by email.
Frame this as useful to them, not as scrutiny of them. A watchdog room hears "one vendor across every agency" as an accountability tool. A room of city staff hears the same query as procurement intelligence they are currently missing, and that is the true and more useful framing here.
Verified live 2026-08-04: 49 records, $14,482,518.24, search_spending(payee_name="MICROSOFT", fiscal_year="2026"), 49 of 49 returned against a page size of 50, so the set is complete rather than truncated. Say that out loud if anyone asks how you know it is all of them.
Then go straight to the next slide, which is where this gets interesting.
49 checks to MICROSOFT CORPORATION, FY2026, across two dozen agencies. Complete, correct, and verifiable.
And it is not the number you wanted.
Two checks issued 2026-01-20 under contract DO185820262006811,
purpose "OTI MS ELA Renewal – Year 1". That is the City's Microsoft enterprise
license agreement.
Payee: DELL MARKETING LP. The payee-name search never sees it.
Most large software is bought through a reseller, so the vendor on the check is not the vendor you are asking about. The connector's own documentation warns about this, and the demo above walks straight into it. The fix is to search the contract purpose, not only the payee name.
This is the best slide in the deck, and it is best because the tool did not save you from the mistake. Reading the result did.
Verified 2026-08-04 via get_agency_spending(agency_code="858", fiscal_year="2026"): the top two OTI checks are $30,473,296.68 and $22,533,148.17, same document ID, same contract, split across budget codes 8100 (CITYWIDE SUPPORT) and 3334 (MICROSOFT ELA INTRA-CITY FUNDING). Both to Dell Marketing LP. OTI has 14,986 spending records in FY2026 in total.
⚠️ Do not say "the City spent $67 million on Microsoft." We have not established that the Dell ELA payments and the 49 Microsoft checks are disjoint, non-overlapping, or exhaustive of Microsoft-related spending citywide. The claim on this slide is about the search, not about the total. Adding them together in front of this room would be exactly the error the deck is warning about.
If someone asks for the real citywide Microsoft figure: say it is a good question, that it needs a purpose-text sweep across resellers, and offer to run it and send it. Then actually do it.
Bills, sponsors, committees, hearings, and voting records out of Legistar. Legislative data is relational, which a flat catalog handles badly.
nyc-council-mcp
Procurement notices, solicitations, awards, and public hearings. Same source as the daily PDF, without reading the daily PDF.
nyc-record-mcp
Full legal text, searchable. This is prose, not tables, so a dataset catalog was never going to reach it.
nyc-charter-laws-rules
Live service-request status and the city-services calendar. Distinct from the bulk historical 311 export in the portal.
nyc-311-mcp
Adopted budgets, discretionary awards, capital projects, and transparency resolutions, parsed from the published documents.
New-York-City-Budget
Albany's bills, laws, members, and committees. Same shape as the Council connector, different spine.
nys-openlegislation-mcp
Spending, contracts, budget, payroll, revenue, from the Comptroller's API.
nyc-checkbook-mcp · chapter 2
The City and State open data catalogs, both portals, one connector.
socrata · chapter 1
Do not read this grid. Point at it, say "nine, all public repos," and ask which two matter to the people in the room. Then talk about those two.
The ninth connector is Google Workspace, which is how the assistant reaches BetaNYC's own documents. It is not on this grid because it is not a civic data source, and padding the count would be the wrong instinct in a deck about precision.
Checkbook's documented API started returning 403 to us. The site loaded fine in a browser.
A letter to the Comptroller's office. Three asks. No header spoofing and no working around the block.
Two days. A real technical response, their CIO looped in, and an offer of a call.
Access working. The residual block was ours. We were exceeding a rate limit.
Our client was following redirects, so we were making roughly forty requests against their origin for every one logical API call. Their fix had already worked. What we were still measuring was our own client getting itself blocked. They also corrected one of our published findings, which was simply wrong. We had missed a field that was there all along.
This slide reads completely differently to a room of city staff than it did to a watchdog room, and that difference is the reason to keep it. To them it is a story about an agency responding well in two days, and about an outside group publicly owning that it was at fault.
Say "we had missed a field that was there all along" in exactly those words. It is the sentence that buys the rest of the meeting.
One open finding worth naming if asked: the rate limit is real and reasonable, and it is documented nowhere. We learned it by violating it. A researcher hitting the same wall just experiences an outage and concludes the data is unreliable. We have passed that back to the office and that is where it sits. Carry no ask on this slide. Do not invite the room to co-sign anything.
Everything so far is a tool we give away. The next three slides are how BetaNYC actually runs on it, because a demo you do not use yourself is a brochure.
Six phases, from a 130-source scan to a multi-channel publish. A human decides what goes in.
Our own website, against WCAG 2.1 AA, with the findings remediated and re-checked.
Discord access issued and revoked from our membership database, nightly.
Transition slide, fifteen seconds. Its only job is to signal that the subject has changed from "here is a civic data tool" to "here is how a small nonprofit actually operates with this."
This chapter is the one most likely to interest agency communications and operations staff, who are usually the people in the room asking what any of this means for their own work. If that is most of the room, consider moving this chapter earlier.
Phase 2 is the important one. The machine proposes and a person disposes, and the pipeline is built so that skipping the human step is not possible rather than merely discouraged.
Phase 2 and the "never auto-sends" line are the whole point of this slide for a government audience. The question underneath every AI conversation in a public agency is "what happens without a human," and the honest answer here is that nothing goes out.
⚠️ Source count: our own docs disagree, one file says ~130 and another says ~115. Say "roughly 130" and if pressed say the exact number is inconsistent in our documentation and you will confirm it. Do not defend a precise figure you cannot source.
The pipeline has run end to end for real, including a first live multi-channel publish that surfaced and fixed four genuine platform API bugs. If asked whether this is aspirational: it is not, it ships weekly.
An automated axe-core 4.9.1 scan across 21 pages of beta.nyc, plus manual DOM inspection on the 10 highest-traffic pages. Standard: WCAG 2.1 AA.
23 distinct issues, 7 of them sitewide. Critical 5 · Serious 9 · Moderate 6 · Minor 3.
Missing alt text on team headshots. Unlabeled newsletter form inputs. A missing skip link. Link text reading "More Details" eight times on one page, which a screen reader announces as eight identical destinations.
Remediated, then re-checked by reading the live page's DOM back, not by trusting the report that said it was fixed.
An automated scan finds the machine-detectable half. It cannot tell you whether your alt text is any good, only that it exists. The manual pass is not optional and we should not imply otherwise.
This is a genuinely useful slide for city staff, because most agencies have a public-facing site under the same obligations and very little capacity to audit it. The method transfers directly and costs nothing.
The verify-by-reading-the-DOM-back detail is worth naming. We do not treat "the agent said it fixed it" as evidence that it is fixed, which is a general rule in this workspace and not specific to accessibility.
If asked what tool: axe-core is open source. The remediation went through our WordPress specialist agent. Do not overclaim that this was fully autonomous. A person reviewed and approved the changes.
Our membership database is the sole source of truth for who gets in. A single-use login link binds a Discord account to a membership record, and a nightly job removes any role the database does not justify.
Access is earned by donating, attending an event, or being on a curated list. It has granted access automatically off a real donation.
A checker enforces that a feature change updates its documentation, running as a hook after every turn, as a check on every pull request, and again in the weekly review.
It encodes 11 of 15 rules. The gap is written down, so a green check is not mistaken for a full pass.
Follower and subscriber counts across 10 platforms. Five come back through APIs. Five have no usable API and are collected by driving a browser.
The split is documented rather than smoothed over.
The middle card is the one we would defend hardest. An automated check that silently covers less than it appears to is worse than no check, so the shortfall is written into the documentation it governs.
The Discord card is the one Noel wanted in and it is the strongest of the three, because revocation is the hard half of access control and the nightly reconcile is what makes it real rather than a signup form.
⚠️ Do not describe the Slack-to-Discord migration as finished. It is in flight, with Slack closing later this year.
If the room asks about applying the membership-gating pattern to their own systems: the useful part is not Discord. It is one authoritative record of who someone is, with every platform identity hanging off it, so that removing access is one action instead of seven.
The connectors are open source and MIT licensed. The guides are CC BY-SA. Most need no API key and no account. A few need a free key, and registration is the only friction.
There is no BetaNYC service in the middle. You run them yourself, against the City's own public endpoints.
Whether your agency's IT policy permits installing them, which assistant you are permitted to use, or how any of this interacts with your own procurement and security review. We have not been through that process and will not pretend otherwise.
What we can do is answer technical questions from whoever does.
The public data is public either way. Every query in this deck can be run by anyone, with no account, which is worth remembering before it becomes an IT ticket.
Do not bluff the right-hand card. Somebody in the room will know their agency's review process far better than you do, and guessing at it destroys the credibility the last fifteen slides bought.
The last line is the practical out and it is true. Nothing here needs to be installed anywhere to be checked. Offer to run a query for them and send the result with the dataset ID attached.
This is the first slide to cut if you are short on time and the room is not technical.
Public repos, open licenses, and most of it needs no key at all. We would rather you check it than take our word for any of it.
Disclosure: BetaNYC received $25,000 in FY2026 Council discretionary funding, via the Fund for the City of New York. You can verify that with the tools in this deck, in about fifteen seconds, with no account.
If there is a question your team runs by hand every month, that is exactly the user journey we want to add.
The ask is the last line. Get one concrete recurring question out of the room before you leave. It is worth more than a follow-up meeting, and it is the only thing on this slide you actually need.
The disclosure line is deliberately small and unemphasized here. A watchdog room gets it as its own card; this room does not need it made into a moment, but leaving it out of a deck that teaches people to query discretionary funding would be worse.