Why Spring Contracts Break Between Repositories While Everything Still Compiles

The separate UNKNOWN outcome makes the stopping point reviewable. One useful synthetic edge case would be the same topic name resolving under two different Spring profiles, with serializer configuration supplied by an environment override in only one repository. A name match should not be enough to infer compatibility or a shared cluster.

I would expect the static result to retain both profile paths and mark the unresolved override explicitly. If runtime evidence later fills that gap, preserve its environment and observation time alongside the static chain so it cannot silently establish a contract for a different deployment.

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.

Thanks for reproducing the synthetic case and keeping the deployment evidence boundary explicit. The separate service scopes and retained static chains address the ambiguity I was trying to expose; matching bootstrap addresses alone was a particularly important shortcut to avoid.

A useful follow-up control would replay a valid observation after the relevant configuration fingerprint changes while the source revision stays fixed. It should become unusable for resolution without erasing the earlier provenance. That would exercise configuration-only drift separately from an expired observation or a different code revision.