Model/packages
Khalim Conn-Kowlessar d4c090fc7c Slice 27b: §3 element-area rounding to 2 d.p. per RdSAP10 §15 (p.66)
Spec text (RdSAP 10 §15, p.66): "For consistency of application, after
expanding the RdSAP data into SAP data using the rules in this Appendix,
the data are rounded before being passed to the SAP calculator. The
rounding rules are: U-values: 2 d.p. / All element areas (gross)
including window areas and conservatory wall area: 2 d.p. / [...]"

Applied 2-d.p. rounding to every per-element gross area inside
heat_transmission_from_cert: gross_wall + party_wall (in _part_geometry),
window total area, door area, top_floor (roof) area, ground_floor area,
roof-window area, alt-wall area, RR-detailed-surface area. U-values
already came from table lookups at 2 d.p.

§3 cascade pins (LINE_31/33/36/37) now close at abs=1e-4 for 5 of 6
fixtures. 000487 remains failing on the RR defect (slice 25).

Scoreboard:
  section_cascade_pins: 151 → 170 PASS (+19)
  e2e SapResult:        27 →  29 PASS (+2)

Per-fixture §3 status:
  field    | 474 | 477 | 480 | 487 | 490 | 516
  LINE_31  |  ✓  |  ✓  |  ✓  |  ✗  |  ✓  |  ✓
  LINE_33  |  ✓  |  ✓  |  ✓  |  ✗  |  ✓  |  ✓
  LINE_36  |  ✓  |  ✓  |  ✓  |  ✗  |  ✓  |  ✓
  LINE_37  |  ✓  |  ✓  |  ✓  |  ✗  |  ✓  |  ✓

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-23 09:13:57 +00:00
..
domain Slice 27b: §3 element-area rounding to 2 d.p. per RdSAP10 §15 (p.66) 2026-05-23 09:13:57 +00:00
fetchers added potential file scaffolding: 2026-05-15 10:56:53 +00:00
repos added potential file scaffolding: 2026-05-15 10:56:53 +00:00
utils added potential file scaffolding: 2026-05-15 10:56:53 +00:00
README.md added potential file scaffolding: 2026-05-15 10:56:53 +00:00

Shared packages

Workspace packages consumed by services/*. Each package is its own Python distribution with its own pyproject.toml; services import via the workspace dependency mechanism ({ workspace = true }).

Package Purpose
domain/ Shared domain types — Property, BaselinePerformance, Plan, Scenario, EpcPropertyData, etc. No persistence, no IO, no business logic.
repos/ Persistence layer — one repo per aggregate. Owns the SQL. Depends on domain.
fetchers/ External API clients (gov EPC, Ofgem, Google Solar, etc.). Depend on domain for response shapes.
utils/ Cross-cutting infra — logging, S3, CloudWatch URL builders, SQS task helpers.

Adding a new shared package

Only when a real second consumer materialises. Don't pre-shatter (repos-epc, repos-property, ...) — split when a deployment needs to drop a dep, not before.

See ../ara_backend_design.md §11 for the broader monorepo layout and ../CONTEXT.md for the domain glossary that names the types living in domain/.