Glossary.

Relating to autonomous AI agents that plan, act, and interact with systems without direct human instruction. In Wombat, the Agentic pillar (Pillar 8) defines controls for governing these agents in production workloads.

See also: Pillar, The 8 pillars

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

See also: AsciiDoc

The markup language used to write Wombat 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 Wombat 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 Wombat framework — a workload either satisfies a control or it doesn't.

See also: Control ID, Pillar, Controls library

The unique identifier for a Wombat 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, AGN for Agentic). Control IDs are stable — once published, they never change or get reused.

The full collection of Wombat controls, stored as structured YAML files in the framework repository under modules/controls/. The library now spans 8 pillars with 100+ controls.

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

See also: Maintainer

Wombat 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 Wombat 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 Wombat v1.x releases.

The set of rules, processes, and roles that determine how decisions are made in the Wombat project. Wombat 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 Wombat 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 Wombat 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 Wombat 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 WOMBATpass 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 eight assessment dimensions of Wombat. Each pillar groups a set of controls that address a specific quality concern for cloud workloads. The eight pillars are: Security, Reliability, Performance Efficiency, Cost Optimisation, Operational Excellence, Sustainability, Sovereign, and Agentic.

See also: Control, The 8 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 Wombat 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 Wombat, covering data sovereignty, regulatory compliance, and jurisdictional control. Added 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 Wombat 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 Wombat: 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.

Cloud Governance & IaC Validation. An open-source, vendor-neutral framework for assessing and improving the quality of cloud workloads. Wombat extends conventional well-architected reviews with a transparent, community-driven scoring model (PASS) and a machine-readable controls library across 8 pillars and 100+ controls.

The official Wombat assessment tooling suite: CLI, server, dashboard, and web scorecard. WOMBATpass consumes the controls library, evaluates a workload, and produces a PASS score report. Current release: v1.1.0.

A topic-focused contributor team within Wombat. 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 Wombat. A workload has a defined scope (e.g. a microservice, a data platform, an entire product) and is assessed against the applicable Wombat controls. Scope is defined before an assessment begins.

See also: Assessment