ADR Index

ADR index

This page lists every Architecture Decision Record for fiscalclock, with its status and the release it concerns, and explains how to propose a new one.

Last reviewed: 1 Nov 2026

ADRs follow the MADR layout described in ADR-0001. Accepted decisions are Decided; Proposed decisions are open and are not implemented. "Delegation" means the maintainer asked for the roadmap and 0.1.0 to be decided and built without them; those ADRs were accepted on 31 Oct 2026 and may be revisited. 0.1.0 was released on 31 Oct 2026 (v0.1.0). ADRs 0022, 0024 and 0027 were accepted under the same delegation on 1 Nov 2026.

All ADRs

Number	Title	Status	Release
0001	Record architecture decisions with ADRs	Accepted (maintainer decision)	All
0002	Single Rust core with thin bindings	Accepted	0.1.0 (built)
0003	Own date type, no date-crate dependency in the core	Accepted	0.1.0 (built); optional conversions 0.2
0004	Calendar as data with no presets; registry outside the API	Accepted	0.1.0 (built); registry 0.4
0005	Independent definition blocks	Accepted	0.1.0 (built); exceptions 0.2
0006	Civil dates only	Accepted	0.1.0 (built); zone helper not scheduled
0007	Half-open intervals	Accepted	0.1.0 (built)
0008	Canonical JSON and calendar_id	Accepted	0.1.0 (built)
0009	JSON Schema generated from Rust types	Accepted (implementation planned for 0.2)	0.2; published schema 0.4
0010	Structured errors; ambiguity is an error	Accepted	0.1.0 (built); TEMPLATES_AMBIGUOUS 0.2
0011	PyO3 and maturin with abi3 plus free-threaded wheels	Accepted	0.1.0 (built)
0012	Arrow PyCapsule Interface as the Python bulk path	Accepted (planned for 0.2)	0.2
0013	MCP server shipped through the npm and PyPI packages	Accepted (planned for 0.4)	0.4
0014	Dual MIT / Apache-2.0 licence	Accepted	0.1.0 (applied)
0015	Scope boundaries	Accepted	All
0016	Required modes for equivalent day and proration basis	Accepted	Proration 0.2; equivalent day 0.3
0017	Pure, deterministic core with no global state	Accepted (maintainer decision)	0.1.0 (built)
0018	Supported date range 0001-01-02 to 9999-12-30	Accepted (maintainer decision)	0.1.0 (built)
0019	Cross-language conformance by comparing JSON output	Accepted (maintainer decision)	0.1.0 (built)
0020	npm build with wasm-bindgen	Accepted (delegation)	0.1.0 (built)
0021	exceptions, history, transitions and table years ship in 0.2	Accepted (delegation)	0.1.0 (rejects them); 0.2
0022	Whether table years accept period boundaries	Accepted (delegation)	0.2
0023	Week numbering has no default; 0.1.0 supports contains_start only	Accepted (delegation)	0.1.0 (built); first_full 0.2
0024	stub semantics for fixed-date years with week-based periods	Accepted (delegation)	0.2
0025	Minimum supported versions: Rust 1.85, Python 3.10, Node.js 22	Accepted (delegation)	0.1.0 (applied)
0026	Project name fiscalclock	Accepted (delegation)	0.1.0 (not yet claimed)
0027	Definition registry location and reviewers	Accepted (delegation)	0.4
0028	The anchor weekday derives from week.starts_on	Accepted (delegation)	0.1.0 (built)
0029	Year numbers must be unique; majority naming in 0.1.0	Accepted (delegation)	0.1.0 (built)

Contradictions in the source documents

The PDR lists contradictions D1 to D12 found in the research documents. These ADRs name the ones they touch:

Contradiction	ADR	State
D1, stub shape	ADR-0024	Resolved (implementation planned for 0.2)
D2, year_number: "table" and boundary numbers	ADR-0021, ADR-0022, ADR-0029	Resolved by ADR-0022 (implementation planned for 0.2)
D3, anchor weekday	ADR-0028	Resolved
D4, week sums in fixed-date years	ADR-0024	Resolved (implementation planned for 0.2)
D5, five or seven oracles	ADR-0019	Noted; does not affect the decision
D6, release of equivalent_day	ADR-0016	Follows the proposal (0.3)
D10, unsourced naming claims	ADR-0029	Open
D11, Care.com divergence years	ADR-0021	Open
D12, anchored and special periods in v0.1	ADR-0021	Resolved for 0.1.0

D7, D8 and D9 do not concern a design decision recorded here; the PDR and the Evidence page cover them.

How to propose a new ADR

AGENTS.md ("When an ADR is required") requires an ADR before changing the definition format, the result of any operation for a valid input, the public API or error codes, core dependencies, supported versions, scope or licence. To propose one:

1. Take the next free number and write the page as ADR-NNNN-short-slug, in the MADR layout of the existing ADRs: Status, Context, Decision drivers, Considered options with honest pros and cons, Decision, Consequences, Links.
2. Give it the status Proposed, with the date. If it would replace an accepted ADR, link that ADR; do not edit the accepted one.
3. Open a thread in the Design decisions category of Discussions and link it from the ADR. The category does not exist yet; until the maintainer creates it, link the issue or pull request where the change is discussed.
4. Add a row to the table above.
5. Do not implement a Proposed decision as if it were accepted. When it is accepted, update its status, and mark any ADR it replaces as Superseded with a link.

Links

• Home, PDR, Roadmap, Glossary
• CONTRIBUTING.md, GOVERNANCE.md