Quality Policy

National Digital — The Trustee for Australian Business Trust, ABN 13 744 838 758

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