Filing a real street-work permit application from a chat, end to end
A structured street-work permit, with a repeatable group of streets and a real attachment, filed for real from a conversation and accepted by the city's own system.
A permit application is usually the least chat-shaped thing a municipal website offers: multiple streets to name, a reason, an attachment, a real document that a back-office system has to receive as a real file — not a description of one. A live municipal deployment filed exactly this kind of form from a conversation, end to end, and the city's own system accepted it.
What the form actually asked for
The request — a street-work permit — needed a repeatable group of inputs (more than one street, each with its own detail) and a file attachment, both handled as declared, structured fields rather than free text a person on the back end has to interpret. The submission reached the city's real intake system and was filed for real, carrying its street rows and one PDF attachment, with a reference number the resident could keep: YZM-2609-00033.
Why the repeatable-group part matters beyond this one form
Handling "more than one of something" inside a structured submission — not a paragraph describing several streets — needed a capability binding that declares which inputs form a repeatable group, so the same mechanism now exists for every tenant's forms, not a one-off built for this permit. The same effort closed three separate defects sitting in series on the attachment path, from a field dropped at one hop to a storage client that hadn't been registered at all — each one hiding the next until every one of them was found.
What a resident experiences
No portal to find, no separate login for permits, no attachment emailed separately and matched up by hand later. The same conversation that can answer a balance question can also take a structured request with an attachment and hand it to the city's real system — filed, not just drafted.