건축·공간의 왜·원리·득실을 인과 경로로 설명한다. "왜 콘크리트에 양생이 필요한가", "왜 방수층에 보호몰탈을 까는가"처럼 이유를 묻는 질문에 쓴다. 수치·조문이 필요하면 k_snippets 를 함께 부른다. relevance=low 또는 no_path_reason 이면 den 이 그 경로를 갖고 있지 않다는 뜻이니 근거로 쓰지 않는다.

두 개념이 어떻게 이어지는지 확인한다. "단열과 결로는 어떻게 연결되나", "전단벽에서 층간변위까지"처럼 출발·도착이 분명할 때 쓴다. 경로가 없으면 만들어 내지 말고 연결이 확인되지 않는다고 말한다.

"A 가 B 를 유발한다"는 한 연결의 근거를 확인한다. 앞선 답에 쓰인 인과를 검증할 때 쓴다. from·to 는 개념명, relation 은 causes/enables/requires 등. evidence_note 와 stance 를 구분해 전하고, disclaimer 가 있으면 그대로 표기한다.

한국 건설기준(KDS·KCS·KS)과 건축 법령의 수치·조문 원문을 찾는다. 건축·토목·시공·구조·설비 질문에 근거를 붙일 때 웹 검색보다 먼저 이 도구를 쓴다.

이럴 때 부른다: · 수치 기준 — "철근 피복두께", "콘크리트 압축강도 시험 재령", "방화구획 면적", "계단 챌판 높이" · 조문·법령 — 건축법·시행령·시행규칙, 국가건설기준 조항 · 시공 방법 — "이어치기 면 처리", "되메우기 다짐", "방수층 시공 순서" · 설계 요건 — 하중·내진·단열·피난·주차 기준

돌아오는 것: 조문 원문과 출처(예: KDS 14 20 22 §4.3.1). 출처를 그대로 인용한다.

★relevance=low 이거나 lacks_answer=true 면 den 이 그 자료를 갖고 있지 않다는 뜻이다. 스니펫을 근거로 쓰지 말고 "den 이 이 부분은 보유하지 않는다"고 말한 뒤 다른 출처로 답한다. (자료가 없는데 있는 척하는 것이 틀린 답보다 나쁘다.)

as_of 로 과거 시점 기준을 조회한다. 예: as_of=2020-06-01

공정 시나리오를 구성한다 — 관련 공정 노드를 모아 enables/requires 엣지로 위상정렬해 순서 있는 단계 흐름을 반환한다. '기초부터 3층까지 시공 순서', '가설공사 절차' 같은 시퀀스·시나리오 요청에 호출하라(단순 사실은 k_snippets). 결정론. ordering_coverage가 낮거나 gaps가 있으면 그래프에 순서 지식이 아직 없다는 정직한 신호 — 그 구간은 지어내지 말고 gaps 그대로 사용자에게 전하라.

두 공법·개념의 차이를 대조한다 — 'RC 구조 vs 조적조 시공순서 차이', '스틱 vs 유닛 커튼월' 같은 비교/차이 요청에 호출하라(단일 순서는 scenario). 각각을 결정론 구성해 A/B 시퀀스, A에만/B에만 있는 단계, 공유 단계, contrasts 엣지를 반환한다. LLM 없음. a_coverage/b_coverage가 낮으면 그쪽 지식이 얇다는 정직한 신호 — 지어내지 말고 gaps 그대로 전하라.

어떤 것의 종류·구성요소·분류를 완전 열거한다 — '건축물 하중의 종류', '구조용 강종 체계', '건축 도면의 종류' 같은 'X의 종류/체계' 요청에 호출하라(순서는 scenario, 비교는 compare). 권위표준 기반 큐레이션 분류학으로 완전한 멤버 목록을 반환하고, 각 멤버 정의는 그래프에서 당긴다. 결정론. match=None이면 미큐레이션 주제 — k_snippets로 폴백. gaps는 멤버 정의가 아직 그래프에 없다는 정직한 신호(지어내지 말고 그대로 전하라).

시공 순서와 선후 관계를 따라간다 — '무엇이 무엇보다 먼저 와야 하는가'. '기초부터 골조까지 순서', '거푸집 해체 전에 확인할 것' 같은 공정 질문에 쓴다. relation=requires 는 선행 조건, enables 는 후속 가능 작업이다. 빈 결과는 den 이 그 순서를 아직 갖고 있지 않다는 뜻이다 — 순서를 지어내지 않는다.

지명·좌표를 기후·문화·관할 조건으로 바꾼다. 대지·지역·행정구역·위경도가 언급되면 다른 도구보다 먼저 부르고, 돌아온 scope 와 jurisdiction 을 뒤따르는 질의에 넘긴다. 행정구역이 확인되지 않은 좌표 결과는 추정이라고 밝힌다.

공간을 순서대로 지날 때의 분위기 전이를 읽는다. "진입에서 거실까지 감정 흐름", "압축에서 해방" 처럼 이동 순서와 체험 목표가 있을 때 쓴다. spaces 는 실제 이동 순서로 넣는다. 작품 평가("왜 걸작인가")에는 쓰지 않는다.

평면도·배치도를 건축 법규 관점에서 검토한다 — 채광·환기·피난·면적 요건 위반을 짚는다. 사용자가 도면을 공유하거나 공간 구성 검토를 요청하면 이 도구를 쓴다. 이미지가 아니라 도면에서 읽어낸 구조를 넣는다: 방(용도·외부창 유무)·인접·개구부·동선. 위반(violation) 항목은 답변에서 빼지 않는다.

사용자가 직접 입력하는 폼이 아니라, 호출 에이전트가 직전 Den 응답을 활용한 뒤 사용자가 보인 반응(수정 지시/불만/채택/무시)을 대화 종료 전 요약 수준으로 기록하는 릴레이 툴. query_id가 있으면 그대로 전달하고, 없으면 직전 Den 툴에 전달한 question_text만 전달한다. satisfied를 기록하고, 불만족이면 issue_type을 지정하며 comment는 반응 요지만 200자 이내로 요약한다. 채택·긍정은 satisfied=true, 수정 지시·불만·명시적 무시는 satisfied=false와 가장 가까운 issue_type으로 매핑한다. 관찰 가능한 반응이 전혀 없으면 만족 여부를 추측하지 않는다. ★satisfied=true(채택·긍정)이면 comment 에 den 이 없었으면 무엇을 하려 했는지 한 마디를 함께 적는다 — "다른 값을 쓰려 했다" · "몰라서 정하지 못하고 있었다" · "다른 출처로 갔어야 했다" 중 사용자가 실제로 말한 것. 이 한 마디만이 'den 을 썼다'와 'den 때문에 달라졌다'를 가른다. ★★사용자가 말하지 않았으면 비워 둔다. 추측해 지어내지 않는다 — 없는 것을 적는 편이 안 적는 것보다 나쁘다. ★★★그렇다고 comment 를 통째로 생략하지는 않는다. satisfied=true 면 무엇을 채택했는지 한 줄은 항상 적는다(어느 값·조문·판단을 그대로 썼는가). 비워 두는 것은 반사실 한 마디뿐이다 — 요지까지 비면 그 만족은 기록에 남아도 쓸 수 없다. 사용자 대화 원문은 전송하지 않는다. 만족/불만족과 사유는 다음 날 그래프 보완에 반영된다.