Model strategy diagnostic

What should this product use: rules, RAG, fine-tuning or a task-specific SLM?

Answer eleven product, architecture and operating questions. The brief starts with the least-complex viable approach, then states what must be proven before you commit.

This diagnostic runs entirely in your browser. Answers are not submitted or stored.

Eleven decision inputs

Describe the product boundary

0 of 11 answered
How bounded is the task?

Choose the narrowest honest description of the decision the product must make.

How quickly does authoritative knowledge change?

This distinguishes knowledge retrieval from behaviour adaptation.

What connectivity can the product rely on?

Use the field condition, not the laboratory or headquarters condition.

What response-time boundary matters?

Do not confuse user preference with a system-level control deadline.

What is the strongest data-security constraint?

Consider customer commitments, classification, trade secrets and deployment policy.

Where must inference run?

The deployed hardware envelope can eliminate otherwise attractive options.

How proprietary must model behaviour be?

Fine-tuning is for repeatable behaviour—not for keeping facts current.

What rights-cleared data exists today?

Select what is actually governed and usable, not what might be collected later.

What happens when the system is wrong?

A language model must never silently become the deterministic safety controller.

How mature is the product evidence?

Architecture commitment should follow evidence, not enthusiasm.

Who will own the model and data lifecycle?

Customisation creates evaluation, update, rollback and incident obligations.

Generate the least-complex viable hypothesisNo confidence score: the evidence gate matters more than a synthetic percentage.