Comment by Ahmet Özel on "Why Spring Contracts Break Between Repositories While Everything Still Compiles"

Distinguishing proven mismatches from unknowns is the design decision that makes a tool like this usable. Most cross-repo analysers collapse "I checked and these disagree" with "I could not resolve this", and the second category is large in any real Spring codebase: runtime-resolved topics, config-driven URLs, DTOs built reflectively. Reporting those as findings trains people to ignore the output within a week.

Kafka is the harder half of what you are modelling. An HTTP contract at least has a caller that names the endpoint, while a topic has producers and consumers that never reference each other in code, so the only evidence is configuration plus a serialised shape. Keeping the evidence attached to the finding is what makes that reviewable instead of a guess.

Exactly. This is the distinction we’ve now made explicit in ArchVerity 2.0.3: PROVEN_MISMATCH and UNKNOWN are separate outcomes, not different confidence levels of the same finding. We report a mismatch only when both sides resolve and the evidence demonstrates a disagreement. If a topic, URL, DTO, or serializer cannot be resolved statically, the result remains UNKNOWN and shows where resolution stopped. Kafka was the strongest reason for formalizing this boundary. ArchVerity now preserves the evidence chain from configuration file, profile, and line through the resolved topic and cluster to producer/consumer payload types and serializer provenance. Runtime evidence may eventually resolve an unknown, but static inference alone is never promoted to fact. Thanks for calling this out — it captures exactly why evidence and uncertainty must remain first-class parts of the result. If you have real-world edge cases we should consider, we’d genuinely value your feedback, especially around where static analysis should stop rather than infer.

Search Hashnode