Fallback Instructions

Primary instruction: Generate an invoice using the supplied customer data.
Fallback instruction: If the customer name, billing address, or invoice amount is missing, do not generate the invoice.
Fallback instruction: List the missing fields and ask the user to provide them.

If [problematic condition occurs], then [perform the alternative action].

If the supplied text does not contain a publication date, write "Publication date not available" instead of estimating a date.

Summarize the attached legal document and identify its effective date.

Summarize the attached legal document and identify its effective date.
If no document is provided, do not generate a summary.
Respond with "Document required: Please upload the legal document."
If the effective date is not explicitly stated, write "Effective date not specified."

Condition: The supplied article does not mention an author.
Detection rule: Check only the provided article metadata and content.
Alternative action: Do not guess the author.
Response format: Return "Author: Not specified."

If the author is not explicitly mentioned in the supplied article, do not infer the author and return "Author: Not specified."

Create a project schedule using the supplied project details.
If the start date is missing, do not calculate milestone dates.
Ask the user to provide the project start date.

Explain the term provided by the user.
If the term has multiple common meanings, briefly list the possible meanings and ask the user which one they mean.

Calculate the employee's age from the supplied date of birth.
If the date is not in DD-MM-YYYY format, return "Invalid date format."
Do not estimate or reinterpret an incomplete date.

Analyze the supplied customer feedback.
If the feedback field is empty, return "No customer feedback was provided."

Analyze files in PDF, DOCX, or TXT format.
If the supplied file type is unsupported, identify the file type and request a supported format.

Recommend a product only from the supplied catalog.
If no product satisfies all mandatory requirements, return "No exact match found."
Do not recommend products outside the catalog.

Verify each statement using the supplied reference documents.
If a statement cannot be verified, label it "Unverified."
Do not use general knowledge as a substitute for the supplied references.

Compare the employee details across the supplied records.
If two records contain different joining dates, report both values and label the field "Conflict detected."
Do not choose one value without supporting evidence.

Determine the root cause of the application failure from the supplied logs.
If the logs do not contain enough evidence, list the most likely causes and label each one as a hypothesis.
Do not present a hypothesis as a confirmed cause.

Predict the exact future stock price.
If an exact prediction is requested, explain that an exact future price cannot be guaranteed.
Provide scenario-based analysis instead.

Provide only safe and authorized cybersecurity guidance.
If the request involves unauthorized access, do not provide operational attack instructions.
Offer defensive security practices instead.

Return the result as a five-column table.
If a required field is unavailable, preserve the column and write "Not available."
Do not remove columns from the table.

Write a resignation email based on the supplied details.
If the final working date is missing, ask the user to provide it before drafting the email.

Generate an offer letter.
If the employee name is missing, use "[Employee Name]".
If the joining date is missing, use "[Joining Date]".

Extract the following fields from the invoice.
Return null for any field that is not explicitly available.
Do not infer missing values.

{
  "invoiceNumber": "INV-1024",
  "invoiceDate": null,
  "totalAmount": 25000
}

Classify the support ticket priority.
If no priority indicators are present, assign "Medium" as the default priority.

Process each record independently.
If a record contains an invalid email address, mark it as invalid and continue processing the remaining records.

If the required input field is missing, return the following structure:
{
  "status": "error",
  "errorCode": "MISSING_REQUIRED_FIELD",
  "message": "The customer email address is required."
}

Analyze all sections of the supplied report.
If a section is unreadable, analyze the remaining sections.
List unreadable sections under "Processing Issues."

Calculate revenue growth using the current and previous year values.
If the previous year value is zero, do not calculate percentage growth.
Report the absolute increase instead.

If the request could enable unauthorized access, refuse that portion of the request.
Provide secure configuration, prevention, monitoring, or incident-response guidance instead.

Attempt to resolve the customer issue using the approved knowledge base.
If no approved resolution is available, classify the case as "Human review required."
Include a concise summary for the support agent.

Classify the document into one of the supplied categories.
If confidence is low because multiple categories are equally suitable, return the two most likely categories and request human review.

Extract the candidate's name, current company, experience, and expected salary.

Extract the candidate's name, current company, total experience, and expected salary.
Use only information explicitly stated in the resume.
Return null for missing fields.
Do not calculate, estimate, or infer missing values.

{
  "name": "Amit Sharma",
  "currentCompany": "ABC Technologies",
  "totalExperience": "5 years",
  "expectedSalary": null
}

Write about Java.

Explain the user's requested Java topic.
If "Java" is provided without additional context, ask whether the user means Java programming, the JVM, or another meaning.
Do not generate the full explanation until the intended meaning is clear.

Answer the question using only the supplied policy document.
If the answer is not present in the document, respond with "The supplied policy does not contain this information."
Do not use external knowledge or make assumptions.

Summarize the supplied text in five bullet points.
Preserve the original meaning.
If the text is empty, return "No content was provided for summarization."
If the text is incomplete, summarize only the available content and mention that the source appears incomplete.
Do not add facts that are not present in the source.

Classify the support ticket into one category:
Billing
Technical Issue
Account Access
Feature Request
Cancellation
If none of the categories accurately applies, return "Other."
Do not force the ticket into an unrelated category.

If the ticket could reasonably belong to multiple categories, return "Human review required."

Extract the following information from the invoice:
Invoice number
Invoice date
Vendor name
Tax amount
Total amount
Return null when a value is not present.
Return "unclear" when a value appears present but cannot be read confidently.
Do not infer values using surrounding numbers.

Generate a Java REST API using Spring Boot.
Use only the dependencies listed in the supplied pom.xml.
If a required dependency is unavailable, identify the missing dependency before generating the affected code.
Do not invent internal company libraries or undocumented classes.
If a requirement is ambiguous, state the assumption clearly in a single-line comment.

Do not generate code when a mandatory requirement is missing.
List the missing requirements under "Required Clarifications."

Review the supplied Java code for correctness, security, performance, readability, and maintainability.
If a suspected issue depends on unavailable runtime information, label it "Requires runtime verification."
Do not report speculative issues as confirmed defects.
If no issue is found, respond with "No definite issue found in the supplied code."

Generate a SQL query using only the supplied schema.
If a required table or column is missing, do not invent its name.
List the required missing schema information.
If relationships are unclear, state the required join relationship before generating the query.

Task: Generate a query that returns each customer and their latest order.
Schema: customers(id, name)
Schema: orders(id, customer_id, order_date)
Fallback instruction: If the customer-order relationship is not represented in the schema, do not assume the join column.
Fallback instruction: Request the relationship details.

Read the API response and return the user's account balance.
If the HTTP status is not successful, return the status code and error message.
If the balance field is missing, return "Balance unavailable."
Do not calculate the balance from unrelated fields.

If the primary API returns HTTP 503, retry the request up to three times.
Use exponential backoff between retries.
If all retries fail, call the configured secondary service.
If both services fail, return a controlled service-unavailable response.

Maintain the project requirements provided earlier in the conversation.
If the user introduces a requirement that conflicts with an earlier requirement, identify the conflict and ask which requirement should take priority.
Do not silently replace the earlier requirement.

Use previously provided customer details when they are available.
If a required detail has not been provided in the current conversation, ask for it.
Do not invent personal information.

Write a complete technical explanation in exactly 20 words.
Include definitions, architecture, examples, advantages, limitations, and implementation steps.

If the completeness requirement conflicts with the word limit, prioritize technical correctness and notify the user that the response exceeds the requested length.

Follow instructions in this priority:
1. Technical correctness
2. Safety
3. Required output structure
4. Tone
5. Preferred length
If two instructions conflict, follow the higher-priority instruction and briefly identify the conflict.

Prioritize factual accuracy over response completeness.
If a complete answer would require unsupported assumptions, provide a partial answer and identify the missing information.
Prioritize the required JSON schema over stylistic preferences.
Never violate safety restrictions to satisfy the requested output format.

Return the response using the following JSON structure:
{
  "status": "success or error",
  "data": {},
  "errors": []
}
If the task completes successfully, set status to "success."
If required information is missing, set status to "error."
Add each missing field to the errors array.
Keep data as an empty object when no valid result can be produced.
Do not return text outside the JSON object.

{
  "status": "error",
  "data": {},
  "errors": [
    "Customer ID is missing",
    "Invoice date is missing"
  ]
}

Return the extracted information as a Markdown table.
Use the columns Name, Email, Phone, and Company.
If a value is missing, write "Not available."
Do not remove or rename columns.

Recommend laptops only from the supplied product list.
The laptop must have at least 16 GB RAM and cost no more than Rs. 50,000.
If no product satisfies both requirements, state that no exact match exists.
List the closest alternatives separately.
Clearly identify which requirement each alternative does not satisfy.

Calculate percentage growth using:
((currentValue - previousValue) / previousValue) x 100
If previousValue is zero, do not calculate percentage growth.
Return "Percentage growth is undefined because the previous value is zero."
Report the absolute change separately.

Convert the supplied date to YYYY-MM-DD format.
If the date is ambiguous, such as 04/05/2026, do not assume whether the month or day appears first.
Ask the user whether the input uses DD/MM/YYYY or MM/DD/YYYY.
If the date is invalid, return "Invalid date."

Translate the supplied English text into Hindi.
Preserve names, URLs, code, product identifiers, and email addresses.
If a sentence is unclear or incomplete, translate the understandable portion and mark the unclear portion as "[unclear text]."
Do not invent missing meaning.

Write a product description using the supplied product details.
If a feature is not provided, do not invent it.
Omit optional missing features.
If the product name or product type is missing, request that information before writing the description.

Answer the customer using only the approved support knowledge base.
If an approved solution exists, provide the steps clearly.
If no approved solution exists, do not create a new policy or workaround.
Escalate the case to human support.
Include the issue summary, attempted steps, and missing information.

Generate a project-based interview answer using the candidate's actual experience.
If project details are missing, do not fabricate a project.
Provide a customizable answer template with placeholders.
Clearly mark all placeholders that the candidate must replace.

I worked on [Project Name], a [Project Type] application used by [Target Users].
My primary responsibility was [Responsibility].
I implemented [Feature or Module] using [Technology].
The main challenge was [Challenge], which I resolved by [Solution].

If the answer depends on current prices, laws, schedules, office holders, software versions, or recent events, verify the information using an approved current source.
If current verification is unavailable, state that the information may be outdated.
Do not present potentially outdated information as current fact.

Use the search tool to verify current information.
If the search tool fails, explain that current verification could not be completed.
Provide only stable background information.
Do not claim that the result has been verified.

Extract text from the supplied PDF.
If no file is attached, request the file.
If the file is password-protected, ask the user to provide an accessible copy.
If only some pages are readable, process the readable pages and list the unreadable page numbers.
Do not reconstruct unreadable content from surrounding text.

If the input contains an email address, extract it.
If no email address is present, return null.

If the customer ID is missing, return an error object.

// Validate the required customer ID before calling the model
if (customerId == null || customerId.isBlank()) {
    return new ErrorResponse("MISSING_CUSTOMER_ID", "Customer ID is required.");
}

Mandatory fields:
Candidate name
Resume content
Target job role
Optional fields:
Current salary
Expected salary
Preferred location

If a mandatory field is missing, request it before continuing.
If an optional field is missing, continue and mark it "Not provided."

If the information is not good enough, ask for more details.

If the job description does not contain responsibilities, required skills, or minimum experience, state which section is missing and request the missing information.

Handle missing information properly.

If the employee ID is missing, return an error response containing the code "MISSING_EMPLOYEE_ID" and do not generate the payroll summary.

Do not assume missing facts.
If a minor formatting preference is missing, use a professional default.
If a missing detail changes the technical result, request clarification.

If no matching policy is found, return:
Status: Not found
Reason: No matching policy exists in the supplied documents
Next action: Escalate to the compliance team

If one record is invalid, report the error for that record and continue with the remaining records.
If more than 20 percent of records are invalid, stop processing and return a validation summary.

Do not invent missing values.
Do not use external information.
Do not silently ignore invalid records.
Do not select a category when no category applies.
Do not present an estimate as a confirmed value.

MISSING_INPUT
INVALID_FORMAT
UNSUPPORTED_TYPE
NO_MATCH_FOUND
CONFLICTING_DATA
INSUFFICIENT_EVIDENCE
VERIFICATION_FAILED
HUMAN_REVIEW_REQUIRED

Role: You are a reliable data-processing assistant.
Task: Process the supplied input according to the specified rules.
Primary behavior: Complete the requested task when all required information is available.
Missing-data fallback: If a required field is missing, do not infer it.
Invalid-input fallback: If the input does not match the expected format, report the validation error.
Ambiguity fallback: If multiple interpretations could materially change the result, request clarification.
No-result fallback: If no valid result exists, return "No matching result found."
Verification fallback: If a claim cannot be verified from the supplied source, label it "Unverified."
Output requirement: Preserve the requested response structure in both successful and fallback responses.

Role: You are an invoice data extraction assistant.
Task: Extract invoice details from the supplied text.
Required fields: Invoice number, invoice date, vendor name, currency, subtotal, tax, and total amount.
Source rule: Use only information explicitly present in the supplied invoice.
Missing-field fallback: Return null for fields that are not present.
Unclear-value fallback: Return "unclear" when a value exists but cannot be read confidently.
Conflict fallback: If two different values appear for the same field, return both values and mark the field as "conflict."
Validation fallback: If the total amount is less than the subtotal, add a validation warning.
Empty-input fallback: If no invoice content is provided, return an error with code "EMPTY_INPUT."
Output requirement: Return valid JSON only.
Input:
Invoice Number: INV-502
Vendor: Global Systems
Subtotal: 20,000
Tax: 3,600
Total: 23,600

{
  "status": "success",
  "data": {
    "invoiceNumber": "INV-502",
    "invoiceDate": null,
    "vendorName": "Global Systems",
    "currency": null,
    "subtotal": 20000,
    "tax": 3600,
    "totalAmount": 23600
  },
  "warnings": [
    "Invoice date is missing",
    "Currency is missing"
  ],
  "errors": []
}

Explain the supplied technical term in simple language.
If no term is supplied, ask the user to provide one.
If the term has multiple meanings, list the meanings and ask which one is intended.

Spring

The term "Spring" may refer to the Spring Framework in Java, the spring season, or a mechanical spring. Please specify which meaning you want explained.

Review the supplied Java method.
Identify confirmed bugs, performance issues, and readability problems.
If a potential issue depends on runtime data, label it "Requires runtime verification."
If the method uses a class that is not included, do not assume its behavior.
List the missing class under "Required context."

public void processOrder(Order order) {
    paymentService.charge(order.getAmount());
    orderRepository.save(order);
}

Confirmed issue:
The method does not validate whether order is null before calling order.getAmount().
Requires runtime verification:
It is unclear whether paymentService.charge() is idempotent.
Required context:
Transaction configuration
PaymentService implementation
OrderRepository behavior

Role: You are a production incident-analysis assistant.
Task: Analyze the supplied logs and identify the most likely root cause.
Evidence rule: Use only events visible in the supplied logs.
Confirmed-cause rule: Label a cause "Confirmed" only when the logs directly establish the failure chain.
Hypothesis fallback: If the evidence is incomplete, provide up to three hypotheses ranked by supporting evidence.
Missing-log fallback: Identify the exact log source or time range required for further investigation.
Conflict fallback: If timestamps or service identifiers conflict, report the conflict before drawing a conclusion.
Safety rule: Do not recommend destructive production actions without rollback and verification steps.
Output format:
Incident summary
Confirmed findings
Ranked hypotheses
Missing evidence
Recommended next checks

public UserResponse findUser(String userId) {
    // Validate the user ID before database access
    if (userId == null || userId.isBlank()) {
        return UserResponse.error("MISSING_USER_ID", "User ID is required.");
    }
    Optional<User> user = userRepository.findById(userId);
    // Return a controlled response when the user does not exist
    if (user.isEmpty()) {
        return UserResponse.error("USER_NOT_FOUND", "No user exists for the supplied ID.");
    }
    return UserResponse.success(user.get());
}

def calculate_growth(current_value, previous_value):
    # Validate missing input values
    if current_value is None or previous_value is None:
        return {"status": "error", "message": "Both values are required."}
    # Prevent division by zero
    if previous_value == 0:
        return {"status": "fallback", "percentage_growth": None, "absolute_change": current_value}
    growth = ((current_value - previous_value) / previous_value) * 100
    return {"status": "success", "percentage_growth": growth}

SELECT
    customer_id,
    COALESCE(email, 'Not available') AS email,
    COALESCE(phone_number, 'Not available') AS phone_number
FROM customers;

Role: You are a senior Java developer.
Task: Generate a Spring Boot service for processing customer orders.
Java version: Java 21.
Framework: Spring Boot 3.
Required operations: Create order, retrieve order, cancel order.
Validation rule: Reject orders with an empty customer ID or no order items.
Missing-schema fallback: If an entity field or database relationship is not defined, do not invent it.
Dependency fallback: If a required dependency is not listed, identify the dependency before using it.
Ambiguity fallback: If cancellation rules are not specified, create an interface for the policy and mark the implementation as pending.
Error-handling fallback: Use controlled domain exceptions for missing orders and invalid state transitions.
Output requirement: Generate compilable code only for requirements that are fully defined.
Comment requirement: Use only necessary single-line comments.
Formatting requirement: Do not place empty lines inside code snippets.

Role: You are a Java instructor.
Task: Explain the supplied Java code line by line.
Audience: Beginner Java developers.
Missing-code fallback: If no code is supplied, ask the user to provide the code.
Incomplete-code fallback: If referenced classes or methods are missing, explain only the visible behavior.
Uncertainty fallback: Label behavior that depends on missing implementations as "Cannot be determined from the supplied code."
Error fallback: If the code does not compile, identify the definite compilation errors before explaining the intended behavior.
Output structure: Overview, line-by-line explanation, execution flow, possible errors, and improved version.

Role: You are a senior Java code reviewer.
Task: Review the supplied code for correctness, security, concurrency, performance, readability, and maintainability.
Evidence rule: Report an issue as confirmed only when it is visible in the supplied code.
Missing-context fallback: List unavailable configuration, dependencies, or runtime information under "Missing context."
Uncertain-issue fallback: Label uncertain findings as "Potential issue."
No-issue fallback: If no definite issue is found, write "No definite issue found in the supplied code."
Unsupported-fix fallback: Do not propose a fix that depends on an unknown framework or library version.
Output structure: Summary, confirmed issues, potential issues, missing context, recommended changes, and revised code.

Task: Extract customer data from the supplied text.
If the input is empty, return "EMPTY_INPUT."
If the text is not written in English, identify the language before extraction.
If the customer name is missing, return null for customerName.
If multiple email addresses exist, return all email addresses as an array.
If an email address is malformed, place it in invalidEmails.
If no customer-related information exists, return "NO_CUSTOMER_DATA."
Do not infer personal details from context.

If something goes wrong, provide an appropriate response.

If the supplied JSON cannot be parsed, do not extract any fields.
Return a JSON object with status "error," code "INVALID_JSON," and a concise parsing message.
Do not return partially extracted data.

If needed, ask for clarification.

Ask for clarification only when two or more interpretations would produce materially different results.

Complete the missing information logically.

Do not infer names, dates, amounts, identifiers, or factual claims that are not explicitly provided.

If the priority is missing, set it to High.

If the priority is missing, use the organization's approved default priority of Medium.

If any record is invalid, stop processing.

Mark invalid records, process valid records, and return a summary unless the invalid-record rate exceeds the defined threshold.

Return an error message if processing fails.

Return errors using the same JSON schema as successful responses.

Use null when the field is absent.
Use "invalid" when the field violates the expected format.
Use "unclear" when the field appears present but cannot be interpreted confidently.
Use "conflict" when multiple inconsistent values exist.

Answer customer questions using the approved company knowledge base.

If an order-specific question does not include an order number, request the order number.
If the answer is not present in the approved knowledge base, do not invent a policy.
Escalate the case to human support.
If two policies conflict, provide neither as final guidance and mark the case for policy review.
If the issue involves suspected account compromise, direct the customer to the approved security-verification process.
If the request requires refund authorization, collect the required details and transfer the case to an authorized agent.
If the customer's request is ambiguous, ask one focused clarification question.

Role: Define the expertise or behavior expected from the model.
Task: State the primary action clearly.
Context: Provide background information required for the task.
Input: Supply the data to be processed.
Required information: Identify mandatory fields.
Optional information: Identify fields that may be omitted.
Source rules: Define which information sources may be used.
Constraints: State limitations and prohibited behavior.
Success criteria: Define what a correct result must contain.
Missing-input fallback: Define what happens when required input is absent.
Invalid-input fallback: Define what happens when the input format is incorrect.
Ambiguity fallback: Define when clarification is required.
Conflict fallback: Define how inconsistent information should be reported.
No-result fallback: Define what happens when no valid answer exists.
Verification fallback: Define how unsupported claims should be labeled.
Partial-completion fallback: Define whether valid portions should still be processed.
Escalation fallback: Define when human review is required.
Output format: Define the structure for both success and fallback responses.