[integrity] DIFC Integrity-Filtered Events Report — 2026-04-13

[github-actions[bot]]

Executive Summary

In the last 7 days, 263 DIFC integrity-filtered events were detected across 50 workflow runs spanning 16 distinct workflows. The most frequently filtered tool was list_issues (150 events, 57%), followed by search_issues (55, 21%) and pull_request_read (37, 14%). Every single filtered event was caused by the same root cause: integrity_too_low — resources (issues, PRs, commits) authored by external contributors carry the none:all integrity tag, which falls below the agent's required approved threshold.

The volume spiked sharply on 2026-04-13 with 166 events (63% of the weekly total), primarily driven by Auto-Triage Issues (67 events) and the Dev workflow (32 events). There is no secrecy-related filtering whatsoever — this is entirely an integrity boundary issue where community-authored content is blocked from being processed by workflows that require "approved" integrity-level resources.

Key Metrics

Metric	Value
Total filtered events	263
Unique tools filtered	5
Unique workflows affected	16
Most common filter reason	integrity_too_low (100%)
Dominant integrity tag	none:all (263 events)
Secondary integrity tag	unapproved:all (9 events)
Busiest day	2026-04-13 (166 events)
No. of runs analyzed	50

📈 Events Over Time

Date	Count
2026-04-10	28
2026-04-11	7
2026-04-12	62
2026-04-13	166

The trend is strongly increasing, with a 2.7× jump from Apr 12 to Apr 13. This aligns with higher community PR/issue activity on weekdays (Apr 13 was a Sunday, Apr 12 Saturday — but the surge likely reflects a batch of community contributions arriving over the weekend being triaged by automated workflows on Monday morning). The low Apr 11 count (7 events) coincides with fewer community PRs on that day.

Charts uploaded as run artifacts for this workflow run (§24364571228).

🔧 Top Filtered Tools

Tool	Events	%
list_issues	150	57.0%
search_issues	55	20.9%
pull_request_read	37	14.1%
list_commits	20	7.6%
issue_read	1	0.4%

list_issues dominates because it returns batches of issues at once — a single list_issues call can surface many issues authored by community members with none:all integrity, producing multiple filtered events per call. search_issues has the same amplification effect. This explains why workflows like Auto-Triage Issues and Dev accumulate high event counts quickly.

🏷️ Filter Reasons and Tags

All 263 events share the single reason: "Resource has lower integrity than agent requires" — the agent threshold is approved but all filtered resources carry none:all (263 events) or unapproved:all (9 events). There are zero secrecy-related filtered events, confirming that information flow control is operating correctly in the secrecy dimension; only the integrity dimension is generating noise.

📋 Per-Workflow Breakdown

Workflow	Filtered Events
Auto-Triage Issues	67
Dev	32
Design Decision Gate 🏗️	28
The Daily Repository Chronicle	26
Sub-Issue Closer	22
Weekly Issue Summary	21
Dependabot Dependency Checker	20
Agent Performance Analyzer - Meta-Orchestrator	14
Issue Triage Agent	13
Daily Team Evolution Insights	9
Daily Copilot PR Merged Report	4
Smoke Claude	3
Daily Community Attribution Updater	1
Smoke Copilot	1
Workflow Health Manager - Meta-Orchestrator	1
Test Quality Sentinel	1

📋 Per-Server Breakdown

MCP Server	Filtered Events
github	263 (100%)

All filtered events originate from the github MCP server. No other MCP server triggered integrity filtering during this period.

👥 Top 20 Issue/PR Authors Triggering Filtered Events

These are authors of the issues/PRs that workflows attempted to read but were blocked by the integrity gate:

Author	Filtered Events
yskopets	18
JanKrivanek	17
jaroslawgajewski	15
dkurepa	15
gopherbot	15
kthompson	14
jfomhover	13
arthurfvives	13
bbonafed	11
tadelesh	10
duncankmckinnon	9
szabta89	7
johnpreed	6
shea-parkes	4
susmahad	4
jeremiah-snee-openx	3
wtgodbe	3
strawgate	2
glitch-ux	2
neta-vega	2

Note: 37 events show "unknown" author (from pull_request_read and list_commits which don't expose an author login in the filtered event).

🔍 Tuning Recommendations

1. High-volume triage workflows need integrity-aware filtering at the query level

Auto-Triage Issues (67 events) and Dev (32 events) together account for 37.6% of all filtered events. Both workflows issue list_issues or search_issues calls that return community-authored issues with none:all integrity. Recommendation: Add a pre-filter step that only passes issues with approved or higher integrity to the agent, or configure these workflows with a lower integrity threshold if community issue processing is intentional and safe.

2. Design Decision Gate PR filtering is expected but could be optimised

28 events from Design Decision Gate 🏗️, each filtering exactly 1 PR per run (the Copilot-authored PR being evaluated). The gate correctly blocks reading the PR body/commits before integrity approval. Recommendation: This is working as designed — Copilot PRs arrive with none:all until reviewed. No tuning needed, but consider explicitly documenting this as expected behaviour in the workflow definition.

3. Sub-Issue Closer and Weekly Issue Summary warrant review

Sub-Issue Closer (22 events) and Weekly Issue Summary (21 events) show significant filtering. These workflows likely iterate over open issues without pre-filtering by integrity. Recommendation: Review whether these workflows actually need to process community-authored issues, or can be scoped to approved issues only to reduce noise and avoid integrity-gate failures.

4. Dependabot Dependency Checker commit filtering (20 events)

All 20 events are list_commits calls, likely reading Dependabot PR commits. Dependabot is a machine actor (gopherbot appears in the top users list with 15 events). Recommendation: Consider granting Dependabot-generated content an approved integrity label via a dedicated bot-trust rule, since Dependabot commits are deterministically generated and low-risk.

5. Consider unapproved:all tag escalation path

9 events involve the unapproved:all secondary integrity tag. These represent resources that have been explicitly tagged as unapproved (rather than simply untagged). Recommendation: Audit which resources carry this tag and whether a human review workflow should be triggered to escalate them to approved.

6. Apr 13 spike — Monitor for recurrence

The 2.7× spike on Apr 13 (166 events vs 62 on Apr 12) should be monitored. If a similar spike occurs next Sunday/Monday, it confirms a weekly batch-processing pattern. Consider rate-limiting automated triage workflows during low-activity windows to spread the load.

---

References:

• §24364571228 — This analysis run

Generated by Daily DIFC Integrity-Filtered Events Analyzer · ● 3.5M · ◷

• expires on Apr 16, 2026, 8:52 PM UTC

[github-actions[bot]]

This discussion has been marked as outdated by Daily DIFC Integrity-Filtered Events Analyzer.

A newer discussion is available at Discussion #26283.