An engineering problem statement defines the system, the observed failure or limitation, the operating conditions, the constraints and the evidence needed for a decision. For AI-assisted research, it also serves as the retrieval brief. It is an input to research and later requirements work, not a formal requirements specification. If the statement is vague, the assistant will usually return broad solution ideas rather than relevant patents, papers or technical precedents.
Write the problem before asking for solutions. A useful statement describes what is happening and what must change without embedding an untested preferred answer. NASA systems-engineering guidance makes the same distinction between the problem and the implementation: define the need, objectives, system boundary and constraints before committing to a design solution. Patsnap patent and literature research can then use the statement to identify terminology, prior approaches and evidence gaps.
The six parts of a searchable engineering problem statement
1. System boundary
Name the product, process or subsystem under investigation and what sits outside the current scope. “Improve battery safety” is too broad. “Reduce internal-short detection time in a pouch-cell formation line” defines a system and a stage.
2. Current behavior
Describe the observable baseline: what the system does, under which conditions and how performance is currently measured. Include ranges when they matter, but avoid invented precision.
3. Failure or limitation
State the gap between current and required behavior. Use a measurable failure mode where possible: excessive temperature rise, unstable signal, cycle-time loss, contamination, crack initiation or false-positive rate.
4. Affected outcome
Explain why the gap matters to a technical decision. Connect it to reliability, quality, energy, throughput, maintainability or another defined outcome. Do not replace the technical outcome with a general claim such as “improve customer experience.”
5. Constraints
List constraints that materially shape the solution space: geometry, materials, operating temperature, safety, standards, process compatibility, cost envelope, available sensors, time or prohibited changes.
6. Evidence questions
Specify what the research must discover. Typical questions include:
- Which physical mechanisms could explain the observed failure?
- Which approaches have been implemented in comparable systems?
- Under what conditions did reported approaches work or fail?
- Which variables are most influential?
- Which constraints eliminate otherwise plausible routes?
- What evidence would justify the next experiment?
A reusable statement template
In [system or process], under [operating conditions], the current [component or mechanism] produces [measured behavior or failure], which affects [technical outcome]. The desired change is [target] while preserving [constraints]. Research should identify [mechanisms, prior approaches and evidence] and exclude [out-of-scope branches]. The work is complete when [decision-ready output] is available.
The last sentence matters. It tells the AI workflow whether the desired output is a terminology map, a shortlist of mechanisms, a comparison of technical routes, a patent set or an experiment recommendation.
Before and after
Weak statement
Find AI solutions to improve cooling in our device.
This prompt does not define the device, heat source, operating condition, failure, constraints or evidence need. It also assumes that “AI solutions” are relevant before the physical problem is understood.
Research-ready statement
In a sealed edge-computing enclosure operating at 35–45°C ambient temperature, the processor reaches its thermal limit during repeated peak-load cycles, causing clock throttling after approximately eight minutes. The enclosure footprint and external fan count cannot increase, and acoustic output must remain within the current specification. Research should identify passive and control-based approaches that reduce junction temperature or delay throttling, with evidence from comparable compact electronics. Exclude data-center-scale cooling systems. The work is complete when the team has a mechanism map, representative patents and papers, and two routes suitable for thermal modeling.
The improved version does not dictate a heat pipe, phase-change material or control algorithm. It gives the research enough structure to compare those routes fairly.
Convert the statement into search concepts
Do not paste the full paragraph into every database and expect the same result. Break it into concept groups:
| Problem element | Search concepts |
|---|---|
| System | sealed electronics enclosure, edge device, compact computing device |
| Failure | thermal throttling, junction temperature rise, transient overheating |
| Mechanism | heat spreading, passive cooling, thermal storage, dynamic power control |
| Conditions | repeated peak load, high ambient temperature, limited airflow |
| Constraints | acoustic limit, fixed footprint, fan-count restriction |
These groups support keyword expansion, semantic descriptions and classification discovery. The constraints also help reject superficially relevant results.
Define exclusions deliberately
Exclusions improve precision only when they reflect the decision. Excluding “liquid cooling” because the current product cannot support a pump may be appropriate. Excluding it because the team assumes it is expensive could remove useful passive two-phase or sealed-system approaches.
Record why each branch is excluded. Some exclusions are hard constraints; others are hypotheses that may need validation.
Prepare an AI research brief
Alongside the problem statement, give the assistant four operating instructions:
- Preserve the exact statement and search scope.
- Separate retrieved facts from interpretation.
- Keep source identifiers and conditions attached to each finding.
- Ask before changing a hard constraint or expanding the decision scope.
Worked example: AI research brief
The research-ready edge-computing statement above can be converted into a brief like this:
| Brief field | Example |
|---|---|
| Decision | Select two technically plausible routes for thermal modeling before the next enclosure design review. |
| Problem statement | In a sealed edge-computing enclosure at 35–45°C ambient temperature, repeated peak loads cause processor throttling after approximately eight minutes. The enclosure footprint and external fan count cannot increase, and acoustic output must remain within the current specification. |
| Evidence questions | Which heat-spreading, passive-storage or control mechanisms delay junction-temperature rise in comparable compact electronics? Under what loads and ambient conditions were they tested? Which failure modes or integration limits were reported? |
| Required output | A terminology map; a source table with patent or publication identifiers, mechanisms, test conditions and limitations; a comparison of the strongest routes; and unresolved evidence gaps. |
| Hard constraints | Fixed enclosure footprint, unchanged external fan count and current acoustic limit. |
| Exclusions | Data-center cooling systems and approaches that require an external liquid loop. Record the reason for every excluded branch. |
| Completion rule | Stop when the team can choose two routes for modeling and can see which assumptions still require testing. Do not recommend a final design. |
| Connected research tool | Use Patsnap Patent & Literature Search for traceable patent and literature records. Use Claude, ChatGPT, Codex or another compatible assistant to organize the scope, evidence table and comparison. |
This example gives the AI workflow a decision, a bounded search space and a defined output. It also tells the reviewer which facts must remain connected to source records and where the workflow should stop.
Ask for an intermediate terminology and route map before asking for recommendations. This creates a review point where an engineer can correct misread constraints, remove irrelevant branches and add missing terminology.
Claude, ChatGPT, Codex or another AI assistant can organize this workflow, but the available retrieval depends on its connected tools. A general model may help structure the question; a connected patent and literature source is needed for traceable technical records. Patsnap Patent Search and other Patsnap Open research tools can supply records for review in a compatible workflow.
Acceptance test before research starts
The statement is ready when a colleague unfamiliar with the project can answer:
- What system and operating condition are in scope?
- What failure is observed, and how is it measured?
- What outcome should improve?
- Which constraints are hard, and which are provisional?
- What evidence should the research return?
- What decision will that evidence support?
If any answer requires undocumented background, add it to the brief. If the statement already contains a favored solution, rewrite it around the underlying function or failure.
Common mistakes
Starting with a product category. “Find a better sensor” hides the measurement problem and may exclude non-sensor routes.
Mixing several system levels. A material property, component failure and plant-level throughput loss should be linked causally, not treated as interchangeable search terms.
Using goals without baselines. “Increase efficiency” is not searchable until efficiency, current performance and operating conditions are defined.
Treating constraints as universal facts. Some constraints come from the current design, not physics. Label which can change.
Asking for recommendations before evidence. First retrieve mechanisms, prior approaches and conditions. Recommendations require a comparison basis.
Start research from a stable problem statement
Connect the research tools needed for the evidence questions, then preserve the statement and scope through each search branch.
FAQ
How long should an engineering problem statement be?
Usually one paragraph plus structured constraints and evidence questions. Completeness matters more than length.
Should the statement include the suspected root cause?
Include it as a hypothesis, not a fact, unless it has been demonstrated. Ask the research to find supporting and weakening evidence.
Can one statement cover several failure modes?
Only when they share the same system boundary and decision. Otherwise split them so evidence and completion criteria remain clear.
What is the output of the framing step?
A stable problem statement, a constraint list, explicit exclusions, evidence questions and a completion rule. Candidate solutions come later.
Sources and disclosure
The enclosure example is illustrative. It does not report a completed Patsnap search, engineering test or product recommendation. AI-generated search concepts and summaries require source and engineering review. Method reference: NASA Systems Engineering Handbook, System Design Processes.