Answer
Capture one recurring decision through real project examples. Ask what evidence changed the expert’s answer, write the normal rule and its exceptions, then have another qualified teammate apply it to a different case. Keep the rule’s scope, owner and revision visible. A checklist should preserve judgment, not pretend to replace it.
“Ask the senior designer” is a useful escalation route, but it is a poor instruction for every routine question. Start knowledge capture with one decision that repeatedly interrupts that person: whether an intake packet is usable, which revision controls a proposal, or when a change needs another review.
This is an editorial method for documenting team decisions. It does not authorize an inexperienced employee to make engineering judgments or claim that a checklist reproduces an expert’s competence.
Interview around contrasting project examples
Ask the expert to choose a routine case, an exception and a case that had to be returned. Remove customer information that the training audience should not see. Walk through the evidence available at the time, rather than explaining the answer with hindsight.
Use these prompts:
- What decision were you being asked to make?
- Which input did you check first, and why?
- What missing or conflicting evidence changed your response?
- Which conditions made this case different from the routine one?
- What could a teammate decide, and what had to come back to you?
Keep the original evidence linked to the example. A statement such as “this roof needs more information” teaches little unless the learner can see which observation was missing.
Write a rule someone can use at the point of work
| Field | What to record |
|---|---|
| Decision | The specific question the rule helps answer |
| Scope | Project types and stages it covers |
| Required inputs | Records the reviewer must have before applying it |
| Normal route | The action allowed when the stated conditions hold |
| Exception | A condition that stops the normal route |
| Escalation | Who receives the exception and what evidence to send |
| Ownership | Rule owner, revision and next review trigger |
Avoid instructions such as “use common sense” or “check carefully.” Replace them with an observable question. For an intake rule, that might be whether the submitted address and selected building agree. It is not a universal instruction for designing that building.
Test the rule without coaching the answer
Give another appropriately qualified teammate a different project example and the written rule. Ask them to explain their decision and identify where the instruction is ambiguous. The point is to test the document, not to grade a person on information that remains in the expert’s memory.
Illustrative example: a draft rule says “return incomplete bills.” A learner receives a bill whose consumption pages are present but whose site identity is unclear. The expert explains that identity matters to this decision. Revise the required-input section to name that check, rather than adding a vague instruction to be thorough.
Record disagreements. If reasonable reviewers interpret the rule differently, clarify its scope or escalation route before treating it as a standard.
Maintain examples when the rule changes
NASA’s configuration-management guidance describes controlling changes and keeping product information consistent with its configuration. This is a process reference from NASA, not a solar training requirement. Apply the limited lesson here: keep the active rule and its supporting examples on the same revision.
When a rule changes, record the reason and which training materials need revision. Retain prior versions for understanding past decisions, while making the current instruction clear to the team.
Put the captured knowledge into a handoff
Try the rule where it will actually be used: an intake review, design return or proposal check. Ask whether the recipient can find the evidence and act without another explanatory call. Use the project handoff worksheet to decide where the rule and its exception record belong.
Use the founder-delegation worksheet to define who may act on the captured rule and when a decision must return to its owner. Capturing an instruction and delegating authority are separate tasks; a shared document alone does not establish either technical competence or permission to approve.
SurgePV publishes this workflow guide. Product training can explain an interface; your organization still owns role authority, technical qualifications and the evidence needed for its decisions.
Frequently asked questions
Which decision should we document first?
Choose a recurring decision with an identifiable output and examples the expert can explain. Start narrower than an entire design discipline. Intake completeness or revision selection may be easier to document than a complex engineering judgment.
How do we know whether the checklist works?
Ask a qualified teammate to apply it to a different case without coaching. Record ambiguity, missing inputs and unexpected exceptions. This tests whether the instruction communicates the intended decision; it does not certify technical competence.
Who should maintain the rule?
Assign an owner who can approve changes within the rule’s scope. Name review triggers such as changed equipment documentation, revised internal responsibilities or an exception that the current rule does not handle.
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.
