A Code Without a Date Is a Rumor

Draw the same apartment corridor in two Texas cities and you may not be checking it against the same book. Both cities start from the International Building Code, but each one adopts its own edition, on its own schedule, with its own amendments.

I've written before that a zoning number without a date is a rumor about the present. The same is true of the building code, and of every limit that shapes what you're allowed to build. The rules are shared. The law is whatever this place adopted, in which edition, with which changes, starting on which date.

This essay is about treating those limits the way software treats dependencies: pinned, versioned and checked continuously while you draw.

The envelope is the first design move

Before anyone designs a unit, entitlements have already drawn a box. Height, setbacks, density, permitted uses and review conditions shape the design space before detailed design begins.

My envelope study uses a 200 × 150 ft lot with equal setbacks on all sides and a fixed 12 ft floor-to-floor. Maximum gross area is the lesser of two numbers: FAR times lot area, and the inset footprint times the number of whole stories the height limit allows. A second study on a 120 × 100 ft parcel adds a fixed 10 ft rear setback and a coverage limit.

The useful lesson is which limit binds. A site can have a generous FAR while its setbacks leave too little practical floor plate to use it. A narrow lot gets choked by setbacks. A wide one can hit its area cap before the envelope is full. Form-based codes describe the container with planes and step-backs instead of a single FAR number, which changes the shape of the box but not the fact that there is one.

Figure out which boundary governs before you arrange anything inside it. That's not a parcel-specific zoning finding, and local amendments and interpretations will move the real envelope. It's the order of operations.

Approval is a negotiation, not a checkbox

The entitled envelope isn't a blank canvas, and an approval doesn't make a project financially viable. Approval is also a negotiation between public and private interests. A proposal changes in response to community concerns, agency requirements and policy goals, and the time it takes can change the feasibility on its own.

That gives architects two jobs: make an approvable proposal, and understand what the approval leaves open. A review condition can become part of the program. So write down who owns each condition and when it has to be resolved, or it'll get resolved for you at the worst possible time.

Shared text, local law

Here's how the code side actually works, because most people outside the profession get it wrong.

A model code is a book written by a private standards body. The International Code Council writes the I-Codes, including the IBC, the IRC and the IFC. NFPA writes the National Electrical Code and the Life Safety Code. A new I-Code edition appears every three years: 2012, 2015, 2018, 2021, 2024. A model code binds no one until a state or city adopts it by statute or ordinance, usually with amendments and an effective date of its own.

So every project has four facts to pin down:

1. The jurisdiction.
2. The base edition.
3. The local amendments.
4. The date that decides which of those apply.

The shared part is the base text. Everything else is local.

One state, several editions

Texas makes the point better than any analogy. The state sets a floor, and cities adopt above it on their own timelines, so more than one edition of the same model code can be in force across the state at once. In Dallas–Fort Worth, cities coordinate a shared set of regional amendments, but each city still adopts them on its own.

A city can also sit on an old edition for years and then jump several at once. And adopting a code and enforcing it are separate events: the adoption date and the effective date differ, and the one that governs your project is whatever the jurisdiction's transition rules say.

One state, one model code family, several editions on the books.

Other states go further. Some republish the model codes under their own titles with state amendments, and some large cities keep codes of their own.

Version pinning, not forking

The software analogy that survives is version pinning, not forking. A city on an older edition doesn't maintain its own IBC. It pins an older release and patches it with local amendments. Cities that pin the same release and share one patch set have the closest thing to a shared dependency this industry has.

I first wrote this thesis as "the building code is open-source law." That title was too generous. The ICC and NFPA hold copyright in their model codes and sell them. The development process is public, and outsiders can propose changes at open hearings, but final votes at the ICC belong to its governmental members. That's public comment on a privately published standard, not a pull request against a GPL repo. Free read-only viewing exists, sometimes behind a sign-in, and the standards a code cites are often sold separately.

Once a jurisdiction adopts a code, though, who can copy and share it becomes a legal question, not a design one.

I'm an architect, not a lawyer. The practical point is simple: "the law" and "the book the law points to" are different objects with different reading rights.

Nothing in the drawing moved

My study for this holds one small unit fixed and asks where and when it's being permitted. Pick a city and slide the permit-application date, and the study looks up which edition governs on that date and runs that edition's minimum room-size checks. The habitable-space rules change between editions, so the same unit can pass under one and fail under the next.

Nothing in the drawing moved. Only the place or the date did. And because the study counts the application month, an application dated in the month a new code takes effect gets no answer at all, and the study says why. That refusal is the whole thesis in small: without a pinned edition and date there's nothing to check against.

Try it: drag the room width, the kitchen width and the permit date, and switch between Houston and Austin to watch the governing edition and the checks change.

A firm working in two cities on the same unit plan can be maintaining two builds of one product.

Zoning should be a linter

Once the rules are pinned, you can do the thing software figured out decades ago: check continuously instead of at the end.

A zoning linter checks a design as it changes and flags measurable conflicts, a setback, a floor-area overrun, before formal submission. My linter study uses example limits: 6 floors, 60% coverage, FAR 2.5, 60 homes an acre, 15 ft setbacks and 1 stall a home. Each repeated floor gives 80% of its gross area to whole 900 ft² homes, and surface parking uses unbuilt parcel area at 325 ft² a stall. Drag the building and watch which limit lights up first.

Try it: drag the parcel corner, the footprint edges, the floor marker and the parking marker, and watch all seven checks update together.

Those limits belong to the example, not to any adopted district. The value is the feedback loop. A designer who sees the warning on every edit learns the limits through repetition, instead of finding them in a comment letter months later.

It needs two things to work: structured zoning rules and a model registered to the right parcel. Where both are reliable, the tool can show exactly which condition triggered the warning.

The permit should run like CI

Push the same idea one step further and you get continuous integration for permits. Today a permit review usually comes after most of the design work, so one discovered issue can ripple through dozens of sheets. Checking selected requirements as the design changes gives the team feedback while it's still cheap.

Try it: step through one submission run like a CI pipeline, from automated checks to the failing parking check that blocks it, then human review and the authority's decision.

Much of the code is arithmetic: occupant loads, exit counts, travel distances, widths. That part should be encoded once and run continuously while you draw. The rest isn't arithmetic. Building officials interpret provisions and approve alternate methods. Overlays, exceptions and discretionary approvals don't reduce to a rule.

So the honest version is narrow. Automated checks handle the explicit rules and let reviewers spend their time on the cases that need judgment. They don't replace the authority having jurisdiction. And a rule engine that reports pass or fail without naming the jurisdiction, edition, amendments and date it checked is linting against the wrong book with total confidence.

The plan is also a legal document

One more kind of rulebook hides inside a plan: ownership. A condominium is a building and a legal arrangement at the same time. The governing documents define unit boundaries, common property, maintenance duties and how owners decide things together.

Those definitions reach back into the drawings. If a boundary puts a balcony, a window or a utility line inside a unit, that can change who maintains it and who's allowed to alter it. The details vary by jurisdiction and by project documents, so a plan alone can't settle ownership. What the design team can do is make sure the physical plan and the legal description say the same thing, early, before buyers find out what they actually own.

What I'd write down first

Before drawing the first egress path, write down the jurisdiction, the base edition, the local amendments and the date that fixes them. That date is usually tied to the permit application, but check the jurisdiction's transition rules. Then tie every requirement to the occupancy and conditions it applies to, and record its source.

The shared rules let you reuse most of a design. The local adoption tells you which parts you can't.

Pin the edition. Then draw.

Check your parcel's envelope against its rules as you draw. Book a TestFit demo and run this on your own site.