Architecture Decision Records (ADRs)

This directory contains Architecture Decision Records (ADRs) for NLSQ.

What is an ADR?

An Architecture Decision Record (ADR) captures an important architectural decision made along with its context and consequences. ADRs help future maintainers understand why certain decisions were made.

ADR Template

Each ADR follows this structure:

# ADR-XXX: Title

**Status**: Accepted | Proposed | Deprecated | Superseded

**Date**: YYYY-MM-DD

**Deciders**: Names or roles

## Context

What is the issue we're facing? What factors are we considering?

## Decision

What decision did we make?

## Consequences

### Positive
- What benefits does this bring?

### Negative
- What are the tradeoffs or downsides?

## References
- Links to related resources

Index of ADRs

ADR

Title

Status

Date

003

Streaming Optimization Over Subsampling

Accepted

2025-10-17

004

Parameter Unpacking Simplification

Accepted

2025-10-18

005

JAX Autodiff for Gradient Computation

Accepted

2025-10-18

When to Create an ADR

Create an ADR when making decisions about:

  • Technology choices: Which libraries, frameworks, or platforms to use

  • Architecture patterns: How to structure the code or system

  • API design: How users interact with the library

  • Performance trade-offs: When optimizing for speed vs. memory vs. accuracy

  • Breaking changes: When introducing incompatible changes

References