What are you changing?
Use this page when you know the behaviour you want to change, but not the owning package or review evidence yet.
| If you want to | Start with | Owning package |
|---|---|---|
| Add an input fact, derived fact or question prompt | Add a fact | Usually @taxkit/core for shared descriptors, or the owning rule package for rule-specific facts |
| Add or change a tax formula, threshold, parameter table or source-backed derivation | Add a rule | @taxkit/rules-au-pay, @taxkit/rules-au-income-tax or @taxkit/rules-au-stsl |
| Add a public calculation goal, request context or report shape | Add a calculator | Rule package for the calculator program, @taxkit/calculators for reusable orchestration |
| Add support for another tax year | Add a tax year | The rule package that owns the parameter table and calculator context |
| Fix a reported incorrect result | Fix an incorrect result | The package that owns the failing fact, rule, parameter table or calculator |
| Change HTTP endpoint shape or SDK helper shape | Backward compatibility | @taxkit/api-http for transport contracts, @taxkit/sdk for SDK facades |
| Prepare a reviewable pull request | PR evidence checklist | The package you changed, plus public docs when behaviour changes |
Boundary rule
HTTP and SDK layers must not hide tax business logic. Put calculator lookup, fact decoding, rule execution, graph assembly and expected calculator errors in the owning engine, rule or calculator package. HTTP handlers can translate route input and status envelopes. SDK helpers can adapt developer-facing calls to canonical calculator requests.
For deeper boundaries, read Package ownership and API and SDK.
Next step
Open the guide that matches your intent, then keep PR evidence checklist open while you work.