homemaker-layout/examples/health-centre/patterns.config
Claude a7ef9e2fa0
Remove ratio_circulation: the score is already a ratio
Owner: "I think a corridor could be worth a sixth of a room, this is ok. maybe
we should dump the ratio_circulation altogether if there is already a pressure
in circulation caused by the cost benefit ratio per msq. this is the kind of
thing we want to root out of the scoring model: anything that is double
counting, or using a gaussian where a linear ramp is appropriate, etc."

value_circulation = 50 stands; hxi's rate question is closed.

The duplication argument is stronger than it first looks. score = value/cost is
already a ratio, so the per-m2 economics (50 against a build cost of 200) is not
merely an absolute pressure -- adding corridor moves value/cost by an amount
that depends on how much of the building is already corridor. It is ALREADY
proportional. ratio_circulation said the same thing again as a whole-building
multiplier, on a curve where twice the corridor is far more than twice as bad.

Correction to my own first measurement: I overrode ratio_circulation and got
scores going DOWN when a <=1 multiplier was removed, which is impossible. All
four corpus programmes DECLARE ratio_circulation, so the CONF_DEFAULTS value I
had changed was never in play and the two arms differed only in sigma. Same
trap as value_supported in 39.19.

Against the keep-it case, recorded because it is the one real argument: three of
four declare a POSITIVE target (harbor/maple 0.08, health-centre 0.10), making
the term formally two-sided rather than "less is better". It does not survive
the numbers -- the lower side is worth at most 13.3% on the large programmes
against 99% on the upper side, and "a building needs some circulation" is
enforced structurally by access and connectivity, which no amount of value can
buy off.

Disabled in CONF_DEFAULTS and the four corpus configs, each with the reason
inline and a note that a [target, sigma] pair re-enables it. Fail sets
unchanged; it was always a value multiplier. Scores +42% to +7712%.

39.24 also sweeps every remaining term against the owner's two tests. Verdicts:
perpendicular, proportion, width, crinkliness, access, size's lower side,
ratio_outside, staircase volume and the count/limit fails are all sound.
Filed as homemaker-py-dpt: size's UPPER side (cost already charges area; 82% of
size fails are over-target), the minimum-internal-area factor (a third
statement of "build the rooms"), the 0.5**n_fails curve (a ruling, not a
measurement), and two dead paths -- ratio_public/private_outside, which no
config declares, and the daylight factor pinned to 1.0 since the descope.

Also updated a test I added last turn which asserted ratio_circulation was the
second charge; it now pins that the linear ramp is the ONLY one.

419 passed.

Closes homemaker-py-hxi.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MJ84Feep79Hhm3E4zZJmnB
2026-09-06 15:28:33 +00:00

378 lines
6.7 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
# homemaker-py-hxi (DESIGN.md §39.24): disabled. The score is value/cost, a
# ratio, so the per-m2 economics (circulation worth 50 against a build cost of
# 200) is ALREADY a proportional pressure against circulation -- this said the
# same thing a second time, and with a curve where twice the corridor is far
# more than twice as bad. Its other side, "a building needs some circulation",
# was worth at most 13% here and is enforced structurally anyway by the access
# and connectivity checks. Set a [target, sigma] pair to re-enable.
ratio_circulation:
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