Help: My push protection is blocking internal service account tokens.

Our organization has recently enforced GitHub Advanced Security push protection across all repositories, and we are encountering a significant operational hurdle. The system is correctly identifying and blocking potential secrets, which is its intended function. However, it is generating a high volume of false positives by flagging internally generated service account tokens and machine identities that are, by our security policy, valid for use within our private ecosystem. This is causing substantial development friction and deployment failures.

The core issue appears to be that our internally issued tokens, which follow a predictable pattern (e.g., `ghp_`-like prefixes for our internal GitHub instance, or `abcde`-style strings for our CI/CD runners), are being caught by the generic secret patterns. We have attempted to address this by creating custom patterns in the repository or organization security settings, but the results have been inconsistent. For some token types, the push protection still triggers an alert even after the pattern is added to the allowed list.

I have documented our current configuration and the specific error flow. Our setup involves:

* **GitHub Enterprise Cloud** with Advanced Security enabled.
* **Internal GitHub Instance** (GHES) for some legacy projects, requiring service tokens.
* **Custom CI/CD System** that generates deployment tokens prefixed with `myorg_ci_`.

Our push protection is configured at the organization level. We attempted to add the following custom allowed patterns:

```json
{
"patterns": [
{
"name": "internal-ghes-token",
"pattern": "ghp_[a-zA-Z0-9]{36}",
"description": "Internal GHES service account token"
},
{
"name": "internal-ci-token",
"pattern": "myorg_ci_[a-zA-Z0-9]{40}",
"pattern_id": "myorg-ci-token",
"description": "Internal CI/CD system token"
}
]
}
```

Despite this configuration, pushes containing strings matching `myorg_ci_` are still being blocked approximately 40% of the time, according to our logs from the past week. The error returned to the developer is the standard push protection alert, without indication that it matches an allowed pattern.

My specific questions for the community are:

* What is the exact order of evaluation for push protection? Does it check custom allowed patterns *before* or *after* the built-in secret patterns?
* Are there limitations on the regularity or complexity of custom patterns that would cause intermittent failure? Our logs show no errors in the pattern definition itself.
* Has anyone successfully implemented a workflow where internal, non-secret tokens are whitelisted at scale, and if so, what was the precise configuration hierarchy (organization -> repository -> branch)?
* Is there a latency or propagation issue with custom pattern updates? We observed a 15-20 minute delay between updating the organization settings and some repositories respecting the change, while others updated immediately.

The operational cost of this is becoming non-trivial. We are tracking approximately 15 developer-hours per week spent on troubleshooting these blocked pushes and manually overriding with `--no-verify`, which defeats the security purpose. I need to quantify the efficacy and failure rate of the custom pattern system to determine if we need to adjust our token generation schemas or if there is a configuration gap we are missing.

Show me the bill.