- Section 104 CDBG
- Reference schema
Section 104 has been in effect since October 1, 2026 · HUD had not published a format as of September 28, 2026
Two ways to ship your Section 104 database.
Adopt our open format and build it in-house, or build it with us from the list you have. Either way your staff confirms every row and your jurisdiction certifies.
Machine-readable version: https://buildability.us/schema/104.json
Which path?
Two ways in. Same schema.
The 21st Century ROAD to Housing Act (P.L. 119-101) added a certification requirement to CDBG. HUD had not told grantees what a “publicly accessible, searchable database” needs to look like as of September 28, 2026. A mid-sized city with a planning GIS team can adopt the schema and build it themselves. A small city with no IT staff shouldn’t have to. Your jurisdiction certifies either way.
Build it with us.
Building and checking your inventory is free. Publishing it is an annual licence, priced by your FY26 CDBG allocation.- Upload the list you have, or ask us to attribute it from county assessor records.
- We match each parcel to the record, format it to this schema, and host it on a searchable page you can link or embed.
- Your staff reviews the list before it goes public and confirms which parcels qualify.
- You certify. We do not and cannot.
Adopt the schema yourself.
CC0 public domain. No vendor lock-in.- Your team (or your existing GIS vendor) emits a
104.jsondocument from your pipeline. - You host it at a stable URL on your own site. That is how the “publicly accessible” test is usually read; your counsel decides.
- Every parcel row cites the assessor record it came from, so your staff can check any row against its source.
- If HUD publishes an official format later, the schema updates additively. 1.x is stable.
Not sure? If your staff can name your GIS vendor and reach them today, adopting the schema yourselves is straightforward. If not, build it with us. The list and its exports are yours either way.
What the format is
One document per grantee. Every claim traceable.
Whichever path you take, the shape is the same. One JSON document per grantee. Machine-readable, publicly hostable, versioned.
- 01
One document per grantee.
An entitlement city, urban county, or state program each publishes its own
public-land.jsonat a stable URL on its own site. The document describes the grantee, the methodology, and the parcels. - 02
Every row cites its source.
Each parcel row carries a
sourceUrlback to the assessor record it derives from and alastVerifiedIsodate. Your staff never has to defend a number they can’t trace. - 03
Methodology travels with the data.
Your operational definition of “undeveloped,” your ownership source, and the entities you excluded all sit in a
methodologyblock inside the same document. When a council member asks how you decided, the answer is one link.
For your GIS team or vendor
Ten required fields. Every one derived from records you already have.
The reference for the technical reader: your GIS lead, your permit-tech vendor, or the developer who’ll wire the export. Every required field maps to one of the four statutory tests and is derivable from county records.
| Field | What it contains | Why it’s required |
|---|---|---|
grantee.name / state / granteeType | The jurisdiction the document describes. Full name, two-letter USPS state code, and one of entitlement-city / urban-county / state-program. | Every published database has to say which grantee it belongs to. HUD's own formula-grant categorisation is the natural axis. |
methodology.undevelopedDefinition | The grantee's operational definition of "undeveloped." Free text; be specific about use codes, building-footprint thresholds, or other rules applied. | The statute does not define "undeveloped" and HUD has not issued implementing guidance. Publishing the definition next to the data lets a reader audit the scope. |
methodology.ownershipSource / parcelSource | How the grantee determined which parcels it owns and where the underlying parcel data came from. Typically county assessor records attributed by owner name. | Every claim in the database has to trace back to a public record. These two fields tell the reader which record set to trust. |
methodology.excludedEntities | Redevelopment authorities, dependent housing authorities, land banks, and other adjacent entities that are NOT rolled into this document. | Silent exclusion is the compliance failure mode we see most. Naming excluded entities on the record makes the scope decision defensible. |
parcels[].parcelId | Assessor parcel identifier: APN, PIN, or equivalent. Unique within the document. | Every row needs a stable identifier so a consumer can join back to the assessor record. |
parcels[].location | Either a USPS address or a centroid latitude/longitude. At least one is required. | A resident has to be able to find the parcel on a map. Address for platted lots, coordinates for unaddressed acreage. |
parcels[].acres | Positive number. Never zero-as-placeholder. | Acreage is the single most common filter a downstream reader applies. Absent or zero-acre rows silently break search. |
parcels[].ownershipEntity | The exact grantee-owned entity of record on the parcel. Matches the owner-name string on the assessor record. | Verifiability. A reader has to be able to look up the assessor page and see the same name. |
parcels[].sourceUrl | URL of the primary record the row derives from, usually the county assessor's parcel page. | Every finding links back to the record it cites. Without this, "grantee-owned" is a claim the reader can't defend. |
parcels[].lastVerifiedIso | ISO 8601 date the row was last verified against the primary source. | Assessor records change. A four-month-old "verified" date is a claim the current record may not support. |
Optional fields (recommended, not required)
- parcels[].useCode: assessor use-code (often the primary evidence a parcel is undeveloped)
- parcels[].zoning: current zoning designation
- parcels[].dispositionStatus: available / under-review / planned-use / encumbered / not-for-disposition
- parcels[].buildabilityScore: third-party scoring (system, version, score, grade); cite the system so scores from different providers stay distinguishable
- parcels[].notes: parcel-specific caveats (easements, hazard flags)
- documentUrl: canonical URL where this document is published
- grantee.hudGranteeId: HUD internal grantee identifier if published
- grantee.contactEmail / contactUrl: corrections channel
- methodology.certifiedBy: the grantee official who certified this database
Adoption, four steps
If you’re adopting yourself, here’s the whole path.
For the technical reader. If you’re building with us, skip this section. We run these steps on your behalf and hand you the URL when it’s live.
- Generate the JSON. Any pipeline that produces the ten required fields, in the required shape, conforms. Emit from your GIS, from a spreadsheet export, or from a hand-maintained CMS. The schema does not care.
- Validate. Point any JSON Schema validator at
/schema/104.jsonto check your document. We recommend jsonschemavalidator.net in the browser, orajvon the command line. - Host at a stable URL. Serve the file at a URL on your jurisdiction’s own site. This is the “publicly accessible” test. Set
Content-Type: application/json. Regenerate when rows change. - Register it in the readiness index. Tell us the URL and we’ll consume it in the next attribution run. That surfaces your conformance publicly and gives HUD an aggregate view without anyone having to hand-collate.
Not building this yourself? See the product on your city’s parcels
Questions we get from grantees and vendors.
How long does each path take?
Building with us starts the day you upload the list you have, or ask us to attribute it from county records; your staff reviews every row before anything is public. Adopting the schema with an existing GIS vendor is typically 2–4 weeks.
What if our council asks why we didn't pick a HUD-approved standard?
HUD hasn't published one. That is the problem this schema exists to solve. The right answer to the council is: "HUD has not issued a data format for Section 104; we adopted an open reference published under public domain that maps every field to one of the four statutory tests. If HUD publishes a conflicting standard, our format updates additively and we re-issue." That is a posture your counsel can stand behind.
Does adopting the schema (or building with us) make us compliant?
No. Your jurisdiction certifies, with its counsel; we do not and cannot. The schema is a data format and the inventory is a data service. Every required field maps to one of the four statutory tests, so a conforming document with real, current data is evidence for your file, not a ruling.
What is free and what does the licence cost?
Building and checking your inventory is free. Publishing it is an annual licence, priced by your FY26 CDBG allocation. Matching your parcels, the review sheet, CSV/GeoJSON exports and the methodology memo cost nothing; the hosted public page, embed and feature layer are the licence. The schema itself is CC0 and always free.
What if we already have a public inventory in a different format?
Keep it. This schema is a machine-readable companion to your existing interface, not a replacement. Cities can host their interactive search on their own stack and serve /public-land.json alongside it. If your current format already covers the ten required fields, we can help translate to this schema without you changing anything visible to residents.
What license is it under?
CC0 1.0 (public domain). Adopt it, fork it, embed it in a vendor product, or use it as a starting point for a HUD rulemaking. No attribution required. We publish it in the open because a shared format is more valuable than a proprietary one. A city that adopts this owes us nothing.
What happens if HUD publishes their own format later?
If it's compatible, the schema updates additively within 1.x and your document keeps validating. If it conflicts, we publish a migration path and version 2.0. Either way, a document adopted today stays a good-faith record of what you published. HUD's later format doesn't retroactively invalidate a good-faith Section 104 database.
Can HUD ingest this?
That's the intent. Every field name and constraint was chosen so a HUD analyst could concatenate documents across grantees and answer basic questions (how many acres, how many parcels, how many grantees have published) without hand-collation. If HUD wants a direct feed, buildability.us/cdbg is the aggregate today; a formal read-only data endpoint is a follow-on.
Start with the list you have.
The schema is free. Building the list is free. What your own code allows on each parcel is where the work starts.
Confirm findings with your own records and counsel before certifying.