Glossary

The static site generator used to build the WAF++ documentation from AsciiDoc sources. Antora handles component versioning, navigation, and publishing — the WAF++ docs live at /docs/ and are built from the framework repository.

See also: AsciiDoc

The markup language used to write WAF++ framework documentation. Similar to Markdown but with richer semantics for structured documentation. All files in modules/ROOT/pages/ use AsciiDoc (.adoc extension).

A structured evaluation of a cloud workload against the WAF++ controls across all applicable pillars. The output of an assessment is a set of findings per control and a PASS score per pillar and in aggregate.

See also: Workload, PASS model

A short document that defines the purpose, scope, deliverables, leads, and communication channel of a Working Group. A charter is required before a WG can be officially recognised.

See also: Working Group

A specific, testable requirement within a pillar. Each control has a unique ID, a description, an assessment question, and a rationale. Controls are the atomic unit of the WAF++ framework — a workload either satisfies a control or it doesn't.

See also: Control ID, Pillar, Controls library

The unique identifier for a WAF++ control, following the pattern WAF-[PILLAR]-[NUMBER]. Example: WAF-SOV-010 is the first control of the Sovereign pillar. The pillar abbreviation is a three-letter code (e.g. SEC for Security, SOV for Sovereign). Control IDs are stable — once published, they never change or get reused.

The full collection of WAF++ controls, stored as structured YAML files in the framework repository under modules/controls/. Each file defines one control with its ID, pillar, title, description, assessment question, and rationale.

Anyone who submits a pull request, opens an issue, participates in a GitHub Discussion, proposes an RFC, or otherwise contributes to any WAF++ repository. Contributors do not need formal permissions — any GitHub user can contribute.

See also: Maintainer

WAF++ uses two licences: Apache License 2.0 for code, tooling, and schemas; Creative Commons Attribution 4.0 (CC BY 4.0) for documentation and written content. This allows broad reuse while ensuring attribution. See the Legal page for details.

The result of evaluating one control against one workload. A finding is either satisfied, not satisfied, or not applicable. Findings are the raw output of an assessment, which are then aggregated into a PASS score.

A quality standard for the WAF++ governance model, indicating that the project's structure, policies, and transparency meet the requirements for donation to an open-source foundation (e.g. CNCF, Apache Software Foundation). Foundation-readiness is a stated goal for the WAF++ v1.0 release.

The set of rules, processes, and roles that determine how decisions are made in the WAF++ project. WAF++ governance is documented publicly and covers: RFC process, TSC composition and voting, maintainer terms, working group rules, and code of conduct enforcement.

See also: TSC, RFC, Governance & Community page

The practice of managing and provisioning cloud infrastructure through machine-readable configuration files rather than manual processes. Relevant to multiple WAF++ pillars, particularly Operational Excellence and Security.

A lightweight decision-making mechanism used for non-breaking or lower-risk changes. A proposal is posted publicly with a minimum 5-business-day review window. If no substantiated objection is raised, the proposal is considered accepted. For major changes, TSC voting is used instead.

See also: TSC, RFC

A contributor with merge permissions on one or more WAF++ repositories. Maintainers review PRs, approve or reject RFCs, and are responsible for the quality and direction of their area. Maintainer terms are 12 months, renewable. Inactivity for 90+ days may result in emeritus status.

See also: Roles & Members page

The WAF++ scoring model. PASS stands for the four achievement tiers: Pioneer, Advanced, Solid, Starter. Each tier corresponds to a level of control satisfaction within a pillar. The PASS model is the normative scoring specification — see PASS page for details.

See also: PASS score, Scoring tier

The result of applying the PASS model to an assessment. A workload receives a score per pillar and an aggregated overall score. Scores are expressed as tiers (Pioneer / Advanced / Solid / Starter), not percentages, to reflect qualitative maturity rather than raw pass rates.

See also: PASS model

One of the seven assessment dimensions of WAF++. Each pillar groups a set of controls that address a specific quality concern for cloud workloads. The seven pillars are: Security, Reliability, Performance Efficiency, Cost Optimisation, Operational Excellence, Sustainability, and Developer Experience (Sovereign is the 7th pillar added in v1.0-beta).

See also: Control, The 7 pillars

The PASS tier achieved for a single pillar, derived from the control satisfaction rate and any mandatory controls within that pillar. Pillar scores are aggregated into the overall PASS score.

A public proposal for a significant change to the WAF++ framework, governance, tooling, or scoring model. RFCs are opened as GitHub Discussions, reviewed by the community for a minimum of 5 business days, then decided by TSC vote or lazy consensus. Every RFC receives a sequential ID (RFC-NNNN) and is tracked on the RFC Tracker.

See also: RFC lifecycle, Lazy consensus

The defined states an RFC passes through: draft (being written) → open (open for community review) → accepted (decision made: proceed) → implemented (shipped and closed). Alternative outcomes: rejected or withdrawn. All states and transitions are documented publicly.

One of the four levels in the PASS model. In descending order: Pioneer (highest), Advanced, Solid, Starter (baseline). Tiers reflect the breadth and depth of control satisfaction, not just the number of controls passed.

See also: PASS model

The 7th pillar of WAF++, covering data sovereignty, regulatory compliance, and jurisdictional control. Added in the v1.0 beta phase with 10 initial controls (WAF-SOV-010 through WAF-SOV-100). Particularly relevant for regulated industries and EU-based workloads.

The governing body of the WAF++ project. The TSC is responsible for technical direction, RFC decisions, and maintainer appointments. Members serve 12-month renewable terms. TSC composition follows the principle of "active contributors first" and vendor-neutral balance. All TSC decisions are publicly documented.

See also: Governance & Community, Roles & Members

A core design principle of WAF++: the framework's pillars, controls, and scoring model apply equally to workloads on any cloud provider (AWS, Azure, GCP, and others). No control is provider-specific unless explicitly labelled. This enables consistent cross-provider assessments and prevents lock-in to any single vendor's review methodology.

Well-Architected Framework Plus Plus. An open-source, vendor-neutral framework for assessing and improving the quality of cloud workloads. WAF++ extends conventional well-architected reviews with a transparent, community-driven scoring model (PASS) and a machine-readable controls library across 7 pillars.

A topic-focused contributor team within WAF++. Working Groups build specific parts of the framework — a pillar, a tooling component, a reference architecture — and produce outputs as PRs and RFCs. Any contributor can propose a WG with a charter, a lead, and a maintainer sponsor.

See also: Charter, Contributing

The cloud application, service, or system being assessed with WAF++. A workload has a defined scope (e.g. a microservice, a data platform, an entire product) and is assessed against the applicable WAF++ controls. Scope is defined before an assessment begins.

See also: Assessment