# Content Audit: [Documentation set or site name]

> Quality audit and content inventory for a documentation set: scope
> and objectives, method and criteria, one inventory row per page (URL,
> Diátaxis type, owner, last verified date, usage and feedback signals,
> accuracy rating, ROT verdict and action), the verdict rules, a findings
> summary with recomputed numbers, gaps, a remediation backlog, the
> redirect and archive plan, and governance for the next audit.
> Structure aligned with the management and quality-evaluation
> activities of ISO/IEC/IEEE 26511:2018 (requirements for managers of
> information for users) and the review concepts of ISO/IEC/IEEE
> 26513:2017; accessibility signals refer to WCAG 2.2 (W3C
> Recommendation, 12 December 2024). Replace every `[bracketed]` value
> and every row marked *Example*.

<!--
Guidance: How to use this template
- Run an audit when a docs set has grown without pruning, before a
  migration to a new docs platform, before an information architecture
  redesign, or once a year as routine.
- Fill sections 1 to 3 before you open the first page. Agree the
  verdict rules in section 6 with the docs owner first, so the verdicts
  are consistent across auditors.
- Build the inventory (section 5) from the source repository or site
  map, not from the navigation: orphan pages that no menu links to are
  often the worst offenders.
- Use only aggregate, privacy-respecting usage signals. No audit needs
  per-person tracking; see section 2.3.
- Recompute every number in section 7 from the inventory whenever a
  row changes. A summary that disagrees with its inventory destroys
  trust in the whole audit.
- Related documents: Documentation Plan (`docs/documentation-plan`),
  Information Architecture (`docs/information-architecture`), Docs
  Review Checklist (`docs/docs-review-checklist`), Docs Metrics Report
  (`docs/docs-metrics-report`), Technical Style Guide
  (`docs/style-guide-technical`), Accessibility Audit
  (`quality/accessibility-audit`).
-->

## Document control

<!-- Guidance: Identify the documentation set and the snapshot date. Pages change during an audit; the snapshot date tells readers which state was assessed. -->

| Field | Value |
|---|---|
| Document ID | [CAU-001] |
| Documentation set | [Product name] [Docs site, section or repository] |
| Snapshot date (inventory taken) | YYYY-MM-DD |
| Pages in scope | [Number] |
| Product version documented | [Version or versions] |
| Audit lead | [@audit-lead] |
| Version | [0.1] |
| Status | [Planned / In progress / Findings issued / Remediation in progress / Closed] |
| Owner | [@docs-owner] |
| Approvers/reviewers | [@docs-lead], [@product-owner], [@support-lead] |
| Classification | [Internal] |
| Last updated | YYYY-MM-DD |
| Next audit due | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Docs owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Product owner | [@name] | [Decision] | YYYY-MM-DD |
| Support lead | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Scope and method agreed |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Inventory complete, 10 pages assessed |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Findings and remediation backlog approved |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Scope and objectives](#1-scope-and-objectives)
2. [Method and criteria](#2-method-and-criteria)
3. [Roles and schedule](#3-roles-and-schedule)
4. [Audit process](#4-audit-process)
5. [Content inventory](#5-content-inventory)
6. [Verdict and action rules](#6-verdict-and-action-rules)
7. [Findings summary](#7-findings-summary)
8. [Content gaps](#8-content-gaps)
9. [Remediation backlog](#9-remediation-backlog)
10. [Redirect and archive plan](#10-redirect-and-archive-plan)
11. [Governance and next audit](#11-governance-and-next-audit)
12. [Glossary and references](#12-glossary-and-references)

## 1. Scope and objectives

<!-- Guidance: Say what the audit must decide. An audit without a decision to inform turns into a spreadsheet nobody reads. Typical decisions: what to migrate, what to delete, where to invest writer time. -->

| Item | Value |
|---|---|
| Audit trigger | [Platform migration / IA redesign / Annual review / Support escalation trend] |
| Decisions this audit informs | [For example: which pages move to the new platform; writer priorities for next two quarters] |
| In scope | [Sections, versions, languages] |
| Out of scope | [For example: translated pages (audited separately), marketing pages, API reference generated from the description] |
| Audit type | [Full inventory / Sample of [N] pages chosen by risk / Qualitative deep dive on one section] |
| Accuracy check depth | [Spot check by SME / Full task test of every procedure] |

*Example:* Corvid Commerce audits its developer documentation before
moving it to a docs-as-code platform. The audit decides which pages
migrate, which merge and which are archived. Scope: English pages under
`/docs/`; generated API reference and translated pages are out of
scope. The example inventory in section 5 shows 10 representative pages.

Objectives:

1. Produce a complete inventory with one accountable owner per page.
2. Rate each page for accuracy, freshness and usefulness against the
   criteria in section 2.
3. Give each page a ROT verdict and one action from the agreed set:
   keep, update, merge, archive or redirect.
4. Identify content gaps from support and search evidence.
5. Produce a prioritised, owned remediation backlog with dates.

## 2. Method and criteria

<!-- Guidance: Define every rating before rating. Auditors who invent their own scales produce verdicts that cannot be compared or summed. -->

### 2.1 Inventory fields

| Field | Definition | Source |
|---|---|---|
| Page ID | Stable audit ID, CA-NNN | Assigned in this audit |
| URL or path | Published URL or source path | Site map or repository |
| Type | Tutorial, How-to guide, Reference, Explanation, or another declared type (FAQ, release notes, landing page) | Page front matter or auditor judgement |
| Owner | Named person accountable for the page | CODEOWNERS file or docs owner assignment |
| Last verified | Date an SME last confirmed the content as accurate (not the last edit date) | Page metadata or review records |
| Usage signal | Aggregate monthly page views from privacy-respecting measurement | Docs metrics source (section 2.3) |
| Feedback signal | Share of "Was this page helpful?" answers that are positive, with the response count | Aggregate feedback counts |
| Accuracy | Rating from section 2.2 | SME spot check or task test |
| ROT verdict | None, Redundant, Outdated or Trivial | Section 2.2 |
| Action | Keep, Update, Merge, Archive or Redirect | Section 6 |

### 2.2 Ratings

| Rating | Values | Definition |
|---|---|---|
| Accuracy | Accurate | All checked claims and steps are true for the current version |
| Accuracy | Partly accurate | At least one claim or step is wrong but the page's core is correct |
| Accuracy | Outdated | Describes a previous version, a removed feature or a superseded process |
| Accuracy | Inaccurate | Core content is wrong and a reader following it would fail |
| ROT | Redundant | Another page covers the same need; keeping both splits maintenance and search results |
| ROT | Outdated | Content no longer matches the product, process or policy |
| ROT | Trivial | No reader need: internal notes, empty stubs, placeholders, event pages long past |
| ROT | None | Page is needed, unique and current enough to keep |
| Freshness | Fresh / Stale | Stale when the last verified date is older than the verify interval ([12] months) on the snapshot date |

### 2.3 Usage and feedback signals: privacy rules

- Use aggregate counts only: page views per page per month, positive and
  negative feedback counts, zero-result search terms, and support ticket
  tags. Never collect or store names, email addresses, IP addresses or
  device identifiers for an audit.
- Prefer cookieless, first-party measurement, or server log counts that
  are aggregated and stripped of identifiers before analysis.
- Respect consent choices and the Global Privacy Control (GPC) signal
  where your measurement depends on them.
- Treat low-traffic numbers with care: a reference page read by ten
  administrators a month can still be essential.
- Signals inform the verdict; they never decide it alone. A page with
  no traffic may be essential, and a page with high traffic may be
  harmful if inaccurate.

### 2.4 Accessibility signals

Record for each page whether automated checks found accessibility
issues mapped to WCAG 2.2 (for example missing alt text under 1.1.1
Non-text Content, or vague link text under 2.4.4 Link Purpose (In
Context)). The audit notes counts; fixes go through the Docs Review
Checklist (`docs/docs-review-checklist`).

## 3. Roles and schedule

<!-- Guidance: Content audits stall when nobody owns the inventory. Name a lead, give SMEs a fixed window, and time-box the whole audit. -->

| Role | Responsibility | Name |
|---|---|---|
| Audit lead | Builds the inventory, runs calibration, writes the findings | [@audit-lead] |
| Auditors | Rate pages against section 2 | [@auditor-1], [@auditor-2] |
| SMEs | Confirm accuracy for their product areas | [@sme-orders], [@sme-checkout] |
| Support lead | Supplies top ticket themes and deflection candidates | [@support-lead] |
| Docs owner | Approves verdicts, assigns remediation owners | [@docs-owner] |

| Milestone | Date |
|---|---|
| Scope and method approved | YYYY-MM-DD |
| Inventory snapshot taken | YYYY-MM-DD |
| Calibration session (all auditors rate the same 5 pages) | YYYY-MM-DD |
| Ratings complete | YYYY-MM-DD |
| Findings and backlog issued | YYYY-MM-DD |
| Remediation complete (target) | YYYY-MM-DD |

## 4. Audit process

<!-- Guidance: The calibration step matters. Two auditors rating the same page differently is normal at first; agree on the reasons, then continue. -->

```mermaid
flowchart TD
  A[Agree scope, criteria and verdict rules] --> B[Export page list from repository and site map]
  B --> C[Add aggregate usage and feedback signals]
  C --> D[Calibrate auditors on a shared sample]
  D --> E[Rate each page: type, owner, accuracy, freshness, ROT]
  E --> F[Apply verdict rules and choose an action]
  F --> G[Recompute findings summary]
  G --> H[Identify gaps from search and support evidence]
  H --> I[Prioritise remediation backlog]
  I --> J[Approve, assign owners, track to closure]
```

Steps in practice:

1. Export every published page from the source repository and compare
   with the generated site map to catch orphans and pages missing from
   the build.
2. Join the aggregate signals for a fixed period (for example the last
   [3] full months) so seasonal effects do not distort single pages.
3. For each page, open the rendered version, read it, check its type,
   and record the owner and last verified date from metadata.
4. Ask the SME to spot check claims on pages rated Partly accurate or
   worse, and on every page with high usage.
5. Apply section 6 to reach one action per page. Record the reason in
   one sentence.

## 5. Content inventory

<!-- Guidance: One row per page. Keep the verdict reason short and concrete. Rows below are illustrative for the fictional company Corvid Commerce; replace them with your own pages. -->

Snapshot date for the example rows: 2026-06-30 (the Q2 2026 audit that
the Docs Metrics Report (`docs/docs-metrics-report`) example builds on). Verify interval: 12
months, so a page is stale when last verified before 2025-06-30.

| Page ID | URL or path | Type | Owner | Last verified | Views per month | Helpful (responses) | Accuracy | ROT verdict | Action | Reason |
|---|---|---|---|---|---|---|---|---|---|---|
| CA-001 *(Example)* | /docs/quickstart | Tutorial | [@dev-rel] | 2026-05-12 | 4,210 | 82% (310) | Accurate | None | Keep | Primary entry point, current and well rated |
| CA-002 *(Example)* | /docs/how-to/receive-order-events | How-to guide | [@sme-orders] | 2026-06-20 | 1,960 | 88% (142) | Accurate | None | Keep | Reviewed this month with a task test |
| CA-003 *(Example)* | /docs/how-to/configure-webhooks-legacy | How-to guide | [@sme-orders] | 2024-11-03 | 610 | 41% (58) | Outdated | Redundant | Merge | Duplicates CA-002 with the old console path |
| CA-004 *(Example)* | /docs/reference/orders-api | Reference | [@sme-orders] | 2026-05-30 | 3,050 | 79% (96) | Accurate | None | Keep | Matches the current API description |
| CA-005 *(Example)* | /docs/reference/checkout-api-v1 | Reference | [@sme-checkout] | 2025-02-14 | 140 | 35% (17) | Outdated | Outdated | Archive | Checkout API v1 reached sunset; keep as archived version |
| CA-006 *(Example)* | /docs/explanation/webhooks-explained | Explanation | [@sme-orders] | 2025-06-01 | 720 | 52% (39) | Partly accurate | Outdated | Update | Retry model description predates the delivery service change |
| CA-007 *(Example)* | /docs/how-to/export-orders-csv | How-to guide | [@sme-orders] | 2025-04-22 | 880 | 52% (61) | Partly accurate | Outdated | Update | Step 3 refers to a renamed menu; export limit changed |
| CA-008 *(Example)* | /docs/release-notes-2023 | Release notes | Unassigned | 2023-12-18 | 35 | n/a (0) | Outdated | Trivial | Archive | No reader need; history kept in the changelog |
| CA-009 *(Example)* | /docs/faq | FAQ | [@support-lead] | 2025-01-10 | 1,150 | 47% (88) | Partly accurate | Redundant | Merge | Answers duplicate troubleshooting and how-to pages |
| CA-010 *(Example)* | /docs/getting-started | Tutorial | Unassigned | 2023-05-02 | 300 | 30% (22) | Inaccurate | Redundant | Redirect | Old duplicate of CA-001 with broken steps |
| [CA-NNN] | [Path] | [Type] | [@owner] | YYYY-MM-DD | [Number] | [Percent (count)] | [Rating] | [Verdict] | [Action] | [One sentence] |

Accessibility and quality signals per page (from automated checks on
the snapshot date):

| Page ID | Broken links | Lint errors | Accessibility issues (WCAG 2.2 criterion) |
|---|---|---|---|
| CA-003 *(Example)* | 2 | 5 | 3 images without alt text (1.1.1) |
| CA-007 *(Example)* | 0 | 1 | 1 vague link text (2.4.4) |
| CA-009 *(Example)* | 4 | 0 | Skipped heading levels (1.3.1) |
| CA-010 *(Example)* | 3 | 7 | 2 images without alt text (1.1.1) |
| [CA-NNN] | [Number] | [Number] | [Issues] |

## 6. Verdict and action rules

<!-- Guidance: Rules make verdicts repeatable. Apply them in order; the first matching rule decides. Record exceptions with the docs owner's approval. -->

```mermaid
flowchart TD
  S[Page] --> T{Trivial: no reader need?}
  T -->|yes| AR[Archive, or delete if never public]
  T -->|no| R{Redundant with a better page?}
  R -->|yes, has unique content| M[Merge into the better page, then redirect]
  R -->|yes, nothing unique| RD[Redirect to the better page]
  R -->|no| O{Outdated or inaccurate?}
  O -->|describes a retired version| AR2[Archive as versioned page]
  O -->|current feature, wrong details| U[Update]
  O -->|no| K[Keep]
```

| Action | Use when | What happens to the URL | Follow-up |
|---|---|---|---|
| Keep | Needed, unique, accurate | Unchanged | Confirm owner and next verify date |
| Update | Needed and unique, but partly accurate or stale | Unchanged | Remediation item with SME review |
| Merge | Overlaps a better page but holds some unique content | Permanent redirect to the target page | Move unique content first, then redirect |
| Archive | Describes a retired version or has historical value only | Moved to an archive section marked as not maintained, or removed with a redirect to the successor | Banner stating the archive status and the current alternative |
| Redirect | Duplicate with nothing unique worth keeping | Permanent redirect to the replacement | Update inbound links in the docs set |

Never delete a public URL without a redirect or an explicit "gone"
response: readers, search engines and support macros link to it.

## 7. Findings summary

<!-- Guidance: Every figure here must be recomputable from section 5. State the denominators. Recount after any inventory change and say so in the revision history. -->

Figures for the 10 example pages in section 5:

| Measure | Count | Share |
|---|---|---|
| Pages assessed | 10 | 100% |
| Action: Keep | 3 (CA-001, CA-002, CA-004) | 30% |
| Action: Update | 2 (CA-006, CA-007) | 20% |
| Action: Merge | 2 (CA-003, CA-009) | 20% |
| Action: Archive | 2 (CA-005, CA-008) | 20% |
| Action: Redirect | 1 (CA-010) | 10% |
| ROT verdict other than None | 7 | 70% |
| Accuracy: Accurate | 3 | 30% |
| Accuracy: Partly accurate | 3 | 30% |
| Accuracy: Outdated | 3 | 30% |
| Accuracy: Inaccurate | 1 | 10% |
| Stale (last verified before 2025-06-30) | 7 (CA-003, CA-005 to CA-010) | 70% |
| Pages without an owner | 2 (CA-008, CA-010) | 20% |
| Monthly views on Keep pages | 9,220 of 13,055 | 70.6% |

Key findings:

1. *Example:* Usage is concentrated: the three Keep pages carry 70.6% of
   monthly views, so remediation should protect those pages first and
   remove the noise around them.
2. *Example:* Freshness is the main weakness: 7 of 10 pages have not
   been verified in the last 12 months, and every stale page is rated
   below Accurate.
3. *Example:* Duplication confuses readers: three Redundant pages
   (CA-003, CA-009, CA-010) compete with better pages, and all three
   have helpful ratings under 50%.
4. *Example:* Two pages have no owner, which explains why they decayed.
5. *Example:* The FAQ mixes troubleshooting, how-to and reference
   content; splitting it follows the Diátaxis forms.

## 8. Content gaps

<!-- Guidance: Gaps come from evidence, not wish lists: zero-result searches, frequent support ticket themes without a matching page, and new features without docs. -->

| Gap ID | Evidence | Missing content | Proposed type | Priority |
|---|---|---|---|---|
| GAP-001 *(Example)* | 112 zero-result searches for "rotate secret" in the period (aggregate count) | How to rotate a webhook signing secret without downtime | How-to guide | High |
| GAP-002 *(Example)* | Support ticket tag "refund webhook" among the top 10 themes | Event payload reference for `order.refunded` | Reference | High |
| GAP-003 *(Example)* | New feature "partial captures" released without docs | Explanation of partial capture states | Explanation | Medium |
| [GAP-NNN] | [Evidence] | [Content] | [Type] | [High / Medium / Low] |

## 9. Remediation backlog

<!-- Guidance: One item per action other than Keep, plus one per gap. Priority combines reader impact (usage, support load) and risk (accuracy). Every item needs an owner and a date. -->

| Item ID | Page or gap | Action | Work description | Owner | Effort | Priority | Due | Status |
|---|---|---|---|---|---|---|---|---|
| REM-001 *(Example)* | CA-010 | Redirect | Redirect /docs/getting-started to /docs/quickstart; update 12 inbound links | [@docs-eng] | S | P1 | YYYY-MM-DD | Open |
| REM-002 *(Example)* | CA-003 | Merge | Move the legacy console note into CA-002, then redirect | [@sme-orders] | S | P1 | YYYY-MM-DD | Open |
| REM-003 *(Example)* | CA-009 | Merge | Move answers into troubleshooting and how-to pages; redirect the FAQ anchors | [@support-lead] | M | P1 | YYYY-MM-DD | Open |
| REM-004 *(Example)* | CA-007 | Update | Fix menu path and export limit; task test | [@sme-orders] | S | P2 | YYYY-MM-DD | Open |
| REM-005 *(Example)* | CA-006 | Update | Rewrite retry model section; SME review | [@sme-orders] | M | P2 | YYYY-MM-DD | Open |
| REM-006 *(Example)* | CA-005 | Archive | Move to archive with banner pointing to v2 reference | [@docs-eng] | S | P3 | YYYY-MM-DD | Open |
| REM-007 *(Example)* | CA-008 | Archive | Remove from navigation; history stays in the changelog | [@docs-eng] | S | P3 | YYYY-MM-DD | Open |
| REM-008 *(Example)* | GAP-001 | Create | Write the secret rotation how-to | [@author] | M | P1 | YYYY-MM-DD | Open |
| REM-009 *(Example)* | GAP-002 | Create | Add `order.refunded` to the event reference | [@sme-orders] | S | P1 | YYYY-MM-DD | Open |
| REM-010 *(Example)* | GAP-003 | Create | Write partial capture explanation | [@sme-checkout] | M | P2 | YYYY-MM-DD | Open |
| [REM-NNN] | [CA-NNN or GAP-NNN] | [Action] | [Work] | [@owner] | [S / M / L] | [P1 / P2 / P3] | YYYY-MM-DD | [Open / In progress / Done] |

The example backlog has 10 items: 7 from the inventory (every page
without a Keep action) and 3 from gaps; 5 are P1, 3 are P2 and 2 are P3.
Every updated or new page passes the Docs Review Checklist
(`docs/docs-review-checklist`) before it closes.

## 10. Redirect and archive plan

<!-- Guidance: Redirects are part of the content, not an afterthought. Keep this table in the repository so the build can generate redirect rules from it. -->

| Old URL | New URL | Type | Reason | Backlog item |
|---|---|---|---|---|
| /docs/getting-started *(Example)* | /docs/quickstart | Permanent (301 or 308) | Duplicate | REM-001 |
| /docs/how-to/configure-webhooks-legacy *(Example)* | /docs/how-to/receive-order-events | Permanent | Merged | REM-002 |
| /docs/faq *(Example)* | /docs/troubleshooting | Permanent | Merged; per-answer anchors map to their new troubleshooting or how-to pages, the bare URL goes to troubleshooting | REM-003 |
| /docs/reference/checkout-api-v1 *(Example)* | /docs/archive/checkout-api-v1 | Permanent | Archived version | REM-006 |
| [Old path] | [New path] | [Permanent / Gone] | [Reason] | [REM-NNN] |

Archive rules:

- Archived pages carry a banner that states they are not maintained and
  links to the current alternative.
- Archived pages are excluded from site search by default and marked so
  that search engines do not index them, unless a legal or contractual
  reason requires them to stay discoverable.
- Redirect rules follow the information architecture policy
  (`docs/information-architecture`).

## 11. Governance and next audit

<!-- Guidance: Prevent the next audit from finding the same problems. The best outcome of an audit is a set of rules that keep content from decaying. -->

| Control | Rule | Owner |
|---|---|---|
| Ownership | Every page has a named owner in metadata; the build fails without one | [@docs-eng] |
| Verify interval | Each page records last verified date; pages past [12] months appear in the monthly docs metrics report | [@docs-owner] |
| New content | New pages declare a Diátaxis type and pass the review checklist | [@docs-lead] |
| Duplicate prevention | Search existing pages before creating; reviewers check for overlap | [@editor] |
| Retirement | Product deprecations trigger an archive or update item for affected pages | [@product-owner] |
| Next audit | Full audit [annually]; light audit of top 20 pages by views [quarterly] | [@audit-lead] |

Progress on the remediation backlog and the freshness share is reported
in the Docs Metrics Report (`docs/docs-metrics-report`).

## 12. Glossary and references

<!-- Guidance: Define audit terms once so the inventory, summary and backlog use them the same way. -->

### 12.1 Glossary

| Term | Meaning in this audit |
|---|---|
| Content inventory | List of every page in scope with its attributes |
| ROT | Redundant, outdated or trivial content |
| Verdict | ROT classification for a page |
| Action | What happens to the page: keep, update, merge, archive or redirect |
| Last verified | Date an SME last confirmed accuracy, distinct from the last edit |
| Orphan page | Published page no navigation or other page links to |
| Calibration | Session where auditors rate the same pages and agree on criteria |

### 12.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| ISO/IEC/IEEE 26511:2018, Systems and software engineering: Requirements for managers of information for users of systems, software, and services | Edition 2, 2018; reviewed and confirmed 2024 | Management and quality evaluation activities, structure only |
| ISO/IEC/IEEE 26513:2017, Requirements for testers and reviewers of information for users | Edition 1, 2017; second edition at final draft stage when checked 2026-10-24 | Review concepts, structure only |
| W3C, Web Content Accessibility Guidelines (WCAG) 2.2, https://www.w3.org/TR/WCAG22/ | W3C Recommendation, 12 December 2024 | Accessibility signal mapping |
| Diátaxis, Daniele Procida, https://diataxis.fr/ | Checked 2026-10-24 | Content type classification |
| W3C, Global Privacy Control (GPC), https://www.w3.org/TR/gpc/ | W3C Working Draft, as published in September 2026 | Honouring the opt-out signal in measurement |
| [Internal docs metrics definitions] | [Version] | [Signals used] |

## Standard and licence note

Structure aligned with the management and quality-evaluation activities
of ISO/IEC/IEEE 26511:2018 and the review concepts of ISO/IEC/IEEE
26513:2017. Only standard names and general concepts are referenced; no
ISO text, table, definition or clause wording is reproduced.
Accessibility signals cite WCAG 2.2 success criteria by number and
short name only. Content types follow the four forms of the Diátaxis
framework by Daniele Procida (https://diataxis.fr), licensed under CC
BY-SA 4.0; this template uses the type names for classification and
does not adapt Diátaxis text. The ROT method is common industry practice
described here in original words. All example data refers to a
fictional company. This template is original text written for this
collection. Check the current official versions of every cited standard
before use. Template licence: MIT.