Back to Blog
solar business23 min read

8 Design Artifacts Needed Before Scheduling Solar Work

Use eight controlled design artifacts to decide whether solar installation work is ready to enter scheduling without hiding open conditions.

Akash Hirpara

Written by

Akash Hirpara

Co-Founder · SurgePV

Rainer Neumann

Edited by

Rainer Neumann

Editorial contributor · SurgePV

Published ·Updated

Answer

Before scheduling solar installation work, verify eight artifacts: the accepted design basis, current site and access evidence, released layout, electrical design package, structural or mounting disposition, equipment and BOM record, permit and utility status record, and installation work-package release. Each must share the same project revision, expose open conditions, name authority, and state whether scheduling is allowed, restricted, or held.

A project appears on the installation calendar, but the layout is a proposal image, the BOM contains a pending inverter substitution, and the approved permit set is not the file attached to the crew task. Everyone can point to a document. Nobody can prove the documents describe one released project.

That is the distinction between document presence and scheduling readiness. Solar installation work should enter a committed schedule only when the company can identify the current design basis, the authorized work, remaining conditions, and the people who accepted them.

This article defines eight design artifacts needed before scheduling solar work. It does not authorize construction, roof or electrical access, safety plans, engineering, code interpretation, equipment suitability, procurement, permit or utility decisions, or contractual commitments. Qualified project and external owners remain controlling.

The design-to-installation handoff pack covers what crews use during execution. This page is narrower: the evidence gate that lets a project manager decide whether work may enter scheduling at all.

What does scheduling-ready mean for solar installation work?

Scheduling-ready means the company has accepted a work package for a named scope, site, revision, and time window; verified that required design, site, equipment, approval, access, safety, customer, and external conditions are satisfied or explicitly bounded; and assigned owners to every remaining condition. It does not mean all project risk is gone or that internal release replaces required external authority.

DOE’s rooftop permitting and inspection overview describes permitting before installation and inspection after installation in its U.S. context. Those are different events from a tentative calendar reservation, an internal work release or utility permission to operate. Confirm the prerequisites for the specific work and authority.

Separate planning from commitment. A project manager can model crew demand, reserve tentative capacity, or sequence dependencies before final release under company policy. The customer-facing or crew-committed schedule should identify which prerequisites are accepted and what can still change.

DOE’s overview of solar photovoltaic system design basics describes PV systems through modules, mounting structures, power electronics, and optional storage. That system view explains why one “final drawing” cannot represent every scheduling dependency. It does not define a private release standard or validate a project.

Schedule state Meaning Permitted action
Candidate Demand is plausible but prerequisites are unreviewed Capacity scenario only
Conditional Named conditions remain with owners and due events Restricted planning under policy
Ready for named work Required package is accepted for one defined scope Commit that scope subject to recorded conditions
Held Missing, conflicting, stale, unsafe, or unauthorized evidence blocks work Resolve or re-scope
Rescheduled Accepted trigger changes timing or scope Issue corrected plan and notices
Released to crew Current work package and schedule are distributed Execute only the authorized package
Superseded A successor invalidates prior schedule or package Withdraw former release

Map each artifact’s own revision ID to the common project release set. Different documents may carry different revision numbers; scheduling readiness requires compatible accepted versions, not identical labels.

Do not label the whole project “ready” when only one work package is ready. Site preparation, racking, modules, electrical, storage, commissioning, and closeout may have different prerequisites and authority.

Which eight design artifacts should be accepted before scheduling?

Accept eight artifact groups before scheduling related solar work: a controlled design basis, current site and access evidence, a released layout, an electrical design package, a structural or mounting disposition, an equipment and BOM record, a permit and utility status record, and a final installation work-package release. Every artifact must identify source, revision, owner, open conditions, dependencies, and allowed use.

1. Controlled design-basis record

The design basis states what project the company is building and which sources govern the release. It should identify site, customer or owner, project id, contract scope, system class, design objective, site evidence revisions, equipment basis, applicable external records, major assumptions, qualified reviewers, and current limitations.

Without this record, artifacts may agree by coincidence. The layout uses one module, the electrical package another, and procurement a third. A shared project name cannot prove configuration parity.

2. Current site and access evidence

The scheduling gate needs accepted site identity, relevant geometry, surfaces, obstructions, condition changes, electrical and equipment observations, access, staging, delivery, customer or property restrictions, and unresolved site gaps appropriate to the work package.

Site evidence should record source, date, method, units, coverage, uncertainty, and reviewer. Remote imagery or a prior visit may support a bounded decision when current enough for that decision. It cannot universally replace field verification or qualified investigation.

Safety and access evidence belong here as constraints, not as a generic checked box. The employer’s full safety planning and site-specific decisions remain under responsible authority.

3. Released array layout

The layout should identify the current site model, surfaces, modules, quantities, orientation, spacing, obstructions, access and exclusion areas, equipment relationships, revision, reviewer, release purpose, and any dimensions or notes relied on by installation planning.

A customer visual or preliminary concept is not automatically a construction layout. Make status visible on the artifact and in the release index. If installers need a different view or detail, generate it from the same accepted source rather than redrawing independently.

4. Electrical design package

The electrical artifact group may include the current single-line or three-line diagram, stringing information, equipment and service relationships, conductor and protection information, grounding and bonding design, labels or schedules, storage modes, connection details, calculations, notes, and qualified reviews appropriate to the project.

The NFPA 70 development page identifies NFPA 70 as a United States electrical-safety benchmark. The IEEE 1547 page identifies a distributed-energy interconnection standard. A project still needs the adopted editions, local rules, utility requirements, manufacturer instructions, qualified interpretation, and required approval.

Never treat an internal consistency check as engineering, utility, or authority approval. The release index should show the actual state and source of each decision.

5. Structural or mounting disposition

Record the accepted mounting system, attachment or foundation concept, array and equipment loads or inputs, roof or ground evidence, structural or geotechnical questions, manufacturer information, calculations, drawings, qualified reviewers, conditions, and external approvals required for the work package.

The project manager should not infer structural readiness from an array layout or racking quote. A mounting product choice does not establish site-specific capacity or attachment suitability.

6. Equipment and bill-of-materials record

The BOM should identify released equipment models, quantities, approved alternates, source schedules, technical acceptance, availability evidence, procurement state, substitutions, owner-furnished items, long-lead dependencies, and the design artifacts each item affects.

UL describes photovoltaic testing and certification services. That source supports checking equipment-specific conformity evidence. It does not establish that a product is suitable, compatible, available, correctly represented, or accepted for the project.

If a substitution remains proposed, identify the affected layout, electrical, structural, modeling, permit, utility, procurement, proposal, and installation records. Do not schedule work that depends on the substituted item as if the review were complete.

7. Permit and utility status record

The status record should identify applications, submissions, comments, responses, approvals, conditions, effective dates, expiries, revision matches, inspections, permissions, hold points, and responsible sources for permits, utilities, property owners, fire or planning authorities, programs, and other applicable external decisions.

Avoid labels such as “permit approved” without the approved document revision and conditions. One approval may allow a specific design but not authorize utility operation, site access, procurement, construction, inspection, or commissioning.

8. Installation work-package release

The final artifact connects the accepted basis, drawings, schedules, BOM, instructions, permits, utility status, safety and access planning, customer readiness, procurement, crew competence, tools, staging, logistics, scope, sequence, quality checks, stop conditions, and communication route for one named work package.

It should state what is authorized, what is excluded, which conditions remain, who can stop work, how field findings are recorded, how changes return to design, and which former package it supersedes. The release owner confirms distribution to the right recipients.

Artifact Required parity check Example schedule hold
Design basis Site, scope, equipment basis, assumptions, sources Project identity or scope conflict
Site and access Current evidence, access, staging, restrictions Critical area unobserved or access unauthorized
Layout Module, surface, quantity, obstructions, revision Proposal image presented as released layout
Electrical Equipment, stringing, service, diagrams, calculations Package revision or qualified review missing
Structural or mounting Site evidence, system, calculations, conditions Site-specific disposition unresolved
Equipment and BOM Model, quantity, alternate, technical and procurement state Proposed substitution affects design
Permit and utility Submission revision, approval, conditions, permissions Approved set differs from active design
Work-package release Scope, dependencies, safety, recipients, stop route Open condition has no owner or re-entry evidence

How should the scheduling gate be run?

Run the scheduling gate in seven stages: define the work package, resolve the active project baseline, collect the eight artifact groups, compare cross-artifact facts, classify every open condition, obtain required internal and external dispositions, then release or hold the schedule with a controlled record. Re-run affected checks whenever site, design, equipment, approval, customer, access, or safety information changes.

  1. Define the schedulable work package. Name site, scope, sequence, expected inputs, crew class, and predecessor and successor work.
  2. Resolve the active baseline. Identify current site, design, equipment, contract, permit, utility, and customer revisions before reviewing readiness.
  3. Gather artifacts by source. Link controlled files and decisions rather than copying values into a separate checklist without provenance.
  4. Run cross-artifact parity. Compare project, equipment, quantities, geometry, electrical relationships, mounting, assumptions, conditions, revisions, and release purpose.
  5. Classify open conditions. Mark missing, conflicting, stale, proposed, inaccessible, unauthorized, external, safety, procurement, and customer dependencies.
  6. Obtain dispositions. Responsible design, engineering, safety, procurement, project, customer, permit, utility, and external owners accept their scopes.
  7. Release, restrict, or hold. Publish the schedule state, authorized work, conditions, owners, due events, recipients, former versions, and change triggers.

NASA describes configuration management as providing visibility into and control of changing characteristics. A solar installation schedule is not a NASA program. The useful analogy is baseline control: a released date must point to the same configuration that design, procurement, approvals, and crews use.

Compare facts, not filenames

Cross-artifact review should compare the values and relationships that control work. Check project and site ids, surface ids, module and inverter identities, quantities, stringing, service relationship, mounting system, equipment locations, access, design notes, approved conditions, BOM items, and work-package scope. Matching “final” filenames prove none of those facts.

Use a parity table that identifies the authoritative source for each controlled fact and every consuming artifact. When a mismatch appears, return to the source owner instead of editing the easiest file. An isolated correction can make one document look consistent while leaving the underlying configuration split.

Keep automated comparison rules bounded. They can detect unequal model codes, quantities, ids, or revisions, but they cannot decide that different values are technically equivalent. Proposed equivalents and approved substitutions need their own evidence and qualified disposition.

Review the schedule as a dependent artifact

The schedule itself has a version, source inputs, conditions, recipients, and successor. Link each scheduled work package to its accepted release record. If a prerequisite changes, identify which dates, crew assignments, equipment reservations, customer messages, and external coordination events are affected.

Do not copy a date into proposal, CRM, crew, procurement, and customer systems without an owner for parity. A change should propagate through controlled events, or each consumer should receive an explicit disposition. Otherwise, the internal schedule can be corrected while the customer or subcontractor still relies on the former date.

Separate target windows, tentative holds, accepted internal plans, and customer commitments. Their evidence and authority differ. One label such as “scheduled” can hide whether materials, crews, access, approvals, and customer confirmation are actually accepted.

Test distribution and withdrawal before release

A correct work package can still fail if recipients cannot access it, open it on the work device, identify the current revision, or distinguish it from old files. Test the recipient-facing folder, portal, mobile view, print set, offline access, and language or accessibility needs under company policy.

Record who received the package, for which role and purpose, and how a successor will withdraw or supersede it. Preserve history without presenting old releases as current. If a subcontractor or supplier holds a copy outside the primary system, the distribution record should show who must send and confirm the replacement.

Avoid flooding the crew with every internal draft. Provide the current controlled information needed for authorized work and a clear route to supporting evidence or questions. Too many conflicting files are not transparency.

Need connected design, electrical, BOM, and proposal records? SurgePV can support the project artifacts that feed scheduling review while qualified project, safety, engineering, utility, permit, procurement, and installation owners retain release authority.

Explore solar designing workflows

How should unresolved conditions affect the schedule?

Unresolved conditions should affect only the work they actually control, but they must never disappear behind a calendar date. Classify each condition, identify the affected artifact and work package, assign an authorized owner, state permitted planning or field activity, define re-entry evidence, and record the stop condition. If the impact cannot be bounded responsibly, hold the package rather than guessing.

Use a condition register with identity, source, date, project revision, description, affected work, risk class, owner, required decision, allowed activity, target event, escalation, and closure evidence. Avoid “TBD” without those fields.

Some conditions can coexist with tentative capacity planning. Others should prevent crew assignment, material release, site access, electrical work, or customer commitment. The responsible qualified owner makes that distinction under company policy.

Illustrative example, not a project case

A project manager finds that the layout and electrical package identify the same module but different inverter variants. The BOM contains a proposed substitute, and the permit approval refers to the original equipment schedule. The manager does not choose the available inverter or keep the installation date by assumption.

The project enters a restricted schedule state. Design and procurement owners compare product records, qualified reviewers assess affected technical decisions, and the permit or utility owner determines whether resubmission or other action is required. This example reports no customer, equipment decision, delay, savings, safety, compliance, or approval outcome.

Copy-ready solar scheduling release record

Use one record per work package and schedule release. Link each field to the controlled artifact or source decision rather than pasting unsupported summaries.

Field Entry
Project, site, work package, scope, sequence, and target window
Active design basis, site evidence, contract, and customer revisions
Released layout and affected surfaces, equipment, access, and notes
Electrical package, stringing, SLD, calculations, reviews, and conditions
Structural or mounting disposition, calculations, source evidence, and conditions
BOM, equipment models, quantities, alternates, procurement and substitution state
Permit, utility, owner, fire, planning, program, and other external decisions
Access, staging, logistics, crew, tools, competency, safety, and stop authority
Cross-artifact parity checks, failures, and owner dispositions
Open conditions, affected work, allowed activity, owner, due event, and re-entry evidence
Release state, approvers, authorized work, exclusions, recipients, and acknowledgment
Superseded package, change triggers, field feedback route, and next review

The record is not a substitute for the underlying design, calculation, permit, safety plan, work instruction, or contract. It is the index that records which accepted artifacts and decisions support the schedule; it does not itself prove their correctness.

Where can SurgePV support the artifact chain?

SurgePV’s scope includes solar array layout, shading analysis, energy-yield modeling, financial modeling, electrical workflow support, bill-of-materials output, and proposal generation. These functions can help keep design and proposal artifacts connected before the responsible installation team runs its scheduling and work-release process. The solar designing platform describes the product workflow.

SurgePV does not observe the site, authorize access, direct safety, approve engineering, issue permits, grant utility permission, verify equipment availability, accept substitutions, schedule crews, release construction, inspect work, or make customer and contract decisions.

Use the solar sales-to-design handoff guide for the earlier commercial interface, the solar project tracking guide for state visibility, and the installation workflow guide for the broader delivery sequence.

Frequently Asked Questions

Does permit approval mean a solar project is ready to schedule?

Not by itself. Permit status is one project condition. Scheduling may also depend on current site evidence, design release, structural and electrical dispositions, utility status, equipment availability and acceptance, safety and access planning, customer or owner readiness, qualified reviews, and company policy. Record which work is authorized rather than treating one external decision as complete installation release.

Can equipment be scheduled before the solar BOM is final?

A company may reserve capacity or plan conditionally under its approved policy, but procurement or installation commitments should not treat a proposed BOM as released. Record equipment identities, quantities, acceptable alternatives, technical review, availability evidence, dependencies, open substitutions, and the decision owner. If unresolved items affect safe or authorized work, hold the relevant schedule and define re-entry evidence.

Who approves a solar installation work package?

Approval depends on the project’s contract, jurisdiction, stage, company authority, and work content. Internal project, design, safety, procurement, and operations reviews do not replace a licensed engineer, utility, permit authority, manufacturer, property owner, employer, or other external decision where required. The release record should name each approval, its scope, date, conditions, and source.

Should installers receive every design file?

Installers should receive the current controlled information needed for their authorized work, in an accessible and usable package, without stale duplicates or irrelevant ambiguity. The package may reference supporting evidence rather than include every internal draft. Role-based access, privacy, safety, contract, security, and company retention policies should govern what is distributed, to whom, for which purpose.

Can SurgePV release a project for installation?

No. SurgePV supports solar layout, shading, energy-yield and financial modeling, electrical workflow, bill-of-materials output, and proposal generation. It does not authorize site access, direct safety, perform engineering approval, issue permits, grant utility permission, verify procurement, schedule crews, or release construction. Qualified company and external owners must accept the evidence and authorize each work package.

Schedule the released work, not the hoped-for project

A calendar can show intention without proving readiness. The artifact chain gives that intention a basis: one project, one configuration, one defined work package, visible conditions, and named authority.

That shared baseline makes every later change easier to locate and route.

This does not require every project question to be closed before any planning occurs. It requires the company to distinguish tentative planning from committed work and to know exactly which unresolved condition controls each release. That distinction protects crews from stale instructions and gives project managers a defensible reason to hold, narrow, or reschedule work.

Connect the design artifacts behind the schedule

See how SurgePV supports layout, modeling, electrical workflow, BOM, and proposal outputs while qualified owners retain scheduling, safety, engineering, permit, utility, procurement, and installation authority.

Book a SurgePV demo

Sources

Primary research and reference material used for this desk-research article.

Where this fits

This article is part of SurgePV's Solar Business & Operations hub, which works through the topic from first principles to the decisions a project team actually has to make.

About the Contributors

Author
Akash Hirpara
Akash Hirpara

Co-Founder · SurgePV

Akash Hirpara is identified by SurgePV as a company co-founder. His SurgePV author page lists only role information that can be tied to the public profile below; education, certifications, project totals, financial results, speaking engagements, and media appearances are not asserted without retained evidence.

Editor
Rainer Neumann
Rainer Neumann

Editorial contributor · SurgePV

Rainer Neumann is credited as an editorial contributor on SurgePV content. This profile does not assert engineering credentials, project totals, software-testing experience, education, speaking engagements, or media citations because independent verification evidence is not retained in the publication record.

Get Solar Design Tips in Your Inbox

Join 2,000+ solar professionals. One email per week - no spam.

No spam · Unsubscribe anytime

Book Free Demo

Choose which optional technologies SurgePV may use. Essential storage remains active for security and requested features.