General writing
AuraScore 81/100

Public Policy Document Plain-Language and Accessibility Review

Audit complex municipal or agency policy drafts for cognitive accessibility, legal clarity, and public usability.

Use this template when municipal agencies, government task forces, or civic entities must release technical policy briefs, rulemaking documents, or public notices. It provides an in-depth linguistic deconstruction to ensure broad public comprehension without sacrificing statutory precision.

Template

Role: Principal Civic Communications Analyst specializing in public sector readability, legal accessibility, and plain-language governance.

Context

  • Sponsoring public agency: {{jurisdiction_entity}}
  • Policy or regulatory topic: {{policy_topic}}
  • Working policy draft: {{draft_policy_brief}}
  • Primary public audience: {{target_readership_profile}}
  • Statutory and legal constraints: {{statutory_constraints}}
  • Community feedback themes: {{public_consultation_feedback}}

Task

Execute a comprehensive linguistic, accessibility, and rhetorical clarity audit of {{draft_policy_brief}}, isolating bureaucratic obscurity and providing concrete plain-language structural alternatives that satisfy {{statutory_constraints}}.

Method

  1. Parse {{draft_policy_brief}} against standard Federal Plain Language Guidelines and public cognitive load benchmarks.
  2. Cross-examine technical civic terminology against the literacy and background characteristics of {{target_readership_profile}}.
  3. Identify passive voice constructions, nominalizations, nested clauses, and bureaucratic jargon that obscure agency accountability.
  4. Reconcile mandatory legal definitions from {{statutory_constraints}} with plain-language civilian interpretations.
  5. Evaluate whether concerns raised in {{public_consultation_feedback}} are addressed transparently or masked behind administrative euphemisms.
  6. Compute approximate reading grade level metrics and sentence density profiles across each functional section.
  7. Generate alternative plain-language phrasing for complex regulatory clauses while preserving legal enforceability.
  8. Formulate information architecture suggestions (e.g., visual callouts, structural subheadings) to optimize document navigation.

Constraints

  • Every identified instance of bureaucratic jargon MUST include an accessible plain-language translation.
  • Proposed revisions MUST NOT compromise the legal integrity mandated by {{statutory_constraints}}.
  • Technical terms required by statute must be retained but accompanied by an explicit inline gloss or definition.
  • The analysis MUST NOT use generic accessibility advice; recommendations must quote directly from {{draft_policy_brief}}.

Output format

1. Document Readability & Cognitive Load Profile

  • Quantitative score summary (Reading Grade Level, Average Sentence Length, Passive Voice %)
  • Public accessibility risk level (Low/Moderate/Critical) with justification

2. Lexical & Syntactic Friction Analysis

  • Friction Table: [Original Bureaucratic Passage | Linguistic Barrier | Statutory Requirement | Plain-Language Replacement]

3. Public Consultation Responsiveness Audit

  • Assessment of how draft addresses {{public_consultation_feedback}}
  • Identification of lingering transparency blind spots

4. Structural Restructuring Blueprint

  • Revised section hierarchy and suggested informational callout boxes
  • 3-5 core principles for public-facing implementation by {{jurisdiction_entity}}

Self-review

  • Did I preserve all legally indispensable statutory language from {{statutory_constraints}}?
  • Are readability improvements tailored specifically to {{target_readership_profile}} rather than an abstract audience?
  • Does the report address every major theme present in {{public_consultation_feedback}}?
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

writing-content
writing-general
public-sector-nonprofit
plain language
public policy
civic communications