Stack boundary
Hardware, optics, NOS image, configuration, telemetry and support ownership are described as separate parts of the solution.Configured outcome
The Australian work scope is tied to a named topology and operating requirement rather than a generic product family.Operational handover
Documentation, rollback, monitoring and escalation expectations can be included when they are part of the quote.Origin boundary
Any project-level origin wording remains separate from, and does not overwrite, global component provenance.
Evidence boundary
Hardware appearance does not establish solution origin or integration.
The representative device is not evidence that a configured stack was engineered, integrated or validated in Australia. Those statements require a project record that separates global components from the Australian activities actually performed.
What establishes a project-specific claim
- The named hardware, optics, NOS image, configuration and operating requirements
- Records of the Australian integration, validation, documentation and handover work in scope
- Approved project wording that stays within the available origin and delivery evidence
Treat open networking as a configured stack
The value and risk sit at the boundaries between the switch, optics, network operating system, configuration, automation and operating team. A project scope should identify who selects, integrates, validates, documents and supports each boundary.
- Hardware platform and supported interface profile
- Optics, cabling, breakout and environmental assumptions
- NOS image, feature set, configuration, telemetry and rollback ownership
- Acceptance, handover, support and change-control responsibilities
Use operating requirements as the eligibility record
A configured solution should start with measurable requirements: topology, speed, reach, software, observability, recovery and support. The project record then shows which Australian activities were actually performed against those requirements.
- Architecture and bill-of-material decisions recorded against the intended use
- Compatibility or validation items recorded as proven, open, excluded or accepted risk
- Handover records matched to the supplied configuration where scoped
- Project wording approved only within the evidence boundary
Technical and origin references serve different purposes
SONiC and OpenConfig sources describe technology and interfaces. ACCC guidance addresses country-of-origin representations. A technical reference cannot prove an origin claim, and an origin statement cannot prove technical fitness.
Configured scope
How the open networking and origin boundaries stay separate
Is SONiC required for every eligible project?
No. Eligibility and technical fit are separate decisions. The quoted operating model and supporting work determine the project scope.
Does using open hardware establish an Australian origin claim?
No. Hardware architecture and component source do not establish the location or significance of the project-specific work.
What should an operating handover identify?
Where scoped, it should identify versions, configuration ownership, monitoring, rollback, support boundaries, known exceptions and change-control triggers.
When should narrower wording be used?
Whenever the evidence supports only a specific activity, such as Australian architecture review or validation support, use that exact description instead of a broader origin claim.