den — Korean AEC knowledge, curated

건축·공간의 **왜·원리·득실**을 인과 경로로 설명한다. "왜 콘크리트에 양생이 필요한가", "왜 방수층에 보호몰탈을 까는가"처럼 이유를 묻는 질문에 쓴다. → 대신 쓸 것: 이미 아는 인과 **한 줄의 근거만** 확인하려면 evidence_for · 두 개념이 **이어지는지만** 보려면 path_between · **수치·조문**이 필요하면 k_snippets · 용어 **뜻**만 물으면 define. ★파라미터: depth 는 L1<L2<L3 순으로 경로를 넓게 본다(홉 상한 4). profile 은 depth 와 별개로 **탐색 예산**을 정한다 — direct=2홉/3경로, standard=기본, **deep 은 쿼터를 5회분 쓴다**(6홉/12경로). 둘 다 주면 profile 이

두 개념이 **어떻게 이어지는지** 확인한다. "단열과 결로는 어떻게 연결되나", "전단벽에서 층간변위까지"처럼 **출발·도착이 분명할 때** 쓴다. → 대신 쓸 것: 한 지점에서 **관계를 따라가며** 훑으려면 traverse · 공정 **전체 흐름**이면 scenario · **왜 그런지 설명**이 필요하면 answer_why · **한 연결의 근거**만이면 evidence_for. ★파라미터: a·b 는 문장이 아니라 **개념 이름/구**로 넣는다("결로" O, "왜 결로가 생기나" X). a 와 b 가 같으면 빈 결과다. scope 는 쉼표로 여러 축을 주면 **모두 만족**하는 경로만 남긴다 (climate=arid,epoch=ancient). **profile=deep 은 쿼터를 5회분

"A 가 B 를 유발한다"는 **한 연결의 근거**를 확인한다. 앞선 답에 쓰인 인과를 검증할 때 쓴다. → 대신 쓸 것: 두 개념 사이 **경로를 찾는** 것이면 path_between · **왜 그런지 설명**이면 answer_why · 수치·조문 근거면 k_snippets. 이 도구는 **이미 아는 한 엣지**를 겨눈다. ★파라미터: from·to 는 개념 이름이고(문장 아님), relation 은 그래프 엣지 종류다 — causes(유발) · enables(가능하게 함) · requires(선행 필요) · contrasts(대비). 셋 다 필수다. relation 을 모르면 이 도구 대신 path_between 으로 먼저 어떤 관계인지 본다. ★evidence_note 와 stance 를

한국 건설기준(KDS·KCS·KS)과 건축 법령의 **수치·조문**을 찾는다. 건축·토목·시공·구조·설비 질문에 근거를 붙일 때 **웹 검색보다 먼저** 이 도구를 쓴다. 예: "철근 피복두께", "방화구획 면적", "이어치기 면 처리", "되메우기 다짐", 건축법 조항. → 대신 쓸 것: **용어 뜻**은 define · **종류 열거**는 enumerate · **공정 순서**는 scenario · **두 공법 차이**는 compare · **왜 그런지**는 answer_why. 대지·행정구역이 걸리면 site_context 를 **먼저** 부르고 그 scope 를 여기 넘긴다. ★파라미터: scope 와 profile 은 **다른 축**이다 — scope 는 *어느 공종*(좁힘), profi

공정 시나리오를 구성한다 — 관련 공정 노드를 모아 enables/requires 엣지로 위상정렬해 순서 있는 단계 흐름을 반환한다. '기초부터 3층까지 시공 순서', '가설공사 절차' 같은 **시퀀스·시나리오** 요청에 호출하라. → 대신 쓸 것: 단순 사실·수치는 k_snippets · **두 지점 사이**만 궁금하면 path_between · 한 노드의 **선후 이웃**만이면 traverse · 두 공법 **차이**는 compare. ★파라미터: max_nodes 는 **5~60 으로 잘린다**(기본 40). 올리면 넓게 모으지만 느슨한 노드가 섞여 ordering_coverage 가 떨어질 수 있다 — 먼저 기본으로 보고 gaps 를 본 뒤 올린다. 결정론(LLM 없음). ordering_covera

두 공법·개념의 **차이**를 대조한다 — 'RC 구조 vs 조적조 시공순서 차이', '스틱 vs 유닛 커튼월' 같은 **비교/차이** 요청에 호출하라. → 대신 쓸 것: 단일 순서는 scenario · 종류 열거는 enumerate · 용어 뜻은 define · 수치·조문은 k_snippets. ★파라미터: a·b 는 **개념/공법 이름**이다(질문 문장 아님). 'A vs B' 를 a 에 한 번에 주면 b 를 비운다 — 그때 구분자는 vs 다. 한쪽만 주고 b 를 비우면 비교할 짝이 없어 얻을 것이 없다. 각각을 결정론 구성해 A/B 시퀀스, A에만/B에만 있는 단계, 공유 단계, contrasts 엣지를 반환한다. LLM 없음. a_coverage/b_coverage 가 낮으면 그쪽 지식이 얇다는 정직

어떤 것의 **종류·구성요소·분류**를 완전 열거한다 — '건축물 하중의 종류', '구조용 강종 체계', '건축 도면의 종류' 같은 **'X의 종류/체계'** 요청에 호출하라. → 대신 쓸 것: 순서는 scenario · 비교는 compare · **한 용어의 뜻**은 define · 수치·조문은 k_snippets. ★파라미터: query 는 'X의 종류/체계/구성요소' 꼴로 준다. 낱말 하나만 주면(예: '하중') 무엇을 열거할지 정해지지 않아 match 가 안 잡힐 수 있다. 권위표준 기반 큐레이션 분류학으로 완전한 멤버 목록을 반환하고, 각 멤버 정의는 그래프에서 당긴다. 결정론. match=None 이면 미큐레이션 주제 — k_snippets 로 폴백. gaps 는 멤버 정의가 아직 그래프에 없다는

건축·건설 **용어 하나의 뜻**을 돌려준다 — '이형철근이 뭔가', '방화구획이란', '옹벽과 흙막이의 정의' 같은 **'X가 무엇인가'** 질문에 호출하라. → 대신 쓸 것: **수치·조문**이 필요하면 k_snippets · **종류/체계 열거**는 enumerate · **왜 그런지**는 answer_why · **두 개념 차이**는 compare · 두 개념이 **어떻게 이어지는지**는 path_between. 이 도구는 정의 한 덩어리만 준다 — 기준값은 주지 않는다. ★파라미터: term 은 **용어 하나**로 넣는다(질문 문장이나 여러 용어 나열이 아니다). limit 는 동음이의로 갈릴 때 몇 개까지 볼지이고 1~5 로 잘린다(기본 3). as_of 는 YYYY-MM-DD. ★abstaine

**시공 순서와 선후 관계**를 따라간다 — '무엇이 무엇보다 먼저 와야 하는가'. '기초부터 골조까지 순서', '거푸집 해체 전에 확인할 것' 같은 공정 질문에 쓴다. → 대신 쓸 것: 출발·도착 **두 지점이 분명하면** path_between · 공정 **전체 흐름**을 한 번에 구성하려면 scenario · 두 공법 **차이**는 compare · 단순 수치·조문은 k_snippets. ★파라미터: relation=requires 는 **선행 조건**(이것보다 먼저 와야 하는 것), enables 는 **후속 가능 작업**, causes 는 인과, contrasts 는 대비다. 생략하면 전부 본다. direction=out 은 정방향(다음), in 은 역방향(이전) — 'X 전에 무엇을' 은 in 이

지명·좌표를 **기후·문화·관할** 조건으로 바꾼다. 대지·지역·행정구역·위경도가 언급되면 다른 도구보다 **먼저** 부른다. → 그다음: 돌아온 scope 를 k_snippets·answer_why 에, jurisdiction 을 review_plan 에 넘긴다. 이 도구 자체는 기준·수치를 주지 않는다 — 수치는 k_snippets, 도면 검토는 review_plan. ★파라미터: region 을 **먼저** 본다. lat/lng 는 region 이 없거나 못 찾을 때의 대체 경로다 — 둘 다 주면 region 이 이긴다. region 은 등재된 지명·별칭에 맞아야 한다("부산 수영구" O). 셋 다 비우면 아무것도 못 정하고 relevance=low 로 돌려준다. ★행정구역이 확인되지 않은

공간을 순서대로 지날 때의 **분위기 전이**를 읽는다. "진입에서 거실까지 감정 흐름", "압축에서 해방"처럼 이동 순서와 체험 목표가 있을 때 쓴다. → 대신 쓸 것: 작품 평가나 "왜 걸작인가" 같은 **이유**는 answer_why · 법규 관점 평면 검토는 review_plan · 공정 순서는 scenario. 이 도구는 **체험 순서**만 다룬다. ★파라미터: spaces 는 **실제 이동 순서**로 넣는다 — 배열 순서가 곧 동선이고, 순서를 바꾸면 결과가 바뀐다. 하나만 넣으면 전이가 없어 얻을 것이 없다(둘 이상). target 은 선택이고, 넣으면 그 목표에 대한 정합/괴리를 같이 본다. 읽기 전용 · 외부 호출 없음.

평면도·배치도를 **건축 법규 관점에서 검토**한다 — 채광·환기·피난·면적 요건 위반을 짚는다. 사용자가 도면을 공유하거나 공간 구성 검토를 요청하면 이 도구를 쓴다. → 대신 쓸 것: 특정 **수치·조문 하나**의 근거면 k_snippets · **왜 그 요건인지**는 answer_why · 체험·분위기 관점이면 emotional_palette. 대지의 관할이 걸리면 site_context 를 **먼저** 부르고 그 jurisdiction 을 여기에 넘긴다. ★입력: 이미지가 아니라 **도면에서 읽어낸 구조**를 넣는다 — 방(용도·외부창 유무)·인접·개구부·동선. rooms 만 필수이고 나머지는 선택인데, **빠뜨린 만큼 검토가 좁아진다**(adjacency 가 없으면 인접 요건을, circulatio

사용자가 직접 입력하는 폼이 아니라, 호출 에이전트가 직전 Den 응답을 활용한 뒤 사용자가 보인 반응(수정 지시/불만/채택/무시)을 대화 종료 전 요약 수준으로 기록하는 릴레이 툴. query_id가 있으면 그대로 전달하고, 없으면 직전 Den 툴에 전달한 question_text만 전달한다. satisfied를 기록하고, 불만족이면 issue_type을 지정하며 comment는 반응 요지만 200자 이내로 요약한다. 채택·긍정은 satisfied=true, 수정 지시·불만·명시적 무시는 satisfied=false와 가장 가까운 issue_type으로 매핑한다. 관찰 가능한 반응이 전혀 없으면 만족 여부를 추측하지 않는다. ★satisfied=true(채택·긍정)이면 comment 에 **den 이 없었