Answering the operational questions engineers get wrong under pressure

The problem

Consider a concrete Tuesday. A service has started returning stale data. The on-call engineer suspects a caching header, opens the response, and reads:

Cache-Control: no-cache, s-maxage=600
Age: 540

Three separate traps are live in that one response. no-cache does not mean "do not cache": it means "revalidate before serving", and RFC 9111 is explicit about it. s-maxage applies only to shared caches, so it does nothing about the copy in the user's browser. And Age: 540 says nine of the ten minutes of shared freshness are gone; with no-cache present the CDN must revalidate before every reuse anyway, so that arithmetic starts to matter only when someone removes the directive to "fix" the staleness. Getting this right requires either having read RFC 9111 recently or having been burned by it before. At 02:00 the engineer has neither.

The same shape repeats across the whole surface of platform work:

• A livenessProbe with initialDelaySeconds: 10 on a JVM that takes forty seconds to warm up produces CrashLoopBackOff, and the pod events blame the application rather than the probe.
• Three services, each retrying three times with a 10-second timeout, produce a 27× amplification at the bottom of the call stack and a wait at the top measured in minutes. Nobody computed that number, because computing it requires multiplying numbers that live in three different repositories.
• A /24 looks generous for an EKS subnet until you subtract the five addresses AWS reserves and then divide what remains by the VPC CNI's per-node ENI allocation.
• (a+)+$ is a live denial-of-service vector under PCRE and provably linear under RE2. The pattern is identical. The answer depends entirely on which engine will run it, and a review comment saying "this regex looks dangerous" cannot resolve that on its own.

What these share is that the correct answer requires a small, exact computation over a specification, at a moment when nobody has the specification open. So the engineer guesses, the guess is plausible, and the incident review three weeks later identifies a "configuration error" without noticing that the configuration was written by someone who could not have got it right from memory.

The method

The design rests on one decision, and the decision has a cost.

The decision: every tool is a model of the rules, not a probe of your infrastructure. Nothing here resolves a hostname or reaches a cluster. It reasons about the config you paste, so there is nothing to send, because there is nothing that sends. The one exception is /libyear, which asks the public package registries (npm, PyPI, crates.io, Packagist, RubyGems) for release dates of the packages named in the manifest you paste; the page's Content-Security-Policy allows those five hosts and nothing else.

The cost, stated up front in the repository's own README: a tool can be right about the rules and still miss something only your live environment knows. /netpol does not know which pods exist. /certs does not know what your client's trust store holds. /redos answers per engine, and if you tell it the wrong engine it will confidently answer the wrong question. The tools are correct about the specification and silent about your reality, and the documentation says so.

Four consequences follow.

State lives in the URL fragment. Everything a tool needs to reproduce its answer is LZ-compressed into the part of the URL after the #. Browsers never transmit a fragment upstream, so a pasted config with internal hostnames stays in the tab even when the site is served from static hosting with access logging enabled. The architecture note records the alternative: the query string would have been simpler, and crawlable, and would have put IAM policies, certificate chains and internal hostnames into every access log on the way.

Every route is a real static file. The build pre-renders dist/<slug>/index.html for every page in the sitemap (eighty-nine: the index, the twenty-eight tools and the sixty catalogue pages described below), each with its own title, description, canonical and Open Graph tags, plus sitemap.xml and robots.txt. No SPA fallback, no server rewrites, no hash-based routing for the path itself. A tool is legible before any JavaScript executes, which also makes it usable on a restricted corporate browser that would otherwise show a blank page.

Engines are pure, framework-free TypeScript, under src/lib/<engine>/ behind path aliases, with no React imports and no DOM access. They take plain objects and return plain objects, so the test suite exercises the reasoning rather than a rendering of it, and any engine could be extracted and published as a standalone package later.

Simulators are seeded. Anything with randomness — the retry and jitter simulator most obviously — draws from a seeded PRNG whose seed travels in the URL alongside the inputs, so a shared link shows its recipient the same chart its author saw.

The headline results

• Accessibility is tested, not asserted.
• Privacy can be checked in the network tab.
• Dataset gaps are recorded, not filled.

The full results, with the tables and the reasoning behind each figure, are in the PDF.