How Qity works
Every Qity app runs inside the Atlassian tools you already use. One distinction makes all of them easier to learn: Jira is where the work happens, and Confluence is where that work becomes formal documentation.
Jira is where you work
Quality records are native Jira work items. Requirements, specifications, risks, tests, changes, training records, quality events: you manage them in the same agile workflow your engineers already use, not in a separate compliance tool bolted on the side.
The tools around Jira feed into it as well. Design tools, source control, CI pipelines, and security scanners all flow in, so evidence accrues from everyday work instead of being written up afterwards.
Confluence is where documentation is produced
Formal documents live in Confluence, built from Qity macros inside document templates. The macros pull formatted Jira content, requirements, risks, and tests, onto the page, so every document is assembled from the quality data behind it rather than transcribed by hand.
Macros pull only when you ask them to. If Jira holds newer content than the page, the document flags itself as outdated, and a released version stays locked.
Why the split matters
Records are linked, not copied. There is one source of truth for every quality record, so there are no manual traceability matrices to maintain and no drift between what the product actually does and what the documentation claims.
In Document Control the controlled document itself is a Confluence page, with its metadata held in Jira, so that app is the one you drive mostly from Confluence. Every other Qity app is Jira-first.