Add meteorological intelligence domain and weather delivery surfaces

[justinrayshort]

Summary

Add an enterprise-wide meteorological intelligence capability that ingests NOAA-first weather data, publishes governed weather data products, exposes typed query surfaces for a standalone weather UI, and supports analytical consumers such as decision-support and quantitative research services.

Primary Architectural Plane

• enterprise
• schemas
• services
• workflows
• platform
• ui

Owning Subsystem

• enterprise domain: meteorological_intelligence
• primary service: meteorological-service
• primary workflow: weather_ingestion

Architectural References

• docs/adr/0005-domain-bounded-platform-topology.md
• docs/adr/0006-canonical-event-substrate.md
• docs/adr/0008-domain-owned-data-products-with-contracts.md
• docs/adr/0009-lakehouse-open-format-analytical-foundation.md
• docs/adr/0012-layered-intelligence-behind-stable-retrieval.md
• docs/adr/0017-replaceable-compute-and-governed-state.md
• docs/architecture/layer-boundaries.md
• docs/architecture/plugin-application-model.md

Integration Boundaries

Allowed cross-plane touchpoints:

• enterprise/ defines domain ownership, ontology, and evidence requirements.
• schemas/ defines weather contracts, events, and metadata record types.
• services/meteorological-service owns acquisition, normalization, provenance, cataloging, and projection materialization.
• workflows/weather_ingestion is the only mutation path for scheduled ingest and backfill.
• platform/sdk exposes typed weather queries to UI consumers.
• ui/ consumes the weather capability only through SDK/contracts.
• knowledge-service and quant-research-service may add read-only consumers of weather feature products.

Explicit non-goals:

• no new top-level crates/ tree or repo-within-repo layout
• no direct ui/ -> services/ imports
• no direct bulk artifact reads from SurrealDB
• no finance-service mutation changes in v1
• no live-network dependency in default CI

Scope In

• new meteorological_intelligence domain artifacts in enterprise/
• weather contracts, events, and metadata record types in schemas/
• meteorological-service workspace crate with NOAA-first fixture-backed ingest and projections
• weather_ingestion workflow
• SDK weather query support
• standalone governed weather app in ui/
• read-only weather consumers in knowledge-service and quant-research-service
• tests, fixtures, and benchmarks for the above

Scope Out

• authenticated non-NOAA connectors enabled by default
• production cloud deployment manifests beyond existing repo conventions
• direct treasury/finance-service weather integration
• dynamic plugin loading
• monthly/yearly scheduling automation changes

Background and Scope

A new repository file proposes a large meteorological platform but does so as a separate crate topology that conflicts with Origin's enterprise domains, contract-first schema ownership, and plugin-based UI model. The implementation should reinterpret that capability inside the current architecture: one domain-owned weather service publishes canonical products once, then materializes UI and analytical projections for multiple consumers.

Acceptance Criteria

• enterprise/ includes a new meteorological_intelligence domain with ontology, policy owner, evidence requirements, and service boundary metadata.
• schemas/ publishes versioned weather contracts and events, and schema/codegen tests pass.
• services/meteorological-service compiles, exposes a service boundary, and can ingest deterministic NOAA fixture data into canonical products and derived projections.
• workflows/weather_ingestion compiles and is the approved mutation path for ingest/backfill.
• platform/sdk exposes typed weather query access for UI consumers.
• ui/ includes a standalone governed weather app registered by manifest and backed only by SDK/contracts.
• knowledge-service and quant-research-service can consume weather feature products read-only.
• Required tests and benchmarks are added and pass under default local validation.

Validation Requirements

• cargo fmt --all --check
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• cargo test --workspace --all-targets
• targeted fixture-backed integration tests for weather ingest, projections, UI transport, and downstream consumers

Rollback Considerations

• revert the weather domain, schema, service, workflow, SDK, and UI additions behind one issue-scoped branch if governance or contract shape proves incorrect
• keep optional external connectors feature-gated so rollback does not affect default NOAA-first operation
• avoid changing existing service mutation paths so rollback is additive and low-risk

Implementation Notes

• add a new root ADR after 0017; do not reuse 0001-0005
• preserve raw artifacts immutably and store only metadata/catalog/provenance references in SurrealDB
• keep heavy gridded/scened data in open formats aligned with ADR-0009
• ensure the first end-to-end vertical slice is the standalone weather app, with analytical consumers validated from the same published products