Dr. Aisha Raymond spent nineteen years building a state's first agency-wide AI governance program before being asked to help write the law that would outlast her tenure. She had the credibility, the case studies, and the scars. What she did not have, at first, was the discipline to turn three decades of hard-won judgment into a document a legislative committee would actually move. Her first draft was a brilliant essay. A veteran legislative counsel read it, set it down, and said: "This tells me you're smart. It doesn't tell me what to vote for, who's against it, or what it costs." That sentence is the whole craft. A policy paper that changes nothing is a diary entry. This lesson is about writing the kind that moves.

You are at the stage of your career where your influence outlives your title through the documents you leave behind: the policy paper that frames a debate and the legislative proposal that codifies a fix. Both live or die on the same disciplines. We will use one running example throughout, a proposed AI Transparency and Accountability Act covering public-sector use of automated decision systems, to make every principle concrete. It is an illustration rather than a real bill, and it is deliberately generic so that the craft rather than the jurisdiction is what shows through.

The two documents and how they differ

A policy paper argues that a problem deserves attention and proposes a direction. Its job is to change minds and set the terms of debate. A legislative proposal is the machinery: statutory language, definitions, authorities, funding, and enforcement that a body can actually enact. The paper persuades; the bill operates. Most leaders fail by writing one when the moment calls for the other, or by jumping to bill text before the argument is won, which produces a technically competent draft that nobody has any reason to vote for.

Aisha's transparency act needed both, in that order. A paper to convince legislators and the public that opaque government algorithms are a real accountability gap, and a proposal that says precisely what agencies must disclose, to whom, by when, and what happens if they do not. The sequencing matters because the two documents answer different objections. A paper cannot survive the question "what does this cost", and a bill cannot survive the question "why is this a problem". Trying to make one document do both work produces something that satisfies neither audience.

There is a third failure worth naming, because it is common among technically strong leaders. Some write the paper, win the argument, and stop, on the assumption that a persuaded committee will produce the right text. It will not. The text that emerges without your involvement will carry definitions somebody else chose, scope somebody else negotiated, and an enforcement mechanism that may be missing entirely. If you are not in the drafting, your argument survives and your judgment does not.

The policy paper structure

Decision-makers read on a deadline. Structure your paper so a busy chief of staff who reads only the first page still knows what you want. That is not a low expectation to design around; it is the realistic one, and papers built for a reader who will finish them are papers built for a reader who does not exist. Use this skeleton.

1. Executive summary, one page, written last. The problem, your recommendation, the cost, and the single most important reason to act. If this page does not stand alone, the paper fails, and writing it first guarantees it will not stand alone because you do not yet know what the paper concluded.
2. The problem, with evidence. Concrete harm to real people, sized with numbers. Not "AI raises concerns" but a statement of the form: "in the past two years, three state agencies deployed automated decision systems affecting an estimated 400,000 residents, none of which published how decisions were made or offered an appeal."
3. Why existing rules fall short. Show the gap. Honest treatment of current law builds the credibility your recommendation rides on, and a reader who finds a live authority you did not mention will discount everything else you wrote.
4. Options, with tradeoffs. Present two or three real choices, including the cost of doing nothing. Decision-makers distrust a paper that offers only the author's favorite, because they know a real analysis produced alternatives.
5. Recommendation. Pick one, and own the tradeoffs you are accepting rather than presenting your choice as costless.
6. Implementation and cost. Who does what, by when, funded how. This is where credibility is won or lost, and it is the section technical authors most often leave thin.

Two structural habits separate papers that move from papers that circulate. The first is that the executive summary is genuinely written last, from the finished argument, rather than drafted early and patched. The second is that the options section contains options the author could live with. A paper offering one serious proposal flanked by two obvious losers is a familiar trick, and the audience for policy papers has seen it many times. It costs you the credibility that the rest of the document depends on.

Evidence standards: the part that earns trust

In government, your evidence will be attacked by people who want a different outcome. Hold yourself to standards higher than they will, because the asymmetry is real: you need every claim to survive, and an opponent needs only one to fail. Three rules do most of the protective work, and all three are about making your reasoning inspectable rather than about making it sound stronger.

• Cite sources a skeptic can check. Government audits, peer-reviewed studies, agency data, and reports from accountability offices and inspectors general. Never launder a vendor's marketing claim into your evidence base, even when the number is convenient and probably right.
• Distinguish what you know from what you believe. "An audit found a 93 percent error rate" is a factual claim tied to a source. "Similar systems likely carry similar risk" is an inference. Label the difference yourself, or an opponent will do it for you, less charitably and at a worse moment.
• Quantify the harm and the fix. Estimate how many people are affected, the cost of inaction, and the cost of your proposal. A number you can defend beats an adjective every time, and a number you cannot defend is worse than no number at all.

The second rule is the one that gets abandoned under pressure, usually late in drafting when an inference is doing important work and labeling it feels like weakening the paper. It is the opposite. A paper that says plainly which of its claims are established and which are reasoned is far harder to dismantle than one that presents everything at the same confidence, because an opponent who finds one overstatement in the second kind can invite the reader to distrust all of it.

Be equally disciplined about the numbers you carry forward. Check every figure against the document it came from before the paper leaves your desk, and record where each one came from in a working file even if the citation does not appear in the final text. You will be asked. The question usually arrives months later in a hearing room, and the difference between a leader who can answer it in one sentence and one who says they will follow up is the difference between a proposal that keeps its momentum and one that quietly loses it.

One more discipline belongs here, and it concerns the numbers you cannot fully verify. Some of the most important figures in a policy paper are estimates: how many residents a set of systems touches, how many appeals a right would generate, what non-compliance currently costs. Present those as estimates with the method visible, in the form the problem statement above uses, where the count is described as estimated and the basis is available if asked. An estimate offered honestly is a strength. The same estimate presented as a measurement is the sentence that ends the discussion of your paper and starts a discussion of your rigor.

Stakeholder analysis: counting votes before you need them

Aisha's essay had no map of who would help or fight. That is why it stalled. Before you finalize a proposal, chart the field. For each stakeholder, name their interest, their likely position, their power to help or block, and your move. The exercise is uncomfortable for technical leaders because it treats a policy question as a political one, which it is, and refusing to do it does not make the politics go away. It only means you meet it unprepared.

The map tells you where to spend your effort. Aisha's real obstacle was not the civil-liberties groups who already agreed with her. It was the budget office and the agency heads. So she added a phased rollout, a realistic cost estimate, and compliance funding, turning two likely opponents into reluctant partners. Note the pattern: each move addressed the stated interest rather than arguing against it, which is generally the only thing that shifts a position held for institutional rather than ideological reasons.

Two cautions about the map itself. It is a working document, not a public one, and a stakeholder analysis written in language you would not want quoted back to you will eventually be quoted back to you. And it goes stale quickly, because positions move with elections, budgets, and incidents. Redo it before each significant push rather than treating the version you built at the start as the standing picture of the field.

The implementation and cost section nobody wants to write

Of the six parts of a policy paper, the last is the one technical authors leave thinnest and the one that decides most outcomes. Who does what, by when, funded how. It is unglamorous because it is where the vision meets the payroll, and it is where credibility is won or lost, because a reader who has watched several ambitious programs arrive unfunded is looking for evidence that this author has thought about the second year. A paper that is confident about the problem and vague about the delivery reads as an argument made by someone who will not have to deliver it.

Build the section around the three questions a gatekeeper will actually ask. Who is accountable, named by role rather than by aspiration, so that the answer is not "agencies" but a specific office with the authority to compel the work. What is the sequence, expressed in phases with dates, so that nobody has to do everything in the first year. And what does each phase cost, separated into the cost the covered agencies will bear and the cost of whatever oversight capacity the proposal creates, because those two come from different places and are defended by different people.

Phasing is the single most useful device available here, and it does double duty. Practically, it gives agencies time to build capacity rather than forcing an unfunded scramble that produces paper compliance. Politically, it converts a large number into several smaller ones arriving in different budget years, which is a much easier conversation with a budget office than a single figure in year one. Aisha's phased rollout with compliance funding was not a concession that weakened her proposal. It was the change that made the proposal survivable, and the obligations it created were the same ones.

Drafting the legislative proposal

When the argument is won, the bill must operate without you in the room to explain it. Plain-language drafting is not dumbing down; it is reducing the ambiguity that breeds lawsuits and loopholes. Note the word "reducing". No drafting technique eliminates ambiguity, clear text can still be read against your intent, and a leader who believes plain language has made a provision airtight has stopped looking for the reading an adversary will find. A workable AI proposal carries these parts.

• Definitions. Define "automated decision system" tightly enough to capture what you mean and not everything with a spreadsheet. Vague scope is the most common fatal flaw, and no definition survives contact with technology it did not anticipate, which is one reason the review clause below matters.
• Scope and thresholds. Which systems and which decisions are covered? Tie obligations to impact so low-stakes tools are not buried in paperwork. Risk-tiering approaches such as the one in the NIST AI Risk Management Framework, which is voluntary guidance rather than binding law, can inform how you draw those lines.
• Core obligations. What must agencies do? Publish an inventory, conduct impact assessments, provide notice and an appeal path. State each as a duty owed by a named actor, not as an aspiration.
• Oversight and enforcement. Who audits, who can pause a system, and what is the consequence of non-compliance? A mandate with no teeth is theater.
• Funding and timeline. Phased dates and a funding source. An unfunded mandate dies in committee or in practice, and the second death is quieter and more damaging.
• Sunset and review. Require the legislature to revisit the law as the technology changes. This makes cautious members more willing to vote yes, and it is the structural answer to definitions that will age.

Work with legislative counsel from early in the drafting rather than handing over a finished text. Drafting conventions, the interaction with existing law, and the mechanics of how a provision is codified are their expertise and not yours, and a subject-matter expert who arrives with a complete draft usually finds most of it rewritten. Your contribution is the substance: what the obligation is, who owes it, what triggers it, and what happens when it is breached. Bring that clearly and let the people whose craft is statutory text do the rest.

Expect the text you get back to look unfamiliar and to be better. Counsel will collapse several of your provisions into one, move a definition, and replace a phrase you liked with a term of art that carries settled meaning in your jurisdiction. Read the result for substance rather than for style, and raise an objection only where the rewrite has changed who owes what to whom or what happens on breach. Authors who fight the drafting conventions spend their limited credibility on the wrong argument and have none left for the scope negotiation, which is the one where their expertise is genuinely irreplaceable.

What enactment does, and what it does not

It is worth being blunt about a belief that survives in almost every technically strong author. A well-drafted proposal does not produce a policy outcome. It creates obligations and, if you drafted it properly, an enforcement path. Whether the outcome follows depends on things the text can influence and cannot guarantee: whether the funding arrived, whether the oversight body was staffed, whether anyone exercised the appeal right, and whether the agencies covered by it understood what they owed. A statute is an instrument, and instruments are used well or badly.

This matters at the drafting table, not only afterward. If your obligation has no named actor who owes it, no trigger that says when it applies, and no consequence for breach, you have written a statement of values that will be cited approvingly in speeches and complied with unevenly. Test every core provision by asking three questions: who exactly must act, what exactly must they do, and what happens if they do not. Any provision that fails one of the three is a provision that will produce a compliance report instead of a change in behavior.

It also changes what you do after passage. The leaders whose laws actually work treat enactment as the halfway point and stay engaged through the implementation year: the guidance that interprets the definitions, the first inventory that reveals whether the scope was drawn correctly, and the first appeal that tests whether the path exists in practice. That work is unglamorous and it is where a good bill becomes a working one. It is also where a bad definition becomes visible early enough that the review clause can fix it.

Why good ideas die in committee

Most strong proposals fail for reasons that have nothing to do with their merit, which is the observation that most surprises technically strong authors and the one that most repays acting on. The graves are predictable, they are the same five in most jurisdictions, and every one of them is cheaper to prevent during drafting than to recover from after a proposal has stalled once. A stalled proposal also carries a reputational cost into its next session, because members remember what did not move and want to know what changed.

• No cost estimate, so the budget office kills it quietly and you never learn which meeting it died in.
• Scope too broad, so every affected agency lines up against it and the coalition against you is larger than the one you built.
• No champion, so no one carries it when it stalls. Recruit your legislative sponsor before you finalize, not after, because a sponsor recruited early shapes the text into something they can defend.
• Definitions a lawyer can drive a truck through, inviting litigation and loopholes and giving opponents a substantive rather than a political objection.
• All vision, no implementation, so practitioners tell their legislators it cannot be built, which is the most damaging objection because it comes from your own community.

Aisha's act became law in its third session. Not because the second draft was more eloquent than the first, it was actually plainer, but because it told legislators exactly what to vote for, named who would fight it and how she had answered them, and put a defensible price on the page. Her name is not in the statute. Her judgment is in every operative clause, which is what legacy looks like in this work, and it is available to anyone willing to write for the reader who has a few minutes rather than for the reader they wish they had.

Anti-Patterns to Avoid

• Treating enactment as the outcome. A statute creates obligations and an enforcement path. It does not produce transparency, fairness, or accountability by itself. Those depend on funding, staffing, guidance, and whether anyone ever exercises the right you created.
• Mistaking plain language for airtight language. Clear drafting reduces ambiguity; it does not eliminate it, and clear text can still be read against your intent. Keep hunting for the adversarial reading after the provision reads well.
• Writing the essay when the moment needs the bill, or the reverse. A paper cannot answer "what does it cost" and a bill cannot answer "why is this a problem". A document trying to do both satisfies neither audience.
• Winning the argument and leaving the drafting to others. Text produced without you carries definitions, scope, and enforcement somebody else chose. Your argument survives that; your judgment does not.
• Presenting one real option flanked by two losers. Experienced readers recognize the pattern immediately, and it costs you the credibility every other section of the paper depends on.
• Presenting inference at the confidence of fact. An unlabeled inference is the loose thread an opponent pulls, and finding one lets them invite the reader to distrust the whole document.
• Skipping the stakeholder map because the merits should be enough. They are not, and refusing the political analysis does not remove the politics. It only means you meet the opposition without having thought about it.
• Writing an obligation with no named actor, trigger, or consequence. Provisions failing any of those three produce compliance reports rather than changes in behavior.

Practice Prompts

• Take a policy problem you know well and write only the executive summary: problem, recommendation, cost, and the single most important reason to act, on one page. Give it to someone unfamiliar with the issue and ask them what you want. Rewrite until they can tell you.
• Write your problem statement twice, once in the abstract and once with a concrete count of who is affected and what they were denied. Compare which version an opponent would find easier to dismiss.
• Go through a draft you have written and mark every claim as either established with a checkable source or reasoned inference. Rewrite the sentences where the label would surprise a reader.
• Build the stakeholder table for a change you are proposing. Then identify the one row where a change to your proposal, rather than a better argument, would move the position, and design that change.
• Take one core obligation from any AI governance proposal you can find and test it against three questions: who must act, what must they do, and what happens if they do not. Rewrite it so that all three have answers in the text.
• Draft the sunset and review clause first, before the substantive provisions. Notice how it changes what you are willing to define tightly, and which decisions you are content to leave to the next revision.
• List the five ways good proposals die and mark which one your current draft is most exposed to. Write the specific mitigation, with an owner and a date, rather than a note that you should address it.

Reflection

Think about a policy document you wrote that went nowhere. Reading it now, was the problem the argument or the packaging? In most cases the analysis was sound and the document simply failed to answer the three questions Aisha's legislative counsel put to her: what am I voting for, who is against it, and what does it cost. Those questions feel beneath the substance of the work, which is exactly why technically strong authors skip them and why their best thinking never reaches a vote.

Then consider what happens to your judgment when you leave. Programs get restructured, systems get replaced, and the people who learned from you move on. What survives is what got written into a document that binds somebody: a statutory obligation, a funded requirement, a review clause that forces a future legislature to look again. That is a narrow and unromantic definition of legacy, and it is the one that actually holds. It is worth asking now, while you still have the standing to act on it, which of the things you know ought to be written down that way.

Glossary

• Policy paper. A document arguing that a problem deserves attention and proposing a direction. Its job is to change minds and set the terms of the debate rather than to create obligations.
• Legislative proposal. Draft statutory language with definitions, authorities, obligations, funding, and enforcement, written so a legislative body can enact it and so it operates without its author present.
• Executive summary. The standalone opening page carrying the problem, the recommendation, the cost, and the main reason to act. Written last, from the finished argument.
• Stakeholder map. A working analysis naming each group's core interest, likely position, power to help or block, and the specific move you will make in response.
• Scope and thresholds. The provisions determining which systems and which decisions a law covers, ideally tied to impact so that low-stakes tools do not carry high-stakes obligations.
• Sunset and review clause. A requirement that the legislature revisit a law after a set period. It reassures cautious members and provides the structural answer to definitions that will age.
• Unfunded mandate. An obligation imposed without a funding source. It tends to die in committee, or more damagingly, to die quietly in practice after passage.

Related Lessons

• Legislative Framework Development covers the design of the framework itself, where this lesson covers the craft of the documents that carry it.
• AI Regulatory Design addresses the regulatory choices your proposal will have to encode.
• Public Consultation on AI Policy is the structured version of the stakeholder work sketched here.
• Algorithmic Impact Assessments details the obligation this kind of proposal most often creates.
• Public Reporting and Algorithmic Transparency covers the disclosure duties a transparency act would impose.
• NIST AI RMF: MAP, MEASURE, MANAGE explains the voluntary framework whose risk-tiering can inform how you draw statutory thresholds.
• Publishing on Government AI handles the other route by which a practitioner's judgment enters the record.
• State and Local Government AI Policy situates this work in the level of government where most of it currently happens.

Closing

The craft in this lesson is not literary. It is the discipline of writing for a reader who has a few minutes, competing priorities, and no obligation to be persuaded. Every element here serves that reader: the standalone summary because they may read nothing else, the honest options because they distrust a single-choice analysis, the cost estimate because they will be asked about it, the stakeholder map because they need to know who is coming, and the enforcement clause because they have seen mandates with no teeth before.

Aisha's advantage in the third session was not that she had become a better writer. It was that she had stopped writing to demonstrate what she knew and started writing to make a decision possible. That shift is available to anyone who has done the operational work, and it is the thing that converts nineteen years of judgment into something that keeps working after you have left the building.

Key Takeaways

• Know which document the moment needs. A policy paper changes minds and sets the debate; a legislative proposal is the enforceable machinery. Do not confuse the two, and do not try to make one do both jobs.
• Write the executive summary to stand alone, and write it last. A busy reader who sees only page one should still know the problem, your recommendation, and the cost.
• Hold yourself to a hostile reader's evidence standard. Cite checkable sources, label inference as inference, and quantify both the harm and the fix with figures you can defend on the day you are asked.
• Offer options you could live with. One real proposal flanked by two obvious losers is a recognized trick and it costs you the credibility the rest of the paper needs.
• Map stakeholders before you finalize. Name each group's interest, position, power, and your move, and spend your effort on the skeptics who can block you rather than the allies who already agree.
• Address the stated interest rather than arguing against it. Phased rollout, a realistic cost estimate, and compliance funding turned Aisha's two most dangerous opponents into reluctant partners.
• Definitions and scope decide a bill's fate. Tie obligations to impact and define key terms tightly, knowing that no definition survives technology it did not anticipate, which is what the review clause is for.
• Enactment is not the outcome. A statute creates obligations and an enforcement path; funding, staffing, guidance, and use of the rights you created determine whether anything changes.
• Test every obligation three ways. Who must act, what must they do, and what happens if they do not. A provision failing any of the three produces reports rather than behavior change.
• Recruit a champion early and stay through implementation. Good ideas without a sponsor stall at the first resistance, and good statutes without their author present during the first year get interpreted by people who were not in the argument.

Frequently Asked Questions

Should I write the policy paper or go straight to bill text?

Write the paper first unless the argument is already won, which is rarer than it feels from inside the work. A bill arriving before the case has been made asks legislators to accept a premise and a mechanism at the same time, and they will usually contest the premise. The paper's job is to remove that argument so that the bill conversation can be about scope, cost, and enforcement, which are the conversations where your operational experience is most useful.

How much detail belongs in the cost estimate?

Enough that a budget analyst can see your reasoning and check it, which usually means naming the components and the assumptions rather than producing a single confident total. Where a component is genuinely uncertain, say so and give a range with the basis for it. A defensible estimate with visible assumptions survives scrutiny far better than a precise-looking figure whose derivation nobody can reconstruct, including, eventually, you.

What if I cannot get a legislative sponsor?

Treat that as information about the proposal rather than as an obstacle to route around. A proposal nobody will carry usually has a scope problem, a cost problem, or a constituency problem that the sponsor conversation has just revealed early and cheaply. Ask the members who declined what would have to change, and take the answers seriously. Reworking a proposal to fit what a sponsor can defend is not compromise; it is the work.

How tightly should I define "automated decision system"?

Tightly enough to capture what you actually mean and not everything with a spreadsheet, which is the balance the definition is trying to strike and the hardest part of the drafting. Expect the first definition to age badly, and build the review clause on that assumption rather than trying to write a definition that anticipates technology nobody has yet built. Work the wording with legislative counsel, who will know how similar terms have been read in your jurisdiction.

Do I have to include enforcement? It makes the bill harder to pass.

It does make it harder, and a mandate with no teeth is theater. The productive middle ground is usually graduated rather than absent: a duty to report, then a duty to remediate, then a power to pause a system, with the strongest tools reserved for the highest-impact uses. That structure gives cautious members something proportionate to vote for while still creating a consequence for breach, which is the element that separates an obligation from an aspiration.

How do I handle vendor opposition to transparency requirements?

Address the stated interest rather than dismissing it. The concern is usually about protecting proprietary material, and audit rights that do not require forced source disclosure often satisfy it without weakening the accountability the provision is there to create. That was the move in Aisha's stakeholder map. Where the opposition turns out not to be about intellectual property after all, you have learned something useful about who you are actually negotiating with.

My paper was ignored. How do I tell whether it was the argument or the packaging?

Ask three questions of the document, the same ones Aisha's legislative counsel asked. Does a reader finish page one knowing what to vote for? Does the paper name who will oppose it and answer them? Does it put a defensible number on the cost? A paper failing any of those was almost certainly ignored for that reason rather than for its analysis, and all three are fixable in a revision without reopening the substance.