2026-06-07 — Executive dashboard escalation ladder

Design principle

대시보드는 정보를 모으는 화면이 아니라, 주의를 배분하는 화면이다. 임원/아침 브리프용 dashboard IA는 “무엇을 볼 수 있는가”보다 “지금 무엇부터 판단해야 하는가”를 먼저 정렬해야 한다.

핵심 원칙: 상태 → 우선순위 → 이유 → 다음 행동 순서로 노출한다. 장식적 KPI 묶음보다 Escalate / Decide / Verify / Monitor / Archive 같은 판단 상태가 먼저 보여야 한다.

Observed problem

08:00 brief나 unified-report-webapp이 여러 도메인 자료를 모으면 다음 문제가 생긴다.

• 보험, 투자, 뉴스, 프로젝트 이슈가 같은 카드 밀도로 섞여 긴 리스트가 된다.
• 높은 중요도와 높은 불확실성이 구분되지 않아 “급한 것”과 “검증할 것”이 충돌한다.
• 숫자/KPI가 많아질수록 실제 행동 지시가 아래로 밀린다.
• 사용자는 각 카드의 본문을 열어야만 왜 중요한지 알 수 있다.
• 완료/보류/노이즈 항목이 계속 남아 아침 판단 공간을 잡아먹는다.

Improved layout/template

Executive dashboard IA: escalation ladder

# Executive Dashboard / 08:00 Judgment Board

## 0. Morning answer
- 오늘 가장 중요한 판단: {one sentence}
- 오늘 버릴 노이즈: {one sentence}
- 오늘 확인해야 할 미확정 변수: {one sentence}

## 1. Escalate — 지금 Phillip 판단 필요
### {Issue}
- 결론: {recommended decision or stance}
- 이유: {why now / impact if delayed}
- 선택지: {A / B / wait}
- deadline: {time or trigger}

## 2. Decide — 권고안은 명확, 승인만 필요
### {Issue}
- 권고: {do / don't / hold}
- 근거: {2 facts max}
- downside: {main risk}

## 3. Verify — 판단 전 확인 필요
### {Issue}
- 모르는 것: {missing fact}
- 확인 방법: {source / agent / document}
- 판단 조건: {if X then Y}

## 4. Monitor — 오늘 당장 행동 없음
- {Issue}: {trigger that would promote to Verify/Decide}

## 5. Archive / Ignore — 아침 화면에서 제거
- {Issue}: {why removed}

Card metadata for webapp

priority_lane: escalate | decide | verify | monitor | archive
judgment_state: ready | blocked | watch | closed
owner_agent: zain | news | stock | insurance | coder | orchestrator
deadline_or_trigger: "YYYY-MM-DD HH:mm or event"
why_now: "one sentence"
user_action_required: true | false

Mobile readability rules

• 모바일 첫 화면에는 Morning answer와 Escalate만 보이게 한다.
• lane 이름은 명사보다 동사형으로 둔다: Escalate, Decide, Verify, Monitor, Archive.
• lane당 기본 노출은 최대 3개. 초과분은 webapp detail 또는 appendix로 보낸다.
• 각 카드 첫 줄은 결론/권고/모르는 것 중 하나로 시작한다.
• 중요함과 불확실함을 같은 색이나 같은 뱃지로 표시하지 않는다. 중요함은 priority, 불확실함은 confidence/review_required로 분리한다.
• 4열 이상 표는 모바일 본문 금지. dashboard에서는 lane / issue / why_now / action 4필드까지만 요약한다.
• 차트는 lane 승격/강등 판단을 설명할 때만 쓴다. 예: 손해율 추세 악화로 Monitor→Verify 승격. 단순 현황 장식 차트는 제외한다.

How to apply to 08:00 brief or webapp

08:00 brief

• 기존 오늘의 결론 3줄 아래에 Escalate / Decide / Verify / Monitor 순서를 고정한다.
• 전문 에이전트 산출물은 도메인별 묶음이 아니라 lane별로 재배치한다.
• 불확실성이 높은 항목은 중요해 보여도 Decide가 아니라 Verify로 둔다.
• Archive / Ignore를 짧게 남겨 왜 빠졌는지 기록하면 같은 노이즈가 다음날 반복 진입하는 것을 줄인다.

unified-report-webapp

• 홈 화면 default sort는 최신순이 아니라 priority_lane 순서로 둔다.
• 카드 header에는 lane, why_now, deadline_or_trigger, user_action_required만 노출한다.
• 상세 화면에서만 facts/evidence/chart를 펼친다.
• lane 이동 이력(Monitor → Verify → Decide)을 남기면 “왜 오늘 갑자기 중요해졌는지”를 빠르게 설명할 수 있다.

Risks / anti-patterns

• 모든 것을 Escalate로 올리면 dashboard가 알람 피로를 만든다. Escalate는 Phillip의 즉시 판단이 없으면 비용이 생기는 항목만 허용한다.
• Archive / Ignore를 삭제로 처리하면 다음날 같은 이슈가 재등장한다. 짧은 제거 이유를 남기는 편이 낫다.
• lane 기준이 도메인마다 다르면 통합 dashboard가 깨진다. 보험/투자/뉴스 모두 같은 lane 정의를 써야 한다.
• dashboard가 너무 webapp 중심이 되면 Telegram 08:00 brief가 길어진다. 모바일 텍스트가 원본, webapp은 확장/필터 인터페이스로 유지한다.
• 차트로 lane을 정당화하려다 본문이 무거워질 수 있다. 차트는 “승격 사유”를 한눈에 보여줄 때만 사용한다.

Next questions

• Phillip의 실제 아침 판단에서 Escalate 허용 개수는 1개인가, 3개인가?
• Verify 항목의 owner를 사람/에이전트/시스템 중 어디까지 명시해야 하는가?
• unified-report-webapp에서 lane 변경 이력을 UI에 노출할 것인가, 내부 로그로만 둘 것인가?
• Archive / Ignore 노트가 쌓이면 별도 노이즈 패턴 학습으로 연결할 수 있는가?
• 보험/투자/프로젝트 도메인별로 deadline_or_trigger 표현 규칙이 달라야 하는가?

Durable learning

Zain의 오늘 개선 방향: 통합 보고서는 도메인별 목차보다 판단 상태별 lane이 빠르다. 08:00 brief와 unified-report-webapp은 Escalate / Decide / Verify / Monitor / Archive ladder를 기본 IA로 실험한다. 목표는 더 예쁜 dashboard가 아니라 Phillip이 10초 안에 “내가 지금 개입해야 하는가”를 판단하게 하는 것이다.