9 Solar Stringing Checks Before Engineering Release

Engineering release is a permission event. Someone downstream will use the package to review, submit, procure, coordinate, or build. That makes a solar stringing check different from an informal design check: every accepted relationship needs a traceable basis, and every unresolved relationship needs a hold point.

A string schedule can be internally consistent and still belong to the wrong roof revision. Its voltage check can be correct for a module that procurement has replaced. Its labels can match the layout while the SLD shows another inverter. Release review has to test the package against the project, not merely test each file against itself.

The DOE overview of photovoltaic system design describes PV arrays, power electronics, mounting, and other system elements as connected parts of a design. That connection is the organizing idea for this checklist. It does not provide project calculations or approve a string arrangement.

This article is for PV designers, design leads, and electrical reviewers preparing a stringing package for a named engineering audience. It gives nine hold-or-release checks. It supplies no universal module count, temperature, conductor, protection, or code answer. Those values come from current project evidence, product documentation, applicable requirements, and responsible professional review.

Define engineering release in one sentence

Write who will receive the package and what they may do with it. “For engineering” is not specific enough. A package may be released for a licensed engineer’s review, for internal electrical coordination, for a permit-plan workflow, or for construction documentation after required approvals. Each purpose has a different boundary.

Create a release cover record with project ID, site, intended use, current layout, equipment revision, string schedule, SLD, calculation set, preparer, independent checker, responsible approver, open conditions, and issue date. If one item is intentionally absent, explain why the intended use does not require it yet.

Use plain dispositions:

“Checked” is an action, not a disposition. It does not tell the recipient whether the package may leave the design queue.

What belongs in an engineering-release hold-point record?

An engineering-release hold-point record should identify the blocked package and purpose, the finding that prevents release, affected strings and documents, evidence required for closure, assigned owner, decision authority, permitted interim use, due condition, and reopen triggers. Closure should cite the corrected revision and reviewer, so a comment, email, or new export cannot be mistaken for permission to release downstream work.

Open the hold at the earliest source that invalidates the work. If equipment identity is uncertain, do not describe six downstream drawing conflicts as separate root causes. Block the affected package on the identity record, list the dependent outputs, and reopen their checks after the controlling equipment choice is resolved.

Use a copy-ready hold-point record:

Hold ID and date opened:
Project and package revision:
Intended release purpose:
Finding or missing evidence:
Affected strings, inputs, and equipment:
Affected layout, schedule, SLD, model, BOM, and proposal records:
Current evidence and source revision:
Owner responsible for correction:
Qualified role responsible for the decision:
Permitted interim use:
Prohibited downstream use:
Evidence required to close:
Change that reopens the hold:
Closure revision, reviewer, and date:

Make interim use explicit. A design team may be able to study layout alternatives while a string input remains on hold. That does not authorize procurement, customer release, submission, or construction use. If no interim use is permitted, state that plainly rather than leaving recipients to infer a boundary.

Do not close a hold because the visible symptom disappeared. A regenerated schedule may remove an error marker without correcting the equipment identity or project input that created it. The closure evidence should show what changed, which checks were repeated, and which responsible reviewer accepted the current basis.

Keep holds connected to revision control. When a new package is issued, carry open holds forward or close them with evidence. A hold attached only to a superseded PDF is easily lost when the team opens the latest folder. The current release cover should show every unresolved condition affecting its permitted use.

Review aging holds as workflow signals, but never treat age as technical severity. A long-open documentation conflict may be easy to fix, while a newly discovered authority or calculation gap can stop release immediately. Route by what the finding invalidates and who has authority to resolve it.

Check 1: confirm project, site, and equipment identity

Begin with identity because later calculations cannot repair a wrong source. Match the project number, service address or site identifier, array area, module model, inverter or conversion equipment, quantities, equipment documents, and approved substitutions across the project record.

Inspect exact model suffixes and document dates. A library entry may share a family name with the selected device while its ratings or input architecture differ. If a manufacturer has revised documentation, record which approved version the design used and whether the change affects review.

Reconcile total modules before examining individual strings. Compare roof layout, string schedule, electrical equipment schedule, bill of materials, performance model, and proposal where applicable. A quantity difference is a release hold until the team identifies an intentional exclusion or corrects the stale record.

Keep proposed substitutions outside the released identity until they complete the company’s change process. A purchasing suggestion is not an electrical approval. The substitution record should name the reason, affected calculations and documents, reviewers, disposition, and customer or authority impact where relevant.

Check 2: validate the environmental and design basis

String behavior depends on project conditions and the selected design method. Record the source for low- and high-temperature assumptions, irradiance-related inputs used in modeling, elevation or other site factors when relevant, jurisdiction, applicable code basis, and equipment instructions.

Do not allow the software default to become the project basis by silence. If a default is appropriate, the reviewer still records why and where it came from. If the site source remains unavailable, use a visible hold or a qualified preliminary status. Deleting the input from the checklist only conceals the uncertainty.

The Sandia PVPMC modeling guide connects weather, irradiance, module temperature, current-voltage curves, and system output. Those modeled relationships help explain why environmental inputs matter. The project’s responsible method determines how those inputs enter its calculations.

Check units, sign conventions, and the site to which weather evidence belongs. A reasonable-looking value copied from another project can still be wrong for this site. Provenance prevents that error.

Check 3: independently verify string voltage

Review the shortest and longest string associated with every distinct module and equipment combination. Apply the project’s approved calculation method to the environmental basis and compare the outputs with all relevant equipment constraints. Distinguish maximum open-circuit voltage from the operating and start-up voltage ranges: passing one does not establish that the others are satisfied. Retain inputs, units, formula or approved tool, result, source documents, and reviewer.

Independence matters. Do not “verify” a design by reading the same green status that generated it. Recalculate through a controlled second method or inspect an approved calculation artifact that exposes its inputs. The purpose is to catch stale data, configuration errors, and mistaken assumptions, not to reward agreement.

Inspect boundary cases rather than a representative string alone. Roof geometry can create one short remainder string among many repeated groups. An equipment substitution can turn a formerly comfortable configuration into a marginal one. A revised temperature basis can affect the longest string even when its module count did not change.

Use the actual project record and have the responsible reviewer accept the calculation method. A numeric example based on another site or inverter cannot establish this project’s allowable string length.

Check 4: verify current, parallel paths, and equipment inputs

Count how many strings reach every MPPT, combiner, and relevant inverter input. Compare the current basis and grouping with product documentation and the project’s conductor and protection method. Map the actual connection, not the connection a repeating pattern suggests.

The PVPMC DC-to-AC conversion section describes conversion-efficiency models and losses. It provides performance context; it does not establish an inverter’s allowable electrical input.

Treat maximum usable input current, maximum short-circuit current, and connector or branch limits as separate checks. For example, SMA’s DC-input table for a specified Sunny Tripower family lists separate current and voltage constraints, including different voltage ranges for operation and rated power. Use the exact installed model’s current documentation; those listed values are not limits for another inverter.

Review strings connected in parallel for differences in length, module type, orientation, tilt, and expected operating condition. If the selected equipment and approved design method permit the arrangement, keep the basis beside the schedule. If the condition remains disputed, place the affected input on hold rather than smoothing the schedule into a misleading common label. SMA’s module-input instructions for another specified product family, for instance, require equal module counts in connected strings and matching alignment and tilt. An approved method cannot override the selected equipment’s requirements; verify which topology and instructions apply.

Follow the path beyond the inverter input. Confirm that combiner, conductor, connector, protection, disconnect, and termination assumptions shown or referenced in the release package belong to the current grouping. Route sizing and code decisions to the appropriately qualified role.

Check 5: inspect MPPT allocation against roof conditions

A string table can hide the physical roof. Review each MPPT group on the layout and compare module plane, orientation, tilt, shading pattern, equipment architecture, and manufacturer guidance. Look at the transitions where a generator or designer crossed from one plane to another.

Ask why each non-obvious group exists. Valid answers point to equipment behavior, roof constraints, a reviewed performance/design tradeoff, or another documented basis. “It balanced the module count” is incomplete if the balance creates an unsuitable operating group or confusing field route.

Use shading and sun-simulation output carefully. Models depend on geometry, objects, weather data, assumptions, and configuration. They help a reviewer understand expected irradiance differences but do not verify that every obstruction or future site condition is represented.

Where the project uses module-level electronics or another architecture that changes the grouping analysis, record the exact equipment and instructions. Do not generalize a rule from one product family to another. The engineering reviewer should be able to reconstruct why modules share an input without relying on product-category shorthand.

Check 6: trace every module from roof to electrical record

Select modules at string starts, ends, roof edges, obstruction boundaries, and plane transitions. Trace each through its string label, destination input, equipment schedule, SLD, and bill of materials. Then reverse the trace from several SLD strings back to physical modules.

Bidirectional tracing catches different errors. Roof-to-SLD review finds modules with no electrical home. SLD-to-roof review finds labels that remain after a layout revision. Perform both because a document set can balance in total while misassigning individual groups.

Use labels that survive print, scale, and field conditions. Color may assist, but it cannot be the only identifier. Avoid reusing a retired string ID for a new group while older drawings or markups remain active. Revision notes should say which IDs were added, removed, divided, combined, or redirected.

Layout-to-SLD project risk covers the wider handoff between physical and electrical documents. This release check stays narrower: it tests whether current string membership and labels agree between those records. Record which objects were sampled; a sample does not establish complete-package verification.

Check 7: reconcile conductors, protection, disconnects, and grounding context

String release has to show where electrical detail continues. Identify circuit routes and transitions, conductor schedule references, connectors, junctions, combiners, protection, disconnecting means, grounding and bonding context, labels, and equipment connection points required by the project package.

A preparer can confirm that the references exist and agree. The responsible electrical professional decides calculations and requirements within their authority. Write those roles into the release matrix so a completed checklist does not imply that an unqualified person made the technical decision.

Where the National Electrical Code applies, record the adopted edition and local amendments confirmed for the project. Confirm the applicable basis with the authority and qualified professionals rather than labeling a package “NEC compliant” from a generic reference.

OSHA’s electrical safety page is a U.S. federal source for electrical hazard and standards context. It does not replace project safe-work planning, employer responsibilities, training, or qualified field judgment. Keep design-document review and safe execution connected but do not pretend they are the same approval.

Check 8: reconcile layout, schedule, SLD, model, BOM, and proposal

Open the current outputs side by side. Compare project and revision IDs, module and string quantities, equipment identity, input allocation, system configuration, connection points, and customer-facing design-derived facts. Mark intentional differences and remove stale versions from the active release set.

Use a reconciliation matrix rather than relying on memory:

The matrix does not require every document to display every electrical detail. It requires each displayed fact to agree and each omitted relationship to have a known controlling record. Files may have separate revision identifiers and approval states; record each identifier and the accepted design basis it represents, rather than forcing the same revision number onto unrelated artifacts.

The PVPMC modeling guide connects design inputs to modeled system output. A stale string or inverter basis can separate the performance model from the released electrical configuration. Re-run or withdraw affected outputs according to the team’s model-control procedure.

Solar Proposals describes SurgePV’s proposal-generation support, and Solar Designing describes its roof modeling, layout, shading, energy-yield, electrical workflow, BOM, and proposal scope. 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: close exceptions and record release authority

Collect every open issue before asking for sign-off. Each exception needs an affected item, finding, evidence, owner, required action, disposition, approver, due condition, and release effect. A comment bubble without a disposition is not closed merely because someone replied.

Distinguish acceptance from deferral. A reviewer can accept an arrangement with a recorded technical basis. A reviewer can also allow a limited internal use while a site or authority question remains open. The second action is a conditional release and must identify who may see the package and what they may not do with it.

Define which changes reopen which checks. A module change reopens identity, environmental/electrical behavior, calculations, mapping, models, BOM, and customer facts. An inverter change can reopen the entire chain. A label-only correction may need document reconciliation without new electrical calculation, but the reviewer should state that conclusion.

Finish with the authorized person’s name, role, date, package revision, release purpose, and remaining conditions. Send one controlled package. A separate email attachment that was not included in the release record can recreate the conflict the review just resolved.

Use the nine checks as a hold-point sequence

Run the checks in this order because each one establishes the basis for the next:

1. Confirm project, site, module, inverter, quantity, and document identity.
2. Approve environmental inputs and the governing design basis.
3. Independently verify string voltage using project sources.
4. Check current, parallel grouping, and every equipment destination.
5. Compare MPPT allocation with physical roof and irradiance conditions.
6. Trace selected modules and strings in both directions across records.
7. Reconcile balance-of-system references with qualified electrical review.
8. Compare every current downstream document and model.
9. Close exceptions and record the authority and purpose of release.

If an early check fails, hold release of the affected dependent work. Independent checks may continue when their input basis remains valid and their purpose is recorded. Reviewing SLD labels against a string schedule built from the wrong inverter produces neat evidence about the wrong design. Resume from the failed basis after correction and retain the superseded package as controlled history.

For automatically generated groups, use the auto-stringing review checklist to inspect the generation inputs and exceptions. This page records the release boundary for the full package.

The broader solar design review checklist can sit above this sequence. It covers site basis, layout, shading, equipment, outputs, and release across the project. This article supplies the deeper stringing hold points inside that wider review.

How should solar stringing release findings be classified?

Classify stringing release findings by the earliest decision they invalidate: identity, design basis, calculation, physical mapping, document parity, authority, or release control. Then assign a disposition based on affected use, not cosmetic appearance. The classification should identify which outputs stop, which qualified role decides, what evidence closes the finding, and whether a later revision must repeat adjacent checks before release.

Use severity to communicate release effect, not to assign blame. The same visible discrepancy can carry another consequence depending on where it appears. A string label typo in a draft note may require document correction. A reused label that points installers or reviewers to another circuit relationship may require a package hold. The owner should record the actual affected use.

Avoid numerical severity scores that let minor passes average away a release-controlling defect. A package with clean formatting, complete titles, and consistent page numbers is still on hold when its equipment identity or approval authority is unresolved. The classification matrix routes the finding; it does not calculate a winner.

Also separate project correction from process correction. Repair the live package first under its release control. If the finding reveals a recurring configuration, template, training, library, or ownership weakness, open a different improvement action with its own owner. Do not leave engineering release waiting for the organization to solve a broad process problem.

Keep the superseded evidence available under revision control, so the next reviewer can see why the released basis changed and which recipients needed correction.

How should a revised stringing package be regression-checked?

A revised stringing package should be regression-checked by comparing inputs, affected objects, reopened exceptions, repeated verifications, and downstream document parity against the last authorized release. The reviewer should confirm that the requested correction is present without undoing another accepted decision. New output is not evidence of equivalence; the change map and review show what remained valid and what required reconsideration.

Begin with the change request. Name the source, former revision, current revision, and reason. Then map direct consequences and dependent records. A roof-layout change may affect membership and labeling. An equipment change can affect several review stages. A document-only correction may have a narrower path. The actual decision belongs to the responsible project reviewers, not a generic rule in this article.

Use this regression sequence:

1. Preserve the last released package and its exception record.
2. Freeze the new input set and identify every deliberate change.
3. Compare affected modules, strings, inputs, equipment, and labels between revisions.
4. Reopen prior exceptions whose basis or object identity changed.
5. Repeat the checks assigned by the project’s impact review.
6. Reconcile each affected layout, schedule, SLD, model, BOM, and customer output.
7. Confirm that unrelated accepted decisions remain intact.
8. Record the new release purpose, approver, open conditions, and superseded set.

Illustrative workflow example, not an engineering approval: A reviewer returns a stringing package because one schedule uses an equipment record that differs from the current project source. The preparer corrects the equipment identity and reruns the configured workflow. The new output also changes a group on another roof area that was not part of the return.

The preparer does not assume the extra change is an improvement. They identify both differences, reopen any exception tied to the changed group, and place affected documents on hold. The qualified reviewer repeats the project-required checks using current sources and decides whether the new grouping is acceptable. The release note distinguishes the requested identity correction from the additional regenerated change.

This workflow avoids giving project-specific voltage, current, conductor, protection, grounding, equipment, code, utility, or engineering direction. Its purpose is traceability. The team’s responsible professionals determine which technical checks apply and what outcomes are acceptable for the actual design.

Close the regression review with a compact comparison record:

Requested change:
Former and current release revisions:
Controlled inputs changed:
Generated differences not requested:
Prior exceptions reopened:
Checks repeated and evidence retained:
Downstream records reconciled:
Unrelated accepted decisions confirmed:
Current conditions and prohibited uses:
Approver and release date:

Send correction notices to any recipient who could rely on a superseded package under the organization’s document-control process. Do not merely upload the current file and assume every copy has been replaced. The release record should say which active distribution the new issue supersedes.

Frequently Asked Questions

Who should sign off solar stringing before engineering release?

The sign-off must follow the project’s jurisdiction, contract, company authority matrix, and professional-licensing requirements. A designer may prepare and self-check the schedule, while an independent qualified reviewer verifies its basis. Any decision reserved for an engineer, electrician, authority, or other responsible professional stays with that role.

Can a string schedule pass if the layout is still changing?

A schedule can support an internal study while the layout changes, but it should not be released as the settled electrical basis. Record the layout revision and allowed purpose. Any module move, deletion, substitution, plane change, or equipment change must reopen the string checks and every affected downstream document.

Do all PV strings connected in parallel need equal length?

Do not rely on a universal slogan. Compare the proposed string lengths, module characteristics, orientations, irradiance conditions, equipment topology, input limits, manufacturer instructions, and responsible design method. If unequal strings are permitted for the selected arrangement, retain the technical basis and show the difference clearly in the schedule.

What is an engineering-release hold point?

A hold point is a named condition that prevents the package from moving to its intended audience until specified evidence or approval arrives. Examples include unresolved temperature data, a missing equipment document, conflicting string counts, an unapproved substitution, or a jurisdictional question assigned to the responsible professional.

Should proposal data be checked during stringing release?

Yes, where the proposal contains design-derived module quantity, equipment, or production information. The stringing reviewer does not approve the commercial document, but should flag a revision mismatch. The current layout, electrical schedule, energy model, bill of materials, SLD, and customer output must describe the same released configuration.

Release evidence should survive the next revision

Keep the accepted input basis, independent checks, physical mapping, artifact identities, exceptions, and release authority together. When a revision changes that basis, reopen the affected checks and identify which recipients need a correction. A completed checklist supports the decision; the authorized reviewer approves the package for its named purpose.