Capability Checks
Part of Agency quality assurance
Assessing technical work without pretending to be the specialist
Ask for a traceable change, bounded verification and specialist review where needed before accepting agency technical work.
You can decide whether delivered technical work is ready to accept without claiming to validate code or make a specialist diagnosis yourself. Identify the agreed result. Ask what changed and how the change was checked, then assess what that evidence establishes. Bring in a qualified reviewer for a defined question when the consequence of an error warrants one.
Ask for a traceable account
Start with the approved requirement and the problem it addressed. The handover should identify the affected system or pages, deployed version, implementation owner, check performed and remaining limits. Ask the agency to separate what it observed, what it inferred, what it changed and what the subsequent check showed.
Consider a hypothetical task about pages missing from Google Search. Ask which pages were affected, what condition was found, what change was deployed and what the latest inspection shows. Google says meeting its minimum technical requirements makes a page eligible for indexing. Acceptance can therefore address the agreed technical change and its verification without promising that Google will include the page.
Technical verification benchmarks from authoritative sources
- Google indexing eligibility
- Meeting minimum technical requirements
- W3C accessibility conformance
- No tool alone determines compliance
- Australian Contract Management Guide
- Emphasises documented change and verification processes
Define the question the evidence must answer
Ask a question tied to the required result. “Does the submitted form reach the agreed destination?” “Does the live page show the approved content?” “Does the changed URL return the intended response?” The agency might supply a test result, change record or demonstration. Record the version and environment checked. Label a staging result as staging until the relevant live result has been checked.
A useful handover note identifies:
- The agreed requirement and affected component.
- The change and its release version.
- How it was checked and the result observed.
- Known limits, open defects and the correction owner.
- The acceptance decision requested from the client.
How to validate technical handover with confidence
- Clarify the required resultMatch the change to the approved requirement
- Confirm the version and environment checkedRecord staging vs. live status clearly
- Identify what was tested and what wasn’tCheck scope coverage including edge cases
- Request specialist input if neededFor security, accessibility, or complex logic
- Accept only verified outcomesHold acceptance until gaps are closed
Use the right reviewer
A business owner can confirm whether a process produces the intended business result. A developer, security reviewer or accessibility specialist may need to assess the technical method or a relevant standard. Give that person access to the actual change and a bounded question. Ask for a finding with its evidence and limits.
An automated accessibility scan can identify some problems, but W3C says no tool alone determines whether a site meets accessibility standards. Agree the applicable standard and review scope for the project before treating a clean scan as evidence of conformance.
What to verify vs. what to leave to specialists
- Business owner can confirm
- Whether the process delivers the intended business outcome
- Developer may assess
- Code implementation, system integration, and deployment integrity
- Accessibility specialist should review
- Compliance with W3C standards (e.g., WCAG) across all user contexts
- Security reviewer evaluates
- Authentication, data handling, and protection against vulnerabilities
Accept only what was shown
A report may establish that a change was deployed and a named check passed. It may leave other pages, devices or user situations unexamined. Ask what was checked, what was sampled and whether an essential journey falls outside that scope. Hold the relevant acceptance point, or request a further check, when the gap matters.
Record the decision against the reviewed version. Describe an observed defect and the expected behaviour, then let the specialist propose the repair. Recheck the affected result after correction.
