ClaraAI Output Review Checklist for Solar Teams

A polished ClaraAI draft can still contain an incorrect input or unresolved assumption. Review the evidence before another person relies on its layout, calculation, or proposal.

Solar professionals already know that a clean drawing can contain a wrong roof edge, a plausible annual-energy figure can rest on the wrong loss input, and a persuasive proposal can conceal an old tariff. AI assistance does not change those failure modes. It changes how quickly an apparently finished output can reach the next person.

This checklist is for installers, EPC teams, designers, sales engineers, and operations leaders who need a repeatable release gate. It treats ClaraAI as part of a supported workflow, not as a source of authority. SurgePV publishes this article and sells the software discussed, so product references are first-party context rather than independent proof of objective performance.

The checks below are team responsibilities, not a claim that ClaraAI automatically performs or enforces each check. Confirm supported commands and outputs in the ClaraAI product walkthrough. NIST’s AI Risk Management Framework is voluntary guidance; applying this checklist does not establish regulatory compliance or certify a design.

Results depend on source data, assumptions, equipment models, configuration, and review. Outputs support design and documentation workflows but do not replace approval by the responsible engineer, authority, lender, insurer, or utility.

Start with the decision, not the screen

A reviewer cannot judge an output without knowing what another person will do with it. A preliminary roof concept used to request better photographs has a lower consequence than a layout attached to a signed scope. An internal scenario used to compare two module choices differs from a customer-facing savings claim.

Write the release purpose at the top of the review record. Good labels include “sales-stage concept from remote evidence,” “design revision for internal coordination,” “customer proposal pending tariff confirmation,” and “package routed for responsible engineering review.” Avoid labels such as “final” unless the organization has defined exactly what final means and who can grant it.

The NIST AI Risk Management Framework treats context, measurement, management, and governance as connected work. A solar team can apply that logic without turning a project review into an AI policy exercise. Define the use, identify what can go wrong, test the output against evidence, and give a named person authority to stop release.

Freeze the version before reviewing it

Review becomes meaningless when the underlying draft keeps changing. Save or identify the exact project revision, output timestamp, equipment library version where available, and source bundle used for the check. If a teammate changes the array after review, the old approval should not float forward automatically.

Use a simple version rule: any change to a controlling input expires the affected review. A roof-dimension correction should reopen geometry, array, energy, materials, and proposal checks. A tariff correction may leave the drawing untouched but reopen every financial representation. A module substitution may affect layout, electrical grouping, modeled energy, bill of materials, and price.

The record should make that dependency visible. “Reviewed” is a historical event. “Current for release” is a status tied to a specific revision.

What evidence should a reviewer open before inspecting a ClaraAI output?

Before inspecting a ClaraAI output, the reviewer should freeze its revision and open the project identity record, current imagery or survey, measurements, customer inputs, equipment documents, design brief, applicable model settings, prior decisions, open-condition register, and downstream release purpose. The evidence bundle must show source, date, owner, status, and conflicts so visual polish cannot substitute for provenance or reviewer judgment.

Create the evidence bundle from the intended decision. A roof concept used to request field evidence needs site identity, remote sources, observation dates, visible uncertainty, and the exact questions the concept should resolve. A customer production scenario adds the current array, equipment, shade, resource, loss, and model records. A financial representation adds consumption, tariff, export, scope, financing, incentive, and validated calculation evidence.

Use a source-opening order that catches cross-project and stale-input errors before detailed visual review:

1. Confirm project, facility, roof, meter or account, market, owner, and intended output.
2. Freeze the ClaraAI output, design state, source bundle, timestamp, and release purpose.
3. Open the newest accepted site evidence and compare it with the sources named by the output.
4. Review prior decisions, unresolved items, customer corrections, and events that expired earlier work.
5. Open selected equipment and manufacturer records appropriate to the scenario.
6. Open the model settings, resource, shade, losses, consumption, tariff, or financial evidence that applies.
7. Open the downstream template or package that will receive the output.
8. Mark missing, conflicting, inaccessible, or stale evidence before reviewing the attractive result.

Keep status granular. A source can be authentic and still be old. A survey can be current and still omit an inaccessible roof zone. A customer file can be useful and still have incomplete periods or unknown meter coverage. “Documented” should not flatten those limits. Record what the source establishes and what it leaves open for this release.

Illustrative workflow example, not a customer result: A reviewer opens a polished roof model but the output bundle points to older imagery than the current survey record. The reviewer stops geometry review, preserves both sources, and asks the project owner which record controls. Only after the conflict is resolved does the reviewer assess array placement and dependent energy outputs.

This order saves the team from carefully reviewing the wrong thing. It also records why the review stopped. “Roof model rejected” is less useful than “current survey and named output source conflict at the east roof extension; geometry and all dependent releases paused pending source decision.”

Check 1: establish project identity and evidence provenance

Begin with the boring identifiers because cross-project contamination can survive every technical check that follows. Confirm the customer or site name, address or site identifier, meter or account reference when relevant, project owner, market, document dates, and intended project type.

Then inspect provenance. For every material input, ask who supplied it, when it was created, what it actually represents, and whether a newer record exists. A screenshot of a bill is not the same as interval data. A planning drawing is not proof of existing roof conditions. A satellite image is not a field survey. A module name typed into a note is not the manufacturer data sheet used in the model.

Use four evidence states:

A technically plausible output built for the wrong meter is still wrong. Resolve project identity before reviewing its technical details.

Check 2: compare the roof model with its source evidence

Open the source imagery, survey notes, photographs, drawings, and measurements beside the model. Trace the primary roof outline, ridge and hip relationships, pitch, azimuth, height changes, parapets, and roof planes. Look for shapes that the model has regularized because they were awkward in the evidence.

Do not grade the model on beauty. Grade it on whether each material geometric decision has a defensible basis. Remote evidence may support a preliminary model while leaving dimensions or elevations unconfirmed. Record that boundary beside the output rather than burying it in a project-wide note.

Use the broader solar design review checklist when the package has moved beyond an AI-assisted draft. The ClaraAI gate is narrower: it asks whether the proposed output is supported enough to enter the next controlled review, not whether every later engineering or authority requirement has been completed.

Check 3: hunt for missing obstructions and usable-area assumptions

Scan roof photographs and imagery systematically, not by staring at the finished array. Move plane by plane and compare vents, skylights, HVAC equipment, chimneys, drains, roof hatches, access paths, parapets, vegetation, neighboring structures, and objects that may have changed since capture.

Mark uncertainty directly on the review record. If an object cannot be identified, do not quietly classify it as harmless. State where it is, which design decision it affects, and what evidence will resolve it. The missed-obstruction checklist provides a focused inspection sequence for this work.

Usable area also depends on constraints outside image recognition. Access, maintenance, fire, structural, drainage, roofing, and local requirements must come from current project-specific sources and qualified review. An empty patch of roof is not automatically an available patch of roof.

Check 4: test the array layout as a set of decisions

Count and identify the modules, then inspect orientation, spacing, plane assignment, edge relationships, walkways, access zones, row interaction, and proposed mounting context. Compare the layout against the intended system objective. A layout optimized for maximum modeled capacity may not serve a project constrained by consumption, export, inverter limits, budget, roof work, or customer scope.

Ask the reviewer to explain why each populated plane is used and why each conspicuous open area is empty. That short exercise exposes accidental exclusions, hidden assumptions, and output choices that no longer match the brief.

The solar designing workflow can keep modeling and array work in one project environment. The connected record still needs human control. Software can help produce and update a layout; the release owner decides whether its inputs, constraints, and intended use are acceptable.

Check 5: inspect shade inputs before reading the result

Shade is a modeled relationship between solar position, geometry, obstructions, time, and system configuration. A convincing color layer does not prove that every relevant object, height, season, or interaction entered the model correctly.

Review the geometry used for nearby trees and structures, the treatment of parapets and roof equipment, the time basis, and any excluded sources. Compare the output with site photographs or field measurements where the decision demands them. If vegetation may change, state the observation date and management assumption.

Sandia’s PV Performance Modeling Collaborative separates shading, soiling, and reflection losses because the mechanisms differ. That distinction matters in a review. Do not explain an unexplained model loss as shade merely because shade is visually intuitive.

The shading analysis workflow supports project analysis, while project-specific source quality and professional review determine how the result may be used.

Check 6: verify equipment identity and configuration

Match module, inverter, optimizer, battery, racking, and other modeled equipment to current manufacturer records and the commercial scope. Check exact model designations, quantities, electrical characteristics used by the workflow, compatibility questions, and any substitutions introduced since the prior revision.

An equipment name can be almost right and still select the wrong record. Similar product families may contain different ratings, dimensions, connector requirements, or operating ranges. Use document revision dates and an approved equipment library process. Do not accept an AI-generated description as a manufacturer specification.

Record whether the output is a scenario or a procurement commitment. A planning model may use a representative item when clearly labeled. A customer or construction record needs the exact basis appropriate to that release.

Check 7: route electrical logic to the responsible reviewer

Inspect circuit grouping, inverter assignment, string or branch structure, conductor and protective-device references where present, equipment ratings, and consistency with the current layout. Then ask whether the reviewer is authorized and competent to make the decision. A visual pass by a sales user does not become electrical approval because the diagram looks orderly.

Current codes, utility rules, manufacturer instructions, site conditions, and professional responsibilities vary. The Department of Energy’s overview of photovoltaic system design basics explains major system components for public education. It does not approve an individual electrical design.

Use an explicit route: preliminary workflow check, qualified electrical review, responsible engineer review where required, and authority or utility review as applicable. Record the boundary between them.

Check 8: reconstruct the energy-yield basis

Do not begin with the annual total. Reconstruct the path to it. Identify the weather or resource source, location, system geometry, equipment models, shade treatment, loss inputs, operating assumptions, and model version. Check whether all inputs refer to the same project revision.

The open System Advisor Model libraries include performance and financial calculation modules, while the System Advisor Model repository provides the associated application source. Neither resource validates an unrelated project output, but both make the governing principle visible: a number at the end of a model cannot be reviewed apart from the inputs and method that produced it.

Compare changes between revisions. If energy changed, identify which input moved and whether the direction is sensible. Never invent an explanation to close a review note. An unexplained difference is a reason to investigate, not a reason to choose the more attractive number.

Check 9: separate energy, bill, and finance claims

Annual energy, utility-bill effect, payment, cash flow, payback, and return metrics answer different questions. Reviewers should stop any output that slides from one to another without showing the added inputs.

For bill and financial work, verify the consumption source, account coverage, load timing where relevant, tariff and export treatment, price and scope, financing terms, incentives, escalation assumptions, ownership, maintenance responsibilities, and calculation definitions. Apply the current jurisdiction and effective date to every regulated or time-sensitive item.

The solar yield and financial analysis supports scenario modeling. It does not turn missing commercial evidence into fact. Route financing, tax, contractual, and investment representations through the responsible qualified review. Where the output will influence a buyer, the FTC’s advertising guidance is an important United States reference for truthful claims, alongside the rules governing the actual offer and jurisdiction.

Check 10: compare every downstream document

The review is incomplete if the roof model passes while the proposal, materials list, electrical record, and project notes still describe an older revision. Compare system size, module count, equipment identity, layout image, modeled energy, price basis, scope, and assumption labels across outputs.

Build a small reconciliation table:

A mismatch does not always mean one document is wrong. It may mean the documents serve different stages. The reviewer must explain the difference so the next user cannot mistake it for an error or silently select the preferred version.

What should happen when ClaraAI conflicts with project evidence?

When a ClaraAI output disagrees with project evidence, stop the affected release, preserve the output and source bundle, describe the exact conflict, identify every dependent layout, model, material record, electrical document, proposal, and customer claim, then route the decision to the authorized reviewer. Correct the source or output, rerun dependencies, issue a new version, and record restrictions before future reuse.

Do not assume the AI-assisted output is wrong or that the newest-looking source is right. The conflict may come from stale imagery, a survey mistake, a duplicated project, an equipment substitution, a model setting, manual data entry, a customer correction, or a later project event. Establish the controlling evidence and decision authority before editing either side.

Use a copy-ready conflict disposition record:

1. Project, output, model, and release identifiers:
2. Reporter, discovery date, intended use, and affected decision:
3. ClaraAI value, location, label, or conclusion in question:
4. Conflicting evidence, source, date, owner, and accepted status:
5. Why the records cannot both control the same release:
6. Immediate stop, restriction, field protection, or customer action:
7. Dependent geometry, layout, shade, energy, materials, electrical, financial, scope, proposal, procurement, or field records:
8. Authorized decision owner and qualified reviewers consulted:
9. Accepted basis, correction, rerun, and new revision:
10. Superseded artifacts, known recipients, correction notices, receipt confirmation, and unresolved copies:
11. Remaining restrictions, expiry event, and root mechanism:

Separate source correction from output correction. If a customer-provided address or bill was assigned to the wrong record, correct the controlled input and every dependent output. If the source is correct but the model regularized a roof edge incorrectly, preserve the source and revise the output. If evidence genuinely conflicts, keep both visible and restrict the release until the authorized reviewer resolves the condition.

Trace dependencies by claim, not just file. A roof correction can change array quantity, shade, energy, materials, price, proposal imagery, and a seller’s explanation. A tariff correction can leave geometry intact while invalidating bill and financial claims. A module substitution can affect layout, electrical logic, energy, procurement, and customer scope. The disposition record should reopen only the affected gates and all of them.

Tell downstream users what changed. A new version number with no explanation encourages people to keep the copy they already understand. State the conflict, accepted source, outputs revised, restrictions still active, and version that now controls. If a customer saw the earlier result, explain any material change through the approved communication route.

Withdraw or visibly supersede stale artifacts in systems the team controls. Check downloads, email attachments, CRM notes, screenshots, proposals, work orders, and partner files; notify known recipients and record their responses. Downloaded or offline copies may not be recoverable. Log that limitation and the affected release restriction rather than claiming that every copy was recalled. The current project screen does not establish that earlier recipients received the correction.

Check 11: challenge the output with edge cases

A good review tries to break the draft. Ask what happens if the imagery is older than the roof work, one obstruction height is wrong, a module is substituted, the customer adds a major load, export treatment changes, or a field measurement reduces usable area. You are testing whether the workflow exposes dependencies, not predicting every future event.

Use the NIST AI RMF Playbook as governance inspiration: test, document, assign ownership, and manage risk across the use context. For a solar team, a useful edge-case exercise ends with concrete triggers. “Reopen layout and production review if roof geometry changes” is actionable. “Use caution” is not.

Keep the exercise proportionate. A preliminary sales concept needs clear restrictions and next evidence. A release that others may build, finance, approve, or contract against needs a much stronger gate.

Check 12: record the reviewer’s evidence and decision

Require a short written decision that connects the evidence to the intended release. Record a material uncertainty, the test used to reject an unsuitable output, or the reason the output is acceptable. This is a proposed review control, not a measured improvement in review quality.

Useful prompts include:

1. Which input would most likely change this output?
2. Which source did you trust least, and why?
3. What may the next person rely on?
4. What must the next person verify?
5. Which revision event expires this review?

Do not require the reviewer to manufacture criticism. “No material exception found after comparing the named evidence” is a legitimate conclusion when the record shows the work. The purpose is accountable reasoning, not ritual negativity.

Use a consequence-based release matrix

One universal approval route either over-controls harmless drafts or under-controls consequential ones. Classify the output by use.

The names can change. The essential control is that consequence, evidence, reviewer authority, and release language move together.

How should ClaraAI review depth change with consequence?

Review depth should follow what another person may rely on. An exploratory internal scenario needs visible assumptions and an owner. A customer discussion needs version lock, evidence basis, restrictions, and trained review. Coordination needs cross-document reconciliation. Commercial commitments need current technical and commercial approval. Authority, utility, engineering, or construction use needs the responsible professional and every required external review completed.

Classify intended reliance before choosing reviewers. “Internal” is not automatically low consequence if the result controls procurement, staffing, pricing, or a later automated document. “Customer-facing” is not one level either. An educational diagram, preliminary layout, financial offer, and signed scope create different exposure and need different evidence and authority.

Use a review-depth worksheet:

Assign review roles by field, not by seniority alone. A senior salesperson may understand the customer decision but lack authority to approve electrical, structural, safety, tariff, tax, financing, contract, utility, or code treatment. A technical reviewer may validate the physical model while lacking authority over commercial terms. The release record should name each accepted boundary and every unresolved decision.

Independence also scales with consequence. Early drafting can use peer review. A high-consequence claim benefits from a reviewer who did not create the underlying output and who has authority to reject it. External authorities, utilities, engineers, lenders, insurers, or other parties retain their roles; internal confidence does not substitute for required review or approval.

Write restrictions as actions. “Preliminary” is vague. “May be used to request current roof measurements; may not be used for equipment order, customer production claim, permit submission, or field work” tells the next person what the status permits. Put those restrictions on the output and in the handoff, not only in a hidden audit field.

Reclassify when use changes. A concept copied into a proposal has entered a new consequence class even if the pixels stay the same. A layout attached to a procurement message needs the controls for that action. Review does not travel indefinitely with an artifact; it remains tied to the use, evidence, and revision the reviewer accepted.

A compact ClaraAI output review record

Store the following fields with the output rather than in a disconnected spreadsheet:

• Project, revision, timestamp, and output type
• Intended decision and release class
• Evidence bundle with dates and owners
• Assumption and unresolved-item register
• Geometry, obstruction, layout, shade, equipment, electrical, energy, finance, and document checks that apply
• Corrections made and dependent outputs rerun
• Reviewer, competence or role, review date, and decision
• Restrictions communicated to the next user
• Events that expire the review

This record should be short enough to use and specific enough to audit. If every project receives the same paragraph, it is a disclaimer, not a review record.

Sample the review process itself

Quality control also needs quality control. Each month or release cycle, select a small set of outputs from different project stages and compare the review record with the actual evidence. Check whether reviewers opened the cited files, whether restrictions appeared in downstream documents, and whether changes correctly expired earlier approvals.

Look for patterns rather than a vanity pass rate. A recurring missing imagery date points to intake design. Equipment substitutions that escape proposal reconciliation point to revision control. Identical review notes across unrelated projects suggest that reviewers are signing a template rather than recording a decision.

Bring findings back to the checklist carefully. Add a required field only when it prevents a real failure or supports a necessary audit. Long checklists can become camouflage because reviewers stop distinguishing material items from routine ones. Retire checks that no longer apply, and keep project-specific judgment visible.

Never turn internal sampling into a public accuracy or time-saving claim without a retained measurement method and adequate evidence. The purpose is to find where the control system leaks, then repair the workflow before another output reaches the same point.

Frequently Asked Questions

Who should review a ClaraAI output?

Assign the reviewer by the decision and release stage. A trained designer may review an early layout, while electrical, structural, financial, contractual, or approval-sensitive content needs the responsible qualified person. The reviewer must have enough project evidence and authority to reject, revise, or restrict the output.

Can a ClaraAI output replace a site survey?

No. An AI-assisted output can organize available project information and support preliminary design work, but it cannot establish conditions that the source evidence does not show. Field measurements, photographs, equipment records, utility documents, and qualified inspection remain necessary whenever the decision depends on actual site conditions.

What should a reviewer record after checking the output?

Record the output version, review purpose, evidence consulted, checks completed, corrections made, unresolved items, release status, reviewer, and date. Link every restriction to the affected drawing, calculation, proposal, or downstream document. A bare approved label is too vague to support a later handoff or audit.

Should every AI-assisted draft receive the same review?

No. Review depth should follow consequence. A sales-stage concept with visible assumptions needs a different gate from an engineering release or customer financial representation. Define the intended decision first, then require the evidence, expertise, independence, and documentation proportionate to what another person may rely on.

How should teams handle a confident answer that lacks evidence?

Treat confidence in wording as irrelevant. Ask which source, project input, rule, equipment record, or validated calculation supports the statement. If no adequate basis exists, remove the claim, label it as an unresolved assumption where appropriate, or route it to a qualified reviewer before the output moves forward.

Release judgment belongs to a person

ClaraAI can help create an output inside a solar workflow. The release decision stays with the person accountable for the next use. That person needs the exact revision, the controlling evidence, a visible uncertainty record, and authority to say no.

A useful review leaves a trail another professional can follow. It shows what the draft was meant to do, why the reviewer accepted or restricted it, which dependent records changed, and what event will reopen the decision. That is how speed becomes controlled throughput instead of faster ambiguity.