Requirements - Solution Design & Methods - SD09 - Standards Selection

We should adopt the right standards for API development, supported by user, consumer, and market / supplier engagement.

Requirement description

This requirement is about ensuring API standards are selected and applied deliberately rather than arbitrarily. The standards adopted should meet user and consumer needs, support interoperability, align with industry practice, and be informed by engagement with consumers, suppliers and the wider market.

The focus is not simply whether standards exist, but whether the chosen standards are appropriate, consistently applied and supported by evidence of engagement with those who will consume, integrate with, support or supply the API.

In simple terms:
Use recognised API standards, apply them consistently, and demonstrate that the approach has been informed by consumers, users and the market.

Scoring rubric table – API Standards Adoption

Score What it looks like Typical evidence Key gaps / risks
0 No evidence that API standards have been identified, selected or applied. API design appears inconsistent or bespoke. No API standards documentation, no design guidance, no evidence of consumer engagement. Significant interoperability, supportability and integration risk.
1 Limited evidence that standards have been considered. Adoption is informal or dependent on individual developer preference. Verbal statements, isolated design guidance, undocumented implementation approaches. High-risk gaps. Standards are inconsistently applied and consumer requirements are poorly understood.
2 Some API standards are identified and partially implemented. Limited engagement has been undertaken with consumers or suppliers. API specifications, partial design standards, workshop notes, stakeholder feedback from limited groups. Significant notable gaps remain. Adoption is inconsistent and there is little evidence that standards have been validated against market expectations.
3 Most APIs follow defined standards and guidance. Consumer needs have been considered and there is evidence of engagement and design rationale. API design standards, API specifications, consumer feedback, design reviews, architecture documentation, stakeholder engagement records. Notable gaps remain. Some APIs or services diverge from standards, or engagement activities are incomplete or poorly evidenced.
4 API standards are clearly defined, consistently applied and informed by consumer, supplier and stakeholder engagement. Deviations are documented and approved. Maintained API standards, governance records, architecture reviews, onboarding guidance, supplier engagement outcomes, API assurance activities. Minor gaps only. Remaining deviations are understood, justified and subject to review.
5 Comprehensive and exemplar adoption of API standards. Standards are actively maintained, widely understood, informed by ongoing engagement and demonstrably influence delivery decisions. Published and governed API standards, measurable adoption metrics, regular consumer engagement, supplier feedback processes, architecture governance records, continuous improvement activities and evidence of standards evolution. Minimal or no significant gaps identified.

What assessors should look for

  1. Defined API standards – Evidence that recognised API design standards, conventions or patterns have been established.
  2. Consistent implementation – Evidence that standards are applied across APIs rather than on an exception basis.
  3. Consumer engagement – Evidence that API consumers have influenced standards, usability, design or lifecycle decisions.
  4. Supplier and market engagement – Evidence that wider industry practice, supplier capabilities and interoperability considerations have informed decisions.
  5. Governance and assurance – Evidence that compliance with standards is reviewed and managed through architecture governance processes.
  6. Management of exceptions – Evidence that departures from standards are documented, risk assessed and agreed.

What separates a 3 from a 4 or 5

A score of 3 normally indicates that standards exist and are used by most teams, with evidence that consumer needs have been considered. However, adoption may be inconsistent, governance may be weak, or engagement evidence may be incomplete.

A score of 4 requires clear evidence that standards are consistently applied, deviations are managed through governance, and engagement activities have informed the standards being used.

A score of 5 requires a mature and demonstrably effective approach. Standards are actively maintained, regularly reviewed, supported by ongoing consumer and supplier engagement, and evidenced as influencing real architectural and delivery decisions.

Suggested evidence examples (not SAF-mandated artefacts)

  • API design standards and style guides
  • OpenAPI specifications
  • Consumer research and feedback reports
  • Developer portal standards and onboarding guidance
  • Architecture review outputs
  • Supplier engagement records
  • API governance and assurance reports
  • Documented exemption and waiver processes

Updated: 04 September 2026 (SAF Version 1.1)