Skip to main content
The Coverage panel gives you a journey-level view of what the journey is supposed to prove. You map acceptance criteria, tickets, and external work items to the journey, then use that map to find gaps — cases where intended behavior isn’t yet validated by any step or assertion.

​
When to use it

Use the Coverage panel when you want to confirm that a journey actually proves the behavior it’s supposed to. It’s the right place to answer: does this journey cover what we said it would? Coverage is particularly useful when:
  • Linking a journey to a feature spec, user story, or bug ticket.
  • Auditing whether new acceptance criteria have been addressed.
  • Reviewing what a journey proves before a release.

​
Key concepts

  • Acceptance criteria — the intended behaviors the journey is meant to validate. These can be written directly in Reqflo or imported from external tools.
  • Coverage mapping — the act of connecting acceptance criteria (or tickets/work items) to the journey so Reqflo knows what the journey is supposed to prove.
  • Gaps — acceptance criteria that are mapped to the journey but not yet addressed by any step or assertion. The panel surfaces these so you know what’s missing.
  • Journey-level view — Coverage is a journey-wide concern, not per-step. It answers whether the journey as a whole proves what it should.
  • External work items — you can connect tickets from external systems (e.g., Jira or Linear) to coverage entries, linking your API validation directly to the work that required it.

​
How it works

Open the Coverage panel from the Build-mode panel rail. The panel shows:
  • Mapped criteria — acceptance criteria already linked to this journey, with an indication of whether they’re addressed by current steps and assertions.
  • Gaps — criteria that are mapped but not yet covered. These may indicate missing steps, missing assertions, or planned behavior that hasn’t been built yet.
  • Add criteria — add new acceptance criteria directly, or connect existing tickets/work items from an integrated tool.
Coverage does not validate how well a step performs — that’s the role of assertions. Coverage answers the higher-level question: are the right things being tested at all?
Linking coverage to tickets (Jira, Linear) makes it easy to trace from a requirement directly to the journey that validates it — and vice versa. See integrations for setup.

​
Examples

A user-onboarding journey might map to:
Acceptance criteriaStatus
New user can register with valid emailCovered (step 1 + assertion)
Duplicate email returns 409Covered (step 2 + assertion)
User receives welcome email triggerGap — no step validates this yet
Rate limit enforced after 5 attemptsGap — not yet implemented
The two gaps tell you what’s missing from the journey’s current definition.

Coverage concept

The mental model behind coverage in Reqflo.

Assertions

How assertions validate step-level behavior.

Jira integration

Link coverage entries to Jira tickets.

Linear integration

Link coverage entries to Linear issues.