Design Memory Platform

The GALF Contract

v0.008 · 2026-07-17

GALF is the GAAD Architectural Language Framework. GALF defines the Architectural Language Contract that every GAAD Architectural Language must implement.

18 sections, 11 of them Required. Every language file answers this page section by section, by the same numbers: s4 here is s4 there.

REQUIRED (11)    RECOMMENDED (6)    OPTIONAL (1)
s1 Missions2 Requirementss3 Identitys4 Terminologys5 Hierarchys6 Relationshipss7 Parameterss8 Operationss9 Ruless10 Constraintss11 Evidences12 Statuss13 Validations14 Memorys15 Historys16 Implementations17 Resolution Axiss18 Knowledge Status
Part one - What GALF is
Four cards: the definition, the core decision, the base relationship vocabulary and the section addressing rule. Read these once. The sections below are what a language actually fills in.

Definition

GALF is the GAAD Architectural Language Framework. GALF defines the Architectural Language Contract that every GAAD Architectural Language must implement.

Core Decision

GALF is not a single language, not a geometry format, not a BIM replacement schema, and not tied to Blender or any execution engine. GALF is the contract that PRAL, GRAL, MHAL, FWAL and future Architectural Languages conform to.

Base Relationship Vocabulary

itemdetail
ruleEvery s6 triple validates against base UNION the language's declared types. Nothing else passes.
declaring extrasA language MAY declare additional types in its own s6 as declared_relationship_types, each with a one-line definition. Declared types are local to that language.
note

The base vocabulary s6 has always referred to and never had. A triple is valid when its relationship_type is in this set, or is declared by the language in its own s6 with a definition. Ten types, small enough to hold in the head - a vocabulary nobody can remember gets reinvented, which is how the drift started.

measured drift 17 jul 2026

Measured across Languages/ on 17 Jul 2026, and corrected the same day after the first count proved wrong. 21 distinct types are in use, not the 13 first reported: the first scan read only three-element triples and so missed FWAL entirely. Base set covers PRAL, GRAL, MHAL and FWAL's belongs_to/defines. Outside it: TWAL uses has, holds and 'is one of' (retired below), and FWAL brings eight of its own - responds_to, grows_from, projects_over, anchors, reveals, transitions, frames, reinforces - which are real architectural relations and are candidates for FWAL's declared_relationship_types, not for the base. See T030.

rationale element open

OPEN, for the Chief Architect: s6 describes a three-element triple. FWAL's 11 rows carry a FOURTH element, a rationale in plain English saying why the relation holds - and it is the most useful thing in any s6 in the estate. Either FWAL is non-conformant, or the contract should allow an optional fourth element. Not decided here.

types
itemdetail
containsThe source structurally holds the target. Containment, one level down. (City contains District.)
is aThe source is a kind of the target. Classification, not containment. (Cube is_a Primitive.)
belongs toThe source is attributed or assigned to the target without being contained by it. (Land Use belongs_to Parcel.)
assembles intoSeveral of the source form one target. Parts to whole. (Plot assembles_into Parcel.)
definesThe source determines the target's extent or identity without holding it. (Road defines Block.)
controlsThe source governs what the target may be or do. (Land Use controls Building.)
occupiesThe source physically sits within the target's extent. (Landscape occupies Parcel.)
becomesThe source turns into the target over time. The mutation relation.
usesThe source depends on the target to do its work.
supportsThe source bears the target structurally.
retired
itemdetail
hasAmbiguous. Use contains for structural holding, belongs_to for attribution.
holdsAmbiguous. Use contains.
is one ofNatural language, not a type - the exact thing amendment A3 forbids. Use is_a.

Section Addressing

itemdetail
x extensionsx_ keys are no longer the home for content that a section owns. Anything that belongs to a section goes in that section. Research is not language content and does not live in a language file (D170).
conformance is generatedOnce files carry codes, the conformance table is GENERATED from Languages/, never typed. A typed table is a snapshot and rots.
pilotMHAL v0.007 (17 Jul 2026) is the first file on the spine: 10 of 18 present, Required 6 of 11.
rule

NORMATIVE from v0.008: a language file addresses the contract by CODE - s1 to s18 - and carries every section, with no exceptions. A section either holds content or states unknown. Sections are not omitted.

why

Before this rule, sections were found by guessing at each file's chosen key names, and content sat in x_ extensions because no section claimed it. Nothing could be checked, so the conformance table was typed by hand and went stale the day a language moved (it rated MHAL v0.004 while MHAL was at v0.006, and covered four languages of six).

unknown is an answer

An empty section states unknown. Silence is not an answer: it cannot be told apart from an oversight. Amendment A2 still stands - Mission, Identity and Validation must carry meaningful content, never only the unknown marker.

shape
itemdetail
sthe section number, 1 to 18
sectionits name from contract_sections
levelRequired / Recommended / Optional, from contract_sections
statuspresent or unknown
contentpresent only when status is present
noteoptional - what moved here, or why it stands empty
Part two - The 18 sections
s1 to s18. Every language carries all eighteen: content, or unknown.
s1

Mission

REQUIRED

The one-sentence reason the language exists - what body of architectural knowledge it captures and why. May never be empty.

s2

Requirements

REQUIRED

What the language must be able to express or generate to count as complete - the acceptance conditions it holds itself to.

s3

Identity

REQUIRED

Name, full name, framework (GALF), the conforms_to version, and the two status axes (knowledge_status, platform_status). The language's passport.

s4

Terminology

REQUIRED

The controlled vocabulary of named objects and concepts. Every term used elsewhere in the file must be defined here (coherence rule 3.6).

s5

Hierarchy

REQUIRED

How the terms nest - the containment tree from largest to smallest (e.g. Site to Building to Space). Every hierarchy term must exist in Terminology.

s6

Relationships

REQUIRED

Typed triples (source, relationship_type, target) using base or declared relationship types. How objects relate beyond mere containment.

s7

Parameters

REQUIRED

The measurable dials of the language - values with units. Carries the s18 provenance schema and the dimensional standard (m/m2 to 2dp, sub-cm in whole mm).

s8

Operations

RECOMMENDED

What the language can DO in its own vocabulary - the verbs it supports, kept implementation-independent (it names no engine; s10 neutrality).

s9

Rules

REQUIRED

The architectural behaviours the language enforces - the 'shall' statements that make output recognisably in-family. The heart of a design language.

s10

Constraints

RECOMMENDED

Hard limits and forbidden states - what the language must never produce, distinct from Rules which shape what it should.

s11

Evidence

RECOMMENDED

The provenance ledger - where the language's knowledge came from, verified vs unverified, and what remains to be sourced. Pairs with s18.

s12

Status

REQUIRED

Per-concept maturity using the fixed vocabulary (known/assumed/inferred/unknown/deprecated/future) - how settled each part of the language is.

s13

Validation

REQUIRED

How the language proves its output belongs to the reference family - the acid tests it must pass. Recognition, not geometric duplication.

s14

Memory

REQUIRED

What the language preserves across evolution - the design reasoning, pruned branches, and rule provenance that make it Design Memory not just geometry. May never be empty.

s15

History

RECOMMENDED

The language's own version lineage and how its knowledge accumulated - provenance of the file itself, never restarted.

s16

Implementation

OPTIONAL

The honest current state of any prototype - what runs, what does not, and how it runs through the Connector when built.

s17

Resolution Axis

RECOMMENDED

The scale ladder the language operates on (e.g. Site Response, Scale, Building) - declared so languages at different resolutions can be compared.

s18

Knowledge Status

RECOMMENDED

NEW v0.006. The Honest Knowledge section: the 7-level evidence vocabulary, the parameter provenance schema, and the dimensional standard. Records how confidently each fact is known and from where.

Part three - The rest of the contract
Principles, validation layers, stewardship, amendments and the revision history.

Pronunciation Note

GAAD is written GAAD and pronounced GAD. It must not be written as GAD and must not be confused with CAD.

Principles

Architectural Languages

itemfull nameknowledge statusplatform statuscurrent fileresolution axis
PRALPrimitive Architectural Languageseedactivev0.001, conforms_to GALF v0.004not applicable
GRALGarden Room Architectural Languageprototypeunintegratedv0.021, conforms_to GALF v0.004Stage Depth
MHALManhattan Architectural Languageexploringunintegratedv0.003, conforms_to GALF v0.004Scale
FWALFallingwater Architectural Languageseedunintegratedv0.002, conforms_to GALF v0.004Site Response (Site -> Composition -> Sequence -> Space -> Material Detail)

Platform Contact Point

itemdetail
noteStanding precondition banked 07 Jul 2026, extended with the contract version. Replay never mutation.
stage file fields

Validation Layers

Versioning Notes

File Naming Recommendation

files

Record Quote

Missing geometry is a knowledge signal, not a modelling failure.

Review Amendments Applied

Stewardship

GALF is owned by the Specification Owner and versions on the GAAD spec track, filed in Spec/. v0.005 is the first content version cut under stewardship (v0.004 was stewardship-only).

Changes From V0 004

Resolution Axis

itemdetail
stateFROZEN at v0.005 (was EXPERIMENTAL); contract section 17, Recommended
conceptThe language's ordered ladder along which design knowledge resolves - knowledge resolution, not physical containment. Every rung answers: how deeply is this design understood?
acid testFWAL (verdict in FWAL v0.002, 09 Jul 2026): concept survived unchanged.
replayReplay honours the recorded rung as it honours the recorded language (s7).
declaration

X V0 006 Candidates

itemdetail
noteKnowledge Status ADOPTED as s18 in v0.006 (11 Jul 2026). Three candidates remain open for a future version: Site, Experience, Fidelity.
logged2026-07-11 (Miles's clock). Raised by Miles + Specification Owner; for ChatGPT (Architecture Reviewer) review before any v0.006 is opened.
candidates
itemdetail
nameSite / Context
whyFWAL's core claim is that the building is unintelligible without its site; GALF has no Site section, so FWAL carries site in Terminology and Relationships. Candidate: a Recommended Site section.
fwal keyn/a - currently in Terminology/Relationships
itemdetail
nameExperience / Sequence
whyCompression-release, approach-arrival, prospect-refuge describe movement through a building over time; GALF's sections are all static structure. Candidate: a Recommended Experience section.
fwal keycarried via Operations + typed relationships
itemdetail
nameFidelity
whyGALF Validation checks 'is this a valid language file?'; it has no notion of 'does output belong to the reference family?'. Candidate: a Recommended Fidelity section distinct from Validation.
fwal keyx_fidelity_scorecard

Section 18 Knowledge Status

itemdetail
levelRecommended
principleHonest Knowledge
vocabulary reconciliationNOT reconciled by seat decision (11 Jul 2026): the 7-level Knowledge Status vocabulary and MHAL's 4-level V/C/P/I coexist. A language may use either; both are valid GALF evidence vocabularies.
ratified date2026-07-11
confidence field

OPEN (11 Jul 2026): whether a separate Confidence field is retained is undecided. evidence_status already encodes confidence; a Confidence field is admitted only if it captures something evidence_status cannot (e.g. numeric tolerance). Held pending seat decision.

parameter provenance schema
dimensional standard
ratified by
knowledge status vocabulary
itemdetail
VERIFIEDprimary source, official record, measured drawing, survey, or direct observation
DERIVEDmathematical conversion, calculated or aggregated value from verified inputs
SUPPORTED INTERPRETATIONarchitectural reading with multiple corroborating sources, not a measured fact
APPROXIMATEsource uses 'about', 'more than', 'circa', or a rounded value
EXTRACTABLEexists in an authoritative source but not yet transcribed
UNVERIFIEDcommonly repeated, no authoritative source found
UNKNOWNno evidence currently available

Changes From V0 005

v0.006 (11 Jul 2026): Honest Knowledge adopted. Added s18 Knowledge Status (Recommended) - seven-level evidence vocabulary, parameter provenance schema, and the dimensional standard (m/m2 2dp, sub-cm in whole mm). Confidence field held OPEN. The 7-level and MHAL 4-level vocabularies coexist by seat decision. Now 18 sections. Ratified by all three D140 seats. Site/Experience/Fidelity remain open candidates for a later version.

Subtitle

The GAAD Architectural Language Framework - the contract every Design Language implements

Revision History

v0.004 pre-11 Jul 2026

Prior edition (legacy filename).

v0.005 pre-11 Jul 2026

17-section contract, executable conformance. Legacy filename retained.

v0.006 2026-07-11

Honest Knowledge ratified by all three seats. Added s18 Knowledge Status (Recommended): 7-level evidence vocabulary, parameter provenance schema, dimensional standard (m/m2 to 2dp, sub-cm in whole mm). Confidence field held OPEN. 7-level and MHAL 4-level vocabularies coexist by seat decision. Contract grew 17 to 18 sections. First amendment through the full three-seat process.

v0.007 2026-07-11

Presentation and clarity revision (no normative change). Title set explicitly to 'The GALF Contract' with subtitle; version presented as an edition to stop it reading like a language-file version. Added section_definitions: a one-line readability gloss for each of the 18 sections (descriptive, not normative). Added this revision_history. Section count, levels and s18 content unchanged from 0.006.

v0.008 2026-07-17

Base relationship vocabulary written (ten types, plus declared extras and three retired). Section addressing made normative: s1-s18 by code, every section present, unknown stated not omitted. Answers T030 at the contract end; the languages migrate one at a time behind it.

Changes From V0 006

v0.007 (11 Jul 2026): clarity revision, no normative change. Explicit title 'The GALF Contract'; one-line definition added for each of the 18 sections (readability layer, not ratified prose); full revision history for today added. s18 and all section levels unchanged.

Changes From V0 007

v0.008 (17 Jul 2026): two things, both of them holes that were found rather than invented. FIRST, the base relationship vocabulary. s6 has always said triples use 'base or declared relationship types' and amendment A3 ruled they validate against a base vocabulary, but no such vocabulary existed anywhere in the contract - so nothing could be validated, and 13 types drifted into use across five language files, including 'is one of', which is a sentence. Ten base types are now defined, extras may be declared per language, and has/holds/'is one of' are retired with their replacements named. SECOND, section addressing by code. Sections are now found by number, not by guessing at each file's key names, and every section is carried - content or unknown. Both were ruled by the Chief Architect on 17 Jul after MHAL v0.007 proved the shape. The languages are NOT yet migrated: MHAL alone is on the spine.