homemaker-layout/examples/health-centre/patterns.config
Claude 109849e438
A terrace is no longer worth more per m2 than a real internal room
Owner's ruling. Measured over the twelve baseline layouts as realised value per
m2 (rate x quality, not the rate alone):

  as shipped before this   room  67.0   terrace 294.6   violates, 4.39x
  value_supported=100 only room  67.0   terrace  98.2   violates, 1.46x
  geometric mean only      room 132.9   terrace 296.8   violates, 2.23x
  both                     room 132.9   terrace  98.9   satisfies

The 4.4x is roughly 2.2x aggregation and 2.0x rate, so neither half alone is
enough. That is why 39.18's geometric-mean aggregation moves from default-OFF
to default-ON here rather than waiting on its own A/B: it is not an optional
improvement, it is half of a ruling.

value_supported 300 -> 100, and set to value_outside rather than to a number
that makes the inequality come out -- back-solving from the corpus's measured
mean room quality would rot the moment either changed. Outdoor space is worth
the same to an occupant whatever level it sits on; the real difference between
a ground garden and a roof terrace is what it takes to BUILD, and cost already
says that (outside 10.0 vs outside_supported 110.0). Value describes worth,
cost describes structure, and the level belongs in the second.

Changed in CONF_DEFAULTS and the four corpus patterns.config files, which all
declared 300.0 explicitly. NOT changed in harbor-house-l0 (a shape-curve test
fixture) or y51-sweep-* (historical fixtures that exist to reproduce past
measurements) -- repricing those would destroy what they are for.

Neither change can move a fail, structurally rather than luckily: value rates
never enter fail emission, and evaluate_leaf emits each fail from its factor
before anything is combined. Verified corpus-wide: identical fail sets, scores
+11% to +169% (and -5% once, on a layout that is mostly terrace).

tests/test_terrace_value_ruling.py pins the ruling as an invariant of the
objective, and asserts that reverting the aggregation breaks it again, so
neither half can be quietly dropped.

The 500k cold-start baseline (39.12) is superseded -- this changes what "good"
means. The layouts stay valid and their fail counts are unchanged, but a fresh
corpus run is needed before any new number is compared with them.

Still untouched: circulation returns 0.07 per unit cost against a room's 0.66,
by far the worst thing a building can contain. That is homemaker-py-hxi.

Refs homemaker-py-ecx.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MJ84Feep79Hhm3E4zZJmnB
2026-09-05 19:25:02 +00:00

373 lines
6.2 KiB
Text

---
# Health Centre - Non-synthetic third example programme (homemaker-py-9yx)
#
# y51's synthetic n=10/14/18/22 sweep (DESIGN.md 24, extended by xyu 31) scales
# room count by duplicating a handful of already-interchangeable programme-house
# codes (b1/t1/b2/t2/l1) via `count:`. harbor-house has real room-type diversity
# (16 distinct codes) but is out of range at 37 room instances, and its own
# result stayed null-to-negative -- so it cannot distinguish "the effect needs
# more rooms than harbor-house has" from "the effect never existed outside the
# duplicated-code mechanism". This programme fills the gap: a genuinely
# different building type (a small primary-care health centre, not a house or
# a dormitory/co-housing facility) with 19 distinct, individually-sized room
# codes at n=20 room instances -- matching xyu's own n=18 test point without
# leaning on `count:` as the scaling knob (only one deliberate, realistic
# duplication: two public WCs).
#
# Code conventions (per maple-court, homemaker-py-leu.1): generic c/o/s are
# reserved for circulation / outside / sahn in fitness.py's get_space_params
# (any code starting with 's' silently falls back to the *_outside defaults
# instead of its own size/width/proportion targets) -- so no room code here
# starts with c, o, or s.
# Building programme: small primary-care health centre
spaces:
# ---- PUBLIC / RECEPTION ----
rc1:
usage: none
name: Reception
size:
- 10.0
- 2.0
width:
- 2.9
- 0.6
proportion:
- 1.6
- 0.5
level: 0
adjacency:
- c
- o
wa1:
usage: none
name: Waiting Room
size:
- 28.0
- 5.0
width:
- 5.0
- 1.0
proportion:
- 1.8
- 0.5
level: 0
adjacency:
- c
- o
- rc1
ph1:
usage: bedroom
name: Pharmacy / Dispensary
size:
- 12.0
- 2.0
width:
- 3.1
- 0.6
proportion:
- 1.6
- 0.5
level: 0
adjacency:
- c
- o
- wa1
# ---- CLINICAL ----
gp1:
usage: bedroom
name: GP Consulting Room
size:
- 14.0
- 2.0
width:
- 3.2
- 0.6
proportion:
- 1.4
- 0.4
adjacency:
- c
ms1:
usage: bedroom
name: Minor Surgery Room
size:
- 20.0
- 3.0
width:
- 4.7
- 0.8
proportion:
- 1.3
- 0.4
adjacency:
- c
# homemaker-py-1s3 (§26 path b): two similar-scale clinical procedure
# rooms, flexible enough to double up in a small practice.
co_locate:
- de1
de1:
usage: bedroom
name: Dental Surgery
size:
- 18.0
- 3.0
width:
- 4.6
- 0.7
proportion:
- 1.5
- 0.4
adjacency:
- c
- zt1
co_locate:
- ms1
zt1:
usage: utility
name: Sterilisation Room
size:
- 6.0
- 1.0
width:
- 1.6
- 0.4
proportion:
- 1.6
- 0.4
adjacency:
- c
- de1
pt1:
usage: bedroom
name: Physiotherapy Room
size:
- 24.0
- 4.0
width:
- 4.8
- 0.8
proportion:
- 1.6
- 0.5
adjacency:
- c
qr1:
usage: bedroom
name: Counselling Room
size:
- 9.0
- 1.5
width:
- 2.6
- 0.5
proportion:
- 1.4
- 0.4
adjacency:
- c
tr1:
usage: bedroom
name: Treatment Room
size:
- 16.0
- 2.5
width:
- 3.3
- 0.6
proportion:
- 1.4
- 0.4
adjacency:
- c
# ---- ADMIN / STAFF ----
mo1:
usage: bedroom
name: Manager's Office
size:
- 10.0
- 1.5
width:
- 2.8
- 0.5
proportion:
- 1.5
- 0.4
adjacency:
- c
# homemaker-py-1s3: a small practice's manager's office and admin office
# are a natural loose-fit pairing.
co_locate:
- ao1
ao1:
usage: bedroom
name: Admin Office
size:
- 14.0
- 2.0
width:
- 3.0
- 0.6
proportion:
- 1.6
- 0.5
adjacency:
- c
co_locate:
- mo1
- br1
re1:
crinkliness: none # no window needed
usage: utility
name: Records Room
size:
- 7.0
- 1.0
width:
- 1.7
- 0.4
proportion:
- 1.6
- 0.4
adjacency:
- c
- ao1
co_locate:
- dp1
br1:
usage: living
name: Staff Room
size:
- 16.0
- 2.5
width:
- 3.4
- 0.6
proportion:
- 1.5
- 0.4
adjacency:
- c
co_locate:
- ao1
kt1:
usage: kitchen
name: Staff Kitchenette
size:
- 8.0
- 1.5
width:
- 2.7
- 0.4
proportion:
- 1.5
- 0.4
adjacency:
- c
- br1
# ---- SERVICE ----
me1:
crinkliness: none # no window needed
usage: utility
name: Plant / Mechanical Room
size:
- 9.0
- 1.5
width:
- 1.9
- 0.4
proportion:
- 1.7
- 0.4
adjacency:
- c
dp1:
crinkliness: none # no window needed
usage: utility
name: General Storage
size:
- 8.0
- 1.5
width:
- 1.8
- 0.4
proportion:
- 1.7
- 0.4
adjacency:
- c
co_locate:
- re1
t9:
usage: toilet
name: Public WC
size:
- 4.0
- 0.8
width:
- 1.5
- 0.3
proportion:
- 1.6
- 0.4
adjacency:
- c
count: 2
t10:
usage: toilet
name: Staff WC
size:
- 3.0
- 0.6
width:
- 1.4
- 0.3
proportion:
- 1.6
- 0.4
adjacency:
- c
# Building constraints
storey_minimum: 1
storey_limit: 2
force_roof_garden: 0
ratio_circulation:
- 0.10
- 0.12
ratio_outside:
- 0.06
- 0.05
staircase_min: 1
staircase_max: 2
value_inside: 300.0
value_circulation: 50.0
value_outside: 100.0
# homemaker-py-ecx (DESIGN.md §39.19): an upper-level terrace is worth what
# outdoor space is worth (value_outside); it is the COST that differs by level
# (outside 10.0 vs outside_supported 110.0), not the value. At 300.0 -- the
# `value_inside` rate -- a terrace was worth more per square metre than a real
# internal room, which the owner ruled out.
value_supported: 100.0