We use the details you submit to review and respond to your project enquiry. Entries are handled in this website’s WordPress database using Fluent Forms; our hosting and email providers may process the submitted details. Other technical providers receive only the data described in our Privacy Policy.
Please do not send passwords, payment-card details, government identification numbers, sensitive personal data, or unnecessary confidential third-party information.
OSD Tank Hub is an owner-facing guide to the decisions, records and handovers around an Australian detention project. Engineering responsibility stays with the designer. Your job is to provide trustworthy site information, identify the decision-maker for each step, protect the accepted design during construction and keep the evidence the future asset custodian needs.
On-site detention temporarily stores stormwater runoff and releases it at a controlled rate. The on-site detention system sits within the wider drainage system. This stormwater management function can reduce pressure on downstream drainage and flooding risk, but it doesn’t guarantee that flooding won’t occur. This wider asset includes the inlet, storage, controlled outlet, overflow path, access points and the records that explain how each part should be inspected. For the technical flow path, see Storm Manage’s guide to how stormwater detention systems work.
Owner’s rule: follow this guide to prepare questions and keep the evidence. Don’t modify an orifice, overflow, tank, pipe, surface level or access point from commonly available information. Requirements differ by authority and by project, so place final design decisions with the responsible engineer and approval team.
Updated August 2026 · Australian English · Owner and project-client guidance
Start With the Property Question: Is OSD Part of This Site?
With that owner role clear, begin by searching the approved records before making assumptions from surface appearance. Whether this is an existing property or an urban development project, OSD systems might be above or below ground. Approved development consent, drainage plans and maintenance records are more reliable than visible entry points or plaques alone.
Start a brief evidence checklist. Search for the development consent and its drainage conditions, approved civil or stormwater drawings, title or covenant information where relevant, building or strata records, previous inspection reports, maintenance schedules, asset registers and any identified pits or plaques. Write down what you found, where you found it and whether it appears up-to-date. A missing file raises unanswered questions rather than proving the non-existence of an OSD asset.
Local information varies. As a named example, City of Parramatta’s stormwater engineering guidance connects underground storage with service loads, drainage behaviour, surface inspection, access, ventilation and downstream conditions. Those topics help an owner identify useful records and questions; they aren’t a nationwide checklist.
Northern Beaches Council’s engineering specifications list a dedicated OSD technical specification within the authority’s own water-management documents. This is another reason to identify the relevant council and current local controls before treating any document list as universal.
If the property is in New South Wales and you need the detailed pathway discussion, view the separate NSW council and Sydney Water OSD guidance. Keep this first step more modest: identify the probable asset, gather existing records, name the responsible authority and address the gaps with a qualified adviser.
The OSD Responsibility Relay: Who Decides What?
OSD projects work best when each decision is made by the responsible party and the next party receives usable evidence. The OSD Responsibility Relay maps owners, engineers, approval authorities, suppliers, installers, commissioning parties, custodians, maintainers and future recipients. Weak handovers leave the next person working from assumptions. The technical questions in City of Parramatta’s engineering guidance show why storage loads, drainage behaviour, inspection access and cleaning access must remain with the qualified technical team.
Role category
Decision owned
Evidence handed forward
Owner or developer
Project objective, known site records, programme, budget responsibility and future custodian
Consent, drawings, site changes, constraints and a gap list
Civil or hydraulic engineer
Catchment, storage, discharge, overflow, interfaces and design certification
Design basis, drawings, calculations and defined acceptance evidence
Council, certifier or authority
Applicable requirements and the evidence needed for the relevant approval stage
Conditions, comments, acceptance or required revisions
Supplier
Documented product data, configuration boundaries and traceable supporting proof
Approved submittals, product records and installation information
Installer or contractor
Construction to approved details and escalation of site conflicts
Inspection records, photographs and recorded variations
Commissioning party and custodian
Completion checks, document custody, inspection access and maintenance records
Handover file, schedule, contacts and continuing asset history
Maintenance provider
Inspection and maintenance tasks within the approved schedule and site safety controls
Dated findings, work completed, unresolved concerns and repair records
Future owner or manager
Continuing custody, access and escalation after ownership or management changes
Acknowledged transfer of the current master file and open-action register
This transfer isn’t always a straight line. A supplier request might loop back to an engineer; a newly revealed service might return to the design team; an authority comment might affect several parties. Use one simple test: can the next decision-maker see the current approved basis, the open question, who’s responsible for the answer and what has changed?
Owners should avoid two shortcuts. Don’t push the supplier to quietly assume the engineer’s design role, and don’t let a site change become the new basis simply because construction has moved on. Document the problem, pause the affected work where appropriate, and send it back through the relevant technical and approval team.
Read an OSD Plan Without Redesigning It
Owners don’t need to redo the hydraulic calculations, but they should recognise the terms that frame the discussion. Some drawings call the storage a stormwater detention tank or on-site detention tank; treat that label as one storage element within the wider stormwater system, not the whole asset. Plan literacy also helps test whether the real site matches the approved configuration. Penrith City Council’s inspection guidance provides a useful component model: inlet, storage, controlled outlet and overflow, with screens used to reduce blockage risk.
Catchment and impervious area: the surfaces contributing to runoff. Ask if roof areas, pavement, and buildings have been reflected correctly in the approved plans.
Storage or SSR: the detention volume required by the design basis. Ask where it will be provided and what space or cover constraints protect it.
Permissible site discharge: the controlled flow rate according to the design basis. Ask which approved document contains this value and don’t take values from other projects as reference.
Controlled outlet, orifice or orifice plate: the device controlling the release. Ask how it will remain identifiable, accessible and protected from blockage or alteration.
Overflow path: the route the water will take if the controlled system is blocked or overwhelmed. Ask if site works proposed later will alter it.
Discharge point: the location where water leaves the site via the controlled system. Ask if there have been changes in the downstream infrastructure, easements, or connections.
Access and maintenance schedule: how to inspect the site, the routine, and who owns those records.
Different drawings, council documents, suppliers and search results use overlapping language. Use this 9-Category OSD Terminology Map to turn unfamiliar wording into the next owner question. It is a vocabulary check, not a design or product-selection shortcut.
Question category
Terms you may see
Owner boundary
System name
on-site stormwater detention, onsite stormwater detention, Australian OSD
Confirm which term the current approval documents use.
Tank label
on-site stormwater detention tank, onsite detention tank, water tank, rainwater tank, retention tank
Ask whether the asset provides controlled detention, reuse, retention or a documented combination.
Use the engineer’s current basis and authority pathway; do not copy another site’s values.
Site water
rainwater runoff, stormwater runoff, heavy rainfall, impervious surfaces, infiltration, flow of water, storm water
Ask how the approved plans define catchment, inflow, overflow and downstream conditions.
Network interface
local stormwater, stormwater drainage system, stormwater infrastructure, council drainage system, stormwater drains
Confirm the approved discharge point, easements and connection constraints.
Approval path
local council, council requirements, development control plan, drainage infrastructure
Obtain the current local records instead of treating a general guide as approval.
Delivery wording
backfill, curing time, installation time, faster installation, detention market, complete guide to OSD, manage stormwater, prevent flooding
Treat commercial or search wording as a prompt for evidence, not proof of suitability or approval.
Useful owner observations often aren’t quantitative. They might include, “The architectural plans now show a driveway across this area,” or, “This proposed fence would block the existing access.” These comments let the technical team review the design against the real site without shifting design responsibility to the owner.
Build the Eight-Input Owner Brief Before You Ask for a System
Use the Eight-Input Owner Brief as a pre-design record, not as the design itself. It packages what an engineer and supplier need to know about site conditions, clearly separates evidence from assumption and reveals missing decisions early. One document with referenced files is far more useful than a lengthy email filled with half-checked data.
Site and authority: Provide full street address and local government area and identify water or relevant approval authority as applicable.
Development scope and stage: describe what work will be undertaken and what phase the project is currently in (e.g., feasibility, approvals, detailed design, construction, completion).
Available records: List relevant approved drawings (by issue date and name), relevant consent conditions, land title details, survey plans, and any previous drainage documentation (by file name and date).
Impervious-area changes: document known or assumed changes to roofs, paving, driveways and other hard surfaces, then label each one existing, proposed or uncertain.
Downstream constraints: document the known discharge point, easement, connection or downstream concern, but leave hydraulic decisions to the designer.
Physical use constraints: document proposed traffic, cover, buildings, landscaping, services, access, land use and available space.
Programme and responsibility: name who procures, installs, inspects, records variations and coordinates approval evidence.
Future custody: name the expected asset owner, handover format and person or organisation that will maintain the master record.
Use three labels in the brief:
Confirmed fact – evidenced by a current drawing, condition, survey, statement or another named record.
Working assumption – needed for discussion but not yet confirmed.
Open question – has a named owner and a date by which a response is required.
This distinction matters because an unlabelled assumption can pass through several handovers until someone treats it as approved site data. When the brief says, “Discharge point assumed from an old sketch – engineer to verify,” the uncertainty stays visible.
Once the technical basis has been defined, cost and size can move to the centre of the discussion. Storm Manage keeps those commercial calculations on its dedicated OSD cost and sizing project tools, so they don’t burden this owner guide.
Move From Approval to Commissioning Without Losing the Evidence
Keep the approved design traceable through procurement, construction and commissioning. A practical sequence runs from the approved basis to construction information, recorded variations, completion evidence, then operating and maintenance information. Each step should point back to the decision it implements.
Start with a controlled issue of the approved drawings and associated conditions. When a supplier submittal is accepted, record the design or approval item it relates to. During construction, collect photographs and inspection evidence before important areas are covered. Note any service conflict, access change, surface-grade change or substitution against the current design and refer it to the responsible engineer and approval party.
Any undocumented variation carries two risks. The completed asset may no longer match the design evidence, and a future maintainer may inspect the wrong place or misunderstand how the system should function. A verbal agreement reached on site is even less durable after the project manager, developer or facilities provider changes.
Commissioning isn’t just a final tick. It is the point at which the project reconciles what was approved, what was installed, what was inspected and what the owner is being asked to maintain. Those component and access checks in Penrith City Council’s OSD maintenance guidance illustrate why the handover must identify what future inspections actually cover. Document names vary with the authority and project, so ask the responsible engineer or certifier to identify the required set instead of copying another development’s pack.
What Belongs in the OSD Handover File?
A durable document pack should let a future owner identify the asset, confirm the approved basis, arrange inspection and trace later work. Some records are commonly useful; others are authority or project dependent. Label the difference so a practical owner checklist doesn’t become a false statement about what every project must contain.
Current approved design, relevant conditions and nominated design contacts
Can you identify the current issue and approval context?
Completed asset
As-built or work-as-executed information where required, asset locations, access details and recorded variations
Do the records describe what is actually present?
Acceptance evidence
Relevant certifications, inspections, photographs and commissioning records
Has the responsible party identified what the project needs?
Operation and care
Approved maintenance schedule, safe-access information, inspection log and responsible contacts
Can the custodian arrange work without guessing?
Asset history
Repair history, warranties, later modifications, incidents and professional reviews
Will the next owner inherit the decisions, not just the tank?
Put a one-page custody record at the front. Name the master-file location, current custodian, backup location, last update date and transfer recipient. Update it after a sale, strata transition, facilities-management change or substantial repair. A folder that exists but has no owner is still a handover failure.
Store records in a readable format for whoever comes next. Keep final signed or approved documents, not just links to contractor portals that may expire. Where the authority or project requires specific registered, certified or named records, add them to this practical core; don’t expect the core to replace them.
Maintain the System You Actually Own
Base the maintenance routine on the approved system and its schedule, not a generic interval lifted from another site. Translate that schedule into named ownership, accessible records and repeatable inspection entries. The work maintains the asset; the log preserves evidence across its life.
Useful logs should include the inspection date, rainfall or incident context, inlet condition, accessible storage observations, outlet or screen condition, visible overflow evidence, access condition, action taken and any qualified reviewer involved. Record the date and contractor details for each repair or cleaning action too.
According to Penrith City Council’s WSUD inspection and maintenance guidance, a below-ground OSD system includes the inlet, storage, controlled outlet and overflow, with screens used to reduce blockage risk. An empty-looking surface area doesn’t prove that the outlet is clear.
Access is a fundamental part of the asset. City of Parramatta’s engineering guidance connects underground storage with inspection, cleaning access, drainage behaviour, ventilation and service loads. An owner doesn’t need to check unsafe or inaccessible areas personally; the owner needs to keep access available and arrange the right competent party.
After an unusual rain event, building work, paving changes or an observed incident, record the context before arranging a review. Don’t enter a confined space or reach into a chamber to check a suspected blockage. The approved maintenance information and site risk controls should determine who performs the work and how.
Visible Warning Signals and When to Escalate
A warning sign is a reason to investigate further – record it, take photographs and arrange the right review – not a root-cause finding. Similar observations can have hydraulic, structural, maintenance or site-interface causes. Compare the condition with the approved behaviour and maintenance records before deciding the next step. This component-based escalation approach follows the inspection logic in Penrith City Council’s OSD maintenance guidance, rather than assuming one visible symptom proves one cause.
Visible observation
Immediate owner action
Escalation question
Recurring ponding outside the documented behaviour
Record time, rainfall context, location and photographs; keep people away from unsafe areas
Does the responsible engineer or maintainer need to check inlet, outlet, levels or downstream conditions?
Blocked or damaged visible screen, displaced grate or inaccessible access point
Secure the area if needed and arrange competent inspection
Can the approved maintenance task still be performed safely?
Erosion, sinkage, cracking or unexpected overflow marks
Avoid excavation or structural intervention; preserve a dated record
Is structural, geotechnical, drainage or authority review required?
New odour or ventilation concern near an access point
Do not enter; isolate the area as appropriate and call a competent service provider
What site safety controls and specialist checks apply?
Driveway, landscaping, services or structures added near the asset
Compare the proposal with current drawings before work proceeds
Could the change affect loading, cover, access, levels, inflow or overflow?
Records missing after an ownership or management transfer
Create a gap register and request records from previous custodians and project parties
What must be reconstructed or reverified before maintenance or alteration?
This table isn’t an instruction to alter an orifice, force-clear an obstruction, excavate around a buried system or make a structural repair. It defines the owner’s response: protect the area, preserve evidence and send the question to the party qualified for the suspected issue.
From Owner Brief to Supplier Proof
You are ready for commercial system review when you can show the engineer-defined performance basis, current drawings, authority path, local constraints and who manages each handover. Supplier proof should answer those defined needs; it shouldn’t be used to invent the needs after purchase.
Current engineer-defined storage, discharge, overflow and interface basis
Confirmed authority and approval-stage requirements
Known traffic, cover, land-use, access, space and service constraints
Traceable proposed configuration and supporting product records
Named installation, inspection and commissioning responsibilities
Agreed handover format, maintenance schedule owner and asset custodian
Once the inputs are ready, review the OSD Tank Hub solution and project tools. Storm Manage describes its production base, delivered-project history and export reach on the page about Storm Manage. Treat those as first-party company statements; project acceptance still depends on the responsible engineer and authority.
Reviewed first-party figures state that the Shenzhen production base was established in 2014, spans 8,000 square metres, has supported more than 400 delivered projects and serves customers in more than 30 countries. These figures describe the company, not approval or performance for this project.
Have the Eight-Input Owner Brief and current drawings ready?
Use them to open a focused project discussion about documented system evidence and the next technical handover.
How can I tell whether a property already has an OSD system?
Check development consent, approved drainage drawings, title or strata records, maintenance files and visible asset markers, then verify any gaps with the relevant authority or engineer.
Look for development-consent conditions, approved civil or stormwater plans, title or covenant documents where relevant, building or strata asset registers, maintenance schedules, inspection logs, pits and identification plaques. An underground system may not be obvious, while one visible pit may not reveal its function. If records conflict or are missing, ask the relevant council, certifier or qualified engineer to confirm the current approved arrangement.
What OSD documents should I receive at project handover?
Receive the current approved design, completed-asset records, project acceptance evidence, access information, maintenance schedule and a named custodian for the master file after completion and transfer.
Key information includes the current approved design and relevant conditions, completed-asset or as-built information where required, recorded variations, project certification and inspection evidence, asset and access locations, the maintenance schedule, responsible contacts, warranties and inspection history. Document names vary, so ask the responsible engineer or certifier to identify authority-specific items and record who will retain the master file.
Can I change a driveway, landscaping or structures above an OSD system?
Do not change a driveway, landscape or structure until the responsible engineer and approval party have checked its effect on the approved OSD arrangement and maintenance access.
New work can affect loading, cover, surface levels, inflow, overflow paths, inspection access, buried services or the ability to clean the asset. Compare the proposal with the current approved drawings and send the marked-up change to the responsible engineer and approval party. A product load rating or contractor’s verbal assurance doesn’t establish that the whole site arrangement remains acceptable.
Who should keep OSD maintenance records in a strata or commercial property?
Name one accountable asset custodian, one master-file location and a transfer process that survives changes in strata, facilities management or ownership over the asset’s life.
Depending on the property, this may be the owners corporation, building owner or facilities organisation. A contractor can create an inspection or repair log for its work, but the asset custodian should keep the full asset history. Record the primary contact, backup location and transfer process so a new manager or ownership change doesn’t break the maintenance trail.
What should I do if water ponds, an outlet appears blocked or overflow marks appear?
Protect the area, record the rainfall context and visible evidence, avoid entering chambers or altering components, and arrange qualified review against the approved system before work resumes.
Record the time, rainfall context, location, duration and photographs without entering a chamber or attempting excavation, orifice work or structural repair. Check the approved maintenance information for the nominated service process, then contact the responsible maintainer or engineer. A visible condition doesn’t reveal by itself whether the cause is blockage, downstream conditions, altered levels, structural movement or approved detention behaviour.
