ZoneForm

ZoneForm turns a Toronto address into what the property can actually support, drawn in 3D over the real lot. It reads the zoning the City already publishes and renders it as a buildable envelope, a set of graded scenarios, and a report a client can be handed.

It serves both ends of the same question. Someone adding a garden suite for a family member, and a broker testing a tower downtown, are asking what the by-law permits here. The answer has always existed in the City's data. Getting to it meant reading zoning across separate portals and holding a three dimensional shape in your head from a page of setback numbers.

It began at Metrohomes, much smaller, as a way to answer a question that kept stalling client meetings. A homeowner would ask what they could build, and the honest answer took a week of somebody reading by-laws.

The small version did two things nobody had planned for. It converted: people arrived at the site, asked about their own address, and turned into enquiries. And it changed the meeting itself, because the team could now walk in with a diagram of the property and explain it before the client had worked it out themselves.

Once both of those were clear, the shape of a much more sophisticated product was obvious. I looked for one and found nothing on the market that covered this ground, which is usually a warning and occasionally a gap. This was a gap.

The product's whole value is that none of it is invented. Everything on the screen is backed by data that already exists, presented in a way a person can actually use. That sounds like a technical property and it is really a design constraint, because it decides what every screen is permitted to say.

So the first thing I designed was the evidence ladder: what a claim has to be standing on before the interface is allowed to print it. A number measured from City parcel geometry sits on one rung. A number derived from a by-law clause sits on another. A judgment the City makes and no dataset holds does not appear at all.

The same rule governs the assistant. It answers only from the property that is loaded, cites the data layer behind every claim, refuses questions it has no evidence for, and carries the verify-with-the-City line on anything zoning-adjacent. Refusing well turned out to be an interface problem rather than a model one: a refusal has to say what it would have needed, or it reads as a broken feature.

The features that did not ship describe the product better than the ones that did, because each was cut for a reason I had to go and measure.

Keeping the house that is standing. Merging lots ships, and so does the envelope a merged site would carry. What does not ship is the version where you keep the existing house and add to the rest of the site. Probed against twelve real assemblies across three Toronto blocks it placed on three, and two of those three fit only because the City's building layer returned nothing there.

That asymmetry is the whole ruling. Under full redevelopment, a house the City failed to map costs nothing, because the claim already assumes it is gone. Keep the house and the same missing building makes the drawing false: a new block sitting on a home that is still there. Identical data, harmless in one model and forbidden in the other. It is not a precision problem to be tuned. It needs a building source that records what it did not survey, and no such source exists.

Adding up what a merged site holds. The arithmetic is trivial and the product refuses to do it. What ships is the single form that was actually placed by exact containment on the welded lots, and separately the envelope's own ceiling, each labelled as which it is, because a ceiling is not a promise that anything fits inside it. Two words are banned from that sentence and a check greps for both on every commit.

Grading how likely an approval is. When the engine refuses a design it would be useful to say how hard the exception would be to get. Whether an ask counts as minor is the Committee of Adjustment's four-test judgment, and it is not derivable from anything the City publishes. What ships names which standard refused the design and which City process exists for that kind of ask, both facts of law, and leaves the odds to the reader. The function takes the refusal itself as its argument, so the sentence cannot be built against a design that fit. The compiler refuses before a reviewer has to.

Three times on this project the answer was the smaller true thing, and it was the right answer three times.

A residential engine that grades garden suite, multiplex and new build against By-law 569-2013, clause by clause, and draws the envelope each one is entitled to.

A commercial engine that runs a ladder from as-of-right through mid-rise, tall building and land assembly. Each rung carries its own evidence tier, floor area and unit estimate, so a scenario that rests on a policy argument is visibly not the same kind of thing as one that rests on the zoning string.

The geometry is written by hand: polygon containment, parcel welding, setback erosion on a raster. Eight runtime dependencies, because the parts that had to be correct were the parts worth writing.

And the report, which is where the product stops being a tool and becomes something a person hands to somebody else. Two white-labelled documents and a spreadsheet, all rendered from one model so their figures cannot disagree, each number carrying the source it came from.

Test every change, including the small ones. The features here overlap more than they look like they do: adding one often moves how the engine calculates something three screens away, and the only way to know is to go and check.

Testing is less interesting than building the thing, and it is what decides whether the thing reaches what it could be. It is worth as much as the idea, because an idea that does not flow properly into the rest of the application is not finished yet.