See everything. Block nothing.

Pulse shows PR cycle time broken down by repository, team, and author. PRs with unusually long open-to-merge times surface at the top of the cycle time view. You can filter by sprint date range to see which PRs were sitting unreviewed during the affected window and which reviewer or approval gate was the dependency. This is typically the fastest way to identify whether a bottleneck is a reviewer availability problem, a PR size problem, or a review quality loop problem.

Pulse surfaces finding adoption rate per engineer — the percentage of Mesrai's flagged issues that an engineer resolves before merging. A low adoption rate on security findings is a coaching signal; a high dismissal rate on style findings might mean the rules need recalibration. The data is designed to start a conversation, not to render a verdict. Sharing Pulse dashboards directly with engineers, rather than using them as a management-only view, produces better outcomes in practice.

Yes. Mesrai uses a three-layer rule hierarchy: organisation-wide rules that apply everywhere, team-level rules scoped to a group of repositories, and repo-level rules for per-service specifics. A platform team and a product team can have different naming conventions and performance thresholds while both inheriting the org-level security and data-handling rules. Changes to org rules propagate to all repositories immediately with no per-repo deployment.

In practice the opposite tends to happen. Senior engineers most commonly describe Mesrai as removing the most tedious part of their job — the first-pass review of obvious issues. They spend more time on architecture decisions, mentoring, and the genuinely interesting reviews. The engineers who find it most useful fastest are usually the ones who were most fatigued by repetitive review load. Framing the rollout as 'we are giving you back two hours a week' rather than 'we are monitoring your work' makes a significant difference.