Consistency
Make EO data predictable across sources, time, and interfaces.
What Consistency Covers
Consistency governs standards, normalization, schema contracts, API behaviour, versioning, and change control so downstream users can trust repeatable data semantics.
Why Consistency Matters
Without consistency, every supplier requires custom handling, analytics pipelines break, and interoperability costs multiply.
What Good Looks Like
A mature platform enforces STAC-aligned metadata, cloud-optimized formats such as COG, stable API contracts, and transparent lineage for transformed outputs.
Minimum Requirements
- STAC-compatible catalog and metadata behaviour.
- COG or equivalent cloud-optimized output format support.
- Normalized coordinate systems and timestamp standards.
- Published schema contracts and API stability expectations.
- Output versioning with documented change history.
Standards and Interoperability
Metadata Standards
Use a canonical metadata profile with controlled vocabularies.
STAC and Catalog Behaviour
Define mandatory fields, link behaviour, and search semantics.
File and Packaging Standards
Standardize structure, naming, and packaging for portable use.
Spatial Reference Rules
Specify accepted CRS and reprojection policies.
Time and Timestamp Standards
Use consistent UTC timestamps and precision rules.
API Behaviour Standards
Preserve stable pagination, filters, and error schemas.
Normalization and Transformation
Reprojection
Apply deterministic reprojection logic with quality thresholds.
Format Conversion
Convert source formats to standardized delivery formats.
Metadata Translation
Map supplier metadata into canonical contracts.
Quality Preprocessing
Normalize QA masks and known artifact flags.
Product Naming and Semantic Mapping
Enforce consistent naming and semantic classes across suppliers.
Data Contracts and Interface Stability
Assign interoperability ownership and maintain compatibility testing to prevent breaking downstream integrations.
Quality, Versioning, and Lineage
Track lineage for each transformed artifact, including source scene IDs, algorithm versions, and processing timestamps.
Documentation and Change Control
Use a deprecation policy for schema changes with migration timelines and customer notices.
Consistency Decisions
Major decisions include strict vs permissive validation, harmonization depth across sensors, and schema evolution strategy.
Metrics and Health Signals
- Schema validation pass rate.
- Cross-supplier harmonization defect rate.
- API contract breakage incidents.
- Lineage completeness for derived outputs.
- Deprecation compliance progress.
Anti-Patterns
- Ad-hoc field mapping by project.
- Unversioned output changes.
- Semantic drift across suppliers.
- Undocumented timestamp and CRS exceptions.
Implementation Checklist
- Is ownership clear?
- Are minimum controls defined?
- Are failure modes addressed?
- Are measurable health signals defined?
- Are anti-patterns named?
- Are dependencies on other domains explicit?
- Is there at least one EO-specific implementation example?
- Is there a practical implementation checklist?
Example EO Patterns
- Multi-sensor optical imagery normalized into one STAC collection with shared cloud-mask semantics.
- SAR and optical products exposed through stable, versioned search APIs.
- Reprocessing release notes tied to explicit output version increments.