Valid9 Alpha

Developer documentation

Bring your Jira work with you.

Import Jira requirements and tasks with a reviewed file workflow. AIO test cases and Jira Cloud connections are optional.

Alpha rollout: the retained import workflow requires the matching app, API, CLI and MCP release. If Imports is not present in your environment, use the existing local CLI importer or ask your administrator about deployment.

Jira files first. AIO optional.

Bring Jira requirements and tasks into Valid9 using a CSV export. You do not need AIO Tests, a Jira API key or an Atlassian OAuth integration. If you use AIO, add its test-case export separately.

  1. In Jira, export the selected issues as CSV (all fields). Include issue keys/types, summary, description, status, parent and issue-link columns. Keep your original export.
  2. In Valid9, open Imports → Import Jira file. Choose the destination module and team. Upload the Jira CSV; the AIO file is optional.
  3. Map issue types to requirements or tasks, task statuses, the columns linking tasks to requirements, and the risk likelihood and impact given to imported tasks. The simple form creates user requirements. Use advanced JSON for functional/design hierarchy, risk fields, multiple modules, released versions and AIO status mapping.
  4. Prepare and review the preview. Resolve errors and inspect every skipped record. Tasks need exactly one linked requirement; unlinked tasks are skipped. Explicitly accept skips before importing the rest.
  5. Import the reviewed records. If the destination changed after your preview, review the refreshed preview before applying it. You can leave the page while an accepted job runs.
  6. Check the final results against your source inventory and download the report. Quality reviews the migration evidence before the first release that relies on it.

Each uploaded file must be UTF-8 and at most 8 MiB; a job supports at most 20,000 source records. Split larger exports. Jira source keys share an organization-wide namespace: review potential key collisions when migrating from multiple Jira sites.

What gets preserved

Imported records keep their Jira or AIO keys as read-only external IDs. Sources, mapping, checksums, previews and job revisions are retained. Inspection exports include the original source bundles. Revising a mapping creates a new preview while preserving the earlier job.

Tasks enter the backlog, each rated for risk likelihood and impact: every task is rated when it enters the backlog, and the import never assumes a rating. Tasks already in Valid9 keep their own rating. Imports do not recreate Jira approvals, electronic signatures or historical test executions. Preserve earlier history as imported documents. Existing edited records are protected; a preview explains differences instead of silently overwriting them.

If an import stops after partial progress, refresh its preview and review the completed and remaining records before retrying. Source IDs allow the importer to recognize records already imported. Closing a browser is not a cancellation.

A small mapping example

Save this as mapping.json, replacing the destination names and Jira type/status names with yours:

{
  "module": "Product",
  "team": "Delivery",
  "requirements": {
    "issue_types": ["Epic", "Requirement"],
    "level": {"default": "user"}
  },
  "tasks": {
    "issue_types": ["Story", "Task", "Bug"],
    "requirement_fields": ["Parent", "Epic Link"],
    "statuses": {"To Do": "todo", "In Progress": "in_progress", "Done": "done"},
    "risk_likelihood": "medium",
    "risk_impact": "medium"
  }
}

This example maps epics and requirements to user requirements. It does not infer regulatory hierarchy from arbitrary Jira relationships. If your requirements use separate levels, explicitly map requirements.level.issue_types or requirements.level.labels to user, functional and design; name the parent columns in requirements.parent_fields. Parent links must respect Valid9’s hierarchy.

Advanced mapping also supports requirements.acceptance_criteria_field; all three of severity_field, probability_field and detectability_field; module_field and modules; tasks.released_fix_versions; tasks.risk_likelihood_field and tasks.risk_impact_field, to rate each task from a column (low, medium or high, or a value starting with one), used before the mapping’s own tasks.risk_likelihood and tasks.risk_impact; and tests.ready_statuses/skip_statuses for optional AIO definitions. Field names belong inside their indicated requirements, tasks or tests object. Requirement risk ratings must be 1–4. Use names as they appear in the export, including custom-field column names. Keep the preview free of errors before applying.

CLI workflow

v9 import jira upload --organization acme --jira jira.csv --mapping mapping.json
v9 import jira list --organization acme
v9 import jira get --organization acme --job JOB_UUID
v9 import jira apply --organization acme --job JOB_UUID --expected-version 2
v9 import jira history --organization acme --job JOB_UUID

Use the version returned by get. Add --accept-skipped only after reviewing skips. Upload may include --aio aio.csv. replan refreshes the preview; map --mapping revised.json creates a new preview from retained files. Both take --job, --organization and --expected-version. The upload mapping can be JSON or YAML; revised mappings use JSON.

The existing v9 import jira-aio plan/preflight/apply/history commands remain supported and accept Jira alone by omitting --aio. They run locally and do not create server import jobs. See the CLI guide.

Work with an assistant

Upload files in the app or CLI, then ask an assistant to inspect the preview, explain skipped records and propose a mapping. MCP provides valid9_list_import_jobs, valid9_get_import_job, valid9_import_job_history, valid9_map_import_job, valid9_replan_import_job and valid9_apply_import_job.

Writes require an eligible role and MCP write consent. Apply only the specifically reviewed version after you authorize it; skipped records require explicit acknowledgement. MCP does not transfer file bytes or Jira credentials. The same API validates the app, CLI and assistant actions. Connect an assistant.

Optional: connect Jira Cloud

The optional direct connector must first be registered and configured by the Valid9 operator. Each user then authorizes their own Jira access through Atlassian. File import works while this connector is disabled or unavailable.

Direct capture reads standard issue fields and links, up to 2,000 issues and 8 MiB, using a scoped JQL query. It does not write to Jira. Use all-fields CSV for custom fields, rich descriptions, larger exports or AIO cases. A direct capture reflects accessible records while Jira may still be changing; check the scope and counts.

The temporary connection lasts up to fifteen minutes and is lost on a page reload. After capture, the source uses the same retained preview workflow. CLI and MCP can inspect and apply that job; interactive Atlassian authorization remains in the app.