[ atlas · the bpi vocabulary ]
Pattern Atlas
The named behavioral patterns Assemblr can detect across an engineering team's GitHub, Slack, and Linear. This is the open dictionary — the vocabulary of the Behavioural Process Intelligence category.
[ pattern · silent_merge ]
Silent merge
PR merged with no Slack/release-notes followup within 30 min.
Detection rule
merge event with no #releases post within 30 min AND no Slack DM mention by author
Why it matters
Merges without a follow-up create context loss for everyone except the author. Two weeks later, when an incident references the change, nobody can find why it shipped.
What healthy looks like
Every meaningful merge generates a one-line post in #releases or a Slack reply on the original thread. The author closes the loop, not their teammates.
[ pattern · orphan_ticket ]
Orphan ticket
Linear issue closed without a corresponding code merge in 7 days.
Detection rule
ticket transitions to done with no merged PR linked AND no merge in 7d window
Why it matters
Tickets closed without a corresponding merge mean the team is closing for accounting purposes, not because the work shipped. The roadmap looks healthy while the product doesn't move.
What healthy looks like
Tickets are closed only when the code lands. If work was abandoned, it's reopened as a decision (not deleted) so the team can revisit.
[ pattern · half_friday_ship ]
Half-Friday ship
Deploy after 3pm Friday with no rollback plan in PR.
Detection rule
deploy event 15:00-23:59 local Friday AND PR description lacks 'rollback' / 'revert' keyword
Why it matters
Friday-afternoon deploys without a rollback plan cause weekend on-call pages. The author has gone home; whoever is paged didn't ship the change.
What healthy looks like
Friday deploys have explicit rollback steps in the PR body, or are deferred to Monday morning. The team treats Friday-after-3pm as a gate, not a window.
[ pattern · ladder_break ]
Workflow gap
Cross-tool routine fires N-1 of N expected steps for ≥3 occurrences.
Detection rule
cross_toolkit_links sequence missing one step in ≥3 of last 5 occurrences
[ pattern · cold_review ]
Cold review
PR opened and merged with reviewer = author OR no review approval.
Detection rule
merge event with review_count = 0 OR all reviewers === pr.author_login
Why it matters
Self-merged PRs or PRs merged without review approval skip the team's biggest defect-catch step. A senior engineer never gets to teach via review.
What healthy looks like
Every meaningful PR has at least one substantive review comment from someone other than the author. LGTM-only reviews are flagged.
[ pattern · stale_design_code ]
Stale-design code
Code shipped where the linked design doc hasn't been touched in 30+ days.
Detection rule
merge event with linked Notion/Google Doc whose last_edit > 30d before merge
Why it matters
Code shipped against a 30-day-old design doc usually doesn't match the doc anymore. The next person to read the doc will trust it; the code will fight them.
What healthy looks like
Either the design doc gets a timestamp-update before merge, or the PR body includes a 1-line 'design has changed since: X' note.
[ pattern · postmortem_skip ]
Postmortem skip
Incident channel created, no postmortem doc within 7 days of resolution.
Detection rule
Slack channel matching incident-* with no postmortem-tagged Notion doc in 7d post-resolution
Why it matters
Incidents without postmortems repeat. The team learned nothing because nobody wrote down what was learned.
What healthy looks like
Every incident channel gets a postmortem doc within 7 days. Even a one-page postmortem is better than none.
[ pattern · phantom_standup ]
Phantom standup
Standup channel post pattern that ran ≥4 weeks then stopped ≥7 days ago.
Detection rule
Slack daily-standup pattern firing ≥80% in 4 prior weeks, then 0 in 7d window
Why it matters
Standups that ran for 4 weeks then stopped were doing real coordination work. When they stop, the coordination doesn't stop — it migrates to 1:1 Slacks and gets lossy.
What healthy looks like
The team explicitly retires or replaces the standup. Drift to silence is the failure mode; explicit replacement is the win.
[ pattern · solo_handoff ]
Solo handoff
Load-bearing actor performs ≥80% of a class for the period.
Detection rule
actor accounts for ≥0.80 of events in a behavioral class over 30d
Why it matters
When one engineer performs ≥80% of a class (reviews, deploys, on-call response), the team has a single point of failure on a daily activity. The day they're sick, the class breaks.
What healthy looks like
At least 3 engineers can perform each class. The team explicitly rotates so dependency doesn't form silently.
[ pattern · decay_drift ]
Decay drift
Ritual that fired ≥80% of expected times 30 days ago, now ≤40%.
Detection rule
lifecycle: thriving 30d ago → waning/dormant now
Why it matters
A ritual at 80% fire rate dropping to 40% is the same engineering org doing meaningfully less of what it used to do. Usually nobody noticed.
What healthy looks like
Drift detection surfaces the decay before it hits 40%. The team confirms (we don't need this anymore) or restores (we still need it, what changed?).
[ pattern · load_bearing_actor ]
Load-bearing actor
Bus-factor concentration: a single engineer holds ≥75% of a class.
Detection rule
concentration observer: actor centrality > 0.75 within a class scope
Why it matters
Bus-factor concentration is the most-common 'we should have known' surprise when someone leaves. The team didn't realize one person carried a critical area.
What healthy looks like
When concentration crosses 75%, the team gets a heads-up card. Either redistribute the load or document why concentration is OK.
[ pattern · ritual_decay ]
Ritual decay
Lifecycle moved from thriving to dormant within 60 days.
Detection rule
pattern_watchlist.metadata.lifecycle transitions thriving → dormant in 60d window
Why it matters
A ritual that moved from thriving to dormant in 60 days is usually the leading indicator of a quiet morale or process shift. Catching it early is the difference between adjusting and rebuilding.
What healthy looks like
Decay gets named before it completes. The team decides whether to revive, replace, or formally retire the ritual.