Government Data Solutions¶
Built for the operational realities of Pennsylvania municipal government¶
Most boroughs already have everything they need to answer the questions that matter. The ordinances are written. The state regulations are bookmarked. The previous council's resolutions were minuted. The institutional knowledge exists.
What's missing is a way to retrieve any of it under time pressure.
A Right-to-Know request comes in Tuesday afternoon. You have five business days. The records are spread across the records office, the borough manager's email archive, the engineering firm's correspondence, and the budget files. You spend Wednesday and Thursday hunting. You find 80% of what's relevant. You miss two emails that probably matter. The response goes out Friday afternoon. The requester's lawyer notices the gap three weeks later.
This is the problem we solve. Not by building a bigger search engine, but by building a system designed for the operational realities of municipal government — where local procedure operates within state binding requirements, where two of the borough's own documents sometimes disagree, and where every answer needs to be defensible to a council member, an auditor, or a Right-to-Know requester.
What's specifically built for boroughs¶
The platform was designed against operational scenarios that local-government staff face routinely. Five capabilities that aren't standard in generic knowledge tools:
Hierarchical authority awareness. Local borough ordinance operates within Pennsylvania state law. State law operates within applicable federal regulation. When a borough manager asks a question whose answer is constrained by a binding higher-authority document — the PA Sunshine Act, the Borough Code, OSHA general industry — the system surfaces that binding context alongside the local procedure. A clerk who answers a constituent's zoning question gets the local ordinance AND the relevant state-law constraint, not just whichever document matched the keyword first.
Conflict detection across the borough's own records. When two of the borough's documents disagree on the topic of a question — a 2017 SOP and a 2022 council resolution that modified it; an old policy and a newer one that nobody propagated — the system surfaces the disagreement rather than smoothing over it. The user makes the judgment about which document is operationally in force. The system makes the judgment possible by presenting both positions with citations.
Right-to-Know defensibility. Every query is logged with timestamps, the user who asked, the documents cited, and the answer that came back. The audit trail is structured, exportable, and explicitly designed to be RTKL-defensible. If a request comes in for "all queries the system answered about topic X," the borough can produce that record. If a request comes in for "the basis on which staff acted on a particular policy interpretation," that record exists too.
Currency tracking that respects supersession. A 2017 ordinance superseded by a 2022 resolution stays in the corpus but is deprioritized in answers. The replacement relationship is explicit and navigable — the user clicks through from the legacy passage to whatever replaced it. Documents marked outdated by an authorized user apply instantly to retrieval, with no re-ingest, no waiting, no LLM call. The borough's own knowledge of what's currently in force outranks the system's automatic classification.
Calibrated uncertainty. When the system doesn't know — when the corpus doesn't cover the question well, when the synthesis would have to overreach — it says so. A borough manager fielding a question on the edge of the records gets a "this isn't well-covered; you may want to look elsewhere or update the corpus" answer rather than a confident-sounding paragraph cobbled together from tangentially-related passages. Confident answers are reliable; uncertain ones are visibly uncertain.
What this looks like in practice¶
A borough manager starts her week. The questions on her plate this week:
-
Do we need a public hearing for this zoning variance? — The system surfaces the local zoning ordinance procedure AND the PA Sunshine Act constraint that may modify it, with the precedence visible. She has the answer in 30 seconds with both documents cited. She forwards both to the council solicitor for confirmation.
-
What's our process for accepting and recording a council resolution? I have a new clerk. — The system pulls the local meeting procedures and the PA Borough Code requirements for quorum and minutes. The new clerk reads both, asks two follow-up questions on specifics, and is operational on this task within an hour rather than a week.
-
An RTKL request came in for all storm-sewer-overhaul-project resolutions since 2018. — The system retrieves every resolution touching the project, including the ones in the manager's email archive that nobody would have found by hand. The response goes out Wednesday afternoon, three days ahead of the statutory deadline, with complete records. The requester's lawyer notices nothing missing.
-
The DPW overtime policy and the 2022 resolution that modified it say different things about weekend work. — The system flags the conflict explicitly and shows both passages. The manager decides which is operationally in force, dismisses the flag with a written reason, and the same conflict won't re-flag. Future queries on the topic surface the resolved-as-of decision.
These aren't hypothetical. They are the recurring operational moments that determine whether a borough's records are an asset or a liability.
Where to read more¶
The thinking behind the platform is documented in a series of in-depth analyses. Each is readable on its own; together they form the framework for what an effective government knowledge system actually requires:
-
The Information Paradox — Why organizations can't find what they already have. The two failure modes (silos and concentration) and the seven requirements an effective answer has to meet.
-
Why Conflict Detection Is Harder Than It Looks — Why most knowledge systems quietly fail when two documents disagree. The hierarchical case (local procedure constrained by binding state law) is the most consequential class of conflict for borough operations.
-
Authority Hierarchies — Why "treat all documents equally" is the wrong default in regulated environments. State binding regulations operating over local procedure require deliberate retrieval machinery, not just topical search.
-
Citation Discipline — The difference between a confident answer and a defensible one. Why citation traceability is the substrate of any system that has to hold up to audit, RTKL, or legal review.
-
The Half-Life of Documentation — Why date metadata isn't a substitute for currency tracking. The supersession graph as the right mental model for documents that get updated, replaced, or quietly modified by later resolutions.
-
What "I Don't Know" Looks Like — Why a system that admits uncertainty beats a system that confidently produces wrong answers. Calibrated uncertainty as the operational substrate that makes a system trustworthy enough to act on.
-
The Self-Maintaining Corpus — The deployment that ages out of usefulness in six months. What it takes to keep a corpus current with the borough's actual document state without manual intervention.
What the engagement looks like¶
A typical borough engagement starts with a 60-day pilot. We work with the borough manager to ingest the borough's existing document corpus — ordinances, SOPs, meeting minutes, policies, recent RTKL responses, anything operationally relevant. The system is configured for the borough's specific jurisdictional context (state, county, municipal hierarchy) and branded for the borough's identity. Borough staff use it for 60 days. At the end of the pilot, we deliver a closeout health report covering corpus statistics, override activity, conflict resolutions, and coverage gaps — a tangible artifact for the council or borough manager to review.
The pilot is structured so the question being answered is whether this is worth continuing, not whether it's possible to escape from. Continuation pricing is monthly, scaling with usage, cancellable any time. Data exit is documented in the agreement; the borough takes its data with it whenever it wants.
Pilots scale from $2,500 for a small-borough proof of value to higher tiers for larger municipal portfolios. We're priced to convert pilots to ongoing relationships, not to profit on the pilot itself.
Working with consulting partners¶
Some of our work is with boroughs directly. Some is delivered through regional consultants whose existing client relationships make them natural channels for this kind of platform. If you're a consultant whose practice serves municipal clients — records management, compliance advisory, operational consulting, solicitor work, accounting and audit — and you've been thinking about how to add a knowledge-management capability to your service offering, the conversation we'd want to have is whether your client base would benefit and what the engagement model would look like.
This is not a generic referral or affiliate program. It's a specific kind of partnership where you bring the client relationship and the operational context; we bring the platform and the technical work behind it.
Conversation, not pitch¶
If any of this resonates with what's actually happening in your borough's operations — or in the operations of clients you advise — we'd welcome the conversation. Diagnostic, not pitch. Some borough operations look superficially like our use case but have different underlying causes; we'll tell you directly when that's the situation. Some look unfamiliar at first but turn out to fit cleanly.
— Base2ML Pittsburgh-based, founded 2026 chris@base2ml.com · base2ml.com · docs.base2ml.com