Jekt™ Jira Profile

Last Updated: 2026-09-19

Copyright © 2026 GlobalMentor, Inc.

This work is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0).

"Jekt" and the Jekt logo are trademarks of GlobalMentor, Inc.

1. Introduction

1.1 Purpose and Scope

This profile maps Jira ticket metadata to Jekt vocabulary. It states what a Jira property, value, or entity corresponds to in Jekt, not how a converter or importer implements that correspondence. The profile applies Jekt's general vocabulary (Specification §8) to one external system in a form that future source profiles can follow.

The scope is the initial correspondence of a Jira ticket brought into a Jekt repository. Full migration from Jira and ongoing two-way synchronization are separate concerns not addressed here. The profile does not assume that the Jira instance or an export remains available after import. A Jira field with no current Jekt correspondence is identified as such below.

Jira's administrative model varies — team-managed projects configure issue types, workflows, and fields locally rather than through the shared schemes described here; other Atlassian product lines (Service Management, Product Discovery) layer their own issue types and fields; a long-lived instance accumulates historical customization. The mapping below reflects Jira Cloud under its default configuration; a team whose configuration differs extends the mapping using the same principles.

Custom fields are outside this profile; see §2.

1.2 Document Status

This is a living document. It uses the Specification's *(provisional)* and *(TBD)* markers (§1.3) with the same meaning: *(provisional)* marks a correspondence settled in direction but whose exact contour may still shift; *(TBD)* marks one not yet sufficiently settled to state. A correspondence carrying neither marker is settled.

1.3 Relationship to Other Jekt Documents

This profile applies the Specification's metadata vocabulary (§8) and import prescription (§8.8, §14.8) to one concrete external system. It is authoritative for what a Jira concept corresponds to in Jekt's terms; it is non-normative for Jekt's own vocabulary and structure, which the Specification governs, and where the two appear to conflict, the Specification governs. Unlike the Primer and User Guide, which derive entirely from the foundational pair, this profile introduces content the foundational pair does not carry: Jira's own field taxonomy. A future profile for a different source system follows the same pattern.

2. Identifying a Jira Property

Jira exposes the same property through two parallel namings:

• A UI label (e.g., "Fix Version/s"), the display string shown in the Jira interface. Not a stable key — configurable for custom fields, and not guaranteed unique.
• A REST API field id (e.g., fixVersions), the JSON key returned by Jira's REST API (GET /rest/api/3/field, GET /rest/api/3/issue/{key}). System fields have fixed, cross-instance-portable ids; custom fields get an opaque, instance-assigned numeric id (for example, customfield_12345) with no portability at all.

This profile uses the REST API field id as the canonical identifier for a Jira property, since it is Atlassian's own documented, versioned, and programmatically enumerable naming — see the Jira Cloud platform REST API. The UI label is given alongside for recognition. Jira Query Language (JQL) clause names are a query-time convenience rather than a schema description and are not used as a naming source here.

Custom fields are out of scope for this profile. A custom field's REST id is an opaque, per-instance number with no cross-instance meaning; some are recognizable across instances by a stable schema.custom type key (fields belonging to widely-deployed Atlassian ecosystem features — Rank, Sprint, Epic Link, Story Points, and similar), while others are entirely bespoke to one organization's instance. Neither case is mapped here.

3. Metadata Mapping

The mapping is organized by the Jira entity a property belongs to — intrinsic properties of the issue itself, then properties that reference a separate entity (a user, a version, a component, another issue), then the comment and attachment entities an issue owns — mirroring Jira's own data model rather than Jekt's vocabulary order. The table below indexes every property covered and identifies the subsection where its correspondence is described.

3.1 Issue Properties

Intrinsic to the issue itself; none of these reference another entity.

3.1.1 Summary

• UI label: Summary
• REST field id: summary
• Jekt correspondence: description prose heading title (Specification §7.6)

3.1.2 Description

• UI label: Description
• REST field id: description
• Jekt correspondence: description prose body

Jira's description commonly uses Jira Wiki Markup ({{monospace}}, {quote}…{quote}, [text|url], bulleted lists using */**) rather than CommonMark; converting between the two is a converter-implementation concern outside this profile's scope.

3.1.3 Key

• UI label: Key
• REST field id: issuekey
• Jekt correspondence: source property, a URI identifying the ticket's counterpart in the remote system

3.1.4 Created

• UI label: Created
• REST field id: created
• Jekt correspondence: createdAt

3.1.5 Type

• UI label: Issue Type
• REST field id: issuetype
• Jekt correspondence: jekt/kind

Jira issue types map to jekt/kind, but the two vocabularies organize these concepts differently:

Epic and Sub-task have no jekt/kind counterpart. In Jekt, an epic-shaped or sub-task-shaped ticket is an ordinary ticket whose place in a larger structure is expressed through jekt/partOf in the relation graph (see §3.6), not through a distinct kind. Story maps to feature unless Jekt gains its planned Story facility (Specification §2, §4.5). That facility is intended for decomposition before tickets exist and is not yet specified; once it exists, a Jira Story is the more likely candidate for direct import into it rather than into an ordinary ticket's jekt/kind.

3.1.6 Priority

• UI label: Priority
• REST field id: priority
• Jekt correspondence: jekt/priority

Jira provides two default priority scales. Each maps according to the meaning of its values, not merely the number of levels.

The classic scale — Blocker, Critical, Major, Minor, Trivial — maps directly onto five of Jekt's six values:

medium has no source under this scale — it is Jekt's own operational default for natively-created tickets.

The other default, a purely ordinal Highest/High/Medium/Low/Lowest scale, maps instead as:

This scale has no value corresponding to urgent. Conversely, the classic scale has no value corresponding to medium; neither five-value scale can distinguish all six Jekt priorities. A project using another scale requires its own mapping table.

3.1.7 Status

• UI label: Status
• REST field id: status
• Jekt correspondence: jekt/status

Jira separates workflow position (status) from disposition (resolution, §3.1.8). Jekt makes the same distinction, so the fields map independently with no inference from one to the other.

Every Jira status belongs to one of exactly three fixed, platform-defined categories, conventionally named To Do, In Progress, and Done, regardless of a workflow's custom status names. These categories provide a mapping independent of a project's status vocabulary. To Do statuses map to open, including a status named Reopened: Jekt has no separate reopened state, so reopening returns a ticket to open without changing jekt/resolution. In Progress statuses map to started. Done statuses require an additional judgment based on the status name because Jekt distinguishes resolved from closed while Jira's category does not:

3.1.8 Resolution

• UI label: Resolution
• REST field id: resolution
• Jekt correspondence: jekt/resolution

Jira's classic default resolution values map onto jekt/resolution as follows:

Jira has no resolution corresponding to abandoned; like medium in the classic priority scale, it is native to Jekt. The Specification still tracks whether irreproducible should become distinct from invalid (§14.3). Until that question is resolved, Cannot Reproduce maps to invalid.

3.1.9 Resolved Date

• UI label: Resolved
• REST field id: resolutiondate
• Jekt correspondence: jekt/resolvedAt

3.1.10 Labels

• UI label: Labels
• REST field id: labels
• Jekt correspondence: tags / tags.lst

Jira Labels correspond to Jekt's existing tags property and tags.lst file. They are unrelated to a Jekt label (Specification §5.3), which is the short filename handle for an entity.

3.1.11 Due Date

• UI label: Due date
• REST field id: duedate
• Jekt correspondence: none

3.1.12 Environment

• UI label: Environment
• REST field id: environment
• Jekt correspondence: none

3.1.13 Time Tracking

• UI label: Time Tracking (original estimate, remaining estimate, time spent)
• REST field ids: timeoriginalestimate, timeestimate, timespent
• Jekt correspondence: none

3.1.14 Votes

• UI label: Votes
• REST field id: votes
• Jekt correspondence: none

3.1.15 Updated

• UI label: Updated
• REST field id: updated
• Jekt correspondence: none

Jekt records when a ticket was created (createdAt) and when an importer last populated it (importedAt), but has no property for the source ticket's last modification. The Specification has not designed temporal properties beyond these and jekt/resolvedAt.

3.2 Project

• UI label: Project
• REST field id: project
• Jekt correspondence: project slug (for key); project description (for name and description)

A Jira project corresponds structurally to a Jekt project (Specification §4.4). Each has a stable short identifier that prefixes numbered items, together with a human-readable name and description. The Jira project key corresponds to a Jekt project slug (Specification §6.2). The Jira project name and description correspond to the heading title and body of the Jekt project description.

3.3 User

Jira carries a username directly for an issue's assignee, creator, reporter, and comment author. An inline mention may instead carry either that username or a source-local account identifier that resolves to an account record.

3.3.1 Assignee

• UI label: Assignee
• REST field id: assignee
• Jekt correspondence: jekt/assignee

The Jira username corresponds to a Jekt user identifier (Specification §6.7): a username when an email address is unavailable or not desired, or an email address otherwise. It can serve directly because Jekt uses the grammar of an email address's local part, which permits the dotted form common in Jira usernames. Creator (§3.3.2) and comment author (§3.3.3) identify people in the same way.

A source account marked as removed has no Jekt user correspondence. The source's removal marker and the representation of its account record belong to the source format, not to this profile.

3.3.2 Creator

• UI label: Creator
• REST field id: creator
• Jekt correspondence: creator property

3.3.3 Comment Author

• UI label: (not independently addressable; part of the comment structure, §3.7)
• REST field id: (none)
• Jekt correspondence: author in the comment's own YAML frontmatter (Specification §8.4, §9.1)

Jira and Jekt use the same distinction: an issue has a creator, while a comment has an author. Each Jira role corresponds to the Jekt property with the same name.

3.3.4 Reporter

• UI label: Reporter
• REST field id: reporter
• Jekt correspondence: none

Reporter is the most likely future candidate for promotion to a Jekt intrinsic property (Specification §8.4).

3.3.5 Watchers

• UI label: Watchers
• REST field id: watches
• Jekt correspondence: none

3.3.6 Inline Mention

• UI label: (not a field; a construct within description and comment prose)
• REST field id: (none)
• Jekt correspondence: a person reference (Specification §7.5)

A person mentioned in Jira prose corresponds to a Jekt person reference such as [@jdoe]. It names the same user identifier used by the person-valued properties above. Jira has two mention forms: one contains the username, while the current form contains an account identifier that must resolve to its account record before it can name a Jekt user.

A removed account or an account identifier that cannot resolve to an account record identifies no Jekt user. Jekt retains the mention's place in the sentence with the reserved placeholder [@?] (Specification §7.5) rather than creating a reference to anyone.

3.4 Version

Fix Version/s and Affects Version/s both reference a Version entity — a project-level object with its own name and release data, independent of any one issue.

3.4.1 Fix Versions

• UI label: Fix Version/s
• REST field id: fixVersions
• Jekt correspondence: jekt/releases / jekt/releases.lst

Fix Version/s corresponds to jekt/releases.lst, matched to a release by identifier.

3.4.2 Affects Versions

• UI label: Affects Version/s
• REST field id: versions
• Jekt correspondence: none

3.5 Component

• UI label: Components
• REST field id: components
• Jekt correspondence: none

3.6 Issue Relationships

jekt/dependsOn, jekt/partOf, and jekt/relatesTo are (provisional) in the Specification (§8.5); the correspondences below apply regardless of that status.

3.6.1 Issue Links

• UI label: Linked Issues
• REST field id: issuelinks
• Jekt correspondence: jekt/dependsOn, jekt/relatesTo

A Jira issue link's type governs which relation it corresponds to: "Blocks"/"is blocked by" corresponds to jekt/dependsOn; "Relates" corresponds to jekt/relatesTo. Whether every other link type an instance may define maps this cleanly is (TBD). "Duplicates" is a distinct case: whether a ticket is a duplicate is the resolution field's value (§3.1.8), independent of any link; which ticket it duplicates is this issue-link relationship.

3.6.2 Sub-tasks

• UI label: Sub-tasks
• REST field id: subtasks
• Jekt correspondence: jekt/partOf

A sub-task's parent corresponds to jekt/partOf.

3.6.3 Parent

• UI label: Parent
• REST field id: parent
• Jekt correspondence: jekt/partOf

An epic's children correspond to jekt/partOf.

3.7 Comment

• UI label: Comment
• REST field id: comment
• Jekt correspondence: one file per imported comment under comments/, named by the comment's own timestamp and identifier

An imported comment's filename combines the creation time with the Jira comment identifier, which becomes the comment name (Specification §5.6). The timestamp uses whole-second precision; for example, comment 54321 becomes 2026-02-03T21-45-00Z-54321.md. Jira assigns every comment an identifier that is unique within the instance, so the name is always available and independently unique. Comments created within the same second therefore remain distinct, and every import that carries a given comment derives the same filename from the Jira record.

YAML frontmatter records the comment information that the filename does not carry (Specification §9.1). createdAt preserves Jira's finer timestamp precision, while author identifies the person whose statement the comment represents (§3.3.3).

A reply carries Jira's threadParentId, which names the comment it answers. This relationship corresponds to inReplyTo (Specification §8.4), whose value names the answered comment's file. Jira also supplies threadParentCreated, a denormalized copy of that comment's creation time. It has no separate Jekt correspondence because the answered comment records its own creation time. Reply text commonly begins with a mention of the person being answered; the person-reference correspondence in §3.3.6 preserves that independently.

Jira records the last comment revision in updated and the person who made it in updateauthor. Neither has a Jekt correspondence. Jekt defines no property for an artifact's modification and no second person role beside the author to whom the content is attributed.

Jira comment visibility has no correspondence in the current Jekt vocabulary because Jekt has no permission model that represents a source restriction on who may read a comment. (provisional)

3.8 Attachment

• UI label: Attachment
• REST field id: attachment
• Jekt correspondence: one file per attachment under attachments/, in a subdirectory named by the attachment's own Jira identifier

An attachment is stored at attachments/{id}/{filename}, such as attachments/10446/example-diagram.png for attachment 10446. Jira identifies and keys attachments by id rather than by name. Giving each attachment its own identifier directory gives every attachment a stable, distinct location while preserving the original filename, which prose uses to refer to the file (Specification §5.7, §8.8). Because the complete path comes from the Jira record, every import places the same attachment at the same location.

The imported filename comes from Jira's filename value. Jira also supplies displayname, which is identical in every observed record and has no established distinct purpose. It has no separate Jekt correspondence.

A sidecar beside the attachment, attachments/{id}/{filename}.-.yaml, records who uploaded the file and when (Specification §9.2). Jira calls the uploader author, but the field establishes only who added the file. It therefore corresponds to Jekt's creator (Specification §8.4), not author, which would attribute the file's contents to that person. The upload time corresponds to createdAt.

Jira's mimetype, filesize, and thumbnailable values have no Jekt correspondence. The imported file and its filename provide the information a Jekt reader needs; filesize restates the size of the file itself, while thumbnailable records only whether Jira could render a preview.

An attachment uploaded through a comment editor belongs to the issue like any other attachment and also identifies that comment. The additional relationship has no Jekt correspondence. Any comment may refer to any attachment on the issue, and Jekt preserves those relationships in the prose itself.