Writing UW–Madison Policies So AI Can Understand Them

Why this matters

When a person reads a policy, they see the whole document (title, scope, definitions, and the body) all at once. An AI assistant doesn’t work that way.

AI systems built on retrieval-augmented generation (RAG), including agents built on Google’s Gemini Enterprise Agent Platform, break each policy into small chunks of a few hundred words, store those chunks in a search index, and pull back only the two to six chunks most relevant to a user’s question when generating an answer. The model never sees the rest of the document.

That changes what “well-written” means. A sentence that reads beautifully in context can be useless when retrieved alone. The phrase “as described above” points to nothing the AI can see. A pronoun like “it” has no antecedent. A definition three pages away might as well not exist.

The good news: writing for AI doesn’t conflict with the UW–Madison Policy Library style guide. It reinforces it. Plain language, clear definitions, enforceable statements, and consistent structure (the things UW–Madison already asks for) are also exactly what makes a policy machine-readable. This guide layers a few additional habits on top.

The mental model: write for the orphaned paragraph

Before drafting or revising, picture this: a user asks the AI, “Can a department chair issue a public statement on a current event?” The system pulls one paragraph (just one) out of the policy. That paragraph appears alone on the model’s desk. No title above it. No definitions below it. No surrounding sections.

If the answer is no, the paragraph needs more context built in.

Six core principles

1. Make each section self-contained

A reader-facing paragraph can use shorthand because the reader has the full page. A chunk-facing paragraph cannot. Each section, and ideally each paragraph, should be intelligible without its neighbors.

2. Be explicit over implicit

Human readers tolerate (and even enjoy) inference. AI retrieval does not. State the subject, the actor, the condition, and the consequence directly.

3. Use real, semantic structure

Headings, lists, and tables aren’t decoration. They are signals that tell the AI ingestion pipeline how to chunk and label the content. Use the heading levels in the policy template (Heading 1 for the policy title, Heading 2 for major sections like Definitions, Scope, Policy) rather than bolded text that looks like a heading. Use numbered lists for sequenced steps; use bulleted lists for parallel items where order does not matter.

4. Write one idea per sentence

Long sentences with nested clauses scatter the meaning across a chunk boundary and confuse both retrieval and generation. Break compound conditions into separate sentences or a list.

5. Repeat nouns instead of using pronouns

“It,” “they,” “this,” and “the above” all break when a chunk is pulled out of context. Repeat the noun. Yes, it feels redundant. The AI needs it.

6. Define every term once, in one place, the same way every time

The Definitions section is the single most important part of an AI-readable policy. Defined terms become anchors the AI can match user questions against. Inconsistent terminology (“department chair” in one section, “unit head” in another, “supervisor” in a third) tells the AI these are three different roles even when you mean one.

Section-by-section guidance

This section walks the standard UW–Madison policy template field by field and shows what AI-readiness looks like in each.

Title

The title is one of the strongest retrieval signals. The AI uses it to decide whether the whole policy is relevant to a user’s question.

• Name the topic in plain words a user would actually type or speak. “Smoke-Free Policy” beats “Environmental Air Quality Standards Affecting Indoor Spaces.”
• Avoid acronyms. The AI may not connect “ASPP” to “Academic Staff Policies & Procedures” unless it sees both spelled out somewhere in the document.
• If the policy applies only to a constituency, say so in the title (“University Housing Smoking Policy”).

Rationale / Purpose

Write this as a standalone summary of what the policy does and why it exists. The AI frequently retrieves this field when a user asks “what is this policy about” or “why does UW–Madison require X.”

• Open with a one-sentence statement of what the policy mandates, permits, or prohibits.
• Follow with one to three sentences on why it exists (statute, regulation, mission, risk).
• Do not bury the actual rule here. Keep conditions, exceptions, and procedures in the Policy section, as the UW–Madison style guide already requires.

Example opening: “This policy specifies who may issue public statements on behalf of UW–Madison and under what circumstances. It exists to protect the academic freedom of individual scholars while preserving the institution’s neutrality on matters unrelated to its core mission.”

Definitions

Treat this as the policy’s glossary and the AI’s anchor list. Format consistently so each definition is its own self-contained unit.

• Use the term itself as a sub-heading or bold lead-in, followed by the definition as a complete sentence. UW–Madison’s existing template format works well: term on its own line, definition immediately below.
• Begin each definition with the term repeated as a noun phrase, not a verb. “University Leader: The chancellor, vice chancellors, deans...”, not “Refers to the chancellor, vice chancellors...”
• Define every term that appears in the policy with a non-obvious meaning. If a reader from outside your office might guess wrong, the term needs a definition.
• Do not define the same term differently in two policies. Where possible, link to or reuse definitions from related university policies.

Scope

Scope tells both the human and the AI who and what this policy covers. The AI uses it to decide whether to apply this policy to a given user’s situation.

• State who the policy applies to in concrete, enumerable terms: faculty, academic staff, students, contractors, visitors, specific units.
• State what activities, locations, or systems are in scope.
• State explicitly what is out of scope. AI systems answer best when exclusions are written as their own sentences, not buried as parenthetical caveats.

Strong scope statement:

“This policy applies to: (1) all UW–Madison faculty and academic staff; (2) all university-owned facilities; and (3) all university-sponsored events held off-campus.

This policy does not apply to: (1) student conduct, which is governed by UW-XXXX; or (2) UW Hospital staff, who are subject to UW Health policies.”

Policy (the main body)

This is the substance of the rule. Most AI retrievals will land here. Optimize the structure aggressively.

• Use a numbered hierarchy (1., 1.1, 1.1.1) that matches the template. The AI uses these numbers to maintain reference integrity when it cites the policy back to a user.
• Give each numbered section a short, descriptive heading. “3. Reporting Requirements” beats an unlabeled “3.” Think of headings as questions a user might ask.
• Within each section, lead with the rule, then the conditions, then the exceptions. AI retrieval favors content that puts the answer first.
• When a section contains a list of obligations, write each list item as a complete sentence with an explicit subject. “Department chairs must…” beats “Must…”
• If a section refers to another section, state both: “as described in Section 4 (Exceptions)” rather than “see below” or “per the previous section.”

Related UW–Madison Policies, Documents, and External References

These fields do double duty for AI: they help the system understand the policy’s place in a broader regulatory landscape, and they let an AI assistant offer good follow-up reading.

• Use the full policy number and the full policy title in every reference. “UW-205 Use of Institutional Names, Logos, Symbols, and other Trademarks”, not “UW-205” alone, and not “the trademark policy” alone.
• For external references (state statutes, federal regulations, Board of Regents policies), include the citation, the title, and a one-sentence note about why it is relevant.

Policy Administration (Approval Authority, Policy Manager, Effective Date, etc.)

These are metadata fields. They are short, but they are critical for AI trust and freshness.

• Use full role titles (“Vice Chancellor for Strategic Communication”), not just names. Names change; the role usually does not.
• Use dates in unambiguous format (YYYY-MM-DD or September 13, 2024, not 9/13/24).
• When revising a policy, update the Last Revision Date field. The AI uses this to decide which version of conflicting information to trust.

Patterns to avoid

A short list of constructions that look fine to a human reader but break AI retrieval:

A before-and-after example

Before (passes the style guide; AI-hostile):

After (same intent; AI-friendly):

Notice what changed: every paragraph names its subject; “as noted above” is gone; the records policy is named, not referenced indirectly; each exception stands alone as a retrievable chunk; the heading describes the content.

Quick checklist for policy authors

Before submitting a draft to the policy library coordinator, walk through this list:

• The title names the topic in plain language a user would actually type.
• The Rationale / Purpose field summarizes what the policy does and why, in three or fewer sentences, with no embedded conditions or exceptions.
• Every term that could be ambiguous is in the Definitions section, defined as a complete sentence beginning with the term as a noun phrase.
• Scope states explicitly who is in and who is out.
• Every section in the Policy body has a descriptive heading.
• No paragraph relies on “above,” “below,” “previous,” or “the foregoing.” Specific section numbers or titles are used instead.
• Pronouns are replaced with the noun they refer to whenever the chunk could be read in isolation.
• No sentence runs longer than about 30 words without a structural break.
• Acronyms are spelled out on first use and defined where useful.
• Tables, if used, are accompanied by a text restatement of any conditional logic.
• Cross-references to other UW–Madison policies include both the policy number and the full title.
• Dates are written in unambiguous format.
• The Policy Manager and Approval Authority fields use role titles, not just personal names.

How this connects to existing UW–Madison standards

This guidance does not replace https://development.policy.wisc.edu. It builds on the existing guide. The table below shows how each AI-readiness principle aligns with an existing UW–Madison policy-writing standard:

Writing for AI is, in practice, writing more carefully for humans. A policy that an AI can answer questions about accurately is a policy a new employee, a student, or a visiting researcher can also read and understand on the first pass.