EPP minor changes 28th May 2026

[krzysztofstaszalek]

No description provided.

[github-actions]

Auto-Fix Summary

8 issues fixed, 10 skipped across 6 files

Category	Fixes
Removed filler	3
Dale: passive-voice	2
Dale: positional-references	3

Skipped (needs manual review)	Reason

| docs/endpointprotector/admin/cap_module/capai.md:11 — Dale: wordiness | 'a leader in Data Loss Prevention (DLP) technology' is marketing language but not a clear Dale rule violation; rewording would change emphasis |
| docs/endpointprotector/admin/cap_module/capai.md:22 — Dale: wordiness | Sentence is wordy but rewording could alter the author's intended emphasis on compliance |
| docs/endpointprotector/admin/cap_module/capai.md:73 — Dale: wordiness | Marketing-style summary in a video description; rewriting could alter the descriptive intent |
| docs/endpointprotector/gettingstarted.md:9 — Dale: wordiness | 'Welcome to Netwrix Endpoint Protector, your solution for...' is marketing language but rewriting would significantly change tone and meaning |
| docs/endpointprotector/gettingstarted.md:113 — Dale: undefined-acronyms | MDM (Mobile Device Management) is borderline well-known in IT admin contexts; ambiguous whether to define |
| docs/endpointprotector/index.md:19 — Dale: passive-voice | 'sensitive data remains protected' describes a state outcome, not an action — recasting would change meaning |
| docs/endpointprotector/requirements/client.md:11 — Dale: passive-voice | 'processing power consumed' and 'bandwidth used by the Client' are reduced relative clauses; rewriting would significantly restructure the sentence |
| docs/endpointprotector/requirements/client.md:36 — Dale: passive-voice | 'is designed to be lightweight' describes inherent characteristic; active rewrite would alter meaning |
| docs/endpointprotector/requirements/client.md:42 — Dale: passive-voice | 'as it is written' is concise and clear; active alternative would be more awkward |
| docs/endpointprotector/admin/support.md:13 — Dale: passive-voice | No clear passive voice violation; first-person 'We' and 'our' are not covered by Dale rules |

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

[github-actions]

Auto-Fix Summary

0 issues fixed, 0 skipped across 6 files

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

[github-actions]

Documentation PR Review

Editorial Review

docs/endpointprotector/admin/cap_module/capai.md

• Clarity — Line 11: "a set of features that extends Data Loss Prevention to Large Language Models (LLMs)" reads awkwardly because "extends" agrees with the singular "set" rather than the more natural antecedent "features." Suggested fix: "Starting with EPP Client release 2511, Netwrix introduced features that extend Data Loss Prevention to Large Language Models (LLMs)."
• Structure — Line 26: Missing Oxford comma before "and Cursor" in the list of AI technologies. The Netwrix style guide requires Oxford commas in all lists. Suggested fix: "...Claude, Meta AI, Perplexity, and Cursor..."

docs/endpointprotector/admin/support.md

• Clarity — Line 13: "We also recommend tracking..." uses first person ("we"), which is prohibited in Netwrix documentation content. Suggested fix: "Netwrix also recommends tracking the Netwrix Community Portal, which is dedicated to Endpoint Protector."
• Clarity — Line 13: "a section dedicated to Endpoint Protector" is ambiguous — it's unclear whether "section" refers to the linked page or to a part of the Community Portal. Suggested fix: rephrase as "the Endpoint Protector area of the Netwrix Community Portal" or use the rewording above.

docs/endpointprotector/gettingstarted.md

• Clarity — Line 21: "CPU x86 64 bit or ARM64 bit" mixes formatting conventions and reads awkwardly. "ARM64" is already an architecture name, so appending "bit" is redundant. Suggested fix: "CPU: x86-64 or ARM64 architecture," (also adds the missing colon used in the other bullets and aligns with industry-standard naming).

docs/endpointprotector/index.md

• No issues found.

docs/endpointprotector/requirements/client.md

• Clarity — Line 14: "1 GHz dual-core x86 64bit or ARM64bit architecture CPU." contains a double space between "64bit" and "or", inconsistent formatting ("64bit" vs. "ARM64bit"), and a trailing period that breaks bullet-list consistency with the items below. Suggested fix: "CPU: At least 1 GHz dual-core x86-64 or ARM64 architecture CPU"
• Consistency — Line 55: "Before escalating any Endpoint Client performance issue..." drops the product name "Protector." Elsewhere in this file the product is consistently referred to as "Endpoint Protector Client." Suggested fix: "Before escalating any Endpoint Protector Client performance issue..."

docs/endpointprotector/requirements/server.md

• Completeness — Line 10: "For migration plans or environments with regular data exports or API calls, Netwrix recommends increasing EPP Server sizing." leaves the reader with an unanswered question — by how much should sizing be increased, and what criteria determine the increase? Suggested fix: either provide concrete guidance (e.g., "...Netwrix recommends adding one tier above the size indicated in the table below.") or point to a resource that does (e.g., "...contact Netwrix Support for sizing recommendations.").
• Clarity — Line 10: "migration plans" is ambiguous — it could mean planning a server migration, migrating data into EPP, or migrating from a prior DLP product. Suggested fix: specify which migration scenario this applies to, e.g., "For server migrations, environments with regular data exports, or environments with frequent API calls..."

Summary

8 editorial suggestions across 5 files (1 file clean). 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]

Code Review

Scope: changes to docs/endpointprotector/ — one new _category_.json, the rest are markdown content edits (skipped per review scope). No changes to products.js, docusaurus.config.js, sidebars, scripts, or workflows.

Issue: directory name API Logs contains a space

docs/endpointprotector/admin/API Logs/ is the only directory in the entire docs/ tree with a space in its name (verified via find docs -type d -name "* *"). Every sibling folder follows a lowercase no-space convention (cap_module, dc_module, ed_module, ee_module, systemconfiguration, singlesignon, denylistsallowlists, etc.).

Concerns:

• Docusaurus will slugify the segment in the generated URL, so the public path will not visibly contain a space — but the source-folder name still ends up in things like editUrl links to GitHub, where the space becomes %20. That is fragile and inconsistent with how every other category in this product is structured.
• Any tooling, scripts, or future automation that globs or iterates paths must remember to quote — easy footgun.

Recommend renaming the directory to apilogs or api_logs to match the existing convention. The _category_.json label field ("Logs REST API") already controls the human-readable sidebar text, so the folder name is purely an internal identifier.

Minor: missing trailing newline

docs/endpointprotector/admin/API Logs/_category_.json has no trailing newline (the diff shows "No newline at end of file"). All other _category_.json files in the repo end with a newline. Not a build issue, just a consistency nit.

Verified OK

• link.id: "logrestapi" in the new _category_.json resolves — logrestapi.md exists in the same folder and the bare-filename id pattern matches the existing cap_module/_category_.json (id: "capmodule").
• position: 190 slots cleanly after support.md (180); no collisions.
• No security, secret, or workflow concerns. No changes to the KB pipeline, central config, or sidebars.