Auto-Stringing Review Checklist for Solar Designers

An auto-stringing result can look remarkably finished. Modules carry colors, string labels follow a sequence, and every line appears to reach an inverter. That visual order is useful for review, but it proves only that the software produced a grouping. It does not prove that the grouping fits the equipment, site conditions, governing design basis, or downstream documents.

Solar designers should treat automatic stringing like a junior designer’s first pass: valuable because it removes blank-page work, reviewable because the logic is visible, and unreleasable until someone checks the electrical and project context. The point is not distrust of automation. The point is assigning evidence to the decision that matters.

The U.S. Department of Energy’s PV system design basics describes major system elements and the role of power electronics in converting and managing PV electricity. That overview explains why module grouping cannot be reviewed in isolation from inverters and the balance of system. Project release still depends on current product documentation, applicable rules, and qualified review.

This checklist is for designers and electrical reviewers checking an automatically generated string plan before engineering release. It is a review framework, not a code calculation or design approval. Temperature values, safety factors, conductor sizing, protection, grounding, disconnecting means, and equipment limits must come from the project’s current sources and responsible professionals.

Set the release purpose before opening the string view

The review standard changes with the intended use. A concept used to explore array architecture does not carry the same evidence burden as an issue for engineering review, permit submission, procurement, or construction. Write the release purpose at the top of the checklist.

Use a short status vocabulary:

Do not call a design “final” without saying final for what. A stringing plan may be ready for an internal coordination meeting while unsuitable for purchasing conductors or issuing an SLD. The label needs an owner, date, input revision, and permitted downstream audience.

Start the checklist from the current project record, not from the tidy drawing on screen. If the drawing and record disagree, stop and reconcile the source before reviewing electrical relationships.

Check 1: freeze the equipment and input revision

The first check is identity. Record the exact module model, inverter or other power-conversion equipment, quantity, relevant input channels, approved substitutions, datasheet revision, design-temperature source, and the software library record used by the generator. Similar product names are not interchangeable evidence.

Compare the generated quantities with the released layout and equipment schedule. A changed module count may leave an orphan label, an underfilled group, or a string that belongs to a prior roof revision. A substituted module may change electrical characteristics even when its dimensions allow it to fit the same layout.

The Sandia PV Performance Modeling Collaborative’s DC module overview explains that module current-voltage behavior varies with irradiance and temperature and is represented through model parameters. The practical review consequence is straightforward: use the correct module record and project conditions rather than a generic module category.

Record a source hierarchy. Manufacturer documentation controls published equipment limits; the project design basis controls selected environmental and jurisdictional inputs; the responsible professional controls interpretation. A software library is a convenient working copy. Where it conflicts with current approved documentation, resolve the conflict instead of choosing whichever value permits the string.

Check 2: verify the voltage basis at both temperature boundaries

String voltage review needs more than a module count. Confirm the method and sources used to evaluate maximum voltage under the project’s low-temperature basis and operating voltage under relevant high-temperature conditions. Compare the result with the equipment input range and every other applicable project constraint.

Do not insert a generic temperature because the site record is incomplete. Mark the check unresolved and assign the missing source. Climate data, authority criteria, equipment instructions, and the responsible design method may each affect the accepted basis. This article deliberately provides no universal value because the right input is project-specific.

Review automatic groupings for edge cases. A string can sit one module away from another string and still cross an equipment limit under the selected conditions. Mixed string lengths can also change how parallel groups behave and how later reviewers interpret the drawing. Inspect the shortest and longest string in every repeated pattern, not only the first label.

Retain the calculation or approved tool output with units, inputs, method, and reviewer. A green software indicator without the input record cannot explain itself after equipment or weather assumptions change. When the project revises, compare the changed input against this evidence and reopen the affected check.

Check 3: verify current and parallel inputs from the approved basis

Current checks begin with the module and string characteristics relevant to the design method, then account for how strings are combined at each input. Verify the equipment’s published limits and the applicable conductor and protection method. Do not infer acceptance from the fact that connectors can be drawn together.

Map every parallel string to its actual destination. Count the strings at each MPPT, combiner, inverter input, or other relevant device. Automatic numbering can conceal an uneven distribution when a designer scans colors rather than quantities. Write the count beside the equipment schedule and reconcile it independently.

The PVPMC DC-to-AC conversion guide describes inverter modeling as the conversion of DC input behavior to AC output behavior with model-specific parameters and limits. A performance-model description does not replace an electrical design calculation. It does reinforce that the proposed DC arrangement and selected inverter belong to one reviewed system.

Where parallel strings differ, record why. A difference may be a valid response to roof geometry or equipment architecture, or it may be residue from an earlier layout. “The software allowed it” is not the technical basis. The responsible reviewer needs the source, rule, and intended operating relationship.

Check 4: inspect MPPT grouping as a physical roof decision

Auto-stringing often optimizes a graph of modules and equipment inputs. The reviewer has to reconnect that graph to the roof. Compare each string and MPPT group against plane, tilt, orientation, shade pattern, module type, optimizer or electronics architecture where used, and any manufacturer restriction.

Walk the roof visually in the same order an installer would encounter it. Find strings that jump between planes, cross access routes, weave around obstructions, or create a surprising home run. A mathematically valid grouping can create difficult routing, confusing labels, or a mismatch between the model and field sequence.

Do not apply a slogan such as “one plane per MPPT” without examining the equipment and design basis. Instead, make the grouping decision explicit. State which physical differences exist, how the selected equipment treats them, what evidence was consulted, and who accepted the arrangement.

Use the current shading and irradiance model as supporting evidence, with its limitations visible. A simulated shade scene depends on geometry, object placement, weather inputs, time basis, and configuration. Field conditions and later site changes can differ. The reviewer should check whether the proposed grouping makes sense under the evidence, not claim that the model guarantees output.

Check 5: make string lengths and labels traceable on the layout

Every module needs an unambiguous electrical home. Pick several modules at the edges of roof planes, near obstructions, and at string transitions. Trace each from module marker to string ID, input, inverter, equipment schedule, and SLD. If the path depends on color alone, add a label that survives grayscale printing and field conditions.

Inspect numbering after deletions and revisions. Missing sequence numbers are not inherently wrong, but reused IDs are. A string label should refer to one current grouping across every output. If S-04 was removed, a later generator run should not assign S-04 to a different roof area while an older markup remains in circulation.

Use a reconciliation table:

The table is not the review itself. It prevents a reviewer from accepting a locally correct string plan while its neighboring documents tell another story.

Check 6: review routing, conductor, protection, and disconnect assumptions

Automatic stringing may create topology without resolving physical routing or every balance-of-system decision. Identify homerun paths, transition points, exposed and concealed routing, equipment locations, conductor assumptions, connectors, combiners, overcurrent protection, disconnects, grounding and bonding context, and labels that the project’s design method requires.

This is where role boundaries matter. A layout designer can flag an implausible crossing or an undocumented transition. The qualified electrical reviewer decides conductor, protection, grounding, and code matters within their authority. The checklist should never turn a visual-review role into an undeclared engineering approval.

The official NFPA 70 development page identifies the National Electrical Code standard and its development information. It does not prove which edition, amendments, or interpretations govern a specific project. Record the applicable jurisdictional basis and current authority information separately.

Electrical work also carries safety responsibilities outside drawing consistency. OSHA’s electrical topic page is a U.S. federal starting point for electrical hazards and standards. Project-specific safe work, training, equipment, and procedures require the employer and qualified professionals to apply current rules to the actual work.

Check 7: challenge the generator with deliberate exceptions

A normal rectangular roof rarely exposes weak automation logic. Test the result where the project is awkward: a partly filled plane, a module deleted after shade review, mixed orientations, an equipment substitution, an MPPT unavailable by design, a roof crossing, a reserved input, or a string moved between inverters.

For each exception, ask three questions. Did the generator preserve the intended constraint? Did it disclose what it could not resolve? Did the output reopen every downstream item affected by the change? A silent “best effort” is dangerous because it looks no different from a fully accepted result.

Keep an exception register with the affected IDs, generated arrangement, criterion under review, source evidence, disposition, reviewer, and release effect. If a nondefault arrangement is accepted, record why. Otherwise, the next automatic run may restore the default and erase the reasoning.

Test repeatability too. Run the same approved inputs through the same configuration according to the team’s controlled procedure. If the result changes, find the changed library, rule, setting, or software version. Do not assume the newer output is better merely because it is newer.

What should an auto-stringing exception register contain?

An auto-stringing exception register should identify the affected modules, string, input, and equipment; the generated arrangement; the criterion that failed or remains uncertain; the evidence consulted; the assigned reviewer; the correction or accepted disposition; and the release impact. It should also record which future input change reopens the decision, so automation cannot silently restore a rejected configuration during another revision.

Treat the register as a working control, not a graveyard for comments. Open an exception when a generated relationship cannot be accepted from the current record. Close it only when the configuration is corrected or the authorized reviewer records a supported disposition. “Reviewed” does not describe what happened and should not be a closing note.

Use this field set:

Use this copy-ready review record in the team’s controlled issue system or review sheet:

Exception ID and design revision:
Affected module, string, input, and equipment IDs:
Generated arrangement:
Observed conflict or uncertainty:
Current evidence and revision:
Responsible reviewer:
Disposition and technical basis:
Required drawing or data correction:
Outputs blocked from release:
Permitted interim use:
Change that reopens this exception:
Closure evidence and approver:

Avoid one exception for an entire design when the causes differ. A stale equipment record, an unexpected roof transition, and a drawing-label conflict may share a screenshot but require different owners and reopen triggers. Conversely, do not create dozens of duplicate records when one controlled source error affects a repeated family of strings. Name the common cause and list every affected object.

The register should travel with the release packet. A reviewer looking only at the clean output may not know that a default grouping was rejected earlier. The retained exception explains why the current nondefault arrangement exists and which automatic action must not overwrite it.

Check 8: reconcile performance modeling without turning it into approval

String configuration can affect the inputs used in a production model. Confirm that the model represents the released module grouping, inverter selection, DC/AC relationship, losses, clipping treatment, shading basis, and equipment quantities. Mark any simplification that prevents one-to-one representation.

PVPMC’s AC system output guide places AC output downstream of the modeled PV and conversion chain. That is useful context for document reconciliation. It does not establish the energy result for a particular project, and a performance-model pass does not approve the electrical design.

Compare the energy model, electrical schedule, and proposal by revision. A customer-facing production estimate based on the prior inverter or module count must be updated or withdrawn before release. Likewise, an electrically revised string plan should not silently inherit an old performance result.

Generation and Financial Tool describes SurgePV’s energy-yield and financial modeling workflow. Solar Designing covers its broader 3D roof, layout, shading, electrical workflow, bill-of-materials, and proposal support. 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.

Check 9: release one package, not one attractive view

Finish by assembling the release evidence. Include the input and equipment revision, string schedule, checked calculations or approved outputs, layout, relevant equipment schedules, SLD revision, exception register, model/proposal reconciliation, reviewer, date, release purpose, and open conditions.

Use three outcomes: return for correction, ready for responsible review, or released for a named purpose by the authorized person. Avoid “looks good.” That phrase carries no scope and gives the next person no way to know whether the reviewer checked labels, electrical limits, routing, or merely visual order.

The electrical design QA guide provides a broader electrical review. Keep this checklist focused on generated string logic and its immediate document relationships. The wider QA still applies before an electrical package reaches its intended audience.

After release, changes must reopen affected checks. A module substitution returns to identity and electrical characteristics. A roof deletion returns to membership, string lengths, routing, and models. An inverter change can reopen most of the checklist. The change record should name those consequences instead of relying on the reviewer to remember them.

What should the independent auto-stringing review packet include?

An independent auto-stringing review packet should include the release purpose, input and equipment identities, generated configuration, layout and schedules, retained verification outputs, exception register, downstream document revisions, open conditions, and named approval path. The packet must let a qualified reviewer reconstruct what changed and why without relying on the preparer’s memory, software colors, or a screenshot from an earlier run.

Build the packet around decisions, not file volume. The reviewer needs to know which module and inverter records controlled the run, which project inputs were frozen, what the automation proposed, which relationships the preparer changed, and what is still unresolved. A folder full of exports without a cover record makes the reviewer search for the project state before checking the design.

Use a cover sheet with these sections:

1. Purpose and authority: intended downstream use, responsible review role, and release status requested.
2. Controlled inputs: design revision, module and equipment identity, layout source, project design basis, and software or rule-set identity used by the team.
3. Generated result: string schedule, roof mapping, destination mapping, and a record of preparer changes after generation.
4. Verification evidence: retained checked outputs and the source revisions on which the reviewer relied.
5. Exceptions: every open and closed item that affects the current configuration, with its disposition authority.
6. Parity set: current layout, schedules, SLD, bill of materials where applicable, performance-model identity, and any customer-facing output affected by the change.
7. Release decision: accepted use, blocked use, remaining conditions, approver, date, and reopen triggers.

Do not ask the second reviewer merely to repeat mouse clicks. Independence means reconstructing the release-controlling relationships from the approved basis according to the organization’s review method. The reviewer may use another controlled tool or the same tool with an independent check path, but the evidence must show more than agreement with the original display.

Mark preparer annotations distinctly from generated output. If a designer manually moves a string, changes an input assignment, or overrides a warning, the packet should preserve the before state, the after state, and the reason. Otherwise the reviewer cannot tell which logic came from configuration and which came from a human decision.

Link the packet to the layout, stringing, and SLD parity guide when the review reaches neighboring documents. The auto-stringing checklist owns generated grouping review. The parity guide owns the controlled fields that must remain consistent across outputs.

Assign review work to named roles

One person can perform several checks on a small team, but the record should still name which authority they exercised. “Electrical review” becomes ambiguous when it covers file completeness, design calculations, constructability, code interpretation, and release approval in one unchecked box.

The design preparer owns the generated configuration and resolves obvious drawing defects. A second reviewer independently checks the release-controlling electrical basis according to the company’s qualified-review policy. A field or constructability reviewer examines routing and equipment access where that role is part of the project. The responsible professional makes any decision reserved for their license, contract, or jurisdiction.

Define disagreements before they happen. If the generated layout conflicts with an equipment instruction, the instruction and current approved product data control until a qualified person documents another permitted basis. If a site condition conflicts with the model, mark the affected work on hold. If the layout and SLD disagree, neither wins through seniority; return both to the common project source and identify which revision is current.

Reviewer independence should be proportionate to the release. A concept check may use a peer who did not create the grouping. A regulated engineering release follows the organization’s formal authority and applicable jurisdictional rules. Do not turn this article into an authorization matrix. Write the matrix for the actual company, project type, and market, then keep it beside the checklist.

Finally, give reviewers enough time to inspect exceptions. A nominal second set of eyes adds little when the review queue rewards quick acceptance and buries return reasons. Track which checks return work and why, then repair source data, training, configuration, or ownership. Do not respond by deleting the check that found the problem.

How should a design revision reopen auto-stringing review?

A design revision should reopen every auto-stringing check touched by the changed input, plus downstream records that depend on the configuration. The change record should identify the old and new revisions, affected objects, prior exceptions, reviewers, blocked outputs, and completion evidence. Do not rerun automation and replace the drawing until the team understands which decisions the new result may invalidate.

Start with an impact map. A changed roof layout can alter module membership, string length, MPPT grouping, routing, quantities, and model identity. A changed equipment record can affect accepted groupings and neighboring schedules. A label-only correction may require document parity without reopening every technical decision. The responsible reviewer defines the actual scope under the project’s method.

Illustrative workflow example, not an engineering approval: A designer receives a revised roof layout after one array area is removed. The automatic run regroups the remaining modules and assigns a familiar string label to another roof plane. The new view is visually complete, but the former exception register contains an accepted nondefault grouping tied to that label.

The designer does not publish the regenerated view. They compare revisions, list the affected module and string identities, reopen the earlier exception, and mark the layout, string schedule, SLD, equipment schedule, model, and bill of materials for parity review where applicable. The independent reviewer then checks the changed relationships from the current approved sources. No project-specific voltage, current, conductor, protection, grounding, equipment, code, utility, or engineering choice is inferred from the workflow.

Use this revision impact note:

Change request and source:
Prior and current design revisions:
Changed input or object:
Directly affected strings and equipment:
Prior exceptions reopened:
Documents placed on hold:
Checks repeated by the preparer:
Independent checks required:
Qualified decisions required:
Parity evidence completed:
Release decision and approver:

Keep the prior release intact in the archive. Replacing it destroys the comparison that explains why the new review exists. Mark the older package superseded for active use according to company procedure, but retain its identity, approvals, and exceptions in the audit path.

Finish with a regression question: did the revision correct the requested change without undoing an unrelated accepted decision? The answer requires a deliberate comparison, not faith in a clean rerun. If the team cannot show that comparison, the revised stringing remains ready for review rather than released.

A practical review sequence

Use this sequence on each generated design:

1. State the intended release purpose and responsible reviewer.
2. Freeze module, inverter, layout, library, temperature, and design-basis revisions.
3. Independently verify voltage and current checks from approved sources.
4. Count parallel strings and map every destination input.
5. Compare MPPT groups with physical roof and irradiance conditions.
6. Trace edge modules and transition modules across layout, schedule, and SLD.
7. Review routing and balance-of-system assumptions with the appropriate roles.
8. Challenge the result using at least one project-specific exception.
9. Reconcile energy model, BOM, and proposal with the current configuration.
10. Record disposition, authority, open items, and the changes that reopen review.

A checklist item passes only when its evidence can be found. “Experienced reviewer checked it” is an author name, not a technical record. Keep the source and decision together so another qualified person can reconstruct the basis without guessing.

Frequently Asked Questions

Can a solar designer approve an auto-stringed layout without recalculation?

No automatic output should bypass the project’s required electrical checks. The reviewer should use current module and inverter data, the project’s temperature and design basis, applicable rules, and the responsible professional’s method. Recalculate or independently verify every release-controlling value rather than treating a plausible diagram as evidence of compatibility.

What is the first auto-stringing check?

Freeze the equipment and input revision first. Confirm the exact module, inverter or power-conversion equipment, firmware-relevant features where applicable, quantity, site temperature basis, and applicable design criteria. Every later comparison can look internally tidy while still being wrong if the generated strings used a stale model or provisional input.

Should strings on different roof planes share an MPPT?

Do not use a universal yes or no rule. Compare orientation, tilt, irradiance pattern, shading, module characteristics, equipment behavior, and manufacturer instructions for the proposed grouping. Where mismatch can affect operation or interpretation, separate the groups or retain a documented engineering decision by the responsible reviewer.

Does auto-stringing prove the SLD is correct?

No. Auto-stringing can propose module groupings and circuit relationships, while an SLD represents a wider electrical design. The reviewer must reconcile string IDs, quantities, equipment, conductors, protection, disconnects, grounding, labels, and connection points across the layout, schedules, calculations, bill of materials, and current SLD.

What should an auto-stringing exception record contain?

Record the affected string or equipment, generated result, failed or uncertain criterion, source data, reviewer, disposition, required correction, and release impact. If the reviewer accepts a nondefault arrangement, retain the technical basis and approval authority so a later revision does not silently restore the rejected automatic configuration.

Good automation makes review more specific

The best auto-stringing output does not remove engineering judgment. It gives that judgment a visible object to inspect. Reviewers can point to a string, an input, a roof transition, or a conflicting revision instead of rebuilding the entire grouping before they can ask a useful question.

Release the configuration only when its identity, calculations, physical mapping, equipment relationships, and document trail agree for the named purpose. If one part remains uncertain, keep the uncertainty attached to the affected string. A clean diagram should make exceptions easier to see, never easier to forget.