Improve Readability

Wordy phrases to simplify:

• "in order to" → "to"
• "it is recommended" → "we recommend"
• "is able to" / "are able to" → "can"
• "make sure that" → "ensure" or "verify"
• "a number of" → "several" or "many"
• "in the event that" → "if"
• "provides the ability to" → "lets you" or "can"
• "in accordance with" → "per" or "following"
• "on a regular basis" → "regularly"
• "at the present time" → "now"
• "for the purpose of" → "to" or "for"
• "with regard to" → "about"

Do NOT simplify product names, service names, or technical terms (e.g., keep "Azure Policy", "Log Analytics workspace", "RBAC").

2. Shorten sentences (>25 words)

Split AGGRESSIVELY at conjunctions, semicolons, or after prepositional phrases. Target ≤20 words per sentence. Two short sentences ALWAYS beat one long one.

• BAD: "The service enables resources to communicate with each other, the internet, and on-premises networks through features such as network security groups and service endpoints that provide isolation."
• GOOD: "The service lets resources connect with each other, the internet, and on-premises networks. Features like network security groups and service endpoints provide isolation."

3. Break up dense paragraphs (>4 sentences)

Split at the strongest logical break. Add a blank line between the two resulting paragraphs.

4. Unnest clauses

Convert 2+ nested dependent clauses into separate sentences:

• BAD: "Users assigned with roles like contributor that are able to execute operations like deploying extensions which basically has root access should be used with caution."
• GOOD: "Roles like contributor can deploy extensions. These tasks grant root access, so use these roles with caution."

5. Remove filler and padding

Cut words that add no meaning — be aggressive about this:

• "it is important to note that" → cut entirely
• "basically" → cut
• "essentially" → cut
• "actually" → cut
• "simply" → cut
• "In this section, we will discuss" → cut
• "as well as" → "and"
• "in addition to" → "besides" or "and"

6. Convert passive to active (when the actor is known)

• BAD: "Extensions can be installed by the admin."
• GOOD: "The admin can install extensions."
• Do NOT change passive voice when the actor is unknown or deliberately omitted.

What to ignore

• Code blocks, inline code, YAML frontmatter
• URLs, file paths, link syntax
• Product names and service names (Azure Policy, Key Vault, etc.)
• Table content
• Headings (do not rewrite headings)
• Content that is already ≤15 words per sentence and uses simple vocabulary

Rules

• Preserve ALL technical meaning. Never remove information.
• Do NOT change the document structure (heading order, list structure).
• Do NOT add new content, examples, or links.
• Do NOT merge headings with body text.
• Apply as many fixes as needed — NO artificial cap. Fix EVERYTHING you can.
• Each replacement must be self-contained and correct.
• When in doubt, MAKE THE CHANGE. Err on the side of simplification.
• Combine multiple improvements into a single replacement when they affect the same sentence (vocabulary + splitting + filler removal).