Ohio bills before enactment — the text as introduced

Source. Ohio General Assembly, via the Legislative Information Systems service that backs legislature.ohio.gov. Type. Primary source — a bill as it was introduced, which is what a sponsor put in and not what anyone voted on. Location. search-prod.lis.state.oh.us/api/v2/general_assembly_{GA}/legislation/{bill}/00_IN/html/.

What it contains. The whole bill: sponsors, the long title enumerating every Revised Code section it would amend, and the amended text of each section. H.B. 643 of the 136th is one section and eleven kilobytes; H.B. 96 of the same General Assembly is the operating budget and amends more than two thousand.

Why this is a third artifact and not one of the two already here. Ohio Revised Code — the sections this corpus cites serves the Revised Code as it stands today, and Ohio session laws — the appropriation acts themselves serves acts as they were passed. A pending bill is neither: it is not in the code and it has not been enacted, and it may never be either. The same distinction that put the session laws in their own record rather than folding them into ohio-laws — recorded at “The acts themselves” — applies again one document earlier.

The version index answers the question the enrolled acts left open # ↑ Contents

ohio-session-laws records that an act’s enrolled version code is positional — 06_EN for H.B. 215, 05_EN for H.B. 650 and H.B. 770, 08_EN for H.B. 282 — so it differs per bill and a guess returns a nine-byte 404 that reads exactly like “not served”. The fix it named was to read the index at .../legislation/{bill}/ first.

That index turns out to give the whole sequence, and it makes the as-introduced case simpler than the enrolled one rather than harder. Introduction is always the first version, so the code is always 00_IN. For H.B. 96 of the 136th the index returns eight entries:

00_IN   As Introduced
01_RH   As Reported by the House Finance Committee
02_PH   As Passed by the House
03_PSC  As Pending in the Senate Finance Committee
04_RS   As Reported by the Senate Finance Committee
05_PS   As Passed by the Senate
06_CR   As Reported by the Committee of Conference
07_EN   As Enrolled

So 00_IN needs no lookup and every other stage does. The index is also the only reliable way to tell a pending bill from an enacted one: the listing endpoint reports a bill’s first version rather than its current one, so H.B. 186 of the 136th appears there as As Introduced and is in fact enrolled with an effective date of 20 March 2026. Reading a bill’s status off the listing would record several enacted acts as pending.

The index is a record, not a list, and it carries the procedural history # ↑ Contents

Reading it as a list of documents is what left hb-643-136-introduced with two open questions it did not need. Each entry also carries the sponsor roster with an active flag and party, the subject taxonomy, an official local_impact_statement, governor_signed_date, concurrence_date and effective_date — and it advertises two continuations:

meetings     /api/v2/general_assembly_{GA}/legislation/{bill}/meetings/
amendments   /api/v2/general_assembly_{GA}/legislation/{bill}/amendments/

meetings is the committee history: date, time, chair, and whether the sitting was canceled.

An empty array from either is only evidence once the endpoint is shown to fill. Measured 9 September 2026: H.B. 96 of the 136th returns 99 meetings, H.B. 186 returns 14, and H.B. 643 returns 0. Without that control, “no committee history was retrieved” and “no committee history exists” are the same observation, and only the second is a finding.

What the endpoints still cannot say is whether a bill is dead. Zero meetings is the same record for one that will be heard next month and one that never will, and the General Assembly publishes no marker for the difference.

The enrolled entry dates both halves of an act, and one date field is not what it says # ↑ Contents

The EN entry’s effective_date is a single date, and for a budget act it is the appropriation half. The codified half is in a free-text field beside it, effective_date_notes — for H.B. 66 of the 126th, “Certain provisions effective 2005/09/29; certain other provisions effective on other dates; contains item vetoes”. Read 29 September 2026 across twelve acts, from H.B. 94 of the 124th to H.B. 96 of the 136th, it agrees with the date on LSC’s enrolled analysis (LSC Budget Analysis — H.B. 96 (FY2026-27)) for every act where both have a value.

Two do not have one. H.B. 64 of the 131st and H.B. 110 of the 134th return every date field null on all of their versions, so their dates rest on the LSC cover alone.

governor_signed_date is not the signing date for five of them. It reads 12 July 2005 for H.B. 66, 11 July 2007 for H.B. 119, 28 July 2009 for H.B. 1, 12 July 2011 for H.B. 153 and 11 July 2013 for H.B. 59 — eleven to fourteen days after the date the same record, and LSC, give for the appropriations taking effect, which cannot precede the signature. What it records instead is not stated. Read the signing date off effective_date for an act whose appropriations took effect on signing, and never off this field.

A digest here pins the renderer as well as the document # ↑ Contents

00_IN cannot be amended, which is the whole reason it is safe to pin. It still moved.

hb643-136-introduced was pinned 20 August 2026 at ea8896c5…, 11,817 bytes. Re-fetched 9 September it is 12d3a532…, 11,828 bytes, and edfund-connect verify reports “The publication was revised.” It was not. The department’s exporter went from LibreOffice 24.2.7.2 to 25.8.6.2, which reorders CSS properties inside style attributes and fills in an empty <title>. Stripped of markup the two are byte-identical across 3,798 characters.

So a digest mismatch on this host is a prompt to read the diff, not a finding on its own — which is what the tool’s message asks for. Expect the four enrolled PDFs from the same service to drift for the same reason whenever that exporter is upgraded.

And nothing here notices unprompted. fetch is the only command that touches the network; verify compares the cache against the manifest. An upstream change is invisible until someone re-fetches, so the digests are a cache-integrity check and not a freshness check.

What this can be trusted for, and what it cannot # ↑ Contents

It can be trusted for what a sponsor proposed. The text is the document, served as HTML with the amended sections inline.

It cannot be trusted as a description of what will happen, and the reason is stronger than the ordinary caution about proposals. A bill’s text moves under its own URL — 00_IN is stable, but a reader who cites “H.B. 643” without a version is citing whichever stage is current when somebody follows the link. Anything read from here is pinned by digest for that reason, and a draft-legislation node states the version it was written from in a field of its own.

It carries no fiscal analysis. The Legislative Service Commission’s bill analyses and fiscal notes are separate documents that lsc-budget does not retrieve — the gap Sub. H.B. 583 (2022) — corrective and technical changes to the Fair School Funding Plan already records for an enacted act, and it applies with more force to a pending one, where the LSC note is often the only estimate anybody has. open

Why no parser # ↑ Contents

There is deliberately none, and this connector stays at retrievable rather than being wired. Turning a bill into provisions is reading, not extraction: deciding that a section amending R.C. 3310.032 changes eligibility rather than an award amount, and that no lever in this repository expresses it, is a judgment about the funding system. A parser that produced a provision list from section headings would produce something that looked authoritative and was not.

What the retrieval is for is the text itself, pinned, so that a draft node can be checked against the document it claims to describe.