Liquid AI d1 Prompts: 70+ AI Decision Model Prompts for Classification, Automation and Edge AI in 2026
Liquid AI d1 Prompts: 70+ AI Decision Model Prompts for Classification, Automation and Edge AI in 2026
Artificial intelligence is evolving beyond chatbots that generate paragraphs of text. One emerging direction is decision AI: models designed to classify information, select from predefined answers, route requests, and make narrow predictions quickly.
On October 7, 2026, Liquid AI announced two open-weight models in its d1 decision-model family: d1-3B and d1-omni-600M. The company describes them as models for text-based decisions and, in the experimental omni model, combinations involving images and audio. The models are available through Liquid AI's release materials and Hugging Face.
This is an interesting development for AI developers, automation builders, startup founders, and prompt engineers.
Imagine an AI system that doesn't need to write a long answer every time someone contacts customer support. It may only need to classify the request as billing, technical_support, or account_access.
Or imagine a system that reviews an incoming message and selects one of a fixed set of actions:
Send it to customer support.
Route it to the sales team.
Flag it for human review.
Mark it as spam.
Ask for missing information.
These tasks are narrower than open-ended conversation, but they are essential building blocks for practical automation.
In this guide, you'll find 70+ AI decision-model prompts and task templates for classification, customer support, e-commerce, moderation, document routing, workflow automation, multimodal inputs, edge AI, and model evaluation.
Important: These are reusable task specifications and development prompts. They are not guaranteed to be directly compatible with every d1 inference interface. Decision models may use structured inputs, fixed answer choices, or model-specific inference formats rather than conventional chatbot prompting. Check the model documentation before implementing them.
1. What Is a Decision Model?
A general-purpose language model can explain a concept, write an article, generate code, or hold a conversation.
A decision model focuses on a more constrained task: given an input, produce a decision from an allowed set of outputs.
For example, a customer-support classifier might receive:
My order arrived damaged, and I would like a replacement.
The expected result could be:
returns_and_replacements
A sentiment classifier might receive:
The product works well, but delivery was late.
Its output could be one of:
positive
neutral
negative
mixed
The key is that the output space is defined in advance.
Liquid AI's d1 release is relevant because it focuses on fast decision-making rather than only conventional text generation. Liquid AI reports that d1-3B achieved a result of 48.57 on its Decision Index v0.2.1 public split, and reports low-latency performance on supported NVIDIA hardware. Those are company-reported benchmark and performance figures, not guarantees for every application or device.
2. Why Decision AI Matters
Many real-world applications do not require a complete essay from an AI system.
They need a reliable result that can trigger the next step in a workflow.
Examples include:
Classifying support tickets
Detecting spam
Routing incoming emails
Assigning product categories
Identifying document types
Prioritizing tasks
Selecting an appropriate workflow
Flagging records for review
Classifying images
Sorting incoming requests
A constrained decision system can be useful when an application needs predictable outputs, low latency, and a clearly defined task.
However, a small or fast model is not automatically more accurate. Its usefulness depends on the task, the input data, the available labels, and the cost of mistakes.
3. The Best Prompt Formula for Decision Models
A good decision-task specification should define the possible outputs and explain how to choose between them.
Use this template when designing a classification or routing system.
TASK:
[Describe the decision the system must make.]
INPUT:
[Describe the input fields.]
ALLOWED LABELS:
- [LABEL_1]
- [LABEL_2]
- [LABEL_3]
- [REVIEW]
DECISION RULES:
[Explain how the labels differ.]
AMBIGUOUS INPUT:
Choose REVIEW when the evidence is insufficient.
OUTPUT:
Return only one allowed label.
IMPORTANT:
Do not invent missing information.
Do not create new labels.
Do not treat uncertain evidence as a confirmed fact.
For systems that support structured output, you can request a machine-readable response instead:
{
"label": "billing",
"needs_review": false
}
This JSON example illustrates the desired output structure; it does not mean every decision model natively generates or validates JSON. Some systems require a separate wrapper or application layer.
4. Customer Support Decision Prompts
Customer service is one of the clearest examples of a task where a constrained decision can save time.
Prompt 1: Support Ticket Classification
Classify each incoming support ticket into exactly one category.
Allowed categories:
- billing
- technical_support
- account_access
- shipping
- returns_and_replacements
- product_information
- complaint
- other
- human_review
Use the customer's actual message.
Choose human_review if the message is ambiguous or contains multiple unrelated requests that cannot be classified confidently.
Return only the category label.
Prompt 2: Urgency Classification
Classify the urgency of each support request.
Allowed outputs:
- low
- normal
- high
- critical
- human_review
Use only the information in the message and the defined escalation rules.
Do not classify a request as critical simply because the customer uses emotional language.
Use human_review when the available information is insufficient to determine urgency.
Return one label only.
Prompt 3: Billing Request Router
Route each incoming billing request.
Allowed outputs:
- invoice_question
- payment_failed
- refund_request
- duplicate_charge
- subscription_change
- payment_method_update
- other
- human_review
Choose the category that best matches the customer's primary request.
If the message contains multiple distinct billing issues, use human_review.
Return only the selected category.
Prompt 4: Technical Support Triage
Classify technical support messages.
Allowed outputs:
- installation
- login_error
- performance
- software_bug
- integration
- data_loss
- security_concern
- other
- human_review
Choose security_concern when the customer reports possible unauthorized access or exposure of sensitive information.
Do not diagnose a technical problem from insufficient evidence.
Return one category label.
Prompt 5: Customer Sentiment
Classify the sentiment of the supplied customer message.
Allowed outputs:
- positive
- neutral
- negative
- mixed
- insufficient_context
Classify the message as mixed when it contains meaningful positive and negative sentiment.
Do not infer a customer's overall attitude from a single isolated word.
Return one label only.
Prompt 6: Refund Eligibility Routing
Review the supplied order information and refund policy.
Allowed outputs:
- eligible_under_policy
- ineligible_under_policy
- missing_information
- human_review
Use only the policy and order data provided.
Do not invent purchase dates, delivery dates, or refund rules.
If eligibility depends on a missing field, select missing_information.
If an exception or policy ambiguity requires judgment, select human_review.
This output is a recommendation for workflow routing, not an automatic authorization to issue a refund.
Prompt 7: Escalation Detection
Determine whether a support conversation needs escalation.
Allowed outputs:
- no_escalation
- specialist_team
- supervisor_review
- security_team
- human_review
Use the escalation policy provided by the organization.
Route credible security incidents to the designated security workflow.
Do not make promises to customers or take account actions.
Return only the routing label.
5. Email and Message Classification Prompts
Prompt 8: Email Intent Detection
Classify the primary intent of an incoming email.
Allowed labels:
- sales_inquiry
- customer_support
- meeting_request
- invoice
- partnership
- job_application
- newsletter
- complaint
- spam
- other
Use the message subject and body when both are available.
Do not classify an email as spam merely because it contains promotional language.
Return one label.
Prompt 9: Lead Qualification Routing
Classify incoming business leads using the supplied qualification rules.
Allowed outputs:
- high_priority
- standard_priority
- nurture
- insufficient_information
- human_review
Use only supplied evidence such as stated needs, business fit, and declared timeline.
Do not infer budget, purchasing authority, or personal characteristics without evidence.
Return the appropriate routing label.
Prompt 10: Meeting Request Detection
Determine the primary intent of an incoming message.
Allowed outputs:
- meeting_request
- information_request
- status_update
- action_required
- no_action_required
- human_review
Choose meeting_request only when the message actually proposes or requests a meeting.
Do not invent a meeting time or accept an invitation.
Return one label.
Prompt 11: Complaint Detection
Classify whether a customer message contains a complaint.
Allowed outputs:
- explicit_complaint
- implied_dissatisfaction
- general_feedback
- no_complaint
- human_review
Use the message context.
Do not treat a neutral question as a complaint.
Return one label only.
Prompt 12: Email Priority
Assign a priority label to each incoming email.
Allowed outputs:
- urgent
- normal
- low
- human_review
Use the organization's documented priority rules, deadlines, and business context.
Do not equate an urgent-sounding subject line with genuine urgency.
Return one label.
6. E-Commerce Decision Prompts
Prompt 13: Product Category Classifier
Assign the supplied product to exactly one category.
Use only this category list:
- electronics
- clothing
- home_and_kitchen
- beauty
- sports
- books
- toys
- food
- other
- human_review
Use the product title and description.
Do not infer technical specifications that are not supplied.
If the product could reasonably fit several categories and the rules do not resolve the ambiguity, choose human_review.
Return one category.
Prompt 14: Product Review Classification
Classify each product review.
Allowed outputs:
- positive
- negative
- mixed
- neutral
- irrelevant
- human_review
Base the decision on the review text.
A review can be mixed if it praises one aspect and criticizes another.
Do not infer product defects from unrelated comments.
Return one label.
Prompt 15: Return Reason Classification
Classify the reason for a product return.
Allowed labels:
- damaged
- wrong_item
- incorrect_size
- not_as_described
- changed_mind
- delivery_issue
- defective
- other
- unclear
Use the customer's stated reason.
Do not assume that an item is defective solely because the customer wants to return it.
Return one label.
Prompt 16: Inventory Alert Classification
Classify the inventory status using the supplied stock quantity and reorder threshold.
Allowed outputs:
- out_of_stock
- below_reorder_threshold
- sufficient_stock
- invalid_or_missing_data
Apply the following rules:
- Quantity equal to zero means out_of_stock.
- A positive quantity below the threshold means below_reorder_threshold.
- A quantity at or above the threshold means sufficient_stock.
- Missing, negative, or invalid values require review.
Return one label.
Prompt 17: Product Question Routing
Classify each customer product question.
Allowed outputs:
- specifications
- compatibility
- availability
- pricing
- warranty
- usage_instructions
- shipping
- other
- human_review
Use the primary question.
Do not answer the question or invent product facts.
Return one routing label.
7. Content and Moderation Decision Prompts
Moderation systems need carefully defined policies, measured error rates, and a route for ambiguous cases.
Prompt 18: Comment Moderation
Classify a comment according to the moderation policy provided.
Allowed outputs:
- allow
- remove_under_policy
- human_review
Apply only the supplied policy.
Do not remove a comment merely because it criticizes a product, person, or organization.
Choose human_review when context is insufficient or the policy is ambiguous.
Return one label.
Prompt 19: Spam Detection
Classify the supplied message for spam risk.
Allowed outputs:
- likely_spam
- likely_legitimate
- uncertain
Use observable signals such as repeated unsolicited promotions, deceptive link patterns, or irrelevant bulk messaging.
Do not classify a message as spam based on a single keyword.
Choose uncertain when evidence is weak.
Return one label.
Prompt 20: Duplicate Content Detection
Compare two supplied text records.
Allowed outputs:
- exact_duplicate
- near_duplicate
- related_but_distinct
- unrelated
- insufficient_text
Use wording and semantic similarity.
Do not label two articles as duplicates merely because they cover the same broad topic.
Return one label.
Prompt 21: Topic Classification
Assign the supplied article to one topic category.
Allowed labels:
- technology
- business
- education
- science
- health
- entertainment
- travel
- lifestyle
- other
- human_review
Choose the category that best represents the article's main subject.
Do not infer a topic solely from the headline if the body is available.
Return one label.
Prompt 22: Sensitive Content Routing
Classify the supplied content according to the organization's published content-handling policy.
Allowed outputs:
- standard_processing
- restricted_processing
- human_review
Do not attempt to identify a person or infer sensitive attributes.
Use restricted_processing only when the supplied policy requires it.
When the policy or content is ambiguous, choose human_review.
Return one label.
8. Document and Data Routing Prompts
Prompt 23: Document Type Detection
Classify the supplied document into one category.
Allowed labels:
- invoice
- receipt
- contract
- report
- resume
- purchase_order
- statement
- correspondence
- other
- human_review
Use document structure and visible content.
Do not infer document type from its filename alone when the contents are available.
Return one label.
Prompt 24: Invoice Exception Detection
Review the supplied invoice fields.
Allowed outputs:
- complete
- missing_required_fields
- inconsistent_values
- duplicate_candidate
- human_review
Check only the validation rules and fields provided.
Do not approve payments.
Do not assume two invoices are duplicates solely because they have the same supplier.
Return one label.
Prompt 25: Record Validation
Classify the supplied record according to these validation rules.
Allowed outputs:
- valid
- missing_fields
- format_error
- inconsistent_data
- human_review
Use the specified schema.
Do not silently correct original data.
If multiple errors exist, select the highest-priority error according to the provided rules.
Return one label.
Prompt 26: Document Destination
Choose where an incoming document should be routed.
Allowed destinations:
- finance
- legal
- human_resources
- operations
- customer_support
- engineering
- general_administration
- human_review
Use the document's purpose and content.
Do not make legal or employment decisions.
If the document contains multiple unrelated matters, choose human_review.
Return one destination.
9. Workflow Automation Decision Prompts
These templates help determine which workflow should run next. Actual actions should be handled by a separate system with appropriate permissions.
Prompt 27: Workflow Selector
Choose the correct workflow for the supplied request.
Available workflows:
- answer_faq
- create_support_ticket
- route_to_sales
- request_missing_information
- escalate_to_human
- no_action
Use the documented workflow rules.
Do not execute the workflow.
Do not invent missing details.
Return only the workflow identifier.
Prompt 28: Task Priority Classification
Classify the supplied task using the priority rules below.
Allowed outputs:
- P1_critical
- P2_high
- P3_normal
- P4_low
- needs_review
Consider the documented impact, deadline, dependencies, and urgency.
Do not assign critical priority based on wording alone.
If essential information is missing, choose needs_review.
Return one label.
Prompt 29: Missing Information Detector
Determine whether a request contains the required information for processing.
Allowed outputs:
- ready_to_process
- missing_required_information
- contradictory_information
- human_review
Use the required-fields checklist provided.
Do not guess missing values.
If the request contains conflicting information, choose contradictory_information.
Return one label.
Prompt 30: Approval Routing
Classify the approval path required for the supplied request.
Allowed outputs:
- standard_approval
- manager_approval
- specialist_approval
- multiple_approvals
- insufficient_information
Apply the supplied approval policy.
Do not approve or reject the request.
Do not infer authority from a person's title unless the policy establishes it.
Return one label.
Prompt 31: Event Routing
Classify the supplied system event.
Allowed outputs:
- informational
- warning
- action_required
- critical_incident
- unknown
Use the documented event definitions and thresholds.
Do not treat a missing metric as proof that the system is healthy.
Return one label.
10. Fast Decision AI for Edge Applications
Edge AI refers to running AI close to where data is created or used—for example, on a local computer, embedded device, or supported edge platform.
Liquid AI describes d1-3B as supporting deployment across NVIDIA hardware, including edge devices. Its published latency numbers are specific to its reported configurations, so real performance should be tested on the intended device.
Prompt 32: Sensor Event Classification
Classify the supplied sensor record using the defined operating rules.
Allowed outputs:
- normal
- warning
- threshold_exceeded
- invalid_reading
- human_review
Use only the supplied sensor values and configured thresholds.
Do not invent readings or diagnose the physical cause of an anomaly.
If values are missing or inconsistent, choose invalid_reading.
Return one label.
Prompt 33: Machine Status Classification
Classify the supplied machine status record.
Allowed outputs:
- operating_normally
- maintenance_attention
- fault_detected
- insufficient_data
Use the documented status codes and thresholds.
Do not issue machine commands.
Do not assume a fault has a particular cause without supporting evidence.
Return one label.
Prompt 34: Image Category Selection
Classify the supplied image into one of the allowed categories.
Allowed outputs:
- product
- document
- vehicle
- animal
- landscape
- food
- other
- uncertain
Use only visible evidence in the image.
Do not infer the identity of a person.
Choose uncertain when the image is unclear or multiple categories are equally plausible.
Return one label.
This template assumes the selected model and inference pipeline support image input. A text-only model cannot perform the image classification without a suitable vision component.
Prompt 35: Audio Event Classification
Classify the supplied audio input into one of the allowed categories.
Allowed outputs:
- speech
- music
- environmental_sound
- silence
- mixed_audio
- uncertain
Use the available audio signal or an approved audio-processing component.
Do not infer the speaker's identity or personal characteristics.
Choose uncertain when the evidence is insufficient.
Return one label.
This is a task specification, not a guarantee that every d1 model accepts raw audio in the same format. Verify supported inputs and preprocessing requirements first.
11. Multimodal Decision Prompts
Some decision tasks combine different kinds of input, such as text and images. Liquid AI's d1-omni-600M is described as an experimental model supporting text and image, as well as text and audio combinations. Its actual capabilities should be checked against the published model documentation.
Prompt 36: Product Image and Description Matching
Compare the supplied product image and product description.
Allowed outputs:
- consistent
- possible_mismatch
- insufficient_visual_evidence
- human_review
Check visible characteristics such as product type and clearly stated features.
Do not infer hidden specifications.
Do not claim that two items are identical based only on visual similarity.
Return one label.
Prompt 37: Document Image Classification
Classify the supplied document image.
Allowed outputs:
- invoice
- receipt
- form
- letter
- report
- other
- unreadable
Use visible layout and text where available.
If the image is too blurry or incomplete, choose unreadable.
Do not invent text that cannot be read.
Return one label.
Prompt 38: Text and Audio Consistency
Compare the supplied text transcript with the available audio-derived transcript.
Allowed outputs:
- consistent
- minor_difference
- major_difference
- insufficient_audio_quality
Compare only the content that can be evaluated from the available inputs.
Do not infer speaker identity.
Do not claim an exact match when the audio quality is insufficient.
Return one label.
Prompt 39: Image Quality Check
Classify the supplied image for quality control.
Allowed outputs:
- acceptable
- blurry
- too_dark
- overexposed
- obstructed
- wrong_orientation
- uncertain
Use the image-quality criteria provided.
Do not judge the person or subject depicted.
If several problems exist, use the documented priority order.
Return one label.
Prompt 40: Multimodal Support Request
Classify the customer request using the supplied text and supported attachments.
Allowed outputs:
- billing
- technical_support
- damaged_product
- delivery_issue
- account_access
- other
- human_review
Use attachments only if the processing pipeline has actually made their contents available.
Do not assume an attachment was successfully analyzed.
Choose human_review when the text and attachment materially conflict.
Return one label.
12. Prompt Templates for Model Developers
These prompts are designed for planning and implementing a decision system around a model. They do not assume that the model itself accepts a natural-language system prompt.
Prompt 41: Define the Label Set
Help design a classification task for:
[INSERT USE CASE]
Propose a compact label set.
For every label, provide:
- Name
- Definition
- Inclusion criteria
- Exclusion criteria
- Example input
- Borderline example
Add an uncertain or human-review label when necessary.
Identify labels that overlap and explain how to resolve conflicts.
Do not begin implementation until the label definitions are sufficiently clear.
Prompt 42: Create a Classification Dataset
Design a dataset specification for this classification task:
[INSERT TASK]
Define:
- Input schema
- Target label
- Label definitions
- Data collection requirements
- Annotation instructions
- Quality checks
- Train, validation, and test split strategy
Avoid leaking near-duplicate records across splits.
Include a plan for measuring class imbalance.
Use synthetic examples only for development unless real data is available and appropriately authorized.
Do not claim synthetic examples establish real-world accuracy.
Prompt 43: Build an Evaluation Plan
Create an evaluation plan for this decision model.
Task:
[INSERT TASK]
Define:
- Intended use
- Allowed outputs
- Test dataset requirements
- Accuracy metrics
- Per-class performance
- Confusion matrix
- Latency measurement
- Failure costs
- Human-review criteria
Explain which errors matter most.
Do not rely on aggregate accuracy alone.
Specify how results should be reported and how often the model should be reevaluated.
Prompt 44: Compare Two Decision Models
Compare these two candidate models for a defined decision task:
[MODEL A]
[MODEL B]
Evaluate them using the same test cases and hardware conditions.
Compare:
- Task accuracy
- Per-class recall
- False-positive rate
- False-negative rate
- Latency
- Memory requirements
- Deployment complexity
- Licensing and operational constraints
Separate measured results from vendor claims.
Do not declare a winner without considering the cost of errors and the intended workload.
Prompt 45: Design a Human-Review Policy
Design a human-review policy for this classification workflow.
[INSERT WORKFLOW]
Specify:
- Which cases can be processed automatically
- Which cases require review
- What confidence evidence is available
- What to do when confidence is unavailable
- How reviewers correct mistakes
- How decisions are audited
- How disagreements are resolved
Do not invent a confidence score if the model does not provide one.
Prioritize human review when an incorrect decision could cause substantial harm.
13. Advanced Decision AI Prompts
Prompt 46: Multi-Stage Classification
Design a multi-stage classification workflow for:
[INSERT TASK]
Stage 1: Detect whether the input belongs to the task.
Stage 2: Assign a broad category.
Stage 3: Select a more specific label when needed.
Stage 4: Route uncertain or high-impact cases for review.
Minimize unnecessary complexity.
Define how errors in an earlier stage affect later stages.
Recommend evaluation metrics for the complete pipeline, not just individual stages.
Prompt 47: Cost-Sensitive Classification
Design a cost-sensitive decision policy for this task:
[INSERT TASK]
Describe the consequences of each type of error.
Identify which errors are most costly.
Recommend decision thresholds or review rules using the supplied evidence.
Do not assume all mistakes have equal consequences.
Explain when human review is preferable to automatic classification.
Do not deploy the policy until its performance has been validated on representative data.
Prompt 48: Unknown Category Handling
Design a strategy for inputs that do not fit the known categories.
Known categories:
[INSERT LABELS]
Define when to:
- Assign a known label
- Use an unknown label
- Request additional information
- Escalate to a human
Include examples of out-of-distribution inputs.
Do not force every input into a known category when the evidence does not support it.
Prompt 49: Model Drift Monitoring
Create a monitoring plan for a production decision model.
Track:
- Input distribution changes
- Label distribution changes
- Performance on labeled samples
- Error rates
- Human-review frequency
- Latency
- Changes in downstream outcomes
Define alert thresholds using the system's requirements.
Distinguish data drift from confirmed model-performance degradation.
Specify what action to take when monitoring indicates a problem.
Prompt 50: Decision Pipeline Architecture
Design a decision pipeline for:
[INSERT APPLICATION]
Include:
- Input validation
- Data preprocessing
- Model inference
- Output validation
- Human-review path
- Logging
- Monitoring
- Error handling
- Recovery behavior
Specify which components must be deterministic.
Do not allow model output alone to authorize sensitive or irreversible actions.
Include a test plan for each component.
14. Practical Decision AI Projects
The following project ideas can help developers experiment with fixed-label AI systems.
Prompt 51: Local Email Sorter
Design a local email classification system.
Categories:
- personal
- work
- invoices
- newsletters
- support
- spam_candidate
- review
Use a locally available model where feasible.
Describe the preprocessing, classification, and output schema.
Keep email content on the local device when the deployment supports that requirement.
Do not delete or send emails automatically.
Include a way for users to correct incorrect classifications.
Prompt 52: Smart Download Organizer
Design a file-routing assistant that classifies documents into folders.
Possible categories:
- work
- finance
- education
- images
- receipts
- projects
- personal
- unknown
Use filenames and document content only when permitted.
Do not overwrite or delete original files.
Send uncertain files to an unclassified folder.
Create a reversible organization plan before applying changes.
Prompt 53: Support Inbox Router
Design a support inbox routing system.
Classify incoming tickets by:
- Topic
- Urgency
- Required team
- Need for human review
Use a fixed label set.
Log the classification and the version of the routing rules.
Do not send customer messages or modify accounts without a separate authorized workflow.
Measure misrouting rates using reviewed tickets.
Prompt 54: Product Catalog Cleaner
Design a product catalog quality-control pipeline.
Detect:
- Missing titles
- Missing categories
- Invalid prices
- Duplicate candidates
- Inconsistent units
- Unsupported claims
- Missing required attributes
Assign a fixed issue label to each record.
Do not automatically overwrite source data.
Provide a correction suggestion and require review for ambiguous records.
Prompt 55: Task Management Assistant
Design a task classification system.
Allowed outputs:
- do_now
- schedule
- delegate
- waiting
- archive_candidate
- human_review
Use the user's documented prioritization rules.
Do not assume a task is unimportant simply because its deadline is distant.
Do not delete or delegate tasks automatically.
Return the suggested label and the rule that triggered it, where supported.
15. More Decision AI Use Cases
Prompt 56: Fraud-Risk Triage
Design a triage classifier for reviewing potentially suspicious transactions.
Allowed outputs:
- routine_review
- elevated_review
- urgent_review
- insufficient_data
Use only the documented risk signals and validated rules.
Do not treat the model output as proof of fraud.
Do not automatically freeze accounts or reject transactions.
Include human review, auditability, and a process for correcting false positives.
Prompt 57: Research Paper Routing
Classify research papers into the supplied subject categories.
Use:
- Title
- Abstract
- Keywords
- Relevant metadata
Assign one primary category and an uncertain label when needed.
Do not infer results that are not stated in the paper.
Create a separate human-review route for papers that span several categories.
Prompt 58: Customer Feedback Theme Detection
Classify customer feedback into one primary theme.
Allowed themes:
- product_quality
- pricing
- usability
- customer_service
- delivery
- feature_request
- reliability
- other
- uncertain
Use the feedback text.
Do not infer demographic attributes.
Allow mixed feedback to be routed for multi-label analysis if the application supports it.
Return one primary label for this task.
Prompt 59: Form Completeness Check
Check whether the supplied form contains the required fields.
Allowed outputs:
- complete
- missing_fields
- conflicting_fields
- unreadable
- human_review
Use the supplied form schema.
Do not infer missing values.
List the missing field names only if the output schema permits them.
Do not submit the form automatically.
Prompt 60: Alert Deduplication
Compare incoming alerts with the supplied recent alert records.
Allowed outputs:
- new_alert
- likely_duplicate
- related_alert
- insufficient_information
Use event identifiers, timestamps, affected components, and descriptions where available.
Do not merge records automatically.
If two alerts appear similar but may represent different incidents, choose related_alert.
Prompt 61: Customer Intent for a Chatbot
Classify the user's message before passing it to a conversational assistant.
Allowed outputs:
- greeting
- factual_question
- troubleshooting
- account_request
- transaction_request
- complaint
- unsafe_or_disallowed
- unclear
Do not answer the user.
Do not execute an account or transaction action.
Route unclear messages to a clarification step.
Prompt 62: Meeting Action Item Detector
Classify each sentence from the supplied meeting notes.
Allowed outputs:
- decision
- action_item
- open_question
- status_update
- general_discussion
- unclear
Use the actual wording and context.
Do not invent an owner or deadline.
If a sentence contains both a decision and an action, use the documented priority rule.
Prompt 63: News Topic Router
Classify incoming news articles into the supplied editorial categories.
Allowed outputs:
- artificial_intelligence
- business
- science
- cybersecurity
- consumer_technology
- policy
- other
- editorial_review
Use the article body and headline.
Do not infer that an event happened merely because it is mentioned speculatively.
Route ambiguous or multi-topic articles for editorial review.
Prompt 64: Image Content Quality Gate
Classify whether a supplied image meets the specified publication requirements.
Allowed outputs:
- acceptable
- resolution_too_low
- aspect_ratio_mismatch
- visible_watermark
- content_mismatch
- uncertain
Apply the explicit requirements provided.
Do not infer copyright ownership from appearance alone.
Do not reject an image based on irrelevant personal characteristics.
Return one label.
Prompt 65: Workflow Failure Classification
Classify the supplied automation failure.
Allowed outputs:
- invalid_input
- authentication_error
- timeout
- external_service_error
- permission_error
- logic_error
- unknown
Use the actual error message and available logs.
Do not expose credentials or sensitive tokens.
Do not retry destructive operations automatically.
Return one label.
16. Five Bonus Prompts for Decision AI Testing
Prompt 66: Boundary Case Generator
Generate a test set for this classification task:
[INSERT TASK AND LABELS]
Include:
- Clear examples for each label
- Borderline examples
- Inputs with multiple possible labels
- Missing information
- Contradictory information
- Irrelevant inputs
- Adversarial wording
- Out-of-scope inputs
Provide the expected label and a short explanation for every example.
Do not make the test set artificially easy.
Keep the evaluation set separate from examples used to tune the model.
Prompt 67: Confusion Matrix Analysis
Analyze the confusion matrix from this decision model.
Identify:
- Most common errors
- Labels that are frequently confused
- False-positive patterns
- False-negative patterns
- Classes with insufficient test examples
Explain which errors matter most for the intended use.
Recommend targeted improvements to the labels, data, or workflow.
Do not claim the model improved unless new evaluation results demonstrate it.
Prompt 68: Latency Benchmark Plan
Create a reproducible latency benchmark for a decision model.
Record:
- Hardware
- Model version
- Runtime
- Input length
- Batch size
- Warm-up procedure
- Number of trials
- Median latency
- High-percentile latency
- Throughput
- Memory usage
Separate model inference time from preprocessing and application overhead.
Use identical test conditions when comparing models.
Do not treat one unusually fast run as representative performance.
Prompt 69: Error Cost Analysis
Create an error-cost analysis for this decision task.
[INSERT TASK]
For each type of classification error, describe:
- Possible consequence
- Severity
- Reversibility
- Detection method
- Human-review requirement
- Mitigation
Use the organization's actual risk assumptions.
Do not invent monetary losses.
Recommend where automation is appropriate and where human approval is necessary.
Prompt 70: Production Readiness Checklist
Evaluate whether this decision-model application is ready for production.
Review:
- Task definition
- Label quality
- Representative evaluation data
- Per-class performance
- Latency
- Resource use
- Input validation
- Output validation
- Security
- Privacy
- Logging
- Human review
- Rollback
- Monitoring
- Model updates
Mark each item as:
- verified
- incomplete
- not applicable
- unknown
Do not mark a capability as verified without evidence.
Finish with the blockers that must be resolved before deployment.
17. How to Get Better Results From Decision Models
Decision AI works best when the task is well defined. Here are six principles worth remembering.
1. Keep the label set clear
Avoid overlapping categories.
For example, if urgent and high_priority mean the same thing, the model has no clear basis for choosing between them.
Define each category with inclusion and exclusion rules.
2. Include an uncertain option
Real-world inputs are messy. A system that must always choose a known label can confidently produce the wrong answer.
Use an option such as uncertain, unknown, or human_review when appropriate.
3. Evaluate individual categories
A model might perform well overall but fail on a less frequent category.
Measure precision, recall, and the confusion matrix for each important label.
4. Separate decisions from actions
A classification model might recommend refund_review, but a separate, authorized workflow should determine whether a refund can be issued.
For consequential actions, use validation, permission checks, logging, and human approval where needed.
5. Test the real deployment environment
Performance depends on hardware, model version, input processing, batch size, and runtime.
Test the complete pipeline instead of relying only on a vendor benchmark.
6. Reevaluate after changes
New input patterns, changing product catalogs, revised policies, or model updates can affect performance.
Maintain a representative test set and repeat evaluations after meaningful changes.
18. Decision Models vs. General-Purpose AI
| Feature | Decision model | General-purpose language model |
|---|---|---|
| Typical output | Fixed label or choice | Free-form text or structured output |
| Common tasks | Classification, routing, narrow predictions | Writing, analysis, conversation, coding |
| Output constraints | Usually predefined | Can be flexible |
| Best starting point | A clearly defined decision | A task requiring broader reasoning or generation |
| Main evaluation need | Task-specific error rates and latency | Task-specific quality, reliability, and safety |
| Common limitation | May not handle open-ended tasks well | Can be unnecessarily complex for narrow tasks |
Neither approach is universally better.
A decision model can be useful for a narrow, repeatable task. A general-purpose model may be more appropriate when a request requires explanation, nuanced reasoning, or generating new content.
Many practical systems can combine both: a decision model routes the input, and a larger model handles the requests that need deeper analysis.
19. Frequently Asked Questions
What are Liquid AI d1 prompts?
They are task specifications and development templates for decision-oriented AI applications inspired by Liquid AI's d1 model family. They help define labels, routing rules, output constraints, and evaluation requirements.
What is Liquid AI d1?
Liquid AI introduced d1-3B and d1-omni-600M on October 7, 2026. The company describes them as open-weight decision models, with d1-omni-600M being an experimental multimodal model.
Are d1 models the same as chatbots?
Not exactly. The d1 family is presented as focused on decision tasks rather than conventional open-ended text generation. The appropriate model depends on the type of application and its output requirements.
Can decision models classify emails?
Email classification is a suitable example of a constrained decision task. Whether a particular model performs well depends on the email categories, training or evaluation data, inference setup, and deployment requirements.
Can decision models run locally?
Liquid AI states that its d1 models support local deployment options, with d1-3B designed for a range of supported hardware. Check the official model instructions for the requirements of your intended device.
Are decision models always faster?
No. Performance depends on the model, runtime, hardware, input format, and workload. Benchmark the full application before selecting a model.
Can I use these prompts with other AI models?
Yes. The task definitions can be adapted for other models and classification systems. Some models may require natural-language instructions, while others use structured schemas, classifier heads, or constrained decoding.
Can decision models make business decisions automatically?
They can help classify and route information, but the system should not treat a prediction as unrestricted authorization. Financial transactions, account changes, security actions, and other consequential decisions need appropriate rules, controls, and review.
What is the best way to start?
Choose one narrow problem, define a small label set, collect representative examples, and measure performance. Start with a reversible workflow such as sorting support requests before considering more consequential automation.
Conclusion
Liquid AI's d1 models highlight an important direction in AI: not every useful AI application needs to generate a long response.
Many applications need a quick, constrained decision that can move a workflow forward.
That makes decision-model design relevant to customer support, email sorting, e-commerce, content moderation, document processing, edge applications, and business automation.
The prompts in this guide provide starting points for defining those tasks. Their effectiveness will depend on clear label definitions, appropriate model selection, representative test data, and careful validation.
The central lesson is simple:
Define the decision before choosing the model.
When you know exactly what the system must decide, which outputs are allowed, how mistakes will be measured, and when a human should intervene, you have a much stronger foundation for building useful AI automation.
Comments
Post a Comment