Platform: observed on both 8.5.1.1343 and 8.5.1.1423 (1Ci international), Windows Server 2022, MSSQL 2019. Server infobase is temporarily de-registered from the cluster during deployment (deploy performed via standalone ibcmd).

Reproducible behaviour (100%, confirmed across 10+ CI deployments with per-attempt timing logs): after a full `ibcmd config import` of an XML dump into a de-registered infobase, the FIRST `ibcmd config apply --force` always fails after ~2.1-2.7 s with "Integrity of configuration structure violated", while a healthy apply on this configuration takes ~16-19 s. Repeating the pair (import + apply) always succeeds on the second attempt. The stable ~2 s failure timing suggests an early metadata pre-check rejecting a state that the second pass accepts.

Questions: (1) What does the early check in `config apply` validate at that point, and why does the identical repeated sequence pass? (2) Is a repeated import+apply pair the intended workaround, or is there a supported flag/sequence to make the first attempt reliable? We currently auto-retry the pair in CI, which works, but we would prefer to understand the mechanism.

Per-deployment logs with exit codes and timings available on request.