A prompt library for productivity optimises for fluency. A prompt for governance must optimise for something different: accountability. The output of a governance prompt must be specific enough to review, defensible enough to document, and traceable to the principle it is designed to enforce. These requirements are incompatible with the design philosophy of most prompt collections, which prioritise general usefulness over operational precision.
Key takeaways
- Accountability over fluency: Governance prompts are designed to produce output that a compliance officer can review and document. A governance prompt that produces fluent but vague output has failed.
- Five categories: The Cube A Cloud Governance Prompt Library covers five categories: refusal patterns, risk assessment, policy drafting, HITL escalation, and audit and red-team. Each category corresponds to a distinct governance task.
- Required inputs are non-optional: Every governance prompt specifies required inputs. Supplying incomplete context produces output that is technically complete but operationally useless. The inputs are what make the output specific.
- Output shape matters: Each prompt specifies the shape of its output — a numbered list, a structured table, a policy section with defined fields. Consistent output shape makes governance outputs comparable and auditable across time.
- Generic prompts are rejected: The Governance Prompt Library accepts only prompts designed for a specific governance task. A prompt for summarising documents, writing emails, or general research is not a governance prompt.
Why Generic Prompt Libraries Fail Governance Teams
The governance case against generic prompt libraries is not that they produce bad output in absolute terms. It is that they produce output that is not appropriate for governance use: output that is fluent but imprecise, comprehensive but untraceable, and useful as a starting point but not as a governance document.
A risk assessment produced by a generic prompt is a narrative. It describes the system, identifies some risks, and suggests some mitigations. It cannot be audited against a standard because it is not structured against one. It cannot be compared to last quarter's assessment because the format is not consistent. It cannot be used as evidence in a regulatory review because it has no traceable methodology.
Governance work requires structured output. A risk assessment needs a table with defined columns. A refusal condition needs a rule statement, a rationale, and a default action. A policy section needs numbered sub-sections with enforceable language. None of these structures emerge naturally from a generic "help me assess AI risk" prompt.
The Anatomy of a Governance Prompt
The title states what the prompt does in imperative form. "Draft refusal conditions for a new AI deployment" is a title. "Refusal" is not. The title tells the user whether the prompt matches their task without requiring them to read the full prompt.
The required inputs section is the element most commonly omitted from generic prompt libraries, and the element most responsible for the quality gap between governance prompts and generic ones. A prompt that does not specify its required inputs will be used without them. A risk classification prompt used without the decision type and audience information will produce a generic risk tier that does not reflect the actual system.
The expected output shape section specifies what the prompt is designed to produce: a numbered list, a structured table, a policy section, a log entry. This specification does two things. It tells the user what to expect, which allows them to verify that the output is correct. It also disciplines the prompt author to think about whether the output they have designed is actually useful for the governance task.
Three Governance Prompts Examined
The first example is the refusal condition drafting prompt from the Refusal category. The prompt requires the user to supply the AI system description, the primary decision type, and the applicable regulatory framework. In return, it produces eight specific refusal conditions, each with a rule statement, a rationale, and a default action.
The rule statement is written as a condition the system can evaluate at inference time. "The request involves a customer in an active complaint or legal dispute" is evaluable. "The request seems potentially problematic" is not. The prompt enforces this specificity by instructing the model to write each condition as a rule, not as a general guidance.
The second example is the risk register entry prompt from the Risk Assessment category. It requires the system name, deployment context, top three risks, controls in place, and risk owner. It produces a structured risk register entry with eight defined fields, including a composite risk score, a residual risk score, and an escalation threshold. This output can be directly inserted into an enterprise risk register without reformatting.
The third example is the HITL audit prompt from the Audit category. It requires the current HITL workflow, any past incidents, and reviewer qualifications. It produces at least five failure modes across five categories — criteria failure, authority failure, volume failure, qualification failure, and process bypass — with examples and controls for each. The ranked list of the three most critical failure modes is the primary input for the next governance cycle's HITL improvement work.
What the Library Does Not Include
The Governance Prompt Library explicitly excludes prompts for general productivity: summarising documents, writing emails, generating code, brainstorming ideas, or explaining concepts. These are legitimate uses of AI; they are not governance uses. Including them would dilute the library's identity and, more practically, would make it harder for governance teams to find the prompts they need.
The library also excludes prompts that produce aspirational output: policy language that says "employees should use AI responsibly" or risk assessments that produce a "medium risk" category without defining what medium means. Every prompt in the library is designed to produce output that can be audited, not output that can be filed.
Using the Library Alongside the Toolkit
The Governance Prompt Library is designed to complement the other tools in the Cube A Cloud Lab. The refusal condition prompts produce the conditions that the Risk Worksheet's refusal coverage dimension scores. The risk assessment prompts produce the narrative that the Risk Worksheet's table-format scores need to be useful to a board-level audience. The policy drafting prompts produce the sections that the Policy Generator's form cannot produce: the nuanced, organisation-specific language that requires human judgment.
For teams beginning with the library, the recommended starting point is the Refusal Patterns category. Refusal conditions are the foundational control in any AI governance programme: they define what the system will not do, which is the prerequisite for knowing what it is safe to allow.