If you ask a capable LLM to review a mechanical schedule against a LEED energy prerequisite, it may give you a fluent, confident, plausible-sounding answer. Getting a model to produce convincing LEED-related language is no longer the hardest problem.

The hard part is what happens after the model answers.

The prompt is not the product

A specialized prompt genuinely helps. A generic "does this comply with LEED?" question invites a generic, unreliable answer. A prompt that is scoped to the exact credit, category, and requirement language does much better — it narrows the model's attention to the right threshold, the right units, the right prerequisite language instead of a vague sense of "green building."

That is why, in practice, LEED credit analysis is not one giant prompt asking a model to "check the project." It is broken down by category (Energy and Atmosphere, Water Efficiency, Sustainable Sites, and so on) and by the specific credit inside that category, each with its own system instructions and its own framing of what "compliance" means for that credit. A Water Efficiency question and an Energy prerequisite question are different tasks wearing the same "ask an AI" costume, and treating them identically is where a lot of naive LEED-AI tooling falls down.

So specialized, credit-aware prompting is a real improvement over generic prompting. It is also, on its own, nowhere near enough to produce something a LEED reviewer will accept.

A good answer is not the same as usable evidence

Here is the gap. The model's response is text. A LEED submittal is not evaluated on how well-written the text sounds — it is evaluated on whether a specific claim can be traced back to a specific, verifiable source: a schedule, a calculation, a site measurement, a compliance test result.

An LLM response by itself carries none of that. It does not know, on its own, whether the number it produced came from a real document you uploaded, from a calculation performed elsewhere in the pipeline, or from the model filling in a gap with something statistically plausible. Read purely as text, a correct extraction and a confident guess look identical.

That is the actual failure mode worth worrying about. Not "the model is wrong" in some obvious way that a human catches immediately — but "the model produced something that reads exactly like a correct, sourced answer, and it takes real effort to tell the difference."

A high-quality prompt narrows what the model is asked. It does nothing to answer the separate question: where did this specific claim actually come from, and can I show that to a reviewer?

What closes the gap is not a smarter prompt. It is a place for the answer to live.

The fix is not "iterate on the prompt until it stops guessing." The fix is architectural: every piece of output has to land somewhere that tracks what kind of evidence it is and where it came from, before it can count toward anything.

Concretely, that means a small number of things have to be true about the system around the model, not about the model itself:

Every extracted or generated result is categorized as a specific kind of evidence — a calculation, a site measurement, an environmental assessment, an API response, a visualization, a drawing, a photo, a document excerpt, or a compliance/test result. Nine categories, not one undifferentiated bucket called "AI output." A number produced by an energy calculation and a number pulled from a scanned PDF are not the same kind of claim, and the system has to know the difference.

Every stored result carries a source, not just a value. Where a piece of evidence came from — a user upload, a generated calculation, an external API response — is recorded alongside the value itself, not inferred after the fact. If a reviewer or a consultant six months later asks "where did this number come from," the answer should not require reconstructing a chat log.

Nothing gets to skip that path. A model output that never gets categorized and sourced does not get to quietly count as project evidence. This sounds like a minor implementation detail. It is not — it is the difference between "the model said something plausible" and "the project has a documented, traceable claim."

None of this is about the model being smart enough. A smarter model produces smarter-sounding guesses just as easily as it produces smarter-sounding correct answers. The traceability layer is what lets you tell those two apart after the fact, which a better prompt cannot do by itself.

The broader principle: state should be derived, not asserted

This is really a specific case of a more general rule worth building around: the system's understanding of a project should be something that gets derived from a permanent, traceable history of what happened — not something a model (or a person) simply asserts and everyone trusts.

In practice, that means the durable record is the append-only history of what evidence was found, generated, or uploaded, and what the model or a person concluded from it. The current state of a credit — scored, pending, needs-evidence — is something you can always regenerate from that history. It is not a value sitting in a cell that nothing can double-check.

That principle is bigger than any one credit-analysis feature, and it is honestly still a target more than a fully finished implementation everywhere in the system — some parts of the pipeline already work exactly this way today, and extending that discipline everywhere is ongoing work, not a shipped, closed claim. But the direction is deliberate: as more of the analysis pipeline adopts it, the answer to "can I trust this credit's score" stops depending on trusting a single AI response, and starts depending on whether the underlying evidence trail actually holds up.

A worked example: outdoor water use reduction

It helps to walk through one credit instead of talking about "evidence" in the abstract.

Take a Water Efficiency prerequisite for outdoor water use reduction. One compliance path requires showing at least a 30% reduction in landscape water requirement from the calculated baseline for the site's peak watering month, achieved through plant species selection and irrigation system efficiency. To evaluate that, the document set typically includes a landscape plan, a plant schedule listing species and coverage areas, and — when the project is not pursuing the no-permanent-irrigation path — an irrigation controller spec sheet. Somewhere in that stack is the answer to "does this landscape design actually clear the 30% threshold."

A generic prompt asked to "check water efficiency compliance" will often produce a reasonable-sounding paragraph regardless of whether the plant schedule was actually legible, whether the irrigation spec was present at all, or whether it quietly filled a gap with a plausible regional-average number. The output looks the same either way. That is the exact failure mode described above, just made concrete.

A credit-scoped prompt does better at the extraction step: it knows to look for plant species, hydrozone areas, and irrigation efficiency factors specifically, not a vague water-related summary. But extraction quality is still only half the story. What happens next is what determines whether the result is usable:

  • The plant-schedule reading becomes a DOCUMENT category evidence entry, sourced back to the specific uploaded file it came from.
  • Any area or reduction-percentage calculation derived from that reading becomes a separate CALCULATION category entry, so a reviewer can see the math step, not just a final number.
  • If the irrigation spec sheet was missing or unreadable, that credit's water-use-reduction figure is not filled in with a plausible average. It is left as an open, labeled gap — something a consultant has to resolve with a real document, not something the system quietly papered over.

None of this changes what the model is capable of. It changes what happens to the model's output before anyone is asked to trust it. The consultant reviewing this credit later is not asking "did the AI sound confident." They are asking "can I click through to the plant schedule this number came from," and for that question, the categorization and sourcing step is the part that actually matters.

What this means if you are evaluating AI tools for LEED work

If you are a consultant looking at LEED automation tools, the question worth asking is not "how good is the AI." Many product demos will show you a fluent, confident answer — that part is easy now, across much of today's tooling.

The better question is: when the model is wrong, or when it does not have enough information to answer honestly, what happens? Does the tool have a place for "I don't know" that is distinguishable from a real answer? Can you trace a specific claim in the output back to a specific source document or calculation? Or does a confident-sounding paragraph get treated the same whether it is grounded in your actual project files or not?

A fluent answer is cheap now. A traceable one still has to be built for.