# Ps Decision Readiness And Public Communication > A six-element model for presenting an AI proposal so a public decision body (council, board, steering group) can actually approve it: options, relevancy and focus, trust, urgency, strategic alignment, and public-sector decision dynamics. Use when preparing to bring an AI initiative to a public decision-maker for a go/no-go or funding decision. - Skill: `pilot2service/ps-decision-readiness-and-public-communication` (Agent Skill) - Install (CLI): `npx skillmds@latest add pilot2service/ps-decision-readiness-and-public-communication` - Raw SKILL.md: https://api.skillmd.com/api/skills/pilot2service/ps-decision-readiness-and-public-communication/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: Pilot2Service (https://skillmd.com/u/pilot2service) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/pilot2service/ps-decision-readiness-and-public-communication --- # Decision-Readiness and Public-Sector Communication for AI Proposals ## Purpose A well-argued AI business case can still fail to get a decision — not because it's wrong, but because it wasn't built to be *decided on* by a public body. Public-sector decision-making has structural features a private-sector pitch doesn't have to account for: multiple stakeholder interests that all need to be visibly balanced, a public accountability and transparency bar, and decisions made under scrutiny that will outlast the meeting they were made in. This skill gives a six-element model for building decision-readiness into the proposal itself, adapted specifically for AI initiatives (which carry extra unfamiliarity and trust burden compared to a routine infrastructure or service proposal). ## Anchored in Adapted from the owner's own public-sector commercialisation methodology (a six-element decision-readiness model originally built for general post-pilot exploitation decisions) — see `../../references/source-notes.md` for exactly what was kept, generalized, and left out. Applied here specifically to AI proposals, which the source material does not cover. ## Method Work through all six elements before the proposal goes to the decision body — a proposal missing even one tends to stall, not fail outright, which is often worse (it sits in limbo rather than getting a clear no you can act on). ### 1. Provide real options, not one recommendation dressed as three Public decision-makers need to visibly choose between genuine alternatives, not rubber-stamp a foregone conclusion — both because it's better decision-making and because a visible choice is more defensible afterward. For an AI proposal, this usually means presenting at minimum: do nothing / a smaller or manual-first alternative / the proposed AI solution — each with a real cost, risk, and impact comparison, not a strawman "do nothing" option built to lose. ### 2. Provide relevancy and focus — resist the urge to show all your work A team that did five months of AI opportunity scoring, technical scoping, and vendor comparison wants to show it. A decision-maker needs the two or three facts that actually drive the choice, in a form they can scan in the room. Lead with an executive-summary-level view; put the scoring detail, technical architecture, and vendor comparison behind it for those who want to go deeper. ### 3. Create trust — AI proposals start from a trust deficit Because AI is newer and less well understood than most infrastructure decisions a public board reviews, assume extra skepticism by default, and address it directly rather than assuming competence will speak for itself: - Publish the methodology and data sources behind any claim, not just the conclusion. - Where possible, include independent review, a pilot result, or a comparable case from another public body — a first-of-its-kind claim is a harder sell than "this worked elsewhere and here's the evidence." - Build in a visible feedback or complaint channel for the AI system itself, not just for the project. ### 4. Create urgency, tied to the actual public-sector clock Generic urgency ("the market is moving fast") lands weakly with a public decision-maker. Tie urgency to what actually moves this audience: a budget-cycle deadline, an expiring funding window, a service-quality problem citizens are already raising, or a compliance deadline. State it as a real, checkable fact, not a rhetorical push. ### 5. Align explicitly with strategy and policy Show the connection between this AI proposal and the organization's existing strategic plan or policy goals in the proposal itself — don't assume the decision-maker will make that connection unprompted. If no clean connection exists, that's worth knowing before the meeting, not during it (see `ps-ai-opportunity-screening-for-public-value` step 1 on mandate). ### 6. Design for how public-sector decisions actually get made Unlike a single-sponsor private decision, a public decision typically needs to survive scrutiny from multiple, sometimes conflicting, stakeholder interests simultaneously (see `ps-stakeholder-and-political-landscape-mapping`), needs to be defensible on the record after the fact (assume it may be FOI-requested, audited, or publicly reported on), and often needs staged approval rather than one up-or-down vote (a smaller pilot approval now, a scale decision later). Structure the ask accordingly — often the right ask is narrower and more staged than the team's full ambition, precisely because that's what actually gets a yes. ## Choosing the right format Match the artefact to the audience and moment, not by default: - A short, high-level summary for a body that needs to decide quickly or is seeing this for the first time. - A visual, narrative-driven version for building broader buy-in or public communication. - A structured formal document when the decision needs to be recorded and defensible on paper (see `ps-procurement-and-public-funding-navigation` step 3 on documentation burden). - The fullest, most detailed version only for the working team and technical reviewers, not the decision body itself. ## What this skill does NOT do - Doesn't write the underlying business case — see `ps-public-value-business-case-framing` and `../../../../business-case-and-analysis/skills/business-case-builder/SKILL.md`. - Doesn't replace stakeholder mapping — do that first with `ps-stakeholder-and-political-landscape-mapping` so element 6 has real input to work with. - Doesn't guarantee approval — a well-built proposal can still get a legitimate no; this skill improves the odds of getting a clear, timely decision either way, not a specific outcome. ## Refinement notes The six elements are a direct generalization of the owner's own practitioner framework — not synthesized from public literature the way some of this pack's other skills are (see `ps-ai-opportunity-screening-for-public-value`'s Refinement notes for the contrast). If the owner has more example language or case outcomes from real engagements, they belong here as the next refinement layer. ## Continue from here - Business case to present: `../ps-public-value-business-case-framing/SKILL.md` - Stakeholder input for element 6: `../ps-stakeholder-and-political-landscape-mapping/SKILL.md` - General business-case builder: `../../../../business-case-and-analysis/skills/business-case-builder/SKILL.md` - Storytelling craft for the pitch itself: `../../../../prototyping-and-demonstration/skills/opportunity-visioning-with-pr-faq/SKILL.md` ## References - `../../references/source-notes.md` — full detail on what was adapted from the source and what was left out. --- **Reminder:** frontmatter has only `name` and `description`. Everything else goes into `skills_index.json` (run `scripts/generate_index.py`).