slug: jira
provider: Jira
generated_by: planning/capability-mapping/scripts/classify_capabilities.py
model: claude-opus-5
frame:
- Software & Technology
min_confidence: 0.7
capability_model:
  source: https://github.com/vincentmakes/turbo-ea-capabilities
  license: CC-BY-4.0
  attribution: Turbo EA Capabilities by Vincent Verdet — Turbo EA, https://github.com/vincentmakes/turbo-ea-capabilities,
    CC BY 4.0
  notice: NOTICE
edge_count: 8
edges:
- tag: Feature Flags
  spec_file: jira-feature-flags-api-openapi.yml
  capability_id: BC-4210.50
  capability_id_l1: BC-4210
  capability_name: Feature Flag Management
  confidence: 0.82
  evidence: POST /rest/featureflags/0.1/bulk submitFeatureFlags 'Submit Feature Flag data'; GET /rest/featureflags/0.1/flag/{featureFlagId}
    'Get a Feature Flag by ID'
  reason: Operations explicitly manage feature flag records (submit, retrieve, delete by id/property)
    linked to issues, matching Feature Flag Management; Jira is the registry/visibility side rather than
    the flag runtime, which slightly limits confidence.
- tag: Knowledge Base
  spec_file: jira-knowledge-base-api-openapi.yml
  capability_id: BC-430.40
  capability_id_l1: BC-430
  capability_name: Self-Service Management
  confidence: 0.8
  evidence: '"Public REST API for Jira Service Management", "getArticles  Get articles", schema ArticleDTO'
  reason: Retrieval of knowledge base articles within Jira Service Management, the self-service help content
    surfaced to customers raising requests — squarely self-service knowledge base management under customer
    service.
- tag: Security Information
  spec_file: jira-security-information-api-openapi.yml
  capability_id: BC-620.40
  capability_id_l1: BC-620
  capability_name: Vulnerability Management
  confidence: 0.78
  evidence: POST /rest/security/1.0/bulk  submitVulnerabilities  Submit Vulnerability data; GET /rest/security/1.0/vulnerability/{vulnerabilityId}  Get
    a Vulnerability by ID
  reason: Operations ingest, retrieve and delete vulnerability records from linked security scanning workspaces,
    feeding vulnerability triage and remediation tracking — Vulnerability Management. Slight discount
    because it is an ingestion/linking surface rather than the scanning or remediation workflow itself.
- tag: Builds
  spec_file: jira-builds-api-openapi.yml
  capability_id: BC-4210.10
  capability_id_l1: BC-4210
  capability_name: Continuous Integration Management
  confidence: 0.75
  evidence: POST /rest/builds/0.1/bulk — "Submit build data"; GET /rest/builds/0.1/pipelines/{pipelineId}/builds/{buildNumber}
    — "Get a build by key"
  reason: Ingestion and retrieval of CI pipeline build results keyed to pipelines and build numbers —
    continuous integration build/pipeline information management.
- tag: Deployments
  spec_file: jira-deployments-api-openapi.yml
  capability_id: BC-4210.40
  capability_id_l1: BC-4210
  capability_name: Deployment Orchestration
  confidence: 0.72
  evidence: POST /rest/deployments/0.1/bulk submitDeployments 'Submit deployment data'; GET '/pipelines/{pipelineId}/environments/{environmentId}/deployments/{deploymentSequenceNumber}/gating-status
    Get deployment gating status by key'
  reason: The surface records deployments against pipelines and environments and exposes deployment gating
    status, which is software release/deployment management; Deployment Orchestration is the best-fitting
    sub-capability (gating also touches production change authorisation).
- tag: Operations
  spec_file: jira-operations-api-openapi.yml
  capability_id: BC-4220.30
  capability_id_l1: BC-4220
  capability_name: Incident Response Management
  confidence: 0.7
  evidence: POST /rest/operations/1.0/bulk submitEntity 'Submit Incident or Review data'; GET /rest/operations/1.0/incidents/{incidentId}
    getIncidentById; GET /rest/operations/1.0/post-incident-reviews/{reviewId}
  reason: Ingests and manages production incident and post-incident-review entities from linked operations
    workspaces — service operations incident response. Ambiguity between incident response (BC-4220.30)
    and postmortem tracking (BC-4220.40) keeps confidence moderate.
- tag: Project Permission Schemes
  spec_file: jira-project-permission-schemes-api-openapi.yml
  capability_id: BC-620.20
  capability_id_l1: BC-620
  capability_name: Identity & Access Management
  confidence: 0.7
  evidence: PUT /rest/api/3/project/{projectKeyOrId}/permissionscheme 'Assign permission scheme'; GET
    .../securitylevel 'Get project issue security levels'
  reason: Operations assign permission schemes and expose issue security levels/schemes for a project
    — authorisation and access control administration, which maps to Identity & Access Management. Scoped
    to one application's access model, hence not maximal confidence.
- tag: Webhooks
  spec_file: jira-webhooks-api-openapi.yml
  capability_id: BC-4270.80
  capability_id_l1: BC-4270
  capability_name: Webhook & Event Subscription Management
  confidence: 0.7
  evidence: POST /rest/api/3/webhook registerDynamicWebhooks 'Register dynamic webhooks'; GET /rest/api/3/webhook/failed
    'Get failed webhooks'; schema FailedWebhook
  reason: Lifecycle of outbound event subscriptions for apps — registration, expiry extension, and failed-delivery
    inspection — which is exactly webhook and event subscription management on the vendor's developer
    platform. Marked down slightly because webhook endpoints are often treated as pure plumbing.