Two ways to ship your Section 104 database. Pick the one that fits your team.
Adopt our open format and build it in-house, or let us assemble the whole thing free. Either way you're compliant on .
The 21st Century ROAD to Housing Act (P.L. 119-101) added a certification requirement to CDBG. HUD has not told grantees what a "publicly accessible, searchable database" needs to look like. This page is a plain-English answer plus a machine-readable format — released under CC0, so your city, your vendor, or HUD itself can use it without a licensing conversation.
Machine-readable version: https://buildability.us/schema/104.json
Two ways in.Both compliant. Both free.
Cities are shipping this on very different runways. 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. Both roads lead to the same certification.
Have us build it — free
No signup. No card. No pilot that converts.
- We assemble the parcel list from county assessor records attributed to your jurisdiction.
- We format it to this schema and serve it on a URL at your own domain (or ours — your choice).
- 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 satisfies the "publicly accessible" test.
- Every parcel row cites the assessor record it came from, so your data stays defensible.
- If HUD publishes an official format later, the schema updates additively — 1.x is stable.
Not sure? The free build is designed for cities that would otherwise miss the deadline. If your staff can name your GIS vendor and reach them today, you probably have enough runway to adopt the schema yourselves. If not, take the free build — the list is yours either way.
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. Below is the plain-English tour.
One document per grantee
An entitlement city, urban county, or state program each publishes its own public-land.json at a stable URL on its own site. The document describes the grantee, the methodology, and the parcels.
Every row cites its source
Each parcel row carries a sourceUrl back to the assessor record it derives from and a lastVerifiedIso date. Your staff never has to defend a number they can't trace.
Methodology travels with the data
Your operational definition of "undeveloped," your ownership source, and the entities you excluded (redevelopment authority, land bank, etc.) all sit in a methodology block inside the same document. When a council member asks how you decided, the answer is one link.
Ten required fields.Every one derived from records you already have.
This is the reference for the technical reader — your GIS lead, your permit-tech vendor, or the developer who'll wire the export. Nothing here is speculative; every required field maps to one of the four statutory tests and is derivable from county records.
grantee.name / state / granteeTypeThe 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.undevelopedDefinitionThe 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 / parcelSourceHow 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.excludedEntitiesRedevelopment 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[].parcelIdAssessor 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[].locationEither 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[].acresPositive 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[].ownershipEntityThe 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[].sourceUrlURL 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[].lastVerifiedIsoISO 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.
- 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
If you're adopting yourself.Here's the whole path.
For the technical reader. If you're taking the free build, 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? We host the whole thing free →
Questions we get from grantees and vendors
We have weeks left, not months. Can we still meet the deadline?
Yes, on either path. The free build turnaround is typically 5–10 business days from the moment your staff confirms the parcel list — we do the assembly work while you review. Adopting the schema yourself with an existing GIS vendor is typically 2–4 weeks. Either way, October 1 is achievable if you start this week.
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 posture is defensible in front of any auditor.
Does adopting the schema (or using your free build) make us compliant?
No. Your jurisdiction certifies compliance; we do not and cannot. The schema is a data format and the free build is a data assembly service. But every required field maps to one of the four statutory tests, so a conforming document with real, current data is the evidence you carry into certification. Your counsel signs off; we don't.
What does "free" actually mean? What are you going to charge us for later?
The parcel list, the schema-conforming JSON, a hosted searchable interface, CSV/GeoJSON exports, and a methodology memo for your file — all $0, no card, no contract that converts. What we sell is the layer on top: scoring every parcel for what it can support and helping the council figure out disposition. That's a separate conversation your city can decline entirely.
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 is the evidence you shipped on time — 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 compliant on Day 1) 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.
20 days.
The schema is free. The hosting is free. What can be built on the land after October 1 is where the work starts.
See the readiness indexConfirm findings with your own records and counsel before certifying.