> For the complete documentation index, see [llms.txt](https://docs.ins-pi.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ins-pi.com/command/features/ip-studio.md). # IP Studio: authoring guided use cases The IP Studio is where guided use cases and questions are written, reviewed and published. It is built for MSPs, consultants and customers who know a business outcome and the data behind it, and who should not need a developer to add one. Every use case follows the same structure. The analysis itself is done by one of ten **archetype methods**, generic code that ships with Command. A use case only says what to analyse and where the data lives. That is why one structure fits every entry. {% hint style="info" %} **Who can do what** * **Authors** (MSPs, consultants, customers) create and edit drafts and submit them for review. Their entries never reach users until reviewed. * **Reviewers** check an entry someone else wrote, then mark it reviewed or return it with a note. * **IP owners** (Command admins) review, publish to users, merge duplicates, and maintain requirements in Data Governance. Every status change records who made it and when. {% endhint %} ## Find your way around | Area | What it is for | | ------------------- | -------------------------------------------------------------------------------------------------------------------------- | | **Guided catalog** | Every entry, grouped by domain, then topic, then archetype. Filter by domain, archetype, review status and binding health. | | **Needs review** | The review queue, oldest first, with the reason each entry is waiting. | | **Duplicates** | Entries with the same topic, archetype and intent. An IP owner keeps one and merges the rest. | | **New use case** | The authoring wizard. | | **Building blocks** | The reusable definitions (business objects, features, evidence, outputs) that use cases link to. | ## Author a use case in eight steps Open **New use case**, name the outcome, choose whether it is a use case (a guided journey) or a question (one answer), and pick an archetype template. The template sets the guided steps, the result shape and the checks for that archetype. Then work through the eight sections. Each section says what to fill in, why it matters and gives an example; the dot next to each step turns green when its checks pass. ### 1. Outcome and intent Name the outcome, state the goal the run starts from, choose the domain and persona, and list other ways people ask for it. Add **Must not match** phrases for near misses that belong elsewhere. *Example:* "Reduce application run cost", asked as "how can we cut run cost by 20%", not "cost center". ### 2. Archetype method Choose one of the ten archetypes: Current state, Root cause, Prioritization, Ownership and governance, Executive recommendation, Target outcome, Scenario, Roadmap, Risk and compliance, Monitoring and value. The panel below shows the archetype's **contract**: which sources its code reads, which definitions it needs, and what your topic must declare (for example, Prioritization needs weights). An archetype marked *Not registered yet* can be authored and reviewed, but its entries reach users only once its method ships. ### 3. Topic and population Pick the business object the analysis counts (for example Business application on `cmdb_ci_business_app`), an optional **segment field** to split results by, and the **default scope**, an encoded query every run starts from. Several use cases can share one topic. ### 4. Data requirements List the features, measures, scores, lifecycles and relationships the method reads. For each one: * Mark it **Mandatory** (the method cannot conclude without it) or **Important** (it adds context). * Select **Check bindings on this instance**. Each requirement then shows its live status: *Exact* (found as declared), *Renamed* (a confident match was used and is disclosed), *Confirmed* (someone confirmed a match on this instance), *Suggested* (pick one of the candidates with **Map to**) or *Unbound* (nothing on this instance holds it). A confirmation is remembered for the instance. * Decide whether **Data Governance** should maintain it. Mandatory requirements default to yes. Where a DG rule covers the field you see its quality; where none does you see only how many records have the value and how many do not. * Open a requirement to set its source type, table, unit, grain and aggregation. A measure without a unit cannot be summed honestly. IP owners can select **Maintain these requirements in Data Governance**: it previews the scopes and rules it would add, and writes nothing until you confirm. ### 5. Thresholds, bands, targets and weights Declare what good and bad look like. A band is only evaluated when its rules use values the instance actually stores: if the field stores `low`, `medium` and `high`, a band written as `good: 1,2; bad: 4` is refused. Add a target, an ordinal scale for choice values, and ranking weights (`feature-id=weight` per line; a negative weight means lower ranks higher). ### 6. Evidence, blocks, policy and clarifications Choose the quality gate and name exactly which conclusion it blocks, the approval policy and what happens when it is not satisfied, and the questions the reader is asked, in order. Questions are asked only while the answer is still unknown. ### 7. Outputs Choose the result shape (report, dashboard, matrix, timeline and so on) and the dashboard recipe, one widget per line as `widget: definition-id`, for example `kpi-count: entity-application`. ### 8. Review and publish The checklist combines the library validation, the archetype contract, the binding check, band honesty and the section fields. **Save draft** at any time. Then: 1. A new entry is saved straight into the **Needs review** queue: hidden from users, visible to admins with its reason. An entry returned to its author becomes a draft; the author fixes it and selects **Submit for review** again. 2. A reviewer or IP owner runs the checklist and selects **Mark reviewed**, or **Return to author** with a note. If the entry declares a **limitation** (data this instance lacks), it is reviewed as **limited**: it reaches users with that limitation stated, never with invented values. 3. An IP owner selects **Publish to users**. This is only possible when every check passes; publishing also activates the draft requirements, gate, policy and outputs the entry needs. Editing a published entry as an author takes it off users and back to Needs review, so a change is always reviewed before users see it. ## Good practice * Reuse existing business objects, features and topics before creating new ones; the catalog search shows what exists. * Write the request the way a reader would type it, and keep synonyms short. * Never invent a threshold. If the business has not declared one, leave it empty: the result then shows a stated distribution instead of a made-up grade. * If a requirement is unbound on your instance, keep it: it stays visible as a named limitation instead of being guessed. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ins-pi.com/command/features/ip-studio.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.