Cross-check: Corpus ⇄ CORENET X CoP v3.1

Review of Corenetx_corpus.zip against the BCA CORENET X Code of Practice v3.1 shared-parameter extraction (Corenetx_CoP_v3.1/), and the update applied.

What each artifact was

Cross-check findings

1. Component set — 73 of 74 CoP components had a corpus folder. The generic Space (CoP #62, p110, 0 bindings) was missing. Everything else mapped 1:1.
2. Metadata (bindings / parameters / IFC entity list) — the scaffold READMEs matched the CoP exactly for all 73 present components (0 mismatches). The scaffold was correctly generated; only the payload was absent.
3. Parameter data — 100% missing (all parameters.json empty). This was the gap.
4. Reference data — the 10 structural enum groups (p3) and 84 glossary terms present in the CoP were not represented in the corpus.

Update applied

• Populated all 74 parameters.json from the CoP, losslessly, grouped by IFC binding. Each parameter keeps sn, property, type, applies_to, unit, input_limited, examples, and (for URA tables) sn_label / property_raw.
• Resolved input-limited values — 51 parameters whose property name matches a structural enum (BeamSpanType, MaterialGrade, StirrupsType…, PileType, etc.) now carry an inline allowed_values + allowed_values_source, so downstream validators no longer have to chase "Refer to list^".
• Preserved binding-level facts — ifc_subtype(s), no_properties_required (declarative-only bindings), header_kind, and source pages per binding.
• Added the missing Space component (arc/space/, #62), classified ARC/URA to match the Space (Usage) / Space (Area Requirements) family, with a note that the CoP defines no IFC+SG properties for the generic entry.
• Regenerated every README.md and notes.md — READMEs now list per-binding subtypes / param counts / declarative flags and a flattened parameter table; notes carry provenance, binding breakdown, applies_to segmentation, and resolved enums.
• Added _reference/ — structural_enums.{json,md} (10 groups, p3) and glossary.{json,md} (84 terms).
• Rewrote INDEX.md — 74 rows with live binding/param counts and a schema block.

Corrections against the source PDF

The automated CoP extraction dropped rows on tables with large multi-line value cells. Confirmed and fixed against corenet-x-cop---3-1-edition-2025-12.pdf:

This shifts the corpus total from the extraction's 685 to 687 parameters. The same root cause (multi-line example cells) also produced the Text - type artifacts flagged in QA, so other components may still have missing rows — a full reconciliation of every table against the PDF is recommended.

Verified totals (post-update)

74 components · 145 IFC bindings · 687 parameters (685 from extraction + 2 recovered for Site Boundary). JSON validity, declared-vs-actual count integrity, and file completeness all pass.

Notes / assumptions

• Discipline (ARC/MEP/STR) and Authorities are not encoded in the CoP tables; they come from CORENET_X_Components.xlsx and were preserved from the scaffold. For the newly added Space (#62) the CoP gives no authority, so ARC/URA was assigned by analogy to the Space family — adjust if the xlsx says otherwise.
• Page ranges are copied verbatim from the CoP extraction; note the source itself has overlapping ranges for Space (Area Requirements) 111–127 and Space (Usage) 114–171.

Enum resolution pass (Phase 2) — 2026-07-19

Resolved allowed_values coverage of input-limited parameters from 52/219 to 193/219 (26 pending). Applied by scripts/resolve_enums.py from a reviewable resolution file (_meta/enum_resolutions.json) — no parameters.json was hand-edited. Values not clearly confirmed were left pending, never guessed.

Resolved by rule

• Boolean rule — 126 params. Every input-limited Boolean → ["TRUE","FALSE"] (allowed_values_source: "boolean (CoP examples: TRUE / FALSE)").
• Tier B — 12 params (CoP examples confirmed against the glossary page). Accepted only where the glossary values cell set-equals the corpus examples: FireRating (Ceiling, Damper, Door, Finishes), Green Verges (ALS_LandscapeType, ALS_Status, Status), Household Shelter SpaceName, Planting Areas Status, Refuse Chute SpaceName, Prefabricated… SpaceName, Earthworks Status.
• Tier C — 3 params (enumerated on the glossary page). Door OperationType (18 values from the follow-up "parameter values" table), Parking Lot BicycleRack_Type (3), Landscape Plants Status (4). allowed_values_source: "glossary web page (retrieved 2026-07-19)". Door OperationType keeps the page's displayed value ROLLING UP (with a space) rather than the IFC schema token ROLLINGUP; the discrepancy is recorded in that resolution entry's note.

Pending — 26 parameter occurrences (22 distinct), with reasons (full detail in _meta/enum_resolutions.json):

• Glossary list disagrees with the corpus sample (superset, typo, or truncation) — recorded as a conflict, not silently merged: Column & Beam MechanicalConnectionType, Distribution Chamber Status, Project Development Type (web has 12 values, corpus 5), Refuse Chute EquipmentType (web "Dust Scren"—likely typo), Staircase SpaceName, Tank SpaceName, System SystemType (points to a separate "List of System Types"), Prefabricated… SystemType (×5 occurrences; glossary cell "Chilled Water" only).
• Single example only, not an enumerable list: Wall ArrangementType, Green Verges ALS_GreeneryFeatures, Household Shelter AGF_Name, Parking Lot AGF_Name, Parking Lot SpaceName.
• Ambiguous (possible dropped delimiter): Parking Lot VentilationMode.
• Space (Usage) — 7 params, deferred. OccupancyType / SpaceName are per-typology catalogues defined in the IFC-SG Space Usage chapter (not a flat glossary list); the other five rows render on the linked Space Usage (Others) page, not the component's source_url. Defer to the next wholesale regeneration, which can fetch the related page.

Notes

• Component README.md / notes.md were not regenerated in this pass — parameters.json is the machine contract; the flattened README tables and notes will refresh at the next wholesale corpus regeneration.
• Manifest counts are unchanged (they track components/bindings/parameters, not allowed_values).

Space family review (Phase 2 follow-up) — 2026-07-19

Enriched the Space family from the official IFC-SG space-usage / glossary pages and resolved the 7 Space (Usage) parameters that Phase 2 had deferred. Coverage of input-limited parameters rose from 193/219 to 200/219 (19 pending). All via resolve_enums.py + enum_resolutions.json.

Reference data added (not inlined as allowed_values):

• _reference/space_usage.json (+.md) — 95 occupancy types (name, applicability sentence, partial cross-agency mappings) and the 16 Space Name Categories with their names.
• _reference/space_area_names.json (+.md) — the "List of AGF_Name per Development Use" table (15 development uses). AGF_Name / AGF_DevelopmentUsed are not input-limited, so space_area_requirements/parameters.json was left untouched.

Resolved (moved from pending to resolved):

• OccupancyType ← the 95 occupancy-type names (SCDF-oriented classification, verbatim).
• SpaceName ← the deduped union of the "Property Values to input for SpaceName" column only (422 official input values). That column literally defines the valid SpaceName inputs; a permissive superset would make downstream validators accept values CORENET X may reject. The paired SCDF Functional Space variants (the extra ~133, 200 distinct) are classification mappings, retained per rowspan group in _reference/space_usage.json — reference only, not valid inputs. (Supersedes an interim 555-value union that had folded both columns together.)
• From the Space Usage (Others) page: EmergencyVoiceCommunicationSystem (3), FireDetectionAndSuppressionSystem (8), FireEmergencyVentilationMode (6), SmokeControlSystem (4), VentilationMode (3, after de-duplicating a repeated cell value).

Official-page quirks recorded (data kept faithful):

• One <h3> merges two typologies — "6) Hospital with A&E services 7) Hospital without A&E services" — split into two entries.
• Occupancy numbering is not sequential on the page: after typology 52 the list reads "49) Hostel" then "54) Hotel". Numbers are stripped and names kept verbatim, so the misnumbering does not affect allowed_values.
• Cross-agency mapping tables use nested per-row rowspans. SCDF Purpose Group, BCA Type of Occupancy and NEA are parsed where a typology has its own table; 28 typologies are presented in shared groups with no own table (all mapping fields null); the BCA Accessibility Code (2019/2025) and PUB SSW columns never aligned reliably and are always null. All nulls are deferred for manual review, never guessed.

Scope / notes:

• The /regulatory-process/by-key-gateways pages were intentionally excluded per owner decision; only the ifc-sg glossary / space-usage pages were ingested.
• The generic Space component (arc/space/, #62) remains declarative-only with no properties — confirmed correct against the CoP (it defines no IFC-SG properties).
• README/notes not regenerated (as above); manifest counts unchanged.

System types + official rules capture — 2026-07-19

System Types (canonicalized). The System glossary page renders a canonical "List of System Types" inline (18 values). Harvested verbatim into _reference/system_types.json. Resolved System / SystemType (1 binding) and Prefabricated Building Systems and MEP Components / SystemType (5 bindings) from it — coverage 200/219 → 206/219 (13 pending). The CoP-derived 6-value example is a subset of the 18.

Conflicts recorded (not silently merged):

• CoP input_limited inconsistency. 16 components carry the SystemType/SystemName pair with the identical shared vocabulary, but SystemType is marked input_limited on only System and Prefabricated Building Systems — every other component leaves it free-input. (The owner's count of 18 components was verified against the corpus as 16.)
• Prefabricated SystemType page value. The Prefabricated page's own cell reads "Chilled Water", which is not in the canonical List of System Types. Resolved from the canonical list; the "Chilled Water" outlier is flagged here for adjudication at the next CoP regeneration.

Official "Actual Values" / rules capture (new reference dimension). _reference/parameter_rules.json now records official-page Actual Values, rules and notes the CoP corpus doesn't carry, from the Space (Area Requirement) page (IfcSpace/AREA_GFA): ALS_LandscapeType (8 values, incl. "Decked / Patterened Floor" [sic]), ALS_GreeneryFeatures (12), ALS_Species (4, example-only), AVF_IncludeAsGFA (Yes / No), the AGF_Name recommended-values rule sentence, and the "Shurbs" [sic] footnote. These are reference only — NOT promoted to allowed_values, because the CoP marks these parameters free-input; that free-input-vs-official-actual-values conflict is exactly what is recorded.

• Boolean value-set discrepancy. AVF_IncludeAsGFA's page type reads "[Booelan]" [sic] with values "Yes / No"; the corpus renders Booleans as TRUE / FALSE. Recorded, not reconciled.
• Green Verges ALS_GreeneryFeatures stays pending (official values are on the area-requirement page, cross-component applicability unconfirmed). Household Shelter and Parking Lot AGF_Name stay pending, now pointing at the space_area_names.json catalogue as the related official source (applicability unconfirmed). The /regulatory-process/by-key-gateways pages remain excluded.

reference_values mechanism — 2026-07-19

Owner ruling: official canonical values should be visible on every component carrying a property, not only the CoP input-limited bindings. Introduced a second value kind so the two truths stay distinct and no soft value is mistaken for a hard rule:

• allowed_values — hard constraint. Only on params the CoP marks input_limited: true. Apps reject values outside the list.
• reference_values (+ reference_values_source) — official vocabulary that exists even though the CoP leaves the param free-input. Apps should soft-warn, not hard-fail. Never both on one param (allowed_values and reference_values are mutually exclusive).

Applied via reference_resolutions in enum_resolutions.json (18 explicit entries, no wildcards) → resolve_enums.py sets reference_values only on non-input-limited params lacking allowed_values:

• SystemType — the canonical 18-value List of System Types on the 15 components with non-input- limited SystemType bindings (including System's 14 non-IL bindings). Prefabricated (all bindings input-limited) keeps allowed_values, not reference_values.
• Space (Area Requirements) — ALS_LandscapeType (8), ALS_GreeneryFeatures (12), AVF_IncludeAsGFA (kept verbatim as "Yes"/"No" — the page's form, not the CoP's TRUE/FALSE; discrepancy above). ALS_Species is example-only and was not added.

41 params gained reference_values across 16 files; allowed_values coverage is unchanged (206/219). The schema now carries optional reference_values / reference_values_source.

Corpus-wide special-treatment rules sweep — 2026-07-19

Completed the page cache — all 74 official component glossary pages are now cached (53 newly fetched with UA Mozilla/5.0 + 0.5s throttle; 0 unreachable). Swept the pages for special- treatment rules — cardinality/scope/obligation statements and property-specific modelling rules — and, after a reviewer completion pass, extended _reference/parameter_rules.json from 6 to 59 entries (27 rule, 28 note, 4 actual_values; 6 borderline) across 34 components. Verbatim text, official typos flagged [sic]; each property-naming entry was verified against the component's parameters.json (property_as_printed recorded where the page spelling differs, e.g. Distribution Chamber's "System Type"). Canonical example, captured verbatim — Project Development Type: "Only one Project Development Type property applies to the entire IFC model" (scope: model).

• Excluded (per the owner's by-key-gateways decision, and as off-topic): gateway/submission- process content (Design Gateway/CG/DG, PWCS clearance timelines, SS 642:2019 submission), and parking-provision policy text — this material is pulled into several component pages from shared blocks but is not a parameter special-treatment rule.
• Reviewer completion pass — added the recurring "Refer to System … 'SystemType' property" note on 4 more components where it is verbatim-present (Culvert/ Drains, Gutter, Interceptor, Pump), bringing that cross-reference note to all 15 non-System SystemType components; retrofitted scope onto the 6 legacy Space (Area Requirements) entries; flagged the Building Storey "must have be" [sic] grammar error.
• Not written into parameters.json — rules stay central in parameter_rules.json; apps join by component + property via corpus.json. All 74 files still validate against the schema and the build stays deterministic. (The human-facing parameter_rules.md is titled "CORENET X Notes".)

Reference values on pending params (owner ruling) — 2026-07-19

Owner ruling: as long as values match the official source, provide them as a reference/suggestion even where the confirmed hard list stays disputed. resolve_enums.py now allows reference_values on input-limited params too, provided they carry no allowed_values (exclusivity absolute).

• 10 of the 13 pending params gained reference_values from official sources (all 13 stay pending — the hard-list question is unchanged; each annotated reference_provided): Column & Beam MechanicalConnectionType, Distribution Chamber Status, Project Development Type, Refuse Chute EquipmentType (official "Dust Scren Compactor" [sic]), Staircase & Tank SpaceName (recorded glossary web_values); Green Verges ALS_GreeneryFeatures (the 12-value Space (Area Requirement) list, cross-page); Household Shelter & Parking Lot AGF_Name (the full 248-value AGF catalogue — per-development-use breakdown in space_area_names.json).
• 3 stay bare (no confident official list): Parking Lot SpaceName ("Parking place", single), Parking Lot VentilationMode (cell "…Air Conditioning Mechanical Ventilation" — a dropped-delimiter artifact that can't be split confidently), Wall ArrangementType ("Multi-Tier", single).
• allowed_values coverage unchanged (206/219); exclusivity audit — 0 params carry both; every applied reference_values matches its recorded official values. No schema change (the optional reference_values field already existed).