Governance and platform teams use this prompt when they need a consistent, automatable method to classify the maturity of every instruction in their library. Manual classification does not scale and introduces inconsistency, especially as a library grows beyond a few dozen prompts. This prompt acts as a lifecycle auditor: given an instruction's text and metadata, it assigns a lifecycle stage (such as draft, stable, deprecated, or sunset), provides the evidence that supports that classification, and flags instructions that appear to be in transition between stages. The primary job-to-be-done is pre-release audit, CI-integrated quality checks, or generating a library-wide maturity report for stakeholders.
Prompt
Instruction Lifecycle Stage Classifier Prompt

When to Use This Prompt
Identify the right conditions for deploying the Instruction Lifecycle Stage Classifier and understand its operational boundaries.
The ideal user is a prompt engineer, platform engineer, or governance lead who already has access to the instruction text and relevant metadata (author, last modified date, deprecation notices, linked tests, and usage frequency). The prompt is designed to be wired into a CI pipeline that runs on every commit to a prompt repository, or as a batch job that scores an entire library before a quarterly review. It is not a migration or deprecation tool—it does not rewrite instructions, generate migration paths, or execute rollbacks. It only classifies and provides evidence. If you need to generate a deprecation notice or a migration playbook, pair this classifier with a downstream generation prompt.
Do not use this prompt when the instruction text is unavailable, when the lifecycle taxonomy has not been agreed upon by the team, or when you need a real-time classification during model inference. This is an offline, batch-oriented prompt. It assumes a stable taxonomy of lifecycle stages and requires that the input includes enough context to make a classification decision. If your library lacks consistent metadata, invest in metadata hygiene first. If you are classifying instructions that are actively executing in production sessions, use the Legacy Instruction Detection Prompt instead. After running this classifier, always review boundary-case outputs—instructions flagged as in_transition—with a human before taking automated action like blocking a deployment.
Use Case Fit
Where the Instruction Lifecycle Stage Classifier Prompt works, where it fails, and the operational prerequisites for production use.
Good Fit: Governance Library Audits
Use when: you need to classify hundreds of instructions across a library into lifecycle stages (draft, active, deprecated, sunset) for a quarterly governance review. Guardrail: Run the classifier in batch with a human-in-the-loop review step for any instruction flagged as 'transitioning' or 'unknown' before updating the system of record.
Good Fit: Pre-Deployment Release Gates
Use when: a CI/CD pipeline must verify that only 'active' or 'production' stage instructions are deployed to a target environment. Guardrail: Combine the classifier output with a hard schema check in the deployment script. Reject any instruction whose classified stage does not match the environment's allowed stage list.
Bad Fit: Real-Time Session Decisions
Avoid when: you need to decide in a running session whether to use an instruction. This classifier is for offline governance, not low-latency routing. Guardrail: Pre-compute lifecycle stages and store them as metadata. At runtime, read the metadata; do not call the classifier inside the hot path.
Bad Fit: Ambiguous or Undocumented Instructions
Avoid when: the instruction text is a single vague sentence with no version history, owner, or deployment context. The classifier will hallucinate a stage based on weak signals. Guardrail: Require minimum metadata fields (created date, last modified, owner team) before classification. Return 'insufficient_evidence' if the minimum is not met.
Required Inputs
What you must provide: the full instruction text, a last-modified timestamp, and a deployment status flag (e.g., 'currently_deployed', 'in_staging', 'archived'). Guardrail: Validate inputs before calling the model. If the timestamp is missing or the status flag is null, abort and request the data owner to enrich the record first.
Operational Risk: Stage Drift Over Time
Risk: An instruction classified as 'active' six months ago may now be functionally deprecated but still deployed. Guardrail: Schedule a recurring classification job (e.g., weekly) that re-evaluates all 'active' instructions. Alert the owning team if the classifier suggests a stage change, and require a human to approve the transition before it takes effect.
Copy-Ready Prompt Template
A reusable prompt with square-bracket placeholders for classifying an instruction's lifecycle stage, including evidence and boundary-case handling.
This prompt template is designed to be copied directly into your prompt management tool, orchestration layer, or evaluation harness. It accepts an instruction block and a taxonomy of lifecycle stages, then returns a structured classification with the evidence that supports the assigned stage. All square-bracket placeholders must be replaced with your specific content before execution. The prompt is built to handle instructions that are in transition between stages, producing a primary classification and a secondary stage when the evidence is mixed.
textYou are an instruction lifecycle auditor. Your task is to classify the maturity stage of a given instruction using the provided taxonomy. You must ground every classification in explicit evidence from the instruction text and its metadata. Handle boundary cases where an instruction exhibits characteristics of multiple stages by providing a primary stage, a secondary stage, and the conflicting evidence. [TAXONOMY] [INPUT_INSTRUCTION] [OUTPUT_SCHEMA] [CONSTRAINTS] [EXAMPLES]
How to adapt this template: Replace [TAXONOMY] with your organization's lifecycle stage definitions, including stage names, descriptions, and entry/exit criteria. Replace [INPUT_INSTRUCTION] with the full text and metadata of the instruction you are classifying. Replace [OUTPUT_SCHEMA] with the exact JSON schema you expect, including fields for primary_stage, secondary_stage, evidence, conflicting_evidence, and confidence. Replace [CONSTRAINTS] with any hard rules, such as 'If the instruction has no version header, it cannot be classified as Production.' Replace [EXAMPLES] with at least two few-shot examples showing clear single-stage classification and one example showing a boundary case with a primary and secondary stage. For high-risk governance workflows, add a [RISK_LEVEL] field and require the model to flag classifications with low confidence for human review before the output is accepted into your instruction registry.
Prompt Variables
Required inputs for the Instruction Lifecycle Stage Classifier Prompt. Each variable must be populated before classification to ensure reliable stage assignment and evidence extraction.
| Placeholder | Purpose | Example | Validation Notes |
|---|---|---|---|
[INSTRUCTION_TEXT] | The full instruction block to classify, including any metadata headers, version tags, or policy annotations | SYSTEM: You are a support agent. VERSION: 2.4.1. Do not discuss pricing. | Must be non-empty string. Reject if only whitespace or under 20 characters. Strip leading/trailing noise before classification. |
[LIFECYCLE_STAGES] | The taxonomy of lifecycle stages the classifier must choose from, with definitions for each stage | draft, review, active, deprecated, sunset, archived | Must be a valid list with at least 2 stages. Each stage must have a definition in the prompt context. Reject if stages overlap semantically without disambiguation rules. |
[STAGE_CRITERIA] | Observable evidence rules that map instruction characteristics to lifecycle stages | active: has version header AND no deprecation notice AND referenced in current config | Must be non-empty and testable. Each criterion must reference concrete markers (headers, tags, config presence). Reject criteria that rely on subjective judgment without observable signals. |
[TRANSITION_INDICATORS] | Signals that an instruction is between stages, such as deprecation notices with future effective dates or sunset warnings | deprecation_notice_date, sunset_effective_date, migration_pointer_present | Must be a list of detectable markers. Each indicator must have a detection rule. Null allowed if transition detection is not required for this classification run. |
[CONFIG_REFERENCE] | Current production or staging configuration that shows which instructions are active, to ground the active vs. deprecated distinction | {"active_instructions": ["support-agent-v2", "refund-policy-v3"]} | Must be valid JSON or structured reference. If null, the classifier cannot determine active status and must flag this limitation in output. Validate parse before classification. |
[OUTPUT_SCHEMA] | The exact JSON schema the classifier must return, including stage field, evidence array, confidence score, and boundary-case flags | {"stage": "string", "evidence": ["string"], "confidence": 0.0-1.0, "boundary_case": true|false} | Must be a valid JSON Schema or type specification. Reject if schema lacks required fields for stage, evidence, and confidence. Validate that schema is parseable before prompt assembly. |
[BOUNDARY_CASE_RULES] | Explicit rules for handling instructions that match multiple stages or are in active transition | If deprecation notice present AND effective date is future, classify as deprecated with boundary_case=true and note active-until date. | Must be non-empty if transition indicators are provided. Each rule must resolve ambiguity to a single stage. Reject rules that leave stage assignment ambiguous without escalation instructions. |
[CONFIDENCE_THRESHOLD] | Minimum confidence score required for automatic classification; below this, the output must flag for human review | 0.85 | Must be a float between 0.0 and 1.0. Default to 0.80 if not specified. Classifications below threshold must set human_review_required=true in output. |
Implementation Harness Notes
How to wire the Instruction Lifecycle Stage Classifier into a governance pipeline with validation, retries, and audit logging.
The Instruction Lifecycle Stage Classifier is designed to be a deterministic step in a broader instruction governance pipeline, not a standalone chat interaction. Wire it as a single-turn classification call within a script, CI/CD job, or internal admin tool. The prompt expects a complete instruction block as [INPUT] and an optional [TAXONOMY] defining your organization's lifecycle stages. The model should be configured with a low temperature (0.0–0.2) to maximize consistent stage assignment across repeated runs on the same instruction text. Avoid using this classifier in high-frequency, user-facing request paths; it belongs in batch governance workflows, pre-release review gates, and periodic library audits.
Implement a validation layer immediately after the model response. Parse the JSON output and confirm that the lifecycle_stage value is an exact match for one of the allowed stages in your taxonomy. If the model returns an unrecognized stage, a missing evidence array, or a confidence score below your threshold (we recommend 0.7 as a starting floor), route the instruction to a human review queue rather than silently accepting the classification. Log every classification result—including the instruction version hash, the assigned stage, confidence, and the raw model response—to an audit table. This audit trail is essential for governance teams that must prove which lifecycle stage was active when a production incident or compliance review occurs. For high-risk or regulated instruction sets, require a second human approver to confirm any deprecated or sunset classification before it triggers downstream cleanup automation.
When integrating this classifier into a CI/CD pipeline for prompt version bumps, run it as a pre-merge check on the proposed instruction diff. If the classifier assigns a stage that is incompatible with the target environment (for example, a draft instruction being merged to a production config), block the merge and surface the classification evidence to the PR author. For batch audits across an instruction library, call the classifier once per instruction and aggregate results into a lifecycle inventory report. Avoid batching multiple instructions into a single model call; the classifier performs best with one instruction per request. If you observe stage oscillation—where the same instruction flips between two stages on repeated runs—tighten the temperature further and add a few-shot example in [EXAMPLES] that demonstrates the boundary between those two stages with clear evidence criteria.
Expected Output Contract
Fields, types, and validation rules for the lifecycle stage classification output. Use this contract to build a parser, validator, or eval harness before integrating the prompt into a governance pipeline.
| Field or Element | Type or Format | Required | Validation Rule |
|---|---|---|---|
lifecycle_stage | enum: draft | review | active | deprecated | retired | Must match exactly one of the five allowed enum values. Reject any output with a non-standard stage label or hyphenated variant. | |
stage_confidence | float between 0.0 and 1.0 | Must be a number, not a string. Reject values outside [0.0, 1.0]. If confidence is below 0.6, flag for human review regardless of other field validity. | |
classification_rationale | string (1-3 sentences) | Must be non-empty and contain at least one explicit reference to a stage criterion from the input taxonomy. Reject rationale that is generic or repeats the stage name without evidence. | |
criteria_evidence | array of objects with 'criterion' (string) and 'match' (boolean) | Array must contain at least one entry. Each 'criterion' field must map to a known criterion from the governance taxonomy. Each 'match' must be a strict boolean. Reject arrays where all matches are false without explanation. | |
transition_indicators | array of strings or null | If non-null, each string must describe a specific signal suggesting the instruction is moving toward another stage. Null is allowed only when stage_confidence is above 0.85. Reject vague indicators like 'might change'. | |
boundary_case_flag | boolean | Must be true if the instruction exhibits characteristics of two adjacent stages simultaneously. If true, the criteria_evidence array must contain conflicting matches. If false, no conflicting evidence should be present. | |
recommended_action | enum: no_action | begin_review | accelerate_deprecation | escalate | archive | Must be one of the five allowed actions. Reject if recommended_action contradicts lifecycle_stage (e.g., 'archive' for an 'active' instruction without transition_indicators). | |
human_review_required | boolean | Must be true if stage_confidence is below 0.6, boundary_case_flag is true, or lifecycle_stage is 'deprecated' with no deprecation_date present in the input context. Otherwise may be false. |
Common Failure Modes
The Instruction Lifecycle Stage Classifier is a governance prompt. When it fails, the cost is not just a bad output—it is a wrong lifecycle decision that can propagate across a library. These are the most common failure modes and how to guard against them.
Stage Classification Ambiguity
What to watch: The model waffles between two adjacent stages (e.g., 'Active' vs. 'Deprecated-Scheduled') and produces inconsistent classifications for the same instruction across runs. This happens when stage definitions overlap or when the instruction is genuinely in transition. Guardrail: Add a 'Transition' boundary-case rule in the prompt that forces a single classification with a required transition_evidence field. Use a low-temperature setting (0.0–0.2) and run the classifier twice; flag any mismatch for human review.
Missing Evidence for Stage Criteria
What to watch: The model assigns a lifecycle stage but provides no specific evidence from the instruction text to justify the classification. This produces audit-trail gaps and makes governance decisions unreviewable. Guardrail: Require the output schema to include a criteria_evidence array where each element maps a stage criterion to a direct quote or paraphrase from the input instruction. Add a post-processing check that rejects outputs with empty evidence fields.
Over-Classification as Deprecated
What to watch: The model is too eager to classify instructions as 'Deprecated' or 'Legacy' when they contain older terminology, references to previous model versions, or patterns that look outdated but are still actively used. This causes premature deprecation and unnecessary migration churn. Guardrail: Add a 'Deprecated' gate that requires explicit deprecation markers (e.g., a deprecation notice, a sunset date, or a 'superseded by' reference) before that classification is allowed. If no explicit marker exists, the model must default to 'Active-Under-Review' instead.
Ignoring Instruction Metadata
What to watch: The classifier focuses only on the instruction text body and ignores structured metadata fields such as version, effective_date, deprecation_date, or status that already exist in the instruction record. This produces classifications that contradict known metadata. Guardrail: Include a preprocessing step that extracts and injects metadata fields into the prompt as a separate [INSTRUCTION_METADATA] block with explicit priority: metadata fields that conflict with text-derived classification must be flagged in a metadata_conflict output field rather than silently overridden.
Boundary-Case Collapse in Transitional Instructions
What to watch: Instructions that are mid-migration—partially rolled out, partially rolled back, or active in some agent fleets but not others—cause the classifier to collapse to a single stage that misrepresents the true state. Guardrail: Add a deployment_scope input field that tells the classifier which fleet or environment context to use. If scope is 'all' and deployment is partial, the output must include a partial_deployment_warning flag and a per-fleet stage breakdown rather than a single forced classification.
Confidence Overstatement on Ambiguous Inputs
What to watch: The model returns high confidence scores for classifications on instructions that are genuinely ambiguous, incomplete, or missing key lifecycle signals. This creates a false sense of governance certainty. Guardrail: Require a classification_confidence field (0.0–1.0) in the output schema with explicit calibration rules: confidence must be ≤0.6 if fewer than two stage criteria are met with direct evidence, and ≤0.4 if the instruction text is under 100 tokens. Post-process any high-confidence classification on short or sparse inputs for human review.
Evaluation Rubric
Criteria for evaluating the Instruction Lifecycle Stage Classifier output before integrating it into a governance pipeline or automated workflow.
| Criterion | Pass Standard | Failure Signal | Test Method |
|---|---|---|---|
Stage Classification Validity | Output stage matches exactly one of the predefined lifecycle stages in the taxonomy. | Output contains an unrecognized stage label, multiple conflicting stages, or a stage not in the approved taxonomy. | Assert output stage string is in [ALLOWED_STAGES] list. Run 20 labeled examples and check exact match accuracy >= 95%. |
Evidence Completeness | Every stage classification is accompanied by at least one concrete piece of evidence from the instruction text. | Evidence field is empty, null, or contains only a generic restatement of the stage definition without quoting or referencing the instruction. | Parse output JSON. Assert evidence array length >= 1 for each classification. Check that evidence strings contain substrings present in the input instruction text. |
Boundary-Case Handling | Instructions in transition between stages are classified with the earlier stage and a transition flag set to true. | Transitional instructions are misclassified as fully in the later stage without acknowledging the transition, or transition flag is missing. | Run 5 known transitional examples. Assert transition_flag is true and stage reflects the current-not-target state. Check that transition_evidence field is populated. |
Confidence Scoring Accuracy | Confidence score is a float between 0.0 and 1.0 and correlates with evidence strength and ambiguity level. | Confidence is always 1.0 regardless of ambiguity, or score is outside 0.0-1.0 range, or score is a string. | Parse confidence_score as float. Assert 0.0 <= score <= 1.0. Run ambiguous examples and verify score < 0.85. Run clear examples and verify score >= 0.85. |
Output Schema Compliance | Response is valid JSON matching the expected schema with all required fields present. | Response is missing required fields, contains extra untyped fields, or is not parseable JSON. | Validate against JSON Schema. Assert no missing required fields. Assert no additional properties unless schema permits. Run schema validator in CI on 100 outputs. |
Multi-Stage Rejection | When an instruction matches criteria for multiple stages, the output selects exactly one stage with rationale explaining the tiebreak. | Output returns multiple stage classifications without a primary selection, or primary stage is missing rationale for why it was chosen over alternatives. | Run 5 ambiguous multi-stage examples. Assert single primary_stage field is populated. Assert tiebreak_rationale field is non-empty and references specific evidence. |
Empty or Malformed Input Handling | Returns a structured error object with error_code and message when input is empty, whitespace-only, or not a valid instruction. | Model hallucinates a classification for empty input, crashes, or returns unstructured error text. | Submit empty string, whitespace-only string, and non-instruction text. Assert error_code field exists and is not null. Assert stage field is null or absent. |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Adapt This Prompt
How to adapt
Use the base prompt with a single model call and lightweight output parsing. Replace the strict JSON schema with a looser structured text format if you're iterating quickly. Focus on getting stage labels and one-sentence evidence right before adding confidence scores or boundary-case handling.
Watch for
- Instructions in transition (e.g., deprecated but still active) getting misclassified as a single stage
- Overly broad evidence statements that don't cite specific instruction fields
- Missing boundary-case handling for instructions with conflicting lifecycle signals

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us