Pavlo Putrenkov

Thanks, Ahmet. We reproduced your two-profile example and shipped the fixes in ArchVerity 3.0.4, now approved on Marketplace (including the separate IDEA 2024.3 package). Static topic matching now keeps service scopes separate unless a logical cluster scope is explicitly declared. Neither a matching topic name nor matching bootstrap addresses establish a shared physical cluster. The export retains both file/profile/line chains and explicitly marks the missing environment serializer override as UNKNOWN. Equal DTOs, a default value or a fallback path do not close the wire-evidence gap. Accepted runtime bean observations carry service, environment, source revision, configuration fingerprint and observation time. We reject mismatched, expired or future observations, and retain the static candidates alongside runtime provenance. Resolving a bean reference alone does not prove serializer compatibility or establish a contract for another deployment. We extended regression coverage to nested overrides, defaults and cycles, distinct scopes, regex subscriptions, exact versus opaque Kafka factory bindings, and retry/DLT imports when names repeat. The public ArchVerity-Demo repository contains the kafka-profile-lab project: 12 isolated recipes with expected exports, positive/negative controls and launch instructions. These checks validate static conclusions and evidence handling. Physical broker identity, actual serialized bytes and deployment compatibility still require deployment-specific evidence. Thanks for the concrete case; it exposed a boundary we needed to enforce.

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.