Picture the coordinator this is written for, because it is probably you: a PM running a team of about ten — some technical, some not — plus an external dev agency, across a Jira project everyone touches differently. The agency's tickets say Done and mean "merged." Your designer's Done means "handed off." An AI agent asked whether its task is done — and most teams now have agents doing a share of the implementation — says yes. Nobody is lying. Done just means different things to different columns. So the weekly summary gets written by hand, from interviews, and everyone half-believes it.
Sooner or later that coordinator asks the integration question, and it is really two questions: if we added Assay under this project, where would the record live — and what happens to our approvals? Here is the one sentence the rest of this article unpacks: a Jira approval certifies that the workflow, as currently configured, was satisfied; Assay's record of done lives outside anyone's workflow configuration — and where the record lives is the whole game. The queue, the boards, the epics: those stay in Jira. Nothing gets replaced.
status you assert, status you derive
Jira answers "what work exists and where does each item stand, as asserted by whoever last moved it." That is not a defect; it is what a tracker is for. Assay answers a different question: "what does the evidence support saying about this work?" Its board is not a surface people update — it is a build artifact. A program computes it from the work documents themselves: briefs, registers, evidence blocks, review verdicts. That program is the board's only writer, so there is no card to drag to make the roadmap look better; there is no card at all, only sources and a projection of them.
The honest form of that claim, which Assay makes everywhere: the board is derived from the work documents with consistency linting, not measured from some infallible ground truth. Its value is that drift, missing evidence, and quiet edits become machine-visible — not that anyone becomes magically trustworthy.
assay, translated into jira vocabulary
Take one ticket — say, "migrate the export job." In Jira it is an issue: a prose description, an epic link, an assignee, a column. Restated as an Assay brief, it becomes a ticket with a contract: a typed spec whose scope, dependencies, and definition of done are fields a linter fails when one is missing or a dependency dangles. An issue description is prose a human reads; a brief is a document a machine can call incomplete. The rest of the vocabulary maps the same way:
- A stream is roughly an epic: a named initiative that briefs belong to, with a priority and an owner.
- A wave is what your "blocks / is blocked by" links are trying to be: a dependency layer, not a sprint. Waves say what can start, not what will ship this fortnight.
- The lifecycle looks like a five-column workflow — todo, in-progress, implemented, verified, done — with one column Jira doesn't have: verified means someone other than the implementer re-ran the checks. A file lint rejects records that read as self-verification (best-effort — it catches the detectable cases; cross-session independence is enforced by process). The platform-enforced half is the review verdict, which the next section is about.
- The board is your dashboard, generated as above — diffable against last week's, because it is a committed artifact rather than database state.
Every row of that mapping is comfortable. One is not, and it is the load-bearing one.
the row that doesn't map: approvals
Jira has approvals and workflow rules, and they are genuinely useful — but they are configuration, and configuration is admin-editable. You can confirm this on your own instance in about two minutes, which is the whole argument, so do it: open the workflow editor for the project you run. Atlassian's documentation is plain about what you will find — site admins (and, in team-managed projects, project or space admins) edit workflows: the statuses, the transitions, and the rules on them, validators included (work with issue workflows). Approval steps in Jira Service Management are themselves configured in the workflow, or on the request type in team-managed projects (what are approvals) — either way, inside your organization's own admin domain. The organization audit log, on plans that include it, keeps such changes for up to 180 days (audit log activities). It records. It does not prevent.
So ask, while the editor is open: who in this organization could edit the approval step out of this workflow? That person exists, and they work inside the domain the approval is supposed to gate. A Jira approval therefore certifies exactly this: the workflow, as currently configured, was satisfied. The gate and the gated sit in the same admin domain.
Assay's sign-off is built the other way around. A review verdict is a real review on a real pull request, submitted by a separate application identity that the platform itself attributes — and the platform blocks self-approval, so an implementer cannot mint the verdict on its own work. The record is git plus platform history: commits, reviews, verification runs. There is no settings screen inside the project from which that history can be edited into compliance.
This is not a dig at Jira; for human-paced process, easy-to-change workflow is a feature. But if your pain is "done stopped being trustworthy" — or "the agent said it was done" — then where the record lives is the whole game, and it is why the record deliberately does not live in Jira.
agents made this the default case
Atlassian's AI-native Jira launch (2026-07-15; we re-checked the announcement on 2026-08-19) makes the agent version of this the default, not the edge case: work items assign directly to Claude Code, Cursor, or GitHub Copilot; a built-in Jira Coding Agent, included in paid Jira plans, takes a scoped work item and returns a ready-to-review pull request; and admin automation rules route routine work to agents automatically. Agent sessions are recorded on the Jira work item, with Teamwork Graph supplying the context agents draw on.
None of that moves the record. The session history is an observability surface in the same admin domain as every other Jira surface; status is still asserted, now by agents too; and the automation rules that route work to agents are themselves ordinary admin-editable configuration. The two-minute check above covers agent-routed work with no modification — which strengthens the case for a pilot rather than weakening it, because more work than ever flows through the queue while the question of the record stays exactly where it was.
the shapes that survive contact
Four integration shapes come up in every conversation about this, and they sort quickly once "where does the record live" is the test:
- One-way mirror (Assay → Jira): boards and dashboards stay populated from Assay's generated state; dragging a mirrored card changes nothing and the next push snaps it back. Safe and small.
- Two-way sync: the obvious ask and the trap — it makes the board hand-editable again, imports admin-editable card-drags into the evidence chain, and rebuilds the exact two-versions-of-the-truth problem you already have. Declined by design; better said in the first meeting than in the incident review.
- Jira as the front door: the team files and triages in Jira; marked issues flow into Assay's intake and are restated as briefs; evidence receipts flow back as comments. Recommended.
- A native Jira app rendering the board read-only inside Jira: sensible later, if demand shows up.
Front door in, mirror out is not just an architecture — it is a pilot you could run without asking your team to change anything. Point Assay at one existing queue, an epic or a label, real but inconsequential. On day one nobody changes habits: marked issues are ingested and restated as briefs (which forces the one conversation worth having — what would done, checkably, mean for this ticket?); the generator produces the daily board; each source ticket accumulates receipts as comments. Success criteria stated up front so the pilot can fail honestly: fewer or shorter status meetings, zero "where are we on X?" pings for pilot-scope items, and one weekly roadmap artifact nobody wrote by hand. If after three weeks the generated answers aren't beating the hand-assembled ones, stop. That is the deal.
the edges, stated plainly
- Work that doesn't live in git gets lighter-weight checking. Assay's record is markdown documents and pull requests in a repository — that is what the linter reads and what the gates attach to. A Figma file, a spreadsheet, an ad campaign can be referenced by link inside a brief's evidence, but the machinery cannot re-run or lint what it cannot read: for those lanes, done is still gated and dated, but the evidence is a pointer, not a re-runnable check. Extending evidence beyond git-native artifacts is an open design edge, flagged rather than overclaimed.
- If sign-off must happen in Jira for compliance reasons, Assay's core guarantee does not transfer. You can mirror the gate's outcome into Jira; the gate itself cannot live in an admin-editable panel. For some organizations that is disqualifying — better known in the first conversation.
- None of this is built. The connector is a design, not a product, and it is not currently scheduled — a pilot is what would prioritize it. Assay's lived evidence so far is a single-operator agent fleet on real, funds-adjacent software; a ten-person mixed team coordinating an agency is exactly the setting a pilot exists to test, not a proven deployment.
The question under the question is usually "can we get the benefit without leaving home?" Mostly, yes: keep the queue, keep the boards, keep filing where you file. Then run the two-minute check and ask who could edit the approval step out of your workflow — because being able to answer that is being able to explain the whole design. A Jira approval certifies that the workflow, as currently configured, was satisfied. Assay's record of done would live outside that configuration, in git, under identities the platform attributes — and where the record lives is the whole game.
Jira capability claims on this page are cited inline to Atlassian's public documentation and were checked against those pages on 2026-08-19. Jira, Jira Service Management, and Atlassian are trademarks of Atlassian Corporation; Assay is not affiliated with or endorsed by Atlassian.