Community Coliving

Module unit

Zoning Data Factory

The in-house pipeline turning municipal ordinances into canonical, investor-readable zoning records.

Overview · Modules · Zoning Data Factory

What it is

Ordinances in, canonical records out

The zoning data factory is our in-house pipeline for turning municipal zoning ordinances into canonical, investor-readable jurisdiction records. Ordinances are written by and for city attorneys; investors need to know what a parcel actually permits, in plain words, with an honest statement of how sure we are. The factory closes that gap jurisdiction by jurisdiction and the whole platform reads the result. This is one of the two proprietary data assets named in architecture section 12, and it is an owned, compounding asset, not a licensed feed: every finished jurisdiction stays in the corpus at a quality bar we control.

The obvious alternative is licensing zoning data from a third party. We build the corpus in-house instead because a licensed feed cannot carry our provenance discipline: we would be re-serving someone else's confidence claims without being able to defend them. Building the factory cost us time up front. What it bought is a data asset where every claim traces to an ordinance a human can go read.

The questions it answers

For the investor and the operator

Through the surfaces that consume the corpus:

For the reader of this package: how we produce a trustworthy legal-text data asset, and why we believe the quality holds as the corpus grows.

Scope and boundaries

What it owns, and what it does not

The unit owns the path from a municipal ordinance source to a canonical jurisdiction record accepted into the corpus, and it holds that path to the guarantees below: nothing invented, nothing silently missing, independent review, and honest confidence. It ends at the corpus: the analysis engine (architecture section 11) reads canonical records through the warehouse boundary and renders the zoning report from them; the coverage unit reports which jurisdictions are covered, partial, or not yet. The factory never writes into deals, reports, or any tenant's data. It produces reference truth; other modules decide what to do with it.

What it is NOT

Withheld by design Tier 3

The extraction specification's contents, the gate list, source acquisition methods, how extraction work is organized and scaled, and tooling choices inside the pipeline are withheld by design and held at Tier 3, as is a walkthrough of the pipeline itself against a real jurisdiction.

The contract

The unit's public shape

No fields, no schemas, no payloads; responsibilities, the write door, events, guarantees, and refusals only.

Responsibilities

The write door

Like every module, the factory has one write door, and the corpus is written through it or not at all. The door admits a small set of business-named commands, and what it enforces is the point: nothing becomes readable by the platform except a record that passed the quality gates and independent review, and a record may claim an absence only when the absence was actually checked, so downstream readers can distinguish "checked and absent" from "not yet examined."

Withheld by design Tier 2

The command roster is held at Tier 2.

Events announced

Events carry identity plus the business fact, never a data dump.

Guarantees

Refusals

What done means

The gates a change passes

A jurisdiction is done when an investor can read its canonical record and act on it: what the districts permit, stated in investor language; where the parcel boundaries of confidence sit; and, for every rule the record does not carry, the assurance that we looked. Done is not "we extracted the ordinance." Done is "the record survived every gate, a second set of eyes with no stake in the extraction confirmed it, and what the reader sees says what the record says."

We hold this bar because the failure mode of a zoning data product is quiet: a wrong permitted-use claim does not crash anything, it just misleads an investor months later. The gates exist to make that failure loud at build time instead.

Every candidate record climbs a ladder of quality gates defined by a binding extraction specification. The specification is the contract the extractor works against and the standard the reviewer audits against; neither party improvises. The ladder checks the record at more than one altitude, because we have designed for the case where a record is right in one place and wrong in another; a record that is correct in only one of the places a reader could meet it has not shipped.

Above the mechanical ladder sits independent review: a reviewer who did not produce the extraction audits it. This is our standing rule that the writer is never the auditor, applied to data production. We adopted it because self-review converges on the extractor's own blind spots, and legal text is exactly where blind spots hide.

District matching against GIS is gated on conservatism: the match is recorded at the confidence the spatial evidence supports. Where the evidence is ambiguous, the gate requires the record to say so.

Withheld by design Tier 3

The specification's contents and the concrete gate list are held at Tier 3, as is a walkthrough of the pipeline against a real jurisdiction.

The failing cases

Honest-state behaviors

Where it connects

The spine sections this unit realizes

Addi architecture disclosure · v1.0 · 2026-07-31
All modules · Traceability