When Should You Use a Reasoning Model Instead of a Fast AI Model?

Choosing an AI model should not be a contest to find the most powerful option. The better question is: How much reasoning does this task actually require?

A fast AI model can often rewrite a message, extract dates from a document, classify feedback, summarize a straightforward article, or generate ideas in seconds. A reasoning model becomes more useful when the task contains several dependent steps, conflicting information, difficult constraints, unclear instructions, or a high cost of error.

Quick Answer

Use a fast AI model when the task is clear, narrow, repetitive, and easy to check. Good examples include rewriting text, correcting grammar, extracting names or dates, creating short summaries, classifying information, brainstorming titles, and answering simple questions.

Use a reasoning model when the task requires the AI to compare alternatives, connect evidence across multiple sources, debug a difficult problem, follow several constraints at once, plan a sequence of actions, solve advanced mathematics, or explain why one conclusion is stronger than another.

A useful rule is:

Start with the fastest model that can reliably complete the task. Move to a reasoning model when complexity, ambiguity, consequences, or verification requirements increase.

A reasoning model is not automatically better for every request. For a simple task, it may take longer and use more resources without producing a meaningfully better result. For a difficult task, however, the additional analysis can be the difference between a plausible answer and a useful one.

What Is a Fast AI Model?

A fast AI model is optimized to respond quickly and efficiently. It is often the best choice for routine work where the user already knows what needs to happen and can describe the task clearly.

Consider these requests:

• “Rewrite this email to sound more professional.”

• “Extract every date from this document.”

• “Summarize this article in five bullet points.”

• “Classify these support messages as billing, technical, or account-related.”

• “Give me ten alternative titles.”

• “Convert this paragraph into a table.”

Each request has a relatively direct path from input to output. The model does not need to design a complicated strategy, reconcile several competing interpretations, or test multiple possible solutions. It mainly needs to execute the instruction correctly.

That does not mean a fast model is unintelligent. Modern fast models may still perform analysis, understand context, use tools, and solve moderately difficult problems. “Fast” describes the practical balance of response time, cost, and depth - not a complete absence of reasoning.

Fast models are especially valuable when a workflow involves volume. If a business needs to classify 10,000 product reviews, extract fields from hundreds of forms, or generate short descriptions for a large catalog, even a small increase in processing time or cost per item can become significant.

In those situations, a fast model that is accurate enough may be more useful than a deeper model that is slightly better but considerably slower.

What Is a Reasoning Model?

A reasoning model is designed to spend more effort analyzing a problem before producing its final answer.

It is particularly useful for tasks involving:

• planning;

• uncertainty;

• multiple constraints;

• difficult calculations;

• complex code;

• large amounts of unstructured information;

• relationships that are not obvious from a single passage;

• decisions that require comparing several alternatives.

OpenAI describes reasoning models as especially useful for complex problem-solving, coding, scientific reasoning, and multi-step workflows. Its guidance also distinguishes reasoning models that act as “planners” from lower-latency models that function as “workhorses”: the reasoning model can determine what should be done, while faster models execute clearly defined steps.

Google similarly describes model thinking as useful for multi-step planning and complex tasks such as coding, advanced mathematics, and data analysis.

A reasoning model is therefore a strong choice when the answer is not located in one obvious sentence and the model must construct a path to the result.

For example, imagine that you upload three project documents:

• an original project plan;

• a revised budget;

• meeting notes containing a new deadline.

You then ask:

“Can this project still launch by October without exceeding the approved budget?”

A useful answer requires more than summarization. The model must identify the latest deadline, determine which budget is current, connect tasks to costs, locate dependencies, recognize contradictions, and state which information is still missing.

That is a reasoning task.

Reasoning Models Are Not Simply “Better Models”

It is tempting to assume that the deepest model should be selected for every prompt. In practice, that can be wasteful and sometimes counterproductive.

Suppose you ask an AI to change:

“We can’t deliver this on Friday.”

into a friendlier message.

A fast model might return:

“Unfortunately, we won’t be able to deliver this by Friday. Could we agree on a new date?”

That already solves the task.

A reasoning model could spend additional effort considering the relationship, urgency, possible causes, negotiation strategy, and alternative wording. Unless you requested those things, the additional depth does not create much value.

Now compare that simple rewriting request with this problem:

“Our launch date cannot move. Two engineers are unavailable, the vendor integration is one week late, and testing normally takes five days. Review the attached project plan and recommend the lowest-risk recovery strategy.”

Here, the steps affect one another.

Moving development work may compress testing. Reassigning engineers may delay another dependency. Accepting the vendor delay may change the project’s critical path. Reducing the testing period may increase launch risk.

A reasoning model has room to identify those relationships rather than merely restating the problem.

The goal is not maximum intelligence for every prompt. The goal is an appropriate amount of intelligence for the job.

The Five-Factor Model Selection Test

Before choosing an AI model, evaluate five factors:

1. Complexity

2. Ambiguity

3. Consequences

4. Verification

5. Scale and speed

These factors provide a more reliable decision than simply choosing the model with the strongest name or highest advertised capability.

1. Complexity: How Many Steps Depend on One Another?

A task is not complex merely because the input is long.

A 100-page document may contain a simple extraction task, while a three-sentence problem may require difficult reasoning.

Ask yourself:

• Does the model need to complete several steps?

• Does the result of one step affect the next?

• Are there competing constraints?

• Must the model compare several possible approaches?

• Is there no obvious solution path?

• Could solving one part create a problem somewhere else?

Use a fast model for:

“List all payment dates in this contract.”

Consider a reasoning model for:

“Identify every payment obligation, determine which obligations depend on milestones, and explain where the contract creates cash-flow risk.”

The first request is extraction. The second requires interpretation and an understanding of relationships between clauses.

Another example

Fast-model task:

“List the project deadlines mentioned in these meeting notes.”

Reasoning-model task:

“Compare the deadlines in the meeting notes with the official project schedule. Identify conflicts, determine which dates appear to be current, and explain which dependencies are affected.”

Both prompts use the same material, but the second requires considerably more analysis.

2. Ambiguity: Is the Correct Interpretation Obvious?

Fast models perform best when the desired output is clearly defined.

Reasoning models become more valuable when:

• instructions are incomplete;

• sources conflict;

• the user’s objective must be inferred from context;

• several interpretations are possible;

• the model must decide what information matters most.

For example:

“Make this shorter.”

This is relatively simple if the only goal is to reduce the word count.

But consider this request:

“Shorten this proposal without weakening the argument, removing contractual requirements, or changing the promised delivery scope.”

The model must decide what is expendable and what is essential. It must preserve meaning while reducing length. That judgment benefits from deeper analysis.

Reasoning should not replace clarification when critical information is missing. A good model should still identify assumptions, explain uncertainty, or ask a focused question rather than confidently inventing facts.

3. Consequences: What Happens If the Answer Is Wrong?

The cost of an error should influence model selection.

A minor mistake in a list of social-media captions is usually easy to notice and inexpensive to fix. A mistake in a contract comparison, production migration plan, financial model, or safety procedure may be much more serious.

Use more reasoning when:

• the decision is difficult to reverse;

• a mistake could cause financial or operational loss;

• the answer affects customers or employees;

• the task involves legal, medical, financial, or safety-sensitive material;

• several stakeholders will rely on the conclusion;

• the result will be used without immediate human review.

Higher consequences do not mean that a reasoning model can replace a qualified professional. AI can still produce incorrect or incomplete answers.

Instead, deeper reasoning should be one part of a more careful process that also includes:

• source citations;

• calculations;

• tests;

• clearly stated assumptions;

• alternative interpretations;

• human review.

For an important decision, you might ask:

“State your recommendation, identify the evidence supporting it, list your assumptions, describe the strongest alternative, and explain what should be independently verified before acting.”

This does not guarantee correctness, but it makes the answer easier to evaluate.

4. Verification: Can You Check the Answer Quickly?

Some AI outputs are easy to verify.

You can read a rewritten sentence, count extracted rows, compare a translated paragraph with the source, or confirm that a list contains the requested number of items.

Other outputs require substantial judgment.

If the AI recommends one software architecture over another, claims that two contracts conflict, or identifies the root cause of an intermittent bug, the user may need to inspect several sources to determine whether the answer is sound.

A reasoning model is more useful when verification requires:

• tracing claims back to sources;

• comparing alternatives;

• testing edge cases;

• checking dependencies;

• reconciling inconsistent data;

• distinguishing facts from assumptions;

• explaining why evidence supports a conclusion.

A practical prompt is:

“Give your recommendation, list the evidence supporting it, identify the strongest alternative, and explain what evidence would change your conclusion.”

This structure makes the answer easier to audit.

5. Scale and Speed: Is This One Hard Task or Thousands of Simple Ones?

Even when deeper reasoning improves an individual result, it may be inefficient for a high-volume workflow.

Imagine reviewing 5,000 customer comments.

A fast model could classify each comment by topic and sentiment. A reasoning model could then review only the smaller group of comments that are ambiguous, high-risk, or potentially connected to a systemic problem.

This hybrid pattern is often better than sending everything to the deepest model:

1. Use a fast model to process routine cases.

2. Define rules for escalation.

3. Send uncertain or important cases to a reasoning model.

4. Route the highest-risk conclusions to human review.

This approach preserves speed while concentrating deeper analysis where it matters.

When a Fast AI Model Is the Better Choice

A fast model is usually the right choice when the task involves direct execution rather than difficult judgment.

Rewriting and Tone Adjustments

Use a fast model to make a message:

• clearer;

• friendlier;

• shorter;

• more formal;

• less technical;

• easier to understand.

Example:

“Rewrite this update for a nontechnical client. Keep it under 120 words and preserve all dates.”

The model has a direct transformation task with measurable constraints.

A reasoning model may be useful when the message involves negotiation, reputation risk, several audiences, or legal implications. But ordinary rewriting rarely requires deep analysis.

Information Extraction

Fast models are well suited to extracting:

• names;

• dates;

• prices;

• addresses;

• product identifiers;

• invoice fields;

• action items;

• keywords;

• contact information;

• document headings.

Example:

“Extract the invoice number, supplier, due date, subtotal, tax, and total. Return the result as JSON.”

If the document is clear and the fields are explicit, deeper reasoning may add little value.

However, consider a more difficult variation:

“Identify which charges may violate the contract’s pricing rules and explain why.”

This is no longer simple extraction. The model must connect the invoice to another document and apply rules. A reasoning model becomes more appropriate.

Classification

Use a fast model to place items into known categories.

Example:

“Classify each review as shipping, product quality, billing, customer service, or other.”

The categories should be clearly defined, especially if the result feeds an automated workflow.

A reasoning model may be useful for ambiguous or unusual cases, but it is generally inefficient to use deep reasoning for every routine classification.

Straightforward Summaries

A fast model can summarize a clear article, meeting transcript, or short report when the user wants the main points rather than a nuanced interpretation.

Example:

“Summarize this meeting in five bullet points and list the assigned action items.”

Switch to a deeper model if the meeting contains:

• contradictory decisions;

• indirect commitments;

• unresolved dependencies;

• several versions of the same plan;

• unclear ownership;

• participants who disagree without stating it directly.

Summarizing what was said is a simpler task than determining what the conversation actually means for the project.

Brainstorming

Fast models are often ideal for producing initial options such as:

• headlines;

• names;

• questions;

• outlines;

• examples;

• taglines;

• content angles;

• product descriptions.

The first goal is usually breadth, not proof that one option is objectively best.

For example:

“Generate 20 blog-title ideas about AI document analysis for small businesses.”

A fast model can produce useful options quickly.

A reasoning model becomes more helpful when you ask it to evaluate the ideas against search intent, product positioning, audience sophistication, and competitive differentiation.

Simple Coding Tasks

A fast or balanced model may be enough for:

• explaining a short function;

• generating a regular expression;

• converting a small script between languages;

• fixing a clear syntax error;

• writing a simple unit test;

• producing boilerplate;

• renaming variables;

• documenting an API endpoint.

Use deeper reasoning when the bug spans several modules, depends on application state, involves concurrency, or requires architectural tradeoffs.

When a Reasoning Model Is Worth Using

Reasoning models provide the greatest value when several pieces of information must be connected before a reliable answer can be produced.

Multi-Step Planning

Reasoning models are useful when a plan must respect:

• dependencies;

• available resources;

• deadlines;

• risks;

• budgets;

• staffing limitations;

• approval requirements.

A weak request would be:

“Create a launch plan.”

A stronger request is:

“Create a six-week launch plan using the attached requirements. We have two engineers, one designer, and no weekend work. Identify the critical path, assumptions, likely bottlenecks, and the first decision that could delay the launch.”

The second prompt gives the model a genuine planning problem.

The model must do more than create a checklist. It must consider whether the sequence is realistic and determine how one delay would affect later work.

Comparing Conflicting Documents

A fast model can summarize each file separately. A reasoning model is more appropriate when the goal is to understand how the files relate.

Example:

“Compare the original contract, the amendment, and the latest statement of work. Identify which clauses are still active, where the documents conflict, and which obligations changed.”

This requires:

• chronology;

• source attribution;

• comparison;

• interpretation across files;

• recognition that a newer document may override an older one.

A useful answer should clearly separate:

• confirmed facts;

• apparent conflicts;

• reasonable interpretations;

• questions requiring professional review.

Difficult Debugging

Consider two software bugs.

Bug A

print(user_name

A fast model can identify the missing closing parenthesis.

Bug B

An application occasionally creates duplicate orders even though the API uses an idempotency key. The issue appears only during retries after a timeout and involves a queue, a database transaction, and a third-party payment callback.

Bug B requires the model to:

• form several hypotheses;

• reconstruct the sequence of events;

• inspect possible race conditions;

• distinguish correlation from cause;

• identify missing logs;

• propose tests that separate one explanation from another.

That is where deeper reasoning earns its cost.

A useful debugging prompt is:

“Do not jump directly to a fix. Build a timeline, list the three most likely root causes, identify evidence for and against each one, and propose the smallest test that can distinguish them.”

Complex Spreadsheet Analysis

A fast model can extract a column or calculate a clearly defined total.

A reasoning model becomes useful when the spreadsheet contains inconsistencies or the user does not know why the numbers fail to reconcile.

Example:

“The cash-flow forecast and income statement disagree. Trace the difference, check timing assumptions, identify formulas that may double-count revenue, and explain the most likely source of the mismatch.”

This task requires an understanding of relationships between sheets, formulas, assumptions, and accounting periods rather than one simple calculation.

Other reasoning-heavy spreadsheet tasks include:

• finding why totals do not match;

• comparing forecast scenarios;

• tracing circular references;

• identifying inconsistent assumptions;

• explaining unusual values;

• determining which change created a variance.

Research Synthesis

Summarizing one paper is usually straightforward. Combining evidence across many sources is harder.

A reasoning model can help:

• group sources by claim;

• distinguish agreement from repetition;

• identify conflicting findings;

• compare research methods;

• note missing evidence;

• separate source statements from the model’s synthesis;

• identify when several articles rely on the same original study.

Example:

“Using the uploaded studies, create an evidence table. For each claim, list supporting and contradicting studies, sample size, method, limitations, and confidence. Do not treat repeated citations of the same original study as independent evidence.”

That requires more than summarization. It requires reasoning about the structure and quality of the evidence.

Advanced Mathematics and Logic

Reasoning models are generally more suitable when a problem requires:

• multiple transformations;

• proofs;

• case analysis;

• optimization;

• checking boundary conditions;

• verifying that the solution satisfies all constraints.

For a simple calculation, use the fastest available model or a calculator.

For a difficult problem, ask for a structured solution and independent verification.

Example:

“Solve the optimization problem, state the assumptions, check boundary cases, and verify the final result by substituting it back into the original constraints.”

The verification step is important. A plausible derivation does not guarantee that the final result is correct.

Decisions With Competing Constraints

Many real decisions do not have one universally correct answer.

Suppose a company must select a database.

The fastest option may not provide the best consistency. The lowest-cost option may increase operational complexity. The most familiar option may not handle future scale.

A reasoning model can create a decision matrix, but the user must provide the real priorities.

Example:

“Compare the three proposed databases. Weight reliability at 35%, operational simplicity at 25%, cost at 20%, performance at 15%, and vendor portability at 5%. Explain each score, run a sensitivity check, and show which assumption most affects the result.”

The reasoning is valuable because the recommendation depends on explicit tradeoffs rather than one isolated feature.

A Practical Task-by-Task Comparison

The Rekdan Three-Step Escalation Method

Rekdan provides three models in one workspace: Flash for quick basic tasks, Apollo as the balanced everyday model, and Ragnarök for complex, multi-step analysis. Users can switch between the models during the same conversation without losing their place.

That makes it possible to use a simple escalation method instead of choosing the deepest model at the beginning of every chat.

Step 1: Start With Flash for Clear Execution

Choose Rekdan Flash when you need:

• a quick answer;

• a short draft;

• a rewrite;

• straightforward extraction;

• initial ideas;

• a simple lookup.

Example:

“Extract every feature request from these customer comments and group identical requests.”

If the output is clear and complete, stop there.

There is no benefit in escalating a task that has already been completed correctly.

Step 2: Move to Apollo for Everyday Analysis

Choose Rekdan Apollo when the task needs:

• more context;

• stronger writing;

• file analysis;

• planning;

• studying;

• a more developed answer;

• several related instructions.

Example:

“Group the feature requests by user problem, estimate which themes appear most often, and turn the results into a product-feedback summary.”

Apollo is the practical default when the task is more than a quick transformation but does not require the deepest available analysis.

Step 3: Escalate to Ragnarök for Difficult Reasoning

Choose Rekdan Ragnarök when:

• several documents must be reconciled;

• the task has many dependent steps;

• sources conflict;

• the answer requires careful judgment;

• the first result is too shallow;

• a bug or calculation has resisted simpler approaches;

• the model must evaluate alternatives and risks.

Example:

“Compare the feature requests with the current roadmap and technical constraints. Recommend which three features should be prioritized, explain their dependencies and opportunity costs, and identify what additional evidence could change the ranking.”

Ragnarök is positioned for complex research, analysis, long documents, and careful multi-step reasoning.

The important point is that switching models should reflect a change in the task—not a belief that every prompt deserves maximum computing effort.

How to Write Better Prompts for Reasoning Models

Reasoning models do not necessarily need theatrical instructions such as “think harder” or “think step by step.”

Official guidance from OpenAI recommends simple, direct prompts and notes that forcing step-by-step wording may not improve performance.

A strong reasoning prompt usually contains five elements.

1. The Objective

State the decision or output you need.

“Recommend the lowest-risk migration approach.”

Do not make the model guess what the final deliverable should be.

2. The Relevant Context

Provide the facts, files, constraints, and definitions the model should use.

“The application has a two-hour maintenance window, uses PostgreSQL, and cannot lose confirmed transactions.”

Relevant context improves reasoning. Irrelevant context can distract the model and make important details harder to identify.

3. The Evaluation Criteria

Explain what “best” means.

“Prioritize data integrity first, rollback simplicity second, and speed third.”

Without evaluation criteria, the model may optimize for something you do not care about.

4. The Required Evidence

Ask the model to connect its conclusions to sources or observations.

“Cite the file and section supporting every critical claim.”

This makes the final recommendation easier to inspect and reduces the chance that an unsupported statement will be mistaken for a documented fact.

5. The Uncertainty Format

Tell the model what to do when evidence is incomplete.

“Separate confirmed facts, reasonable inferences, and unresolved questions.”

This is more useful than asking the model to sound completely confident.

A complete reasoning prompt might look like this:

Review the attached migration proposal and incident history. Recommend the lowest-risk migration approach. Prioritize data integrity, rollback simplicity, and downtime in that order. Compare at least two approaches, cite the supporting file for every important claim, list your assumptions, and identify the smallest preproduction test that could invalidate your recommendation.

This is considerably more useful than simply writing:

“Think carefully.”

Common Mistakes When Choosing an AI Model

Using Deep Reasoning for Every Task

This increases response time and resource use without guaranteeing a noticeable improvement.

Begin with the simplest model appropriate for the request.

Using a Fast Model Repeatedly on a Fundamentally Difficult Problem

If several rewrites of the prompt still produce shallow or inconsistent answers, the problem may require a deeper model rather than another small wording change.

A more capable reasoning process may be needed when the model repeatedly:

• overlooks dependencies;

• ignores contradictions;

• produces generic recommendations;

• changes its conclusion without explanation;

• cannot connect evidence across files.

Confusing Long Input With Difficult Reasoning

A long file does not automatically require the deepest model.

Extracting every email address from 200 pages is a large-input but conceptually simple operation.

Determining how ten clauses interact across three versions of a contract may involve less text but require much deeper reasoning.

The amount of material and the difficulty of the task are separate questions.

Assuming the Reasoning Model Will Verify Itself Automatically

A polished explanation can still be wrong.

Ask for:

• sources;

• assumptions;

• calculations;

• tests;

• edge cases;

• alternative interpretations.

When possible, verify important claims independently.

Failing to Define the Decision Criteria

A model cannot meaningfully choose the “best” option until you explain what matters.

The lowest-cost, fastest, easiest-to-maintain, and lowest-risk options may all be different.

Define priorities before requesting a recommendation.

Sending Routine and Exceptional Cases Through the Same Workflow

Use a fast model for ordinary cases and escalate only ambiguous, difficult, or high-impact cases.

This is particularly useful for workflows involving:

• customer support;

• document processing;

• fraud review;

• content moderation;

• quality assurance;

• application screening;

• invoice review.

A 30-Second Decision Checklist

Before selecting a model, ask:

1. Is the task primarily transformation or extraction?

2. Is there one clear path to the answer?

3. Can I verify the result quickly?

4. Is the cost of a mistake low?

5. Do I need to process many similar items?

If most answers are yes, choose a fast model.

Then ask:

1. Are there multiple dependent steps?

2. Do sources or requirements conflict?

3. Must the model compare alternatives?

4. Is the correct interpretation uncertain?

5. Would an error be expensive or difficult to reverse?

6. Do I need evidence, assumptions, and a defensible recommendation?

If several answers are yes, choose a reasoning model.

When the answers are mixed, begin with a balanced model and escalate if the result lacks sufficient depth or reliability.

Frequently Asked Questions

Are reasoning models always more accurate?

No.

Reasoning models are often better at complex, multi-step tasks, but they can still misunderstand the request, use incorrect assumptions, overlook evidence, or produce unsupported conclusions.

For a simple task, a fast model may be equally accurate and considerably more efficient.

Are reasoning models always slower?

They generally spend more effort before answering, so they often have higher latency.

The actual response time depends on the model, reasoning setting, prompt, tools, amount of input, and task complexity.

Should I use a reasoning model for writing?

Use one when the writing problem involves:

• strategy;

• competing constraints;

• complex source material;

• a difficult argument;

• several audiences;

• important consequences.

A fast or balanced model is usually enough for grammar corrections, tone changes, short drafts, summaries, and straightforward editing.

Should I use a reasoning model for coding?

Use a fast or balanced model for:

• boilerplate;

• syntax fixes;

• explanations;

• small functions;

• basic unit tests;

• simple refactoring.

Use a reasoning model for:

• software architecture;

• difficult debugging;

• multi-file changes;

• concurrency problems;

• database migrations;

• security analysis;

• tasks involving many edge cases.

Should I use a reasoning model to summarize a PDF?

Not automatically.

A fast or balanced model can summarize a clear document.

Use deeper reasoning when the document:

• is long and dense;

• contains conflicting provisions;

• requires conclusions across several sections;

• must be compared with other files;

• contains important exceptions or dependencies;

• requires interpretation rather than summarization.

Can a fast model solve complex problems?

Sometimes.

The boundary between fast and reasoning models is not absolute, and model capabilities continue to improve.

The practical question is whether the result is reliable enough for your task. If a fast model completes the work accurately, there is no reason to escalate merely because a deeper option exists.

What should I do when I am unsure which model to use?

Start with a balanced model.

Check whether the answer:

• identifies the important constraints;

• supports its claims;

• handles uncertainty;

• follows all instructions;

• recognizes contradictions;

• provides a usable conclusion.

If the answer is superficial, inconsistent, or unable to connect the available evidence, move to a reasoning model.

Final Takeaway

Use a fast AI model for clear execution. Use a reasoning model for difficult judgment.

Fast models are usually the right choice for:

• rewriting;

• extraction;

• classification;

• brainstorming;

• short summaries;

• straightforward coding;

• other tasks with a direct path to the answer.

Reasoning models are more valuable for:

• multi-step planning;

• complex debugging;

• conflicting documents;

• advanced analysis;

• difficult mathematics;

• decisions involving competing constraints.

The best workflow is not:

“Always use the strongest model.”

It is:

Start fast, evaluate the result, and increase reasoning depth only when the task demands it.

In Rekdan, that means using Flash for quick work, Apollo for balanced everyday tasks, and Ragnarök when the problem genuinely requires deeper analysis.

The right model is not the one that thinks the longest. It is the one that gives you a reliable answer with the appropriate amount of time, cost, and effort.