We have argued before that the half of governance built on habit gives way under load. The report that requires busy people to feed it honestly every day fails on precisely the weeks it was bought for. That is a claim about a category. This is the practical follow-on: how to test any single feature in your stack for it, before you find out the expensive way.
It takes about a minute per feature and needs no trial period. Four questions.
1. What has to happen every week for this to stay true?
Be specific, and count the people involved. “It reads the dates that are already on the tasks” and “everyone links their work to the right initiative” are not the same answer, even though both sound like normal usage when a salesperson says them.
If nothing has to happen, stop here. A feature that runs on dates that pass, links that exist, commits that land and timestamps that accumulate is load-bearing, and you can build on it. If the answer involves most of the team doing something habitually, keep going.
2. Is it the busiest people who have to do it?
Upkeep has a way of landing on leads, PMs and senior engineers, because they are the ones who understand the structure well enough to maintain it. They are also the first people pulled into an escalation.
This matters more than the raw volume of upkeep. A feature that needs five minutes a week from everyone degrades gracefully: some people skip, most do not. A feature that needs five minutes a week from the one person who is always in the room when things go wrong has a single point of failure, and that point fails first and fails exactly when the week turns.
3. What does it show when the feeding stops?
This is the question that separates a tolerable dependency from a dangerous one, and almost nobody asks it because you cannot see the answer during a good month.
If the feature goes blank, or greys out, or says last complete data: three weeks ago, it is safe. Wrong, but safely wrong, because you will know not to lean on it.
If it keeps rendering a plausible number, it is capable of misleading you, and it will do so at the worst possible moment. Utilisation built on time logging is the cleanest example. The view still draws, the bars still have heights, the percentage is still a percentage. It is now computed over a fortnight in which half the team stopped filling in timesheets, and less logging looks like less work, which looks like spare capacity. So it reports that the overloaded team has room, during the week they became overloaded, because becoming overloaded is what stopped them logging. There is no error state for that. The output looks the way it always looks.
Worth being precise here, since this is a feature we ship: capacity in SRP is derived from effort sizes, assignments, dates and time off rather than from anybody logging hours, and where those inputs are missing it returns no verdict rather than a reassuring one. That is the distinction the question is designed to draw out. Two features with the same name on the tin can sit on opposite sides of it.
4. Which direction does the wrongness point?
The absence-reads-as-health problem applies to individual features as much as to whole dashboards, and it is the fastest of the four to check: does this feature’s missing input make things look better or worse?
Grade optimistic failure harshly. A pessimistic one costs you a false alarm. An optimistic one costs you the quarter.
The point is weighting, not purity
It would be an easy overcorrection to conclude that anything needing human input should be stripped out. Plenty of what matters can only come from a person, and a tool that refuses human input on principle is not more rigorous, only less useful.
What the four questions give you is a sorting rule, not a hit list. Features that pass are what your safety net is made of. Features that fail are enrichment: worth having, worth reading during a calm month, never the only thing standing between you and a nasty surprise. Most stacks have this exactly inverted: the early warning depends on what people remembered to record, and the parts that need nothing are decorative.
The shorthand, if you only keep one line: if it would still be right after a fortnight where nobody touched the tool except to do the actual work, it is a capability. If not, it is a report on how diligent the team was, which is a different thing and worth much less at the moment you most need it.
SRP is built almost entirely from things that exist as byproducts of work happening: dates, links, activity, repository events. Run the four questions against it and we would rather you did than take our word for it.