Architectural Decision Records

An ADR records one architecturally significant decision: its context, the options considered, the outcome and its consequences. Read them to learn why Hebog is built the way it is; read the architecture overview for what the design is today. New ADRs start from the template. When a decision is replaced, the old ADR is kept and marked as superseded.

ADR	Status	Summary
ADR-001: Use Architecture Decision Records	🟢 Accepted	Use ADRs to explain the rationale behind architecturally significant design choices for future developers and AI assistants
ADR-002: Manage dependencies with uv	🟢 Accepted	Use uv to manage project dependencies
ADR-003: Limit Hebog to Rapthor's source-finding contract	🟢 Accepted	Qualify the Rapthor feature slice through a pipeline-neutral scientific core
ADR-004: Keep top-level scheduling in Rapthor	🟢 Accepted	Keep resource and graph ownership in Rapthor while Hebog exposes explicit executors
ADR-005: Scale large images with hierarchical tiles	🟢 Accepted	Bound worker memory with haloed tiles, boundary summaries, and hierarchical reconciliation
ADR-006: Isolate compatibility with versioned internal schemas	🟢 Accepted	Keep domain schemas explicit and map legacy products only at outer adapters
ADR-007: Use Zarr for intermediate image storage	🟢 Accepted	Keep one maintained intermediate backend and optimize Zarr across all execution tiers
ADR-008: Make the continuum composition tile-native	🟢 Accepted	Define the pass structure, halo, ownership, boundary summary and merge of every public continuum stage
ADR-009: Place the reviewed science below the stages	🟢 Accepted	Redraw the layering as public_api → stages → science → algorithms and state every layer's allowed imports in one tested table
ADR-010: Scale Hebog independently of its integrations	🟢 Accepted	Hebog defines what it needs from a Dask cluster to scale; Rapthor and other callers provide it