Every part of this arc closes by saying what its argument cannot do. That is one half of an honesty discipline. This is the other half.
What follows are failure modes of systems built to provide assurance — evidence pipelines, conformance harnesses, policy engines, agent supervisors, the whole category. None of them is a bug in the ordinary sense. Nothing crashes. No test goes red. In every case the system produces output that is well-formed, plausible, and more complete-looking than the reality underneath it, which is precisely why they survive review.
They share one root. An assurance system is judged, socially and commercially, on whether its output looks complete. Every failure below makes the output look more complete. The pressure runs one way.
One — the endpoint that answers every question the same way
A component is stood up early, before it does anything, with a placeholder health endpoint so the orchestrator will schedule it and the integration work can proceed. The placeholder answers `200 OK`.
It answers `200 OK` to `/healthz`. It also answers `200 OK` to `/ready`, to `/metrics`, to `/api/v1/verify`, and to `/does-not-exist`. It is not implementing health; it is returning success to any path presented to it, because that was the fastest way to make the scheduler stop complaining.
Then the placeholder stays. It stays because it works — the orchestrator is satisfied, the dashboard is green, and the thing it is standing in for is scheduled for next quarter.
What makes this a lie rather than a stub is the consumer. Something downstream is now asking that endpoint a real question and reading its answer as real. A readiness probe concludes the component is ready. A verification step concludes verification passed. A dependency check concludes the dependency is healthy. Every one of those conclusions is correct given the response and false given the world.
The property to test for is not whether the endpoint responds. It is whether it can ever not respond affirmatively. A health check that has never returned a failure in production is either fronting a component that has never been unhealthy — possible, and rare — or it is incapable of expressing failure. Those two look identical on a dashboard and are opposite conditions.
The discipline: *a stub must fail loudly, not succeed quietly.* If a component is not implemented, its endpoint should return an error that names itself as unimplemented. That breaks the dashboard, which is the point — a broken dashboard is an accurate one. The version that returns success is not saving you work; it is deferring the work and removing the signal that would have reminded you.
Two — the component that nothing calls
A library is written. It is correct. It has tests, and the tests pass. It is exactly the component the design called for.
Nothing imports it.
This happens to every system of any size, and in a large fraction of cases it is fine — standalone libraries are supposed to be standalone, and a component built ahead of its consumer is normal engineering. The failure is not the existence of unwired components. It is that *nobody knows which category each one is in*, and the inventory that would tell them does not exist.
The consequence is specific and it is about claims rather than code. Somebody writes a document listing capabilities, and the list is generated from what exists rather than from what is reachable. Every entry is true as a statement about the repository and false as a statement about the running system. The document is not dishonest; it is answering a different question from the one its reader is asking.
This becomes an assurance failure at the moment someone asks does this system enforce X? and the answer is yes-because-the-enforcer-exists rather than yes-because-a-request-passes-through-it.
The discipline: *maintain a reachability census, not a component list.* For every component that participates in a security or assurance claim, record what calls it, and treat "nothing" as a finding rather than a status. The census will be uncomfortable the first time it is run. That discomfort is the information.
Three — the limit that does not say whether it holds
A report lists the constraints under which a system operated. Tools, write scope, network egress, deadline, spend ceiling. Five limits, rendered identically, in one list.
Four of them were enforced: the system refused to exceed them. One of them — spend — was observed, because the metered calls did not traverse the enforcement point, so the ceiling was a number being watched rather than a wall.
The report does not distinguish. It cannot, because the report's data model has one field for limits.
This is the failure with the widest blast radius, and it is entirely a schema decision. The reader — an auditor, a risk committee, an engineer inheriting the system — reasonably assumes uniform treatment, because uniform rendering implies it. They then allocate attention accordingly, which means they allocate none to the measured limit, because the report says it is handled.
A limit you believe in that does not hold is worse than no limit, because you staffed around it.
With no limit, someone watches. With a limit believed enforced, nobody watches. The gap is invisible until it is expensive, and it was never a technical failure — the system behaved exactly as built. It was a failure to say what the system was.
The discipline: *every limit carries an enforcement flag, and every rendering repeats it.* Not a footnote, not an appendix, not documentation elsewhere. In the row, next to the value, every time it is displayed. A report where all limits are marked enforced is either an unusually complete system or a system where nobody has asked, and the flag makes the question unavoidable.
Four — the gate that went green because the tooling was missing
A verification step runs in a pipeline. It checks something real — cross-language conformance, schema compatibility, a signature, a policy compilation. On a correctly configured machine it does exactly what it claims.
On a machine where the required toolchain is absent, it finds nothing to check, has no failures to report, and exits successfully.
The pipeline goes green. The gate is recorded as passed. And the gate was not passed — it was *not run*, which is a different state that the output has no vocabulary for.
This is the most common failure in this list and the least discussed, because it hides inside a genuine convenience: skipping unavailable checks is what lets a test suite run on a developer laptop without every dependency installed. The convenience is real. The problem is that skipped and passed are rendered identically, so the property degrades silently as environments drift.
The characteristic signature is a check that has never failed and never been observed to run. Nobody notices, because nobody audits their green results — green is what you look away from.
The discipline: *fail closed on absence. A check that cannot run must exit non-zero and name the missing dependency and the command that installs it. An empty inventory is a failure, not a pass. If skipping is genuinely required for local development, it must produce a distinct third state that no aggregate reports as success. The rule stated plainly: a missing toolchain must never be reported as a skipped green gate.*
Five — the claim that inherits its confidence from a configuration value
A system emits records describing what it enforced. Each record carries a field naming the enforcement posture it was operating under — say, whether it was mediating actions or merely observing them.
The field is populated from configuration.
So a deployment that sets the value to `mediated` emits records asserting mediation, whether or not anything is mediated. Downstream, a report aggregates those records and concludes the system was operating under containment — a conclusion drawn, through several layers of well-engineered indirection, from a string someone typed in a YAML file.
Nothing here is a bug. Every component did what it was built to do. The failure is that the strongest claim in the output has a weaker provenance than any other claim in it, and the output does not say so.
This is the same structure as the isolation claims discussed in Part III of this arc, appearing one layer down. It is worth stating as its own rule because it is the one an assurance vendor is most likely to build accidentally, and it is very hard to see from inside.
The discipline: *a claim may never be stronger than its weakest input, and the record must carry the provenance.* If a posture is self-declared, the record says self-declared. If it is substantiated by an escape suite, the record carries a reference to the suite result and its date. A record that asserts containment with no attached substantiation should be rejected by the thing that consumes it, not rendered as a green tick.
The shape they share
Read together, none of the five is a failure of correctness. Every component behaved as specified. In four of five cases there is no code change that fixes the problem, because the problem is what the output means rather than what the code does.
They share a direction, too. Every one makes the output look better than the reality: a component appears healthy, a capability appears present, a limit appears enforced, a check appears passed, a boundary appears held. None of them makes a system look worse than it is.
That asymmetry is not coincidence. Failures that make output look worse get found immediately, because someone is annoyed by them and fixes them that afternoon. Failures that make output look better are load-bearing for someone's status report and survive indefinitely.
A green result is the least trustworthy output an assurance system produces, because it is the only output nobody investigates.
The questions that surface them
For any assurance system, including one you built and especially one you are buying:
- *Show me this health check returning a failure.* Not a description of when it would. An instance. If it has never failed, establish whether it can.
- *Which components in this system are called by nothing?* If the answer is "none" or "I would have to check," the census does not exist and the capability list is a repository inventory wearing a system's clothes.
- *For each limit in this report, is it enforced or observed?* An answer entirely of one kind is a finding.
- *Show me this gate failing.* Then show me what it does when its toolchain is absent. If those two outputs differ from a pass in ways a reader would notice, it is a gate. If not, it is a formality.
- *Where does this claim's confidence come from?* Follow it back. If the chain terminates in a configuration value, the claim is a restatement of the configuration and should be labelled as one.
None of these is expensive. All five are answerable in an afternoon by anyone with access. What makes them rare is that they are questions about green results, and the entire social function of a green result is to end the conversation.
What this annex cannot do
- *Five is not the complete set.* It is the set I can state precisely and defend. The arc's own argument is that enumerations are incomplete, and this is an enumeration; treat it as a floor.
- *None of these is evidence of bad faith, and reading them that way will make you worse at finding them.* Every one arises from a reasonable local decision — ship the stub, build ahead of the consumer, keep the schema simple, let the suite run locally, trust the config. They are structural, and they appear in careful organisations for the same reason they appear anywhere.
- *Fixing all five does not make a system trustworthy.* It removes five specific ways it could be lying to you. That is a narrower claim and it is the only one available.
- *This says nothing about whether the assurance was worth having.* A perfectly honest report about a system that should never have been deployed is still a report about a system that should never have been deployed.
The reason to run these questions against your own work first is that all five are much easier to see in someone else's system, and none of them announces itself. They are, in every case, the absence of a signal — and absence is the one thing no dashboard displays.