"Enforce engineering standards" appears on a great many product pages. Read the documentation underneath and the mechanism is usually a scheduled evaluation that produces a score. A score and a gate are different instruments with different failure modes, and the difference decides whether a standard holds.
A score and a gate are not the same instrument
A gate is synchronous and binary. It runs at a specific moment in the workflow, it returns pass or fail, and failing stops the change. Its cost is paid by the person making the change, at the moment they make it, and it is unavoidable.
A report is asynchronous and graded. It runs on some cadence, produces a number or a badge, and displays it. Its cost is paid by whoever is assigned to improve the number, at some later point, in competition with feature work. It is entirely avoidable, and it is routinely avoided — not through bad faith, but because a dashboard entry has no deadline attached and a sprint does.
The revealing detail is what vendors build next. Several internal developer portal products have added campaign, initiative, or nag layers on top of their scorecards — mechanisms for assigning owners, setting deadlines, and sending reminders. That is a well-observed admission from the vendors closest to the data: the dashboard alone does not change behaviour, so a second system is needed to chase people about the first one.
Where standards actually get evaluated
Being precise here matters, because the marketing language and the documentation frequently diverge.
Internal developer portals evaluate standards in their own backend, on a schedule or on property change, and surface the result as a scorecard. Data flows from your CI and your version control system into the portal. It does not generally flow back as a merge gate — several vendors' own documentation describes dashboards, badges, and notifications rather than build failures.
Datadog's scorecards are a clear, publicly documented example of the pattern: rules are evaluated on a 24-hour cycle. That is a reasonable design for a portfolio view. It is structurally incapable of being a merge gate, because a merge decision has to be made in minutes and a daily cycle answers a different question. Datadog does have merge-blocking capability — it lives in a separate product, Quality Gates, with its own configuration and its own pricing.
None of this is a criticism. A scheduled portfolio view is genuinely useful for the question "how are 400 services doing?" The error is reading it as an answer to "can this pull request merge?"
Plenty of tools can fail a build
It would be false to suggest that build-failing enforcement is rare or unclaimed. It is neither.
Danger.js has enforced pull request conventions in CI for the better part of a decade. Semgrep fails builds on pattern matches. Sonar's quality gates fail builds on code quality thresholds. Every linter, type checker, and test runner in existence fails builds. Datadog's own PR-time gating product blocks merges. Coverage thresholds, licence scanners, secret detectors, dependency audits — all of them gate.
Enforcement is a solved capability. Anyone claiming to be alone in it is either uninformed or hoping you are.
The distinction is what is being gated
Line up what the build-failing tools listed above actually check, and a pattern emerges. Every one of them gates code — its syntax, its types, its test results, its security patterns, its dependencies, its coverage. The portals gate nothing at merge time but report on service metadata: ownership fields, on-call rotas, whether a README exists.
Neither category gates the structural integrity of the repository's own knowledge layer. Whether the folder holding your domain documents still has an index. Whether a document was renamed while nine other documents still reference the old name. Whether someone created a parallel file with a version suffix and forked the truth. Whether the routing an agent depends on to navigate the layer still resolves.
These are decidable conditions — a script can answer each one with no understanding of content whatsoever — and they are not covered by any of the tooling above. A repository can pass every linter, hit every coverage threshold, and satisfy every scorecard rule while its knowledge layer has quietly become unnavigable.
What a scheduled report is genuinely good for
Framing this as gates good, reports bad would be a caricature. The two answer different questions and an organisation of any size needs both.
A report is the right instrument when the question is about a portfolio rather than a change. How many of our 300 services have an owner recorded? Which teams are carrying the most repositories without a governed knowledge layer? Is the situation improving quarter over quarter? None of these can be answered by a gate, because a gate sees one change at a time and has no view across the estate.
A report is also the right instrument for anything requiring judgement, or anything where the fix is not available to the person triggering the check. Blocking a developer's merge because a service they did not create lacks an on-call rota is a category error: they cannot fix it, so the block is pure friction and it will be routed around within a week.
The rule that follows is straightforward. Gate the things that are unambiguous and fixable by whoever hit them. Report the things that are contextual, contested, or owned by someone else. Products get into trouble when they market the second as the first — and teams get into trouble when they buy a reporting product expecting standards to hold, then conclude that standards do not work.
What a knowledge-layer gate can and cannot assert
Precision is important here, because this is exactly where an overclaim would be easy.
What such a check can assert: that every folder holding documents has an index; that no two sibling documents share an ordering prefix; that no document carries a version suffix; that no reference points at a name that was retired; that the skills routing is valid. Each of these is a structural property, mechanically decidable, with no judgement involved.
What it cannot assert: that any document is accurate. That a decision record still reflects what the team is doing. That prose matches implementation. A guard that never reads your source code cannot compare prose against it, and no honest tool in this space claims otherwise. Codee3's guards check the structure of the governed .ai/ directory and nothing beyond it.
This is a narrower claim than "we enforce documentation quality", and narrowness is the point. A check that fails a build must be one you can defend at 6pm on a Friday to someone whose fix is blocked. Structural conditions are defensible because they are unambiguous and the fix is obvious. Judgement calls are not, and they get switched off — which is how enforcement decays into reporting.
Warn before you block
The correct rollout is phased, and it is the same in every organisation that has made a gate stick.
Run the check in reporting mode first. Let it produce warnings while people see what it flags and fix the existing violations at their own pace. Then, once the baseline is clean and nobody is surprised by what the check does, turn on blocking for new violations.
Skipping the warning phase is the most reliable way to kill a gate. Turning on enforcement against a repository with 200 pre-existing violations blocks everyone immediately, generates an emergency, and results in the check being disabled — after which it is politically much harder to introduce a second time. Related considerations about what to measure, and what to leave alone, are in what to measure, and what not to.