idmp-analysis

analysis

Read ../idmp-shared/SKILL.md first.

Before any write: Follow the 🛑 Destructive op confirmation protocol. Read-only commands stay read-only here, but delete / write / patch flows still require the shared yes-gate.

Recommended shortcuts

Shortcut	Purpose
+list	Read analyses under one element.
+search	Search analyses globally, including an empty-keyword starting point.

Recommended references

• analysis read flows
• ../idmp-workflow-analysis-create/SKILL.md
• ../idmp-workflow-alert-create/SKILL.md

Missing context to resolve first

Context	Why it must be resolved before create or resume
Final owner and mode	You need the exact elementId or elementTemplateId before you can choose the right command family or reserve a name.
Business root	Element-mode analysis creates still need rootElementId from the business root, even when the real owner moves to a data-bearing leaf. Prove that root with element elements path plus element fullpath get before you send the create payload.
Candidate analysis name	analysis.analyses.new-name and analysis-template.analyses.new-name require a candidate name.
Trigger scope	You need to know applyOnSelf, child-template scope, and which trigger type is valid after that choice.
Output plan	Decide whether to reuse or create output attributes, which valueType they need, and whether they land on self or child scope.
Runtime target	Decide whether Ready is acceptable or whether the final workflow must end in Running and therefore needs resume.

Constrained live behaviors

• Prefer POST /api/v1/ai/analysis/create for natural-language analysis or alert intents, then persist the returned draft through the normal create path. Use the structured DTO workflow as the fallback when the draft is unsuitable or persistence fails.
• analysis.analyses.new-name and analysis-template.analyses.new-name require a candidate name and --ack-risk; do not call them with only the owner scope.
• In element mode, rootElementId comes from the business root rather than the current leaf element.
• Shared environments can force analysis creation onto a data-bearing leaf when trigger-types list is empty on the current owner.
• Child scope does not inherit self-scope triggers. When applyOnSelf=false, the backend can legitimately expose only Session and Interval, so do not assume DataInput or Event will stay available.
• Minimal create payloads need rootElementId, startAfterCreated, a valid trigger, and real output.attributes[].attrId values. For current live ELE_SUBET flows, child-scope analyses can use owner-element output attributes while output.elementTemplate.id continues to point at the child template.
• Analysis create is not complete until get, list, and, when needed, resume prove the backend kept the object in the expected runtime state.
• Current live backends can return success for analysis delete while the generated output attributes remain referenced. Once create, reread, and resume prove the analysis itself worked, classify leaked output-attribute cleanup as a backend boundary instead of a wrong create payload.
• If the workflow must emit events or notifications, switch to ../idmp-workflow-alert-create/SKILL.md instead of treating it as a generic read or create flow.