--- type: Static title: Quality Policy description: National Digital's quality policy — how engineering quality is enforced in the delivery pipeline rather than reviewed after the fact. resource: https://nationaldigital.com.au/governance/quality-policy/ tags: [] timestamp: '2026-08-18T00:00:00.000Z' --- # Quality Policy National Digital's quality policy — how engineering quality is enforced in the delivery pipeline rather than reviewed after the fact. **National Digital** — The Trustee for Australian Business Trust, ABN 13 744 838 758 Version 1.0 Approved 17 August 2026 Approved by Cameron Young, Chief Executive Officer Review date 17 August 2027 ## 1. Purpose This policy describes the quality management system National Digital uses to ensure the software we build and maintain meets client requirements, is fit for purpose, and can be safely changed over the life of the engagement. National Digital does not hold third-party certification to AS/NZS ISO 9001. Our quality system is documented here and is enforced primarily through automated controls in our engineering platform rather than through manual sign-off — which we regard as a stronger guarantee, because the controls cannot be skipped under deadline pressure. ## 2. Quality commitment We commit to: - Understanding what the client is actually trying to achieve before proposing how to build it - Delivering software that meets agreed requirements and behaves correctly under real conditions - Preventing defects through automated verification rather than detecting them after release - Correcting defects we introduce at our own cost - Continuously improving our practices based on what goes wrong ## 3. How quality is controlled ### 3.1 Requirements and scope Work begins with a written statement of what is to be built and what "done" means. Requirements are recorded as tracked issues in Jira, one per unit of work, with acceptance criteria written so they can be tested by someone other than the author. Changes to scope are recorded against the issue rather than absorbed silently. ### 3.2 Version control and traceability All source code is held in Git repositories under organisational control. Every change is traceable to an authenticated author, a tracked issue and a point in time. Nothing reaches a client environment except through this path — there is no direct editing of production systems. ### 3.3 Peer review No change reaches a production system without review by someone other than its author. Review is enforced by branch protection rules, not convention: the platform will not permit an unreviewed change to be merged. ### 3.4 Automated testing and continuous integration Every proposed change triggers an automated pipeline that builds the application and runs the test suite. A change that fails the pipeline cannot be merged. Test coverage is written alongside the feature, and defects found in production are reproduced by a failing test before being fixed, so the same defect cannot silently return. ### 3.5 Quality assurance gate Changes carry an explicit QA state. A change cannot be merged until it has been tested against its acceptance criteria and marked as QA complete by a reviewer, with that state recorded against the tracked issue. This gate is applied uniformly across all client repositories and is enforced by the platform. ### 3.6 Staged environments Changes are promoted through development and staging environments that mirror production configuration before reaching production. Client-facing acceptance is performed in staging, on real data structures, before release. ### 3.7 Release and rollback Releases are automated and repeatable, producing the same result each time they are run. Every release is identified by the exact revision deployed, so the running state of any environment can be established at any time. Where a release causes a defect, we can revert to the prior known-good revision. ### 3.8 Monitoring and defect response Production systems are monitored for availability and error conditions. Defects are triaged by severity: those affecting availability or data integrity are addressed immediately; others are scheduled transparently with the client. Root cause is recorded for significant incidents, and the corrective action is a change to the system or the process, not a reminder to be careful. ### 3.9 Security and privacy as quality attributes We treat security and privacy defects as quality defects. Credentials are never committed to source control; access to client systems is granted per person and revoked on departure; administrative interfaces are placed behind authenticated access rather than exposed publicly. ## 4. Responsibilities **The CEO** owns this policy and the engineering standards it describes, and is accountable for delivery quality to clients. **The COO** oversees delivery management, issue tracking and client acceptance. **Every engineer, employed or contracted,** is responsible for the quality of their own work, for writing tests alongside code, for reviewing others' work honestly, and for raising rather than concealing a problem they have found or caused. Contracted engineers work inside the same controls as employees. They use our repositories, our pipelines and our review gates; there is no separate, lighter path for contracted work. ## 5. Client feedback and complaints Client feedback is sought continuously through regular delivery check-ins rather than only at project close. Any client dissatisfaction is escalated to the CEO, acknowledged directly, and answered with a specific remedy and timeframe. Where we are at fault, we say so and fix it at our cost. ## 6. Continuous improvement We review recurring defects and incidents to identify systemic causes, and change our standards, templates or automated checks in response. Improvements are applied across all repositories rather than to the project where the problem surfaced, so a lesson learned once is enforced everywhere. ## 7. Review This policy is reviewed annually, and additionally following any significant delivery failure or material change to our engineering practices. **Cameron Young** Chief Executive Officer, National Digital 17 August 2026 ## Related **Related:** - [National Digital - Custom Software, AI & Platforms](/okf/home.md) - [Talk to an engineer.](/okf/contact.md) - [Careers at National Digital](/okf/careers.md) - [Graduate Full-Stack Web Developer](/okf/australia-remote-graduate-full-stack-developer.md) - [Senior Software Engineer (Frontend)](/okf/australia-remote-senior-software-engineer-frontend.md) - [Senior Software Engineer (Backend)](/okf/australia-remote-senior-software-engineer-backend.md) - [Privacy Policy](/okf/privacy.md) - [Website Terms of Service](/okf/terms.md) - [Accessibility Statement](/okf/accessibility.md) - [Small team. Serious platforms.](/okf/about.md) - [Real platforms, in production.](/okf/case-studies.md) - [Senior engineering, end to end.](/okf/services.md) - [Knowledge library.](/okf/expertise.md) - [QA & Test Automation Engineer](/okf/australia-remote-qa-automation-engineer.md) - [Governance and Credentials](/okf/governance.md) - [Information Security and Privacy Statement](/okf/governance/information-security-and-privacy.md) - [Work Health and Safety Policy](/okf/governance/work-health-and-safety-policy.md) - [Environmental Policy](/okf/governance/environmental-policy.md)