7 Inputs to Match Across Layout, Stringing, and SLD

Three files can describe three believable solar systems. The layout shows the latest roof. The string schedule uses the new module count but the prior inverter. The SLD is electrically tidy and two revisions old. Each artifact looks competent on its own, which is precisely why the conflict can survive review.

Consistency is not achieved by asking everyone to “use the latest file.” A project needs a controlling source for each design input, an owner who may change it, and a propagation rule that identifies the outputs affected. Without those controls, “latest” means whichever attachment a reviewer opened first.

The DOE introduction to PV system design presents modules, power electronics, mounting, and balance-of-system components as parts of one system. Layout, stringing, and the single-line diagram are different views of that system. They need not display identical detail, but any fact they share must agree.

This guide is for solar designers, electrical reviewers, and operations leaders controlling a residential or commercial PV design package. It identifies seven inputs that need one approved basis across the three records. It is not an electrical design calculation, code determination, or engineering approval.

Build a control table before comparing drawings

Start with inputs, not pages. A page-by-page markup tends to collect visible differences without showing which record should change. An input control table identifies the source, owner, downstream consumers, and release effect before a reviewer judges a mismatch.

The table can live in software, but its governance comes first. If two systems both claim ownership of module count, integration only moves the conflict faster. If no role owns the release status, automated document generation can publish a draft with impressive consistency.

Run parity review at named boundaries: before engineering review, permit or interconnection submission where applicable, procurement, construction issue, and customer delivery of design-derived information. A change between boundaries opens the checks tied to that input.

What should a controlled-input parity ledger contain?

A controlled-input parity ledger should name each shared design field, its approved value and source, owner, effective revision, layout value, stringing value, SLD value, downstream consumers, exception status, and release disposition. It should distinguish “not displayed” from “unknown” and identify which change reopens review, so apparent agreement cannot hide a missing source or a document that legitimately uses different detail.

The ledger is a comparison interface, not a replacement design record. Keep calculations, equipment documents, layouts, schedules, and approvals in their governed locations. The ledger points to them and shows whether each consumer uses the same accepted input. If a reviewer has to paste an untraceable value into the ledger, that field is not controlled yet.

Use one row for each field that crosses artifacts. Module identity and total quantity may need separate rows because one can change without the other. String membership and input destination also deserve separate rows when either can move. Split a field whenever its source, owner, downstream effect, or review authority differs.

Use this copy-ready parity ledger header:

Use fixed status terms. Match means the displayed value agrees with the controlling source. Not displayed means that artifact does not carry the field. Unknown means the approved value is absent. Conflict means another value appears. Qualified means the value carries a visible condition. These states should never collapse into an empty cell.

Assign the correction from the controlling source outward. If the ledger discovers a stale SLD value, do not edit the ledger to match the SLD. Confirm the approved source, correct the affected artifact under its review workflow, and record the new revision. The ledger then reports the resolved relationship.

Finish each review with a package-level disposition. One unresolved release-controlling row can hold the affected package even when every other row matches. Do not average fields or use a percentage that allows agreement on clerical items to outweigh an uncertain design basis or missing authority.

Input 1: project identity and revision state

Every artifact should identify the same project, site, design alternative and active design basis. Retain each artifact’s own revision ID and its relationship to the release set; a layout and an SLD need not use identical document revision numbers. Project identity sounds clerical until a portfolio contains similar building names, adjacent meters, repeated house plans, or multiple customer options.

Use a stable project ID and a separate option or scenario ID. Do not encode all meaning in a file name. “Final-v3-new” is not a controlled revision. The release register should show which artifacts belong together, which ones they supersede, and what audience may use them.

Compare visible title blocks and embedded metadata, then inspect the linked source inside the system. A PDF can carry the right filename while containing an earlier drawing. A schedule can be exported after a revision but still read from cached equipment data. The reviewer needs content identity, not cosmetic identity.

When a project has two active alternatives, preserve both deliberately. Label the equipment and customer purpose for each. Do not merge their best-looking pieces into a hybrid package. The comparison decision may be commercial, but each alternative still needs internal physical and electrical consistency.

Input 2: module identity and quantity

Module model and count connect nearly every PV output. The roof layout shows physical membership. The string record groups those modules. The SLD may show counts or string lengths. The BOM, energy model, and proposal often repeat the same identity or quantity.

Confirm the exact product model, relevant suffix, datasheet revision, approved substitution state, and total quantity. Then reconcile subtotals by array, roof plane, inverter, and string where those divisions appear. Totals can agree while the wrong modules occupy the wrong group.

The Sandia PVPMC DC module guide introduces the input conditions and model forms used for module current-voltage characteristics. That mechanism explains why a physical substitution is also an electrical and modeling change. Similar dimensions do not establish equivalent electrical behavior.

When quantity changes, perform impact analysis rather than updating the nearest label. Reopen string lengths and allocation, equipment loading, relevant calculations, BOM quantities, energy model, and customer-facing figures. The responsible reviewer determines whether the SLD needs a graphical change, but the review itself should always occur.

Input 3: inverter and conversion-equipment identity

The inverter record must match across string destinations, SLD symbols and schedules, model inputs, BOM, and any customer document that names equipment. Confirm the exact model, quantity, input architecture, approved configuration, relevant documentation, and substitution status.

An equipment family name is not enough. Two variants can expose different inputs or limits while sharing a visual symbol. The stringing schedule should map to actual available inputs, and the SLD should show the intended device rather than a generic block that conceals the selection.

PVPMC’s DC-to-AC conversion modeling guide describes conversion losses and the use of algorithms to estimate conversion efficiency. It is not an electrical selection rule. It supports the operational point that performance modeling and electrical grouping must use the same approved conversion equipment.

Treat inverter substitution as a controlled change. Reopen string voltage and current review, MPPT allocation, model settings, SLD, equipment schedule, BOM, labels, and downstream approval questions. Do not allow procurement to close the substitution solely because a supplier describes the device as equivalent.

Input 4: array geometry, orientation, and physical membership

The layout owns more than module count. It locates each module on a plane with orientation, tilt, access context, obstructions, and modeled irradiance relationships. Stringing converts that physical membership into electrical groups. The SLD abstracts those groups, so geometry can disappear unless the team preserves its influence in the string map.

Review module IDs at boundaries: roof edges, plane changes, shade transitions, obstructions, and string ends. Trace them into the string schedule. A designer may have moved two modules to improve the layout while leaving their prior string assignments in place.

Physical routing also begins here. A grouping that crosses planes or access routes can appear simple in a table and awkward on the roof. The layout should show enough string or homerun information for constructability review, or it should point to a controlled routing record.

Keep modeled and measured geometry distinct. Imagery-derived roof dimensions, survey measurements, assumptions, and later field findings can have different confidence. The release status should tell the electrical reviewer which basis applies and which physical conditions remain subject to confirmation.

Input 5: string membership and equipment-input mapping

For a string-based system, each included module needs a current string assignment and each string a defined equipment input or controlled intermediate destination. For module-level conversion, use the actual module-to-device and AC grouping records instead of inventing a DC string. DOE’s PV design overview distinguishes system-level inverters from module-attached microinverters. Review the actual topology and current manufacturer information; do not transfer one architecture’s input map to another. Shared identifiers should agree across layout markers, the applicable electrical schedule, equipment allocation and SLD wherever displayed.

Trace in both directions. Start from several boundary modules and find their electrical destinations. Then start from several SLD or schedule strings and find their physical modules. One-direction checks miss orphan labels and duplicated membership.

Review string length, module type, plane/orientation grouping, parallel relationships, MPPT destination, and exception basis using the project’s approved method. Do not infer validity from balanced counts. Equal-looking groups can conceal different operating conditions; unequal groups can be valid only when the equipment and responsible method support them.

Protect identifiers through revisions. Retiring a string ID is safer than reusing it for a different physical group while old documents circulate. A revision log should say which strings were created, removed, divided, combined, or redirected and which documents were regenerated.

The detailed solar stringing release checks provide the electrical hold-point sequence. This article focuses on keeping that accepted mapping consistent across artifacts after the check is done.

Input 6: balance-of-system electrical basis

The SLD may carry conductors, protection, disconnects, grounding and bonding context, connection points, equipment ratings, and labels that the physical layout only references. Consistency means shared circuit identities and quantities agree, while specialized electrical detail remains controlled by the qualified source.

Link every SLD circuit to its calculation and schedule basis. If the layout or string map changes circuit membership, determine which conductor, protection, combiner, connector, disconnect, grounding, label, and connection decisions reopen. Do not update a module count on the SLD and leave the rest presumed unchanged.

The official NFPA 70 development page documents the National Electrical Code standard’s development. It does not prove local adoption, amendments, interpretation, or project compliance. The SLD release record should name the applicable jurisdictional and professional basis separately.

OSHA’s electrical page supplies U.S. federal electrical-safety context. A consistent document set does not by itself establish safe installation work. Employers and qualified people still need appropriate procedures, training, equipment, and field decisions for the actual conditions.

Assign document checks by role. A design coordinator can verify that a circuit ID agrees across files. The responsible electrical reviewer decides whether the circuit design is acceptable. Combining those two activities under one “SLD checked” box hides authority.

Input 7: assumptions, exceptions, and allowed use

Two drawings can match perfectly and still overstate what the project knows. Consistency includes the status of evidence. If roof dimensions remain provisional on the layout, the string and SLD release should not present the related configuration as verified construction information.

Maintain an assumption and exception register tied to affected inputs. Each entry needs the source gap or conflict, temporary basis, owner, reviewer, permitted use, condition for closure, and documents that must change. Avoid generic notes such as “verify in field” without naming who, what, and release consequence.

Use status language readers can apply: preliminary for a defined discussion, ready for responsible review, conditionally released for a named use, or released by an authorized person. “Final” says nothing about purpose or authority.

When an exception is accepted, preserve the technical or operational basis. When it is deferred, preserve the hold condition. Those are different decisions. A later designer should not see an unusual grouping and “correct” it back to a default without realizing a qualified reviewer approved the exception.

Reconcile by input after every meaningful change

A change-impact matrix makes propagation visible:

Do not regenerate everything without inspection. The matrix identifies affected outputs, while a responsible owner determines the actual change. Preserve superseded records so the team can tell what recipients previously received and whether a correction notice is needed.

Compare values at the data layer where possible, then inspect the rendered documents. Machine checks catch quantity and identifier differences. Human review catches a leader line pointing to the wrong equipment, an illegible route, a qualification buried in a note, or a diagram whose visual hierarchy implies the wrong connection.

Use a parity review that another person can repeat

Create a review worksheet with one row per controlled input and columns for approved value, source, layout value, stringing value, SLD value, downstream values, disposition, owner, and date. Record “not displayed” where a document legitimately omits the item. Do not force an artificial value into every cell.

Run the review in this sequence:

1. Freeze the release set and identify every artifact by revision.
2. Confirm project and scenario identity across the set.
3. Reconcile module and inverter identities from their approved sources.
4. Compare geometry and physical membership with the string map.
5. Trace string IDs and equipment destinations in both directions.
6. Link shared electrical items to approved calculations and schedules.
7. Compare assumptions, exceptions, and allowed use.
8. Repair from the earliest controlling source, then regenerate affected outputs.
9. Have the authorized reviewer record release or a named hold.

Do not repair a conflict by manually editing every exported PDF. Correct the controlling source and reproduce the outputs under revision control. If one artifact cannot be generated from the same source, document its manual handoff and add a comparison step at every change.

The broader solar design source of truth explains how project teams can govern competing records. Here the rule is concrete: source-of-truth ownership belongs to individual inputs, not to one magical file that necessarily contains every design detail.

Keep modeling and customer outputs inside the same revision

Energy and financial outputs often sit beyond the three artifacts named in the title, but they consume the same equipment and quantity inputs. PVPMC’s DC-to-AC modeling overview places conversion losses inside performance estimation. A changed configuration can separate the modeled result from the electrical release.

Generation and Financial Tool describes SurgePV’s modeling support, while Solar Proposals covers proposal generation. 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.

Before customer delivery, compare the design revision used by the proposal with the current release set. Do not change a module count or equipment name in the proposal without updating its originating design and model. The customer document may omit string detail, but every design-derived fact it does show needs the same approved basis.

How should layout, stringing, and SLD source conflicts be resolved?

Resolve a layout, stringing, or SLD conflict by freezing the affected release, naming the disputed input, and returning to its approved source, revision, and owner. Compare candidate values with their purpose and authority, obtain the responsible decision, correct consumers from the source outward, notify affected recipients, and retain the superseded record. Matching files do not outvote a current controlling source.

Three matching documents do not outweigh one current approved source. A layout, schedule, and proposal can all repeat the same stale module count while a reviewed change order establishes another quantity. Consistency review must test authority and revision before it counts agreement.

When sources conflict, freeze the affected release and write the disputed input in plain language. List every candidate value, its document, author, date, purpose, and approval state. Then ask the role authorized for that input to select or create the controlling basis. Do not settle the issue by copying the value found in the largest number of files.

After the owner decides, identify how the conflict arose. A user may have edited an export, a system integration may have failed, a library substitution may have bypassed review, or two design options may have lost their scenario labels. Repair the transfer that allowed the divergence, then correct the live project from the source outward.

Notify anyone who received the superseded information when the difference affects their work. Procurement may have acted on a BOM, an engineer may have reviewed an earlier SLD, or sales may have presented an older customer scenario. The release record should name the audience, correction supplied, and remaining action rather than assuming that uploading a new file retracts the old one.

Some apparent conflicts are legitimate differences in representation. An SLD may summarize repeated strings while the layout identifies each module. A performance model may aggregate subarrays differently from the electrical schedule. Record the mapping and verify that the underlying equipment, quantity, and configuration agree. Do not force documents into identical granularity simply to make a comparison tool turn green.

Close the conflict only after the controlling source, affected outputs, recipient actions, and process cause have dispositions. That record turns a mismatch into a recoverable change instead of a future argument about which attachment someone meant.

Use this conflict-resolution sequence:

1. Stop the affected release and preserve the current files.
2. State the disputed field without proposing a winner.
3. List each candidate value, source, revision, author, purpose, and approval state.
4. Identify the role authorized to control that field.
5. Obtain or create the approved basis through the project’s review process.
6. Map every consumer that inherited the wrong or uncertain value.
7. Correct from the source outward and repeat affected checks.
8. Notify recipients who may rely on superseded information.
9. Record the cause, current disposition, and reopen trigger.

Copy this conflict record into the project issue log:

Disputed input:
Affected release and audience:
Candidate values and sources:
Current controlling source:
Authorized owner or reviewer:
Decision and evidence:
Consumers requiring correction:
Recipients requiring notice:
Superseded revisions:
Process cause and separate improvement action:
Closure evidence and date:

Keep the live-project correction separate from the systemic follow-up. A broken integration, ambiguous ownership rule, or uncontrolled manual export may deserve a broader process fix. The package still needs a current, authorized disposition now. Do not hold a customer or engineering workflow open until an organization-wide improvement project finishes.

What happens when approved equipment changes after parity review?

When approved equipment changes after parity review, reopen the identity, every dependent design check, and each document or model that consumes the former selection. Preserve the released package, record the substitution source and authority, map affected fields, repeat qualified reviews, reconcile all outputs, and notify prior recipients. Do not treat similar names, dimensions, or supplier language as proof of equivalence.

Begin with the change event, not the new drawing. Record who proposed the equipment, why, which current project source authorizes consideration, and which documents use the former identity. Purchasing availability, customer preference, or a library update can initiate review, but none automatically completes the technical or contractual decision.

Illustrative workflow example, not an engineering approval: A procurement note proposes another inverter model after the layout, string schedule, and SLD have passed parity review. A designer finds the new model in the software library and can generate a visually complete replacement package. The team does not issue it merely because the export succeeds.

The design lead opens a change record and preserves the released package. The responsible reviewers compare current manufacturer information, project requirements, and the authorized design basis. The team maps every affected string destination, equipment schedule, SLD reference, bill-of-materials entry, performance-model input, proposal statement, exception, and approval. Each technical decision stays with the qualified role assigned by the project, jurisdiction, and company matrix.

If the proposed equipment is not accepted, record the rejection. Continue using the former equipment basis only if it remains valid and usable for the actual release; otherwise retain the affected hold and route another selection or resolution. Rejecting a substitute does not establish that an unavailable or otherwise invalid former choice can proceed. If it is accepted, the team produces another controlled release and identifies the older set as superseded for active use. Neither path permits a hybrid package that combines the new model name with unchecked relationships from the former configuration.

Use a change walkthrough record:

Change proposal and originator:
Former and proposed equipment identity:
Current authorization state:
Project sources reviewed:
Affected controlled inputs:
Layout impact:
Stringing and mapping impact:
SLD and electrical-review impact:
Model, BOM, and customer-output impact:
Exceptions reopened:
Qualified reviewers and dispositions:
Recipients of the prior release:
Final decision, release revision, and date:

This walkthrough deliberately avoids project-specific voltage, current, conductor, protection, grounding, code, utility, or equipment-selection instructions. Those decisions depend on the actual product, site, jurisdiction, and responsible method. The workflow records evidence of routing, review, propagation and release. Qualified reviewers must still assess the technical basis; matching documents alone cannot establish its correctness.

End with a regression check. Confirm that the requested equipment change appears everywhere it should, nowhere it should not, and did not silently reverse another accepted exception or customer choice. A clean parity ledger after regeneration is useful only when its controlling sources and approvals are also current.

The changed-equipment record is not complete until each consumer has a disposition. “No visible change” can be valid only when the responsible reviewer records why the artifact does not display or depend on the revised field. An empty cell cannot distinguish a reviewed nonimpact from an overlooked file. Use updated, reviewed with no change, not applicable, on hold, or superseded, then link the evidence for that status.

Before closing, ask a reviewer outside the change preparation to open the active release set without verbal guidance. They should be able to identify the selected equipment, trace its controlled source, find the affected stringing and SLD decisions, see which model and bill-of-materials records apply, and understand every remaining condition. If the reviewer finds two plausible identities or needs an old chat message to choose, the parity handoff is not finished.

Finally, inspect distribution. Confirm that engineering, procurement, sales, operations, and any external reviewer in scope received the revision appropriate to their work. The team need not send every artifact to every role, but each recipient should have a clear supersession notice when a fact they use changed. Record that notice beside the release rather than trusting inbox order.

Frequently Asked Questions

Which file should control when the layout and SLD disagree?

Neither file should win automatically. Return to the approved project source for the disputed input, identify its current revision and owner, then correct every affected output. If no controlling source exists, place the release on hold and have the responsible role decide the basis before editing either document.

Does a module-count change require a new SLD?

Review the SLD whenever module quantity changes. The effect depends on string membership, equipment loading, conductor and protection basis, labels, and the level of detail shown. Record which electrical checks and documents were reopened, even when the responsible reviewer determines that the SLD graphic itself needs no visible change.

Can a spreadsheet be the source of truth for PV stringing?

A controlled spreadsheet can own a defined string schedule if its inputs, formulas, revision, access, and review are governed. It should not become an unofficial source beside a design model and SLD. Name which fields it controls, which system supplies them, and how approved changes propagate to downstream records.

How often should layout, stringing, and SLD parity be checked?

Check parity at every release boundary and after any change that affects a controlled input. Do not rely on a calendar interval alone. A module substitution, inverter change, roof revision, string move, electrical-basis update, or accepted field condition should reopen the named consistency checks immediately.

Can software prevent every layout-to-SLD mismatch?

Software can share identifiers, propagate values, flag conflicts, and retain revisions. It cannot prove that source evidence is correct or decide whether a project exception is acceptable. Teams still need controlling-source rules, qualified review, change impact analysis, and a release record that names unresolved conditions.

Agreement comes from controlled inputs, not matching PDFs

The layout, string record, and SLD have different jobs. Forcing them to look alike would remove useful detail. Their agreement should appear in the seven inputs they share, the revisions that bind them, and the exceptions that qualify their use.

Give each input one approved source and owner. Reconcile downstream values after a change. Keep specialized technical decisions with qualified roles. A reviewer can then explain why the three artifacts describe one system, even though each shows a different view of it.