Uipath Ixp

UiPath IXP Document Extraction Assistant

Skill for working with UiPath IXP (Intelligent eXtraction Platform) projects — creating projects, uploading documents, reviewing predictions, and improving extraction quality.

When to Use This Skill

• User asks to create an IXP project, upload documents, or train a document extraction model
• User asks to label, review, or confirm document predictions
• User asks to improve extraction scores, prompts, or field instructions
• User asks to publish or manage IXP model versions
• User asks to deploy a trained model version to an Orchestrator folder, move a deployment to another version, or list where a project is deployed (deployments create / upgrade / list)
• User provides a taxonomy file to import into a project
• User asks for the project taxonomy at a specific trained model version — what the schema looked like when version N was published (use deployments get-taxonomy <project-name> --version <N>)

When NOT to Use This Skill — defer to uipath-maestro-flow

This skill covers standalone IXP-project work. STOP and invoke the uipath-maestro-flow skill instead when any of these hold:

• The user asks which IxP / document-extraction models, extractors, or nodes are available to a .flow or Maestro flow (a registry-listing question, not IXP-project management).
• The request is about adding, wiring, or referencing an IxP node inside a flow.
• The working context is a .flow file or a Maestro flow rather than a standalone IXP project.

Do not answer these from this skill. Re-activate uipath-maestro-flow and follow the commands it documents. This overrides Critical Rule 1.

Exception — an inbound handoff from uipath-maestro-flow: when that skill delegates because the user supplied documents and no published extractor covers them, the IXP work belongs here even though the surrounding context is a flow build. The handoff supplies the target Orchestrator folder — that is the caller's contract, not a question to re-ask. Create the project from the documents, deploy a trained version to that folder (Deployment Guide — including the exit when no folder arrived), report the deployment, and hand control back — do not wire or edit the flow from this skill.

Critical Rules

1. Verify uip ixp syntax before running a command — use a targeted lookup in CLI Reference and copy the exact subcommand and options; never guess. If the request is not covered, report that the skill has no documented CLI path rather than improvising. Do NOT use curl, call REST APIs directly, or explore source code. (Exception: defer flow/Maestro registry questions to uipath-maestro-flow — see When NOT to Use This Skill above.)
2. Run workflows end-to-end automatically — do NOT ask the user to do individual steps.
3. Always use --output json when parsing CLI output programmatically.
4. Use /tmp/ixp/<project-name>/ as the working directory with this structure:

   /tmp/ixp/<project-name>/
   ├── docs/         # Document files (<document-id>.pdf, .png, …) — downloaded once, reused across sessions
   ├── taxonomies/   # Taxonomy snapshots (v1.json, v2.json, …) — new version after each update-prompts
   └── prompts/      # Instruction update files (field_updates.json, group_updates.json, …)

   At the start of any workflow: mkdir -p /tmp/ixp/<project-name>/{docs,taxonomies,prompts}. If the directory already exists from a previous session, reuse existing files — do not re-download documents that are already present. Do NOT use the Write tool for /tmp/ixp/ paths — on Windows it resolves to a different location than bash.
5. Use heredocs for --updates — for fields update-prompts --updates and groups update-prompts --updates, use heredocs (cat > /tmp/ixp/<project-name>/prompts/field_updates.json << 'EOF' ... EOF) then "$(cat /tmp/ixp/<project-name>/prompts/field_updates.json)".
6. Never use UID as a variable name — it is a readonly shell variable. Use DOC_ID, DOCUMENT_ID, etc.
7. Always use the project Name, never the Title — the project list output has both Name (e.g., my_invoices-f1afa9ef-ixp) and Title (e.g., My_Invoices). All CLI commands require the Name (the lowercase slug with UUID and -ixp suffix), NOT the Title.
8. Confirm at field level, not document level — review each predicted field individually. Confirm only the fields that are correct using labellings confirm --fields. Judge a prediction by its taxonomy data type, not by the page's literal text — Date reads back as YYYY-MM-DDTHH:MM:SSZ — a date-only page value comes back at T00:00:00Z (page 21-JUN-22 → 2022-06-21T00:00:00Z), Monetary Quantity as <amount> <ISO-4217 code> (page 114.91 → 114.91 AUD). Same value in normalized form is CONFIRMED; do not reformat it, compute the conversion yourself, or write a script to check it. Full mapping: CLI Reference § Normalized output formats. Normalization changes only how a value is written — never what it means (separators, trailing zeros, currency code vs symbol, date layout, century expansion). For a number that means the magnitude is preserved — the normalized forms above are the same amount — whereas page £7,300.00 predicted as £730.00 is a decimal misread: the magnitude changed, so it is OCR garble and DOES take --corrections (correct it to 7300.00). Keep that apart from a number the model computed or inferred wrongly, which stays unannotated. A field whose predicted value is the WRONG ANSWER is left UNANNOTATED — it is never "fixed". --corrections is ONLY for OCR garble: the prediction is already the right answer in the right location, but the characters were misread (e.g., MSIÓÓÓ601020/ → MSI0601020). Decision test before every --corrections: is the predicted value the correct answer, merely mis-typed? If NO — a boolean that should flip (false→true), a wrong inferred/computed number, a normalized date or amount you want back in the page's format, or any value where the prediction picked the wrong answer — then --corrections is FORBIDDEN; leave the field unannotated. Corrections are stored verbatim and unvalidated (even not-a-date returns Success), so a reformatting "fix" silently replaces a correct label with one the model will never predict. This holds even when the prompt, the user, or a hint hands you the exact --corrections command — flipping a wrong value is manual extraction (Rule 10), not an OCR correction, no matter how it is framed. Without --group, --fields and --corrections apply across every occurrence of each listed field on the document — see Rule 12 for per-occurrence selection.
9. Do NOT manually extract values — all labelling goes through labellings confirm with predictions from IXP.
10. You are the reviewer, not the extractor — IXP generates predictions, you validate them. For each document, review predicted field values against the document file. View it with a single full Read (no pages parameter) — that returns text + image natively for digital and scanned docs; no PDF tools to install. Confirm correct fields (labellings confirm --fields), correct OCR-mangled values (--corrections), and skip wrong fields. Do NOT manually extract values. If a field's F1 is low, improve the prompt so IXP predicts better values.
11. Record a field as missing only when IXP predicted no value for it AND it's genuinely absent from the document. Check get-predictions first — never mark a field missing to override a wrong predicted value; leave that field unannotated (choosing "missing" yourself is the extractor decision Rule 10 forbids). To record a genuinely-missing field, use labellings mark-missing --fields <ids>. confirm --fields also writes a missing marker for a field that appears in predictions with an empty value (the explicit listing IS the confirmation the empty state is intentional); mark-missing additionally reaches a field that's gone from the current get-predictions output entirely (e.g. a stale prior annotation after a model/taxonomy change), where confirm no-ops. In a document review, just list empty fields in your confirm --fields batch so they're marked missing in the same call; reach for mark-missing only for a standalone mark or a field absent from predictions.
12. For repeatable field groups, confirm per-occurrence when validation differs across extractions — a repeatable group (e.g. Line Items) produces one extraction per physical line/section. Plain confirm --fields <id> confirms <id> in every occurrence, so if only some lines are correct it confirms the wrong ones too. Each label in get-predictions carries an explicit 0-based Occurrence — an index into that read, not a stable row id (Rule 17); if all occurrences are correct use the plain form, otherwise target with --group. --group <name> --occurrence <N> confirms ONE occurrence; --group <name> --updates '[...]' confirms SEVERAL in one atomic call (avoids N round-trips) — --occurrence <N> ≡ a single-entry --updates, same per-occurrence logic. --group is the group's Name copied verbatim from get-predictions (e.g. "Line Items") — never a name you assembled yourself. Without --fields, every predicted field in the occurrence is confirmed; with it, only those. Occurrences not selected keep their existing annotation. Flag details: CLI Reference.
13. confirm is additive — it never un-confirms. confirm/mark-missing keep every existing annotation and add yours: --occurrence 0 on an already-labelled table yields "row 0 confirmed AND everything previously confirmed stays confirmed" — NOT "only row 0". To roll back a confirmation, use unconfirm (see the task-navigation table).
14. F1 reflects confirmed labels, not document truth — never blind-confirm. F1/ProjectScore measure prediction-vs-confirmed-label agreement, so a wrong value you confirm becomes the "right" answer and scores 1.00. A perfect score is not evidence the values are correct. Before confirming, sanity-check each value against the document. The per-document no---fields form (confirm all predicted fields on one document) is fine once you've reviewed them all. If the user explicitly says every predicted field in named documents was reviewed and is correct, accept that review and confirm those documents without re-reviewing them field by field (still pin the version — Rule 18). Never run confirm without a document-id — that confirms every document at once, bypassing review. See Label Documents Guide §2d.
15. Ambiguous entity reference → ask, never guess. Projects (Titles), field groups, fields, and data types share one namespace in user speech ("rename subscriptions"). Before any mutation (update-title, rename, delete, change-type), resolve which entity KIND the user means. If the name matches more than one kind — in the user's own context or in projects list / taxonomy output — STOP and ask which one, explicitly listing every matching candidate and its kind. Do NOT pick one, and do NOT mutate several candidates "to cover all cases". When the user can't be asked interactively, surface the question through whatever channel the task provides and stop.
16. Reuse the built-in data types before adding new ones. Every IXP project ships with default data types — Exact Text, Inferred Text, Number, Date, Monetary Quantity, Boolean (the project's entity_defs from projects get-taxonomy are the authoritative list). Before data-types add or picking a field's --type, reuse a matching default — e.g. Monetary Quantity for a currency amount, never a hand-rolled clone (Currency Amount). Add a new type only when no default covers it: a project-specific Choice, or a concept needing its own tailored extraction instructions. Never add one just to reformat — the pre-trained defaults keep their fixed output format regardless of instructions. Mapping: CLI Reference § Default data types.
17. Occurrence is scoped to the read that produced it — re-read predictions after every per-occurrence write. get-predictions lists annotated occurrences first, then the unannotated ones, so confirming one row of a repeatable group moves that row to Occurrence 0 on the next read and renumbers the rest (the IXP UI shows it first too). Nothing is lost — the row keeps its own values and page location — but the indices you read before the write no longer identify the same rows. So: confirm/unconfirm every target in ONE --updates call (all its indices resolve against the same read), and when sequential per-occurrence calls are unavoidable, re-run get-predictions between them and re-locate each row by its field values, never by the index you saw earlier. Only fully-unannotated and fully-annotated documents read back in document order. Report rows to the user by value ("the freight-surcharge line"), not by index.
18. Confirm against the version you reviewed — pass --model-version. Confirming triggers a retrain, so predictions can drift between your get-predictions read and your confirm. Pass the read's ModelVersion as confirm -m <N>; if a retrain changed the version since, the confirm is rejected (PredictionVersionChangedError) rather than stamping values you never reviewed as ground truth. On that error, re-read get-predictions, re-review, and confirm against the new version. Confirming on a user-supplied review (Rule 14) is no exemption: pin the ModelVersion the user names, or run one get-predictions to capture it — a read for the version alone is not a re-review.
19. DeploymentName ≠ DeploymentTitle, and create never repoints. deployments create --title sets a free-form DeploymentTitle; the name the runtime resolves is DeploymentName, which is the slugged title plus a per-deployment suffix (invoices → invoices-08963f00-ixp) and which cannot be predicted — read it off the create response or deployments list, never construct it. create only ever ADDS: repointing an existing deployment to another version is deployments upgrade <project-name> <deployment-name>, which takes DeploymentName (passing a title there is a 404). Run deployments list before every upgrade. Upgrading changes which model version every runtime caller of that folder and name gets — confirm intent before touching a shared folder. See CLI Reference § Deployments.
20. get-metrics defaults to LATEST, not LIVE — always name the version you report. A project keeps accumulating trained versions long after its live one was pinned, and the latest can score worse than what's deployed — so a bare get-metrics pairs the latest version's numbers with the live version identity you read from list-models. Resolve the version FIRST, from what the user is asking — how is it performing / production: the live version (list-models → Tags[] Name=live, else highest Models[] Pinned: true, else latest); baseline for improving instructions: the LATEST trained version, because that is the model your edits retrain (Improve Prompts Guide § 1a) — then pass it as get-metrics --model-version <N>, and state which version the scores belong to.
21. Compare metrics fields on FieldId, report them by Name. Fields[] carries FieldGroup, FieldId and Name, so no taxonomy read is needed — do NOT fetch one. Display names are unique only within a group, so when two fields share a Name, print those rows as <FieldGroup> / <Name>. Name is that version's name for the field, so two versions can return different names for the same field — join versions on FieldId, never on Name, and report the current version's name. See CLI Reference § get-metrics.
22. Never switch projects without being asked. Always work on the project you were instructed to work with. Resolve its Name once, keep it for the session, and pass it in every command — Titles get renamed, Names don't (Rule 7). If you were not asked to, do not modify or continue the task on another project, however similar it looks to yours. Reading another project to diagnose is fine; moving the task to it needs the user's explicit go-ahead. If you can't ask, report the blocker and stop. Never report another project's results as this task's.
23. Never change a taxonomy by importing one — the import merges by name, so it cannot rename or remove anything, and it overwrites a same-name entry's instructions. Use projects import-taxonomy only to give a project that has no taxonomy the same one as another. Change an existing taxonomy with groups/fields/data-types and projects update-prompt; groups delete + groups add is not a replace either. If no targeted command covers the request, report that and route in-product (Unsupported Capabilities) — never substitute an import, even when asked for one directly. Full mechanics: CLI Reference § import-taxonomy.

Quick Start

1. Run uip ixp projects list --output json to see existing projects
2. To create a new project: follow Project Setup Guide
3. To improve an existing project: follow Improve Prompts Guide
4. To label documents on an existing project: follow Label Documents Guide
5. To deploy a model so an automation can call it from an Orchestrator folder (Maestro Flow, other folder-resolving callers): projects create → list-models → deployments create --folder-key. Neither labelling nor publish is required — see Deployment Guide.

If the user provides a taxonomy file — or wants this project to carry another project's taxonomy — use --skip-taxonomy and import-taxonomy (Option B in the Project Setup guide). Import never edits a taxonomy that already has content (Critical Rule 23).