Catalog-Grounded, Not Guessed: An AI Scoping Tool for Physical Installation Work

A scoping call for a low-voltage or smart-home installation project produces a transcript full of scattered, half-formed requirements — camera counts mentioned in passing, a network closet described but not measured, an offhand comment about a client's own equipment they want reused. Turning that into a structured, accurately priced scope of work is normally manual, slow, and dependent on whoever's writing it remembering the right SKUs and install-hour estimates from memory. I built a tool that does that conversion directly, and grounds every output in a real product catalog instead of letting a model improvise pricing.

Two ways in: transcript or photo

The tool accepts either a scoping-call transcript as text, or a photo of a floor plan or project document. The transcript path is a straightforward text-extraction prompt. The floor-plan path is more interesting: the image goes directly to a vision-capable model as multimodal input, and the extraction prompt asks it to identify technology-infrastructure requirements straight from the drawing — the same structured-output contract as the transcript path, just a different input modality feeding it.

Catalog grounding: the model doesn't price anything

The design decision that matters most in this system: the model is never asked to remember a SKU or a price. The full product catalog — item name, brand, SKU, price, install hours — is passed into the prompt as context on every request, and the model's job is to match each extracted requirement to a real catalog entry wherever one exists. If nothing matches, it can describe the item, but it cannot invent a price for it. That's a deliberate anti-hallucination constraint: pricing accuracy doesn't depend on the model's training data being current or correct, because the model is never the source of the price — it only ever points at data that was handed to it in the same request.

A schema the front end can actually use

The output is constrained to a specific JSON structure — a short summary, a line-item array (each tagged with a catalog match or flagged as client-supplied), assumptions, out-of-scope items, client dependencies, and labor notes — rather than a paragraph of prose a human then has to reformat into a proposal by hand. That schema constraint is what turns a language-model output into something a UI can render directly as a usable, editable proposal, instead of a novelty summary someone still has to do real work on afterward.

The part that actually compounds: a persistent assumptions library

The most interesting mechanism in the whole system has nothing to do with the model call itself. Every generated proposal produces assumption and scope-of-work language — the boilerplate-but-necessary sentences about what's included, what isn't, and what the client needs to provide. Rather than regenerate that language from scratch on every single proposal, any accepted line can be promoted into a small persistent library, keyed by job type and section, stored in a lightweight key-value store rather than a database. The next proposal for that same job type draws on the accumulated library instead of starting cold.

It's a deliberately low-tech mechanism — no fine-tuning, no embeddings, just a deduplicated list that grows through actual use of the tool — but the effect is that output quality compounds over time instead of staying static. Every proposal a human reviews and accepts makes the next one for that job type slightly better calibrated, without retraining anything.

From approved scope to populated document

The first version of this system called a document-generation API directly — populate a real template with tokens and a pricing table, get a finished document back with no human retyping anything. That path still exists in the code. It is not what actually gets used.

In practice, the tool now generates the structured SOW sections — scope, assumptions, out-of-scope, client responsibilities — formatted as clean, copy-ready text with the exact variable names the document template expects, and a person copies each section into the corresponding field by hand. That is a deliberate step back from full automation, not an unfinished version of it. Direct API document creation meant every project type's template and token structure had to be mapped and kept in sync in code — brittle across multiple document types, and one more thing to break silently when a template changed on the document platform's side. The copy-ready output gets almost all of the time savings with a small fraction of the ongoing maintenance surface, because a human doing the actual pasting catches a mismatched field immediately, in a way an API call failing silently does not.

The lesson generalizes past this one tool: full end-to-end automation of the last step isn't always the better engineering choice once you count the ongoing cost of keeping it correct. Sometimes the right stopping point is generating something a human can place correctly in five seconds, not eliminating the five seconds.

Where the real engineering time went

The AI portion of this system — a structured-extraction call constrained by a JSON schema and grounded against inline catalog data — is a comparatively small piece of the total build. The real engineering time went into the surrounding structure that makes the model's output trustworthy and reusable: the catalog-grounding pattern that keeps pricing accurate, the schema constraint that keeps the output directly usable, and the persistent assumptions library that lets the system's quality compound with use instead of resetting to zero on every single call. None of that shows up if you only look at the prompt.

I'm Jesse Myers — Marine veteran, 32 years in enterprise IT, now building production AI systems. This site is where I write about what I've actually built, technically, in my own words.