> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Demo Whiteboarding tagging rules Integration > Enforcing schema-driven tagging by integrating canonical tagging rules and a locked system prompt so LLM agents produce validated, machine-readable JSON outputs for automation and auditing Hello and welcome back. In this lesson we'll take the next step: making the agent produce structured, schema-compliant output so it's predictable and machine-parseable. Instead of a vague, one-off prompt that asks the model to "try to see if there is an owner" or to "let us know", we'll integrate the organization's tagging rules and enforce a strict output format. That lets automation pipelines and downstream tools consume results reliably across teams. Why enforce structured output? * Vague prompts yield inconsistent, noisy outputs that are hard to validate or automate. * A canonical `tagging-rules.yaml` captures the authoritative schema for tags, types, patterns, and allowed values. * Combining that rules file with a locked-down system prompt forces the agent to return only schema-compliant results, enabling automated validation, auditing, and remediation. Two central concepts * Tagging rules file (`tagging-rules.yaml`): your organization’s canonical schema and policy for tags. This file varies across orgs and defines required tags, allowed values, and validation patterns. * System prompt: an authoritative, version-controlled instruction set provided to the LLM that end users cannot override. It defines the required output format (for example, a JSON object matching the tagging schema) and how to behave when fields are unknown or ambiguous. In the diagram below I zoom into the agent block and surrounding components to show where the tagging rules and system prompt fit. ![Screenshot of a diagrams.net (draw.io) canvas showing a flowchart of a Kubernetes FinOps agent architecture with boxes labeled Agent, LLM - KodeKloud, MCP - K8 Docker, kube-system, Tagging Rule yaml, System Prompt, and Output format as logs. The editor UI with the shapes palette on the left and style/options panel on the right is also visible.](https://mintcdn.com/kodekloud-c4ac6d9a/rjGeTDj8cr6D5YbW/images/Building-Kubernetes-FinOps-AI-Agent/LLM-Policy-Aware-Label-Audit/Demo-Whiteboarding-tagging-rules-Integration/drawio-k8s-finops-agent-flowchart.jpg?fit=max\&auto=format\&n=rjGeTDj8cr6D5YbW\&q=85\&s=b18ab71e4668dceb984e8198c211d4d8) How to link `tagging-rules.yaml` to the agent and guarantee structured output 1. Supply the rules as model context * Inject either a concise representation or the relevant subset of `tagging-rules.yaml` into the system prompt or as a separate tool input. * If the rules file is large, only surface the applicable subset to keep within token/context limits. * Prefer a normalized representation (key names, types, enums, regex patterns) that the model can apply directly. 2. Enforce compliance with a strict system prompt * The system prompt must require a single structured output (e.g., JSON) and forbid any free-text outside that structure. * Keep the system prompt short, authoritative, version-controlled, and editable only by a small, trusted team (SRE/DevOps/Platform). * Use the system prompt to define behavior when data is missing: set required fields to `null` and include an `errors` array describing missing/ambiguous fields. Tip: Surface only the subset of the tagging rules relevant to the resource being analyzed. This reduces token usage and keeps the model focused on what's important. 3. Require and validate a strict output format * Ask the model to return JSON that maps exactly to the tagging schema. * Implement an automatic validation step against your schema and: * Accept and process valid outputs. * On validation failures, either return a deterministic fallback, re-run the agent with clarifying context, or flag for manual review. * Log both the raw model output and validation results for auditing and continuous improvement. 4. Use model-assisted enforcement tools (optional) * Use function-calling, output-parsers, or typed response features if your LLM provider supports them. * Consider a small parser/validator microservice that receives model output, runs schema validation, and returns clean, sanitized results to downstream consumers. Example minimal `tagging-rules.yaml` (illustrative) ```yaml theme={null} # tagging-rules.yaml tags: owner: type: string pattern: "^[a-z0-9._-]+@[a-z.-]+$" required: true environment: type: string enum: ["prod", "staging", "dev"] required: true cost_center: type: string pattern: "^[A-Z]{3}-[0-9]{4}$" required: false ``` Concise, enforceable system prompt (example) ```text theme={null} You are an assistant that MUST produce a single JSON object that conforms to the organization's tagging schema described below. - Do NOT include any text outside the JSON object. - Always enforce types, enums, and regex patterns. - If a required field cannot be determined, set it to null and include an "errors" array with validation messages. Tagging schema (abbreviated): see `tagging-rules.yaml`. Output keys: "owner", "environment", "cost_center", "errors". ``` User instruction prompt (example) ```text theme={null} Analyze the following Kubernetes resource metadata and return tags according to the schema in `tagging-rules.yaml`. Return only a JSON object conforming to the system prompt. Resource metadata: ``` Expected structured output (example) ```json theme={null} { "owner": "alice@example.com", "environment": "prod", "cost_center": "FIN-0123", "errors": [] } ``` Best practices and checklist | Area | Recommendation | | - | - | | System prompt management | Keep it short, authoritative, versioned, and editable only by a small trusted team. | | Context size | Surface only the relevant subset of `tagging-rules.yaml` to reduce token usage. | | Validation | Validate automatically against the schema and implement deterministic fallbacks (e.g., request human review). | | Observability | Log model inputs, outputs, and validation results for auditing and improvement. | | Testing | Write unit/integration tests that exercise edge cases from your tagging rules. | Warning: Never allow end users to modify or override the system prompt or the canonical tagging rules. This can introduce policy drift and enable outputs that break automation or compliance requirements. Operational tips * Version the tagging rules file and the system prompt together so changes are auditable. * If you use regex patterns in `tagging-rules.yaml`, include unit tests for edge-case inputs (e.g., unusual email formats, utf-8 characters). * Consider exposing a schema introspection API for the model wrapper; the wrapper can fetch only the relevant tag definitions for a given resource type. * If your LLM supports function-calling or typed return values, prefer those mechanisms for strong enforcement of types and shapes. References and further reading * JSON Schema overview: [https://json-schema.org/](https://json-schema.org/) * Designing effective system prompts for LLMs: [https://platform.openai.com/docs/guides/system-roles](https://platform.openai.com/docs/guides/system-roles) * Using function calling and typed outputs (LLM provider docs): check your provider's "function calling" or "response schema" documentation. From this point on you are working as a prompt engineer and architect: craft system-level prompts, feed the right subset of tagging rules, and build validation logic so the agent consistently produces machine-readable, schema-compliant tags for your automation pipelines. Well, that's it for this lesson. See you in the next one. > **[Watch Video](https://learn.kodekloud.com/user/courses/building-kubernetes-finops-ai-agent/module/5045eac8-8b03-4ecd-9213-d50eda3353c5/lesson/ff560b4d-87a8-4422-b454-489111ab95dd)** This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.