← BlogData Contracts (Spec & Schema)· 4/4

We Were Writing the Same Thing Five Different Ways — Schema Fragmentation and Consolidation

The same entity (vessel specifications) was described in five different schemas. Starting from 0% canonical adoption, this is the story of consolidating to a single authoritative schema and attaching standards-based validation.

~4 min
schemadata-contractversioningmigrationgovernance

We Were Writing the Same Thing Five Different Ways

Data contracts tend to accumulate a quiet form of debt — representing the same thing in multiple shapes. One day we audited the codebase and found that vessel specifications (length, displacement, speed, sensors) were scattered across five different schemas. Each asset used its own format, so even "what field holds this vessel's speed" was ambiguous.

The Cost of Fragmentation

Rendering diagram…

Five schemas means five codepaths reading them, five validation branches, and five times the bug surface. Every new feature starts with the question: which schema do I follow? That is a broken single source of truth (SSOT).

⚠️ Fragmentation grows because "it's faster right now" — when an existing schema doesn't quite fit a new asset, the path of least resistance is to create a slightly different schema on the spot. Repeat that five times and you have fragmentation. "Save one minute now" becomes "five times the debt later."

Consolidation — One Canonical Schema + a Migration Path

The solution is to designate one canonical schema and migrate existing data to it.

Rendering diagram…
  • Audit — measure which assets use which schema and track canonical adoption rate. We started at 0%.
  • Migrate — convert existing data to the canonical format and drive the adoption rate up.
  • Validate — attach standards-based rules to the canonical schema so values are automatically checked for physical plausibility (e.g., speed vs. displacement ratio).

In practice, this process raised canonical adoption from 0% to roughly 78% and added 21 validation tests.

💡 The canonical schema is the anchor for validation — once all data converges on one schema, you only need to attach standards rules (naval specifications, hydrodynamic formulas) once and they apply to every asset. That kind of consistent validation is impossible in a fragmented state — consolidation is what makes it achievable.

In a nutshell

📌 Describing the same entity in multiple schemas multiplies codepaths, validation branches, and bugs (fragmentation). The fix is one canonical schema + audit → migrate → validate — measure and drive up adoption (0% → 78%), then attach standards validation to the canonical form to recover consistency. Fragmentation grows from convenience, so the canonical schema must be defended deliberately.

See standard test results with videos and verdict evidence on the imSim Portal.

View public results →