Architecture Decision Records¶
ADRs capture why a significant architectural decision was made. They use the MADR format (lite): Status, Context, Decision, Consequences.
We only keep ADRs for load-bearing decisions that affect plugin authors or external consumers — contracts that are expensive to change. Minor naming or refactor decisions are not recorded here; they live in commit history.
Until the project reaches 1.0, ADRs may be edited in place as the design evolves. After 1.0, overturned decisions get a new ADR marked "Supersedes N" rather than in-place edits.
| # | Status | Title |
|---|---|---|
| 0001 | Accepted | Engine fmt= parameter across format-aware methods |
| 0002 | Accepted | Split secret provider from secret resolver |
| 0003 | Accepted | Number-slot transformer ordering (10/20/30/70/80/90) |
| 0004 | Accepted | Metadata provider returns raw JSON watermark text |
| 0005 | Accepted | Qualified SQL relations in PolarsEngine |
| 0006 | Accepted | Portable FabricPlatform Azure backends |
| 0007 | Accepted | Private engine implementation packages |
| 0008 | Accepted | Portable DatabricksPlatform native and SDK backends |
| 0009 | Accepted | Use-case-oriented optional dependencies |