In PRIZ, a project is the place where you investigate a problem, use creative tools, and track ideas. Shape Investigation sits one step before that. It takes messy investigation context — meeting notes, an email, a Slack thread, an AI chat, or anything you can paste — and turns it into a structured Problem Candidate you can review before starting a project.
This is useful when you already have a lot of raw text, but you are not yet sure how to frame the problem, who should own it, or whether it is even a real investigation.
In this document, we’ll walk through the current Shape Investigation flow: paste context, shape it with AI, review the preview, and save a draft. After that, continue in Problem Candidate Inbox to review, approve, archive, or convert the candidate into a project.
Sign Up & Login
This document assumes you have already registered and logged in. If you need help with registration or authentication, please refer to our Sign Up & Login Instructions.
Shape Investigation is available when the feature is enabled for your workspace.
Starting Shape Investigation
You can open Shape Investigation from several places:
- On the Projects & Tools page, open the create menu next to Add New Project and choose Shape Investigation.
- Open Problem Candidate Inbox, then click Shape Investigation.
- If you have no projects yet, use the Shape Investigation button on the empty Projects & Tools page.
- Go directly to https://app.priz.guru/shape-investigation.
The page heading is Shape Investigation. The workspace path is Home > Projects & Tools > Problem Candidates > Shape Investigation.
Pasting investigation context
The first screen is a rich-text editor. Paste the selected investigation context into it.
You can format the text with the toolbar (bold, lists, links, images, and similar options), but formatting is not required. What matters is that the text contains a real situation, symptoms, impact, and any open questions you already have.
Good source material includes:
- Meeting notes
- Email text
- Slack thread text
- AI chat
- Investigation notes
The AI preview is not stored yet. PRIZ saves a Problem Candidate only when you click Save as Draft.
Shaping into a Problem Candidate
When you are ready, click Shape into Problem Candidate.
PRIZ sends the pasted text to AI shaping and returns a structured preview. This can take a short while. Stay on the page until the Problem Candidate preview appears.
If shaping fails, an error message is shown, and you can try again.
Depending on the content, the preview may also include one of these alerts:
- A short rationale explaining how the candidate was shaped.
- Needs review, when PRIZ is not sure this is a clear problem.
- No problem detected, when PRIZ is highly confident the text is not a problem. You can still edit the draft and save it if you believe it is a real investigation.
- A fallback message if AI shaping was unavailable. In that case, fields are pre-filled from your submitted context.
Reviewing the Problem Candidate preview
Shaping does not create a Problem Candidate yet. PRIZ first shows you a Problem Candidate preview so you can check whether the AI understood the situation before anything is saved.
This checkpoint is intentional. Meeting notes, emails, Slack threads, and chats are messy. The AI may miss a constraint, overstate the impact, leave a field empty, or write a title that does not match how your team talks about the issue. Saving immediately would put that draft straight into the Candidate Inbox. The preview lets you correct it first — or discard it if it is not a problem worth keeping.
Treat the preview as a working draft, not as the final record. If the fields look right, save it. If they are close, edit them. If this is not a useful investigation, click Discard. Nothing enters the inbox until you click Save as Draft.
Every field in the preview is editable. Review the form from top to bottom before you save.
What you see at the top
Before the form fields, PRIZ usually shows three things: a rationale, recommended-action chips, and scores.
AI rationale: A short explanation of how the candidate was shaped — why PRIZ thinks this is (or is not) a clear problem, and what to look at next. Use it as orientation, then verify the fields yourself.
Recommended-action chips: Up to two of the highest-priority next goals, shown as chips. These are the same items that appear later in Recommended actions. They are investigation goals, not a chosen PRIZ method.
Scores: Each score is 0–100. They are a reading of the pasted context, not a ranking of your team. Roughly: 80–100 means the problem is clear and well supported; 50–79 means it is identifiable but missing scope, impact, or evidence; 0–49 means the context is still too thin.
Confidence: How confident PRIZ is that this is a clear, actionable problem candidate.
Value: How much business or engineering value solving it would have. This score rises when yield loss, scrap, downtime, customer escalation, CAPA exposure, rework, shipment delay, or engineering time loss are present.
Recurrence: How strongly the text suggests the issue is repeating — language such as “again,” “still happening,” “intermittent,” “workaround,” or “known issue.” If no recurrence is mentioned, this score should stay low.
Urgency: How time-sensitive the operational risk looks from the text.
Evidence: How specific the supporting detail is: named tools or processes, measured impact, frequency, and actions already tried.
If a score looks too high or too low, that is a signal to edit the related fields before saving. The scores themselves are not edited on this screen.
Core description
These fields answer: what is the problem, in language a reviewer can understand without reading the original notes.
Title: A short name for the problem. Keep it specific — what failed, where, and what changed — so reviewers can recognize it in the inbox.
Summary: A short synthesis of the situation, usually a few sentences. This is what people will read first. Make sure it states the issue, the impact, and why it matters now.
Background: The fuller story from your pasted context: when it started, what changed, who is involved, and any related history. Use this to keep important context that does not belong in the title or summary.
Observed symptoms: What people can actually see or measure: defect signals, error messages, holds, haze, scrap, downtime, and similar observations. Keep this to facts, not suspected causes.
Affected scope
These fields bound the problem. They tell a reviewer where the issue lives, so they can tell whether it is local, spreading, or already owned by another team. Leave a field empty if the pasted context does not say.
Process: The process or step involved, such as CMP, wet etch, or incoming inspection.
Tool: The equipment or tool family, if named.
Product: What is being made or affected, such as a wafer size, layer, or product family.
Customer: A customer at risk or already involved, if the text names one.
Area / line / fab: The physical or organizational location: line, area, layer, or fab.
Impact
This section explains why the problem is worth investigating. Reviewers use it to decide urgency and whether the candidate should become a project.
Impact category: The primary type of harm. Choose the closest match:
- YieldLoss — yield is dropping.
- Scrap — material or lots are being scrapped.
- Downtime — a tool or process is down or blocked.
- CustomerEscalation — a customer is at risk or already involved.
- CapaExposure — quality-system or CAPA risk.
- Rework — extra work is needed to recover product.
- ShipmentDelay — a delivery is at risk or late.
- EngineeringTimeLoss — engineering time is being consumed by firefighting.
- Other — the impact does not fit the list above.
Impact description: A plain-language explanation of the harm: who is affected, how, and what is at stake.
Impact estimate: The numbers from the context, if any — percentages, cost, lots on hold, time lost. If the original text had no numbers, leave this honest rather than inventing them.
Urgency: How soon action is needed. Current options are Low, Medium, High, and Critical. Match this to real-time pressure, such as a shipment deadline, not to how interesting the problem is.
Recurrence signal: Any sign that this has happened before or is still happening: a prior excursion, an intermittent pattern, a workaround, or a known issue. If nothing in the text suggests recurrence, leave this empty.
Business risk: What happens if the team does nothing: customer impact, repeated scrap, delayed shipments, or an unresolved prior issue coming back.
Reasoning
These fields separate what is known from what is only suspected. That distinction matters later, when someone reviews or converts the candidate. Enter one item per line.
Hypotheses: Possible causes or explanations that were stated or clearly implied in the text. Example: the slurry vendor change may be driving the scratch increase.
Assumptions: Claims the draft is treating as true even though they were not proven in the text. Put unsupported inferences here, not in symptoms or evidence.
Unknowns: Facts that are missing: a QC result, a process setting, whether another line is affected. These are gaps, not questions.
Open questions: The questions the team should answer next. If you later ask for more information from the inbox, that request is also added here.
Recommendations
This is the proposed next move, not a project plan. Correct ownership and actions here so a reviewer does not have to reconstruct them from the original notes.
Suggested owner: Who should own the investigation, usually a role or team from the pasted context, such as Yield Engineering. Change it if the AI picked the wrong group.
Suggested stakeholders: Other people or functions who should be involved. Enter one per line.
Recommended actions: Higher-level goals for what to do next — establish root cause, confirm scope, protect a shipment, gather a missing measurement. These are investigation goals, not a PRIZ tool selection. Enter one per line.
Evidence
If PRIZ extracted supporting snippets from your text, they appear under Evidence. Each item is a quote from what you pasted, plus a type:
- Excerpt — a relevant passage from the original text.
- Observation — something seen or reported, without a number.
- Measurement — a quantified signal, such as yield loss or scrap cost.
- Action Tried — a containment or investigative step already taken, such as putting lots on hold.
- Other — supporting detail that does not fit the types above.
Evidence is shown so you can see what the AI used. It is not edited on this screen. If an excerpt is wrong or incomplete, correct the related fields above rather than expecting to edit the evidence list here.
Finding similar projects
If similar-project search is enabled in your workspace, click Find similar projects.
A side panel opens with Similar projects and the subtitle Projects that look related to this work. Matching projects are listed with a closeness label:
- Strong match
- Related
- Loosely related
Click a result to open that project, or close the panel and continue editing.
Discarding the preview
If the preview is not useful, click Discard.
PRIZ asks: Discard this draft? The confirmation explains that the shaped preview will be discarded and that nothing has been saved yet.
Click Yes to return to the empty paste editor, or Cancel to keep reviewing.
Saving the candidate
When the preview looks right, click Save as Draft.
PRIZ stores the candidate with status NeedsReview. A success message appears with:
- The candidate title
- Status: NeedsReview
- Open in Candidate Inbox
- Go to Candidate Inbox
- Shape another investigation
Open in Candidate Inbox takes you to that candidate’s review page. Go to Candidate Inbox opens the list. Shape another investigation returns you to an empty paste editor so you can start again.
A candidate created from Shape Investigation is stored with source PRIZ and source title PRIZ-native investigation.
What happens next
Saving a draft does not start a project. The next step is human review in the Problem Candidate Inbox.
From the inbox, you can edit, approve, ask for more information, merge, reject, archive, or convert an approved candidate into a PRIZ project. See Problem Candidate Inbox for that flow.
Tips for better shaping
- Paste selected investigation context, not an entire unfiltered dump.
- Include what happened, where it happened, measured impact, timing, and open questions.
- After shaping, treat the form as a draft. Correct the title, scope, impact, and recommended actions before saving.
- Use Find similar projects before saving if you think this issue may already exist.
- Save as a draft first. Approve and convert only after a person has reviewed it.
That’s it. I hope it’s clear and easy.
P.S. Please let us know if you require any assistance.