Imagine a designer issues Revision C of a solar drawing while an installer still has Revision B saved on a phone. The coordinator has uploaded the new file, but nobody has checked who received it. Everyone believes they are using the latest information.
This hypothetical problem is about distribution and evidence as much as filenames. A useful revision system shows which document is authorised for which purpose, what it replaces and who needs to act on the change.
The process below is an original administrative framework. It supports the responsible professionals; it does not transfer their design or installation responsibilities to the person maintaining the register.
Decide who can issue a drawing
Name the person authorised to release each type of document and define what release means. A drawing issued for comment may be suitable for discussion while remaining unsuitable for installation. “Approved” without a purpose leaves that distinction unclear.
For systems seeking small-scale technology certificates (STCs), the Clean Energy Regulator requires the relevant SAA-accredited design and installation roles and compliance with applicable requirements. Uploading or renaming a file does not satisfy those responsibilities. CER: rooftop solar installers and designers.
Give the document coordinator authority to record an issue after receiving the appropriate instruction. Preserve that instruction with the revision. If the instruction is ambiguous, send a focused question rather than choosing an approval status on the designer's behalf.
Agree the boundary with your designer using the PV design support responsibility guide.
Build one register across the document set
Use one register for the job's controlled documents. Each drawing or schedule needs an identity that remains stable when its revision changes. A job number alone is insufficient when the job contains several different documents.
| Register field | What it makes traceable |
|---|---|
| Job and document ID | The project and the particular drawing, schedule or report |
| Revision and issue date | The version under consideration and when it was issued |
| Change-request reference | Why the revision was prepared and where the request is recorded |
| Preparer and responsible reviewer | Who prepared the record and who assesses the relevant work |
| Status and permitted purpose | Draft, under review or issued for a defined use |
| Release evidence | The instruction authorising that issue, including unresolved conditions |
| Current file location | The controlled copy recipients should obtain |
| Superseded location and distribution log | The earlier version and the people requiring an update |
This is a proposed management template, not a prescribed regulatory form. Define your own status labels with the responsible professionals.
For a multi-file issue, record the included revisions together. Otherwise a new layout can travel with an old equipment schedule while both individual files appear current.
Keep the review copy separate from the issued copy
Maintain a visible distinction between working material and released records. Drafts can change during review; an issued file should remain a record of what was distributed. Correcting an issued document should create a traceable new revision rather than silently replacing its contents.
Ask the reviewer to identify the exact revision considered. An email saying “looks fine” is difficult to interpret when the conversation contains several attachments. The coordinator can request a document ID, revision and intended issue purpose without attempting the technical review.
SAA's technical requirements place responsibilities such as system specifications, site-specific design and equipment compatibility with the system designer. Administrative checks that a title block matches the register are a different activity. SAA Technical Requirements, section 3.3.
Keep the original request linked to the review. The PV design brief checklist can help identify which inputs and questions belong to that request.
Confirm recipients have the replacement
Treat distribution as a short, recorded handover. The issue message should identify the job, document IDs, new revisions, replaced revisions, purpose and any action the recipients need to take.
Use a distribution log with recipient, channel, issue time, acknowledgement and unresolved follow-up. A delivery notification proves something different from a recipient confirming that the replacement is available in the place they work.
In the hypothetical Revision C example, the coordinator asks the installer to confirm that the current issue has replaced the downloaded Revision B. The responsible professional determines what any change means for planned or completed work. A coordinator should not assume that sending the new drawing makes earlier work acceptable.
Where people use printed packs or offline devices, include those copies in the handover. Identify who will replace them. If a required recipient has not confirmed receipt, raise the exception with the person authorised to decide the next step.
Retain history without leaving old copies in circulation
Archive superseded issues in a clearly marked location with appropriate access. Preserve the release instruction, distribution record and reason for replacement alongside the file. Do not delete the evidence of what people previously received simply to tidy the working folder.
Make the active issue easy to find, while preventing an archived file from looking like a current instruction. A shared link can direct people to the current register, but each issued version should remain retrievable as a historical record.
The CER can request required STC documents for up to five years after certificate creation, including approved claims. That scheme requirement is not a universal disposal date for every business document. Set retention rules that cover the records and obligations applicable to your operation. CER: required STC documents.
Periodically test whether someone outside the original email thread can retrieve a selected issue and its release evidence.
Give offshore support a daily control routine
A trained Filipino administrator can maintain the register, prepare issue messages, follow up receipts and flag inconsistent document references. Provide named accounts, clear permissions and an escalation contact. Technical changes and release decisions remain with the appropriately authorised people.
At the start of the day, check for revisions awaiting review, authorised issues awaiting distribution and recipients awaiting follow-up. At handover, leave the next coordinator a short exception list with the affected document and specific next action.
Measure missing acknowledgements and occasions when a superseded file is found in active use. Review the cause rather than rewarding the number of files uploaded.
Talk with Nexus about solar administration support if version confusion is creating repeat work. Begin with one document register and a release process the designer and installation team both understand.
