On 26 August 2026, IBM Research authors released an arXiv paper detailing a YAML schema designed to let organisations document the permitted and prohibited outputs of a generative AI model, and apply those constraints across the entire lifecycle from training to deployment S¹P⁴. The "Granite.Trust Policy Tools" paper contends that current software governance tools are designed for access management, rather than the more complex task of restricting the actual output of a language model. Example policies, the schema itself, and enforcement utilities are currently available on GitHub with an Apache 2.0 licence S¹P². The paper raises, but does not resolve, the question of whether a YAML file is sufficient to bear the burden of AI governance.

My read: I have not seen another attempt to create a unified, shareable policy format that covers the entire GenAI lifecycle instead of just attaching guardrails to a single phase. I remain skeptical of the "specify once, enforce everywhere" assertion because the preprint lacks comparative benchmarks and proof of real-world use. With 17 stars and a single external fork on GitHub P², the project is clearly in its infancy. However, the fundamental realization that access-control logic is inadequate for content generation is both accurate and long overdue.

Why access control breaks for generative AI

Conventional policy frameworks resolve a straightforward query: does this user have permission for this action? For instance, a database administrator might have read access to a specific table while a junior analyst does not. Such rules are binary and linked to user identity S¹.

Generative AI disrupts this paradigm. The challenge lies not in the identity of the requester, but in the nature of the generated response. For example, a customer support bot may be permitted to talk about billing but prohibited from suggesting particular financial products. Similarly, a medical assistant could be allowed to clarify a diagnosis but forbidden from prescribing medication. The authors argue that these content-focused restrictions cannot be natively articulated by current access-based policy systems S¹.

This paper proposes a format where a team writes the rule once in a structured file and references it at every stage.

What the Actionable Policy schema actually does

The schema relies on YAML, a human-readable configuration format commonly used by DevOps teams for infrastructure management. A policy file dictates the permissible and prohibited contents of model responses S¹.

Additionally, the paper introduces an exception-based governance approach. Instead of viewing every policy breach as a binary failure, the schema enables teams to establish and monitor exceptions, allowing a breach to be recorded, evaluated, and resolved within a workflow instead of merely halting the output S¹.

The paper also details a synthetic data generation pipeline that runs alongside the schema. This pipeline creates training data conforming to the defined policies, enabling a model to be fine-tuned to obey the rules prior to user deployment. Those identical policies are subsequently applied during runtime monitoring S¹.

The authors assert that this enables organisations to "specify policies once and enforce them throughout the GenAI application lifecycle" S¹. This remains an unverified claim from the authors' own preprint.

What is actually verifiable

The ibm-granite/granite.trust.policy-tools GitHub repository is publicly accessible P². Established on 14 April 2026, it is licensed under Apache 2.0 and includes Python code, Jupyter Notebooks, and HTML P². Nathalie-B is the leading contributor with 13 contributions, while Heiko Ludwig, a paper author, has a single contribution P². The repository is housed within the ibm-granite GitHub organisation, and multiple authors list IBM Research as their affiliation P⁴. However, the source provides no confirmation of IBM officially productising these utilities or of any production deployment by organisations.

On 21 August 2026, a distinct but related repository named erjui/PolicyGuide emerged, focusing on steering the entire workflow of LLM agents toward policy compliance instead of merely safeguarding individual actions P⁵. With zero stars and a single contributor, this project indicates that the wider domain of AI policy tooling is still in its nascent stages.

What to do about it

For those building or deploying generative AI applications, reviewing the schema is worthwhile even without adopting the accompanying tools. The concept of documenting content rules in a structured, version-controllable format, instead of hiding them within prompt templates or ad hoc guardrail scripts, represents a practical shift accessible to any team.

Take a pathology lab that uses an AI assistant to help pathologists draft reports. The lab requires the model to detail tissue findings but strictly prohibits it from suggesting a specific treatment plan to a patient. Currently, such a rule might be scattered across a system prompt, a post-processing filter, and a separate fine-tuning dataset, with no assurance of consistency. The Actionable Policy schema suggests a single source of truth: one YAML file read by the training pipeline, the inference guardrail, and the monitoring dashboard.

This week, consider cloning the repository, examining the example policies, and contrasting them with the content rules your application currently enforces informally. If your rules cannot be represented within the schema, that discrepancy highlights the vulnerabilities in your existing guardrails.

What we don't know yet

The document is a version-1 preprint on arXiv that has not undergone peer review S¹. It offers no empirical benchmarks comparing the Actionable Policy schema to existing policy frameworks or guardrail utilities. There is no proof of production deployment, no independent validation, and no data regarding the schema's performance at scale or across various model families.

The paper makes no claims of endorsement from any governmental or standards organisation, and the schema has not been ratified as an industry standard S¹. Its connection to IBM stems from author affiliation and the GitHub organisation, rather than an official corporate product roadmap.

The next signal: monitor the ibm-granite/granite.trust.policy-tools repository for external contributions and issue activity in the coming weeks. If other organisations start submitting pull requests or adapting the schema, it will be the first indication of traction beyond the original authors. We will review the repository's contributor graph and issue tracker to verify this in October.

If this kind of reporting helps you make better decisions about AI deployment, subscribe to keep reading.

Sources: S1 — Granite.Trust Policy Tools: Shareable, Actionable Policies for Generat · P2 — ibm-granite/granite.trust.policy-tools · P3 — declare-lab/trust-align · P4 — Granite.Trust Policy Tools: Shareable, Actionable Policies for Generat · P5 — erjui/PolicyGuide

More from Not A Tech Guy

Generated from an audited evidence pack with primary-source research. Social-media items are discussion signals, not verified facts. Nothing here is financial, legal or medical advice.