The Placentia Corrections
Fourteen corrections, a sixty-day clock, and the stucco note that explains everything.
Cameron pulls up the letter mid-call. Second or third round with the City of Placentia on a property at North Jefferson — he's lost count. "Instruction information for the next plan review. Please resubmit complete sets of hard copy plans and supporting documents in response to the comment list of the City of Placentia."
Fourteen corrections. Some are straightforward — add governing codes to the cover sheet, specify the stucco type. Others require documentation the designer doesn't have yet. Sewer load calculations. The size of the existing waste line. Fixture counts. Things that mean a site visit, a phone call to the engineer, and another sixty-day review cycle before anyone looks at it again.
"And that's the thing," Cameron says. "It's always back and forth. And sometimes the designers could be backed up. Every time there's a correction, it's another sixty days for them to review. For this stupid correction, you wait another sixty days for them to correct it."
He's running twenty jobs. He doesn't do the submittals himself — that's his designer, a third party — but he feels every delay downstream. Each correction cycle isn't just paperwork. It's a client wondering why their ADU isn't moving. It's revenue sitting in a pipeline that nobody can unclog.
He shares his screen. The corrections letter is a PDF — dense, formatted like it was printed from software built before most of his crew was born. Cameron walks through the structure: comment number, the sheet it references, the specific ask. "Add this to governing codes on the cover sheet." "Specify what type of stucco." "Provide documentation of adequate utility service for the increased plumbing load."
"So your AI can kinda go through and just do that automatically," he says. "And if it doesn't know the answer, you can prompt it — hey, what do you input here?"
That's when it clicks. Not the corrections themselves — those are mechanical. What clicks is the workflow. The letter arrives. The designer reads it, cross-references each comment against the plan set, figures out what they can fix immediately versus what requires new information from the contractor or engineer. Then they compile a response, revise the drawings, resubmit. The whole cycle is research, cross-reference, draft, wait.
We feed the system Cameron's plan set and the corrections letter. No special formatting, no pre-processing — just the raw PDFs, same as they'd arrive in anyone's inbox. The AI parses the corrections, maps each one to the relevant sheet, looks up the applicable code sections from the HCD handbook and the city's published guidelines, and starts generating a response.
Some corrections it can resolve outright — the ones that just need a code reference added or a note placed. For the rest, it generates questions. Specific ones. "What is the size of the existing waste sewer line?" "What is the permanent number of fixtures?" The things you'd need a site visit or a phone call to answer.
A few weeks later, we run the demo live with Cameron and Mario — a designer he connected us with who teaches at Long Beach State and runs his own drafting practice. Mario's watching the corrections analysis populate in real time.
"So you basically added the PDF of the corrections that Cameron received," Mario says. "And it summarized it."
Not summarized, exactly. Mapped. Each correction tied to a sheet, a code section, and either a resolution or a question. The response letter drafts itself as the analysis runs.
Then Mario spots something. The AI references sheet A3 for a correction that should point to the site plan.
"That's not the site plan," he says.
He's right. A3 is the roof plan. The site plan is A1 — the second or third page, not the seventh. The AI had the right idea — it even said "site plan" in its notes — but pointed to the wrong sheet.
"Try A1," Mario says. One page back. There it is.
A small thing, maybe. The kind of mistake a designer would catch in seconds. But it matters because it draws the line honestly. The response letter, the code lookups, the contractor questions — those landed. The spatial awareness of which sheet is which in a sixty-page plan set — that needs work.
"I would still go in and manually place it," Mario says about the revision clouds. "But if AI tells me where to put them and what the correction is? That's helpful. That saves me time."
The call runs long. Mario starts talking about a project in Costa Mesa with minor corrections, offers to send it over. Cameron mentions a new one coming through. The energy shifts from "let me show you this thing" to "send me more."
Mario's take is practical, the way you'd expect from someone running a one-person shop: "For someone in my position, this would help a lot for smaller teams. For bigger companies, they have designated people that only do corrections. But I can see it still being a helpful tool."
Cameron's thinking bigger. "If you can figure this out — if you sell some sort of software to the cities... that's a ton."
But the thing that sticks is something Cameron said earlier, almost offhand, when we were talking about why corrections happen in the first place: "Why don't we specify the stucco type in the beginning? Just so we don't have the correction. Let's get ahead of the horse here and put as much information as possible. That way, there are no corrections."
Sixty days. For a stucco label.
That's the whole thing, really. Not the AI, not the software. The fact that somewhere in California right now, someone's ADU is sitting in a queue for two months because a plan set didn't specify something that everybody already knew. And the person who could fix it in thirty seconds won't see the letter for weeks.
The corrections letter from Placentia had fourteen items. Most of them could have been caught before the plans were ever submitted. That's not a corrections problem. That's a pre-check problem.
We're building for that.