Update AA 2601 installer docs for the --size string change

[mckibbenc]

Summary

• access-analyzer PR fix(script): silence git rm --cached stdout to prevent JSON corruption #735 replaces the numeric --size 1-10 scale with named deployment sizes (small/medium/large/enterprise, default medium); numeric values are now rejected.
• Updates the flag reference, config file example, and sizing tables in the AA 2601 installer docs to match the new CPU/RAM/disk profiles.
• Corrects the preflight disk-math footnote that described the old per-unit scan-queue formula (disk floor is now a fixed 40 GB, with per-size figures as warn-only recommendations).
• Notes that --size micro exists but is for development/CI/demo installs only, not production.

Test plan

• Vale/Dale pass on the four changed files (CI auto-fix workflow will run on the PR)
• Spot-check rendered pages for install-commands.md, quickinstall.md, prerequisites.md, and system/requirements.md

Generated with AI

Co-Authored-By: Claude Code ai@netwrix.com

[github-actions]

Documentation PR Review

Editorial Review

docs/accessanalyzer/2601/install/system/requirements.md

• Clarity — Line 13: The new intro packs three separate rules into one sentence (how to choose a size, that CPU/memory are hard minimums, and that disk behaves differently). A reader scanning for "will this block my install?" has to parse the whole paragraph. Suggested fix: split into three short sentences or a short paragraph plus a bulleted contrast — "Choose a deployment size with --size — see Installer Command Reference. The installer enforces each size's CPU and memory figures as hard preflight minimums and blocks installation if the system falls below them. Disk is different: a fixed 40 GB floor blocks installation regardless of size, and the size's disk figure only produces a warning if the host falls short."
• Completeness — Line 13: This line tells the reader that CPU and memory are enforced per size, but the Preflight Check Requirements table on the linked page still lists single fixed thresholds (RAM fail below 24 GB, CPU fail below 6 cores, disk fail below 20 GB on /var). A reader who follows the link gets a contradictory answer about what preflight actually enforces. Suggested fix: update that preflight table to state the thresholds are per-size (or add a sentence pointing to the Deployment Sizing table as the source of the CPU and memory values), so both pages agree.
• Clarity — Line 15: The new Scale column header is vague — it doesn't say scale of what, and the previous header ("Data Threshold") at least named the dimension. Suggested fix: rename the column to "Environment Size" or "Supported Scale".
• Clarity — Lines 17–20: "Up to ~25 million objects and under 5,000 identities" mixes three ways of expressing a bound across the four rows ("Up to ~", "under", and a range like "5,000–25,000"), and "Up to" reads oddly when applied to a range ("Up to ~200 million objects and 5,000–25,000 identities"). The tilde also isn't used elsewhere in this doc set. Suggested fix: split into two columns — "Objects" and "Identities" — and spell out the approximation: "Objects: up to approximately 200 million / Identities: 5,000–25,000".
• Completeness — Line 23: The micro warning gives figures (8 cores, 24 GB, 80 GB SSD) but never says how a reader would select it or why it's documented at all if it shouldn't be used. Suggested fix: add one sentence tying it to the flag and the audience — "Select it with --size micro. It exists for development, CI, and demo installs, and Netwrix doesn't support it for production."
• Clarity — Line 35: The cell reads "40 GB minimum; see table above for the recommended amount **", but the column it sits in is headed Minimum Free Space — putting a recommendation inside a minimum column makes both numbers harder to trust. "See table above" is also a positional reference that breaks if the page is reordered. Suggested fix: keep the cell to the enforced value ("40 GB") and move the recommendation into the footnote, referencing the section by link: "see Deployment Sizing".
• Clarity — Line 39: [idiom] "40 GB free on /var/lib is the hard floor for every size" uses "hard floor" as a metaphor for an enforced minimum. Suggested fix: "The installer requires at least 40 GB free on /var/lib for every size and fails preflight below that."
• Clarity — Line 39: This footnote is a single 60-word sentence carrying an em-dash clause, a semicolon clause, and a causal clause, and it introduces "thin-provisions" without defining it. Suggested fix: break into two sentences and define the term in passing — "The recommended amount in the Deployment Sizing table is what your chosen --size is designed to hold as data accumulates. A host below it passes preflight with a warning rather than failing, because k3s allocates storage on demand (thin provisioning) and consumes it only as data arrives."
• Consistency — Line 39: This line writes "k3s" in lowercase, while the table directly above it (line 34) writes "K3s". Suggested fix: use "K3s" to match the surrounding table.

docs/accessanalyzer/2601/install/install-commands.md

• Clarity — Line 179: "sets the CPU, memory, and disk allocations for all Access Analyzer workloads and the host minimums preflight enforces" runs two different things — workload allocations and host preflight minimums — through one verb, and the trailing relative clause ("the host minimums preflight enforces") is hard to parse without a comma or "that". It also states that disk is part of what preflight enforces, which contradicts Hardware and System Requirements, where the disk figure only warns. Suggested fix: "The --size option selects a deployment size profile. The profile sets the CPU, memory, and disk allocations for all Access Analyzer workloads, and it sets the CPU and memory minimums that preflight enforces on the host."
• Structure — Lines 181–183: The micro warning is inserted between the paragraph that describes --size and the example command that demonstrates it, so the example no longer sits next to the concept it illustrates. The warning is also an exception case, which belongs after the main path. Suggested fix: move the :::warning block below the code block, next to the "See Hardware and System Requirements" line.
• Completeness — Line 192: The note says the installer "names the closest replacement size", but a reader upgrading from a numeric value most likely has it in ~/.dspm/installer.yaml or a SIZE environment variable, where the installer's message isn't the first thing they'll see. Suggested fix: add a pointer to both places — "Update any numeric value in your SIZE environment variable or ~/.dspm/installer.yaml before upgrading."
• Clarity — Line 192: "confirm that size's requirements against your server" compresses two actions into an ambiguous phrase, and it doesn't say where the requirements are (the link is in the preceding paragraph, outside the note). Suggested fix: "Before you use the replacement size, check its CPU, memory, and disk requirements in Hardware and System Requirements against your server."

docs/accessanalyzer/2601/install/prerequisites.md

• Completeness — Line 29: Marking Medium as (default) tells the reader that a size gets selected during installation, but this page never says how to select a different one. The reader picks Large from this table and then has nothing to act on. Suggested fix: add a sentence under the table — "Set the size with the installer's --size option — see Installer Command Reference."
• Consistency — Lines 28–31: This table's column is headed Minimum Disk Space and line 24 introduces the values as "absolute minimums", but the same disk figures are described as recommendations that only produce a warning in Hardware and System Requirements. A reader who sees both pages can't tell whether 400 GB will block a Small install. Suggested fix: rename the column to "Recommended Disk" and adjust line 24 to say the CPU and memory values are enforced minimums while disk is a recommendation.

docs/accessanalyzer/2601/install/quickinstall.md

• Completeness — Line 30: Same gap as in prerequisites.md — the new (default) marker implies the reader can choose a size, but Step 4 (line 230) runs sudo dspm-installer with no options and the page never mentions --size. A reader who selected Large here has no way to act on that choice. Suggested fix: add a sentence under the table pointing to --size and the Installer Command Reference, or note in Step 4 that the installer prompts for the size.
• Consistency — Lines 29–32: The Minimum Disk Space heading conflicts with Hardware and System Requirements, where the same figures are recommendations that only warn. Suggested fix: rename the column to "Recommended Disk" to match.

Summary

15 editorial suggestions across 4 files. The recurring theme is the disk figures: this PR makes them enforced minimums on two pages and warn-only recommendations on a third, and the CPU/memory story on requirements.md line 13 doesn't match the unchanged preflight table on install-commands.md. Vale and Dale issues are auto-fixed separately.

---

What to do next:

Comment @claude on this PR followed by your instructions to get help:

• @claude fix all issues — fix all editorial issues
• @claude help improve the flow of this document — get writing assistance
• @claude explain the voice issues — understand why something was flagged

You can ask Claude anything about the review or about Netwrix writing standards.

Automated fixes are only available for branches in this repository, not forks.

[github-actions]

Auto-Fix Summary

3 issues fixed, 7 skipped across 4 files

Category	Fixes
Dale: passive-voice	2
Dale: positional-references	1

Skipped (needs manual review)	Reason

| docs/accessanalyzer/2601/install/system/requirements.md:39 — Dale: passive-voice | "what your chosen --size is designed to hold" — every active rewrite tested ("needs", "requires", "covers") shifts the sentence from a design target to a hard requirement, which contradicts the following clause stating that a host below it only warns rather than fails. |
| docs/accessanalyzer/2601/install/install-commands.md:182 — Dale: passive-voice | "this profile is sized for development, CI, and demo installs only" sits inside the HIDDEN HTML comment block (lines 130-205). Commented-out content isn't published; left as parked by the author. |
| docs/accessanalyzer/2601/install/install-commands.md:192 — Dale: passive-voice | "Numeric values are no longer accepted" sits inside the HIDDEN HTML comment block (lines 130-205). Commented-out content isn't published. |
| docs/accessanalyzer/2601/install/quickinstall.md:335 — Dale: passive-voice | "The Entra ID installer is invoked using CLI flags" and "The flags are passed directly to the install command" sit inside the HIDDEN HTML comment block (lines 307-393, marked post-GA). Commented-out content isn't published. |
| docs/accessanalyzer/2601/install/quickinstall.md:256 — Dale: positional-references | "Log in at the URL above" is inside a fenced code block reproducing the installer's own output — editing it would misrepresent what the installer prints. |
| docs/accessanalyzer/2601/install/prerequisites.md:17 — Dale: passive-voice | "TLS certificate option chosen; certificate files prepared" is a checklist fragment. The completed-state form is the convention for task checklists, and the same pattern is used in quickinstall.md line 19. |
| docs/accessanalyzer/2601/install/system/requirements.md:23 — Dale: undefined-acronyms | "CI" is a general industry term rather than a product-specific acronym, and the rule excludes well-known terms a sysadmin audience would recognize. |

Ask @claude on this PR if you'd like an explanation of any fix.