How engineering conversations changed BlockerDeck's traceability engine
We thought every engineering team linked code to work items the same way.
We were wrong.
After talking to engineers from different companies, we found there is no standard for maintaining traceability between code and work items. Teams use branch names, commit messages, PR titles, work item links, or nothing at all, depending on their tools, their policies, and their habits.
That changed how we are building BlockerDeck.
Why this matters: If BlockerDeck links the wrong task, the wrong work item gets blocked. If it misses the task completely, engineering managers never see the delivery risk. Getting traceability right is the foundation of everything else.
The Challenge
BlockerDeck originally relied on a single signal: the branch name. The assumption was straightforward. If a developer is working on task PT-123, their branch is probably named feature/PT-123-signup-flow.
This worked fine for some teams. It failed silently for many others.
Before -- single signal
CI Failure
workflow_run event
Extract key from branch name
"feature/signup-reward" → No key found
❌ Recorded as unlinked
Task never blocked
What We Learned
Across discussions with engineers using GitHub, GitLab, Azure DevOps, Bitbucket, and Perforce, one pattern became clear: no two teams handle traceability the same way.
Some teams enforce branch naming conventions via policy. The branch must start with a ticket ID.
Others write the task key in commit messages and keep branch names short and descriptive.
Many teams include ticket references in PR titles, particularly in GitHub and GitLab workflows.
Azure DevOps teams often link work items directly to the PR, with no key in the branch or commit at all.
Some PRs span multiple work items, raising the question of whether one CI failure should affect several tasks.
Many smaller teams rely on convention with no enforcement, and conventions drift.
How This Changed BlockerDeck
Instead of relying only on the branch name, I'm redesigning BlockerDeck to consider multiple sources of traceability. The new approach combines multiple traceability signals to improve the confidence of a match.
Example -- Conceptual Matching Flow
Multiple engineering signals
Higher-confidence work-item match
New direction -- multi-signal engine
CI Failure
workflow_run event
Multiple engineering signals analyzed
Higher-confidence work-item match
✓ Task can be automatically linked to the failure
CI failure linked
Task detail view
What we're changing
Before
New Direction
Why This Matters
Adapts to your team's workflow
No need to rename branches or change commit conventions. BlockerDeck works with the signals your team already produces.
Fewer missed failures
CI failures that were previously lost as unlinked events now reach the right task before the engineering manager notices the slip.
Transparent decisions
The signal that triggered the block is visible in the task detail view. Engineers always know exactly why something was auto-blocked.
Multiple work items, one CI event
A single technical failure can have a wider impact than one work item.
Research Timeline
Mar 2026
Initial implementation
Started with branch-name-based task traceability.
May 2026
Started talking to engineering teams
Engineering discovery across GitHub, GitLab, Azure DevOps
Jun 2026
Existing assumption challenged
Found different workflows across teams and tools.
Jul 2026
Redesigned the traceability engine
Multi-signal architecture
Aug 2026
Multi-signal prototype implemented
Multiple traceability signals
Have a different workflow?
I'd genuinely like to understand how your team handles traceability between code and work items.
How does your team link CI failures to the right work item today?
Do you enforce branch naming, or rely on commit messages?
What edge cases would break this multi-signal approach for your team?
Research
Engineering discussions
12+
Platforms
GitHub
GitLab
Azure DevOps
Bitbucket
Perforce
Updated
August 2026
Status
OngoingRelated Research
Deployment Verification
How BlockerDeck verifies a deployment actually completed before marking a task unblocked.
Follow the research →
ReleaseRelease Readiness
How BlockerDeck surfaces release risk before stakeholders ask about it.
Follow the research →
EnvironmentsEnvironment Blockers
How BlockerDeck detects when a task is stuck waiting on a shared test environment.
Follow the research →