@@ -183,11 +183,13 @@ Once the estimation specification is clarified, many other design decisions beco
 
 | 項目 | 仕様上の期待 | 現状実装 | GAP | 優先度 |
 |---|---|---|---|---|
-| 共通推定エントリ | app 側 `estimate.sh` を薄くし、共通呼び出し順を持つこと | `scripts/estimation/common.sh` と package 呼び出し型の `qws/estimate.sh` がある | 他 app への横展開が未着手 | 最優先 |
+| 共通推定エントリ | app 側 `estimate.sh` を薄くし、共通呼び出し順を持つこと | `scripts/estimation/common.sh` と package 呼び出し型の `qws/estimate.sh` がある | 他 app への横展開が未着手。`estimate.sh` 内の宣言ブロックの共通 API も未固定 | 最優先 |
 | 軽量推定 package | FOM-only、weak scaling 前提、補正なしなら FOM 一定 | `lightweight_fom_scaling` が実装済み | 参照実装は 1 本のみ。current/future 側で別 model を使う実運用は未整備 | 高 |
 | 適用可能性判定 | 不足入力を `applicable/fallback/not_applicable/needs_remeasurement` で扱うこと | `lightweight_fom_scaling` と `instrumented_app_sections_dummy` はこれらを扱え、final Estimate JSON では `applicable`、`partially_applicable`、`fallback`、`not_applicable` を表現できる。requested/applied package の識別も保持できる | 複数 detailed package 間の分岐、より細かい fallback 選択、UI 表示は未実装 | 高 |
 | package metadata | package 名、版、required inputs、fallback policy を持つこと | 軽量/詳細ダミーとも最小 metadata を持つ | richer metadata を discovery や UI に活かす実装がまだ無い | 中 |
-| section ごとの package 指定 | 区間ごとに推定 package を割り当てられること | `bk_emit_section` / `bk_emit_overlap` から Result JSON に `estimation_package` を載せられ、`instrumented_app_sections_dummy` でも dispatch に利用している | 他 app への横展開と package discovery の整理が未完 | 最優先 |
+| section ごとの package 指定 | 区間ごとに推定 package を割り当てられること | `bk_emit_section` / `bk_emit_overlap` から Result JSON に `estimation_package` を載せられ、`instrumented_app_sections_dummy` でも dispatch に利用している | 他 app への横展開と package discovery の整理が未完。app 側が実行前に宣言する形は設計整理済みだが未実装 | 最優先 |
+| app 側推定宣言 | app 側が実行前に section / overlap と `estimation_package` をまとめて宣言できること | `estimate.sh` に宣言ブロックを寄せる方向性は整理済み | 宣言 API、既定値の与え方、`run.sh` からの読込み方は未固定。実装も未着手 | 最優先 |
+| 追加採取実行 | 通常実行と別に詳細推定入力の採取だけを共通入口から追加実行できること | `run_estimation_data_collection` 方向は整理済み | shell API、分岐条件、保存処理との接続は未実装 | 最優先 |
 | section ごとの補助データ参照 | tgz 等の補助データを section ごとに紐付けられること | `qws` では section / overlap ごとに `artifacts` を Result JSON に保持し、詳細ダミー package でも利用している | 他 app への横展開と artifact 収集方式の一般化が未着手 | 高 |
 | overlap 推定 | overlap を独立した推定部品として扱えること | Result JSON で保持でき、詳細ダミー package でも overlap の `bench_time/time` は扱える | overlap 専用 package や複数方式切替は未実装 | 中 |
 | 詳細推定 package | `instrumented_app_sections` など取得方式別 package を持てること | `instrumented_app_sections_dummy` を `qws` 向け参照実装として実装済み | 実測区間時間や外部ツール区間時間を使う本格 package は未実装 | 最優先 |
@@ -249,11 +251,12 @@ AI 駆動最適化連携は、PoC を含む試行錯誤を前提として早め
 
 ### 6.1 短期 / Short Term
 
-1. `estimate.sh` のテンプレートまたは共通補助を整える
-2. `qws` 以外に 1 から 2 本の app へ推定を横展開する
-3. Estimate JSON と portal 表示を section / overlap 詳細まで整える
-4. 再推定比較の UI / API を整える
-5. package metadata discovery を portal や比較導線に活かす
+1. `estimate.sh` の宣言ブロックと共通補助を整える
+2. `run_estimation_data_collection` の共通入口を整える
+3. `qws` 以外に 1 から 2 本の app へ推定を横展開する
+4. Estimate JSON と portal 表示を section / overlap 詳細まで整える
+5. 再推定比較の UI / API を整える
+6. package metadata discovery を portal や比較導線に活かす
 
 ### 6.2 中期 / Mid Term
 
 
@@ -303,6 +303,41 @@ At this stage, this document does not fix whether section / overlap registration
 
 However, the semantic elements ultimately received by BenchKit should preferably be aligned as described above.
 
+### 6.4 app 側宣言ブロック / Application-Side Declaration Block
+
+詳細推定では、app 側が `estimate.sh` の中に推定用の宣言ブロックを持てる形が望ましい。`run.sh` は必要に応じて `estimate.sh` を読み込み、`estimate.sh` 自身は CI や再推定の入口としても使える形にしてよい。
+
+ここで app 側が先に宣言する内容は、少なくとも次が望ましい。
+- section 名
+- overlap 名
+- 各 section / overlap に割り当てる `estimation_package`
+- target system や target nodes などの app 既定値
+
+重要なのは、これらの宣言は「何を推定したいか」を先に示すためのものであり、実測値が確定したあとに後付けで決めるものではない、という点である。
+
+### 6.5 `bk_emit_*` との共存 / Coexistence with `bk_emit_*`
+
+`estimate.sh` 内の宣言を導入しても、`bk_emit_section` や `bk_emit_overlap` を直ちに廃止する必要はない。宣言は section / overlap と package 割当てを先に示し、`bk_emit_*` は実際に得られた値を Result JSON に流し込む既存手段として共存してよい。
+
+この形により、少なくとも次の 3 通りが同居できる。
+- app 実行中に直接得られた section 時間を `bk_emit_section` で出す
+- 実行後のログ解析で得た値を `bk_emit_section` で出す
+- 追加採取実行の結果を BenchKit 側でまとめて反映する
+
+### 6.6 追加採取実行 / Additional Data-Collection Run
+
+PAPI のように、通常実行とは別に追加採取実行が必要な入力は、`run_estimation_data_collection` のような共通入口から扱える形が望ましい。
+
+概念的には次の 2 段に分かれる。
+1. 通常実行
+   - 例: `mpiexec a.out ...`
+   - 主に FOM や通常 section 時間を得る
+2. 推定データ採取実行
+   - 例: `run_estimation_data_collection mpiexec a.out ...`
+   - package metadata を見て必要な counter / trace / 追加ログ採取を行う
+
+このとき、どの追加採取が必要か、複数回実行が必要か、保存先をどうするかは BenchKit 側で共通化して扱うのが望ましい。app 側は原則として、通常実行コマンドと section / overlap への package 割当てを示せばよい。
+
 ## 7. 失敗時の扱い / Failure Handling
 
 ### 7.1 採取失敗と実行失敗を分ける / Distinguish Acquisition Failure from Execution Failure
@@ -352,6 +387,8 @@ The application developer should generally only need to ensure:
 - auxiliary artifact references can be passed when needed
 - application-specific section names can be defined
 
+詳細推定では、これに加えて app 側が `estimate.sh` の宣言ブロックで section / overlap と `estimation_package` の割当てを先に示せるようにしてよい。ただし、採取手順の詳細や保存形式の詳細まで app 側へ押し込めない方が望ましい。
+
 ### 8.2 推定パッケージ開発者の責務 / Estimation Package Developer Responsibility
 
 推定パッケージ開発者は、原則として次を定義する。
@@ -386,6 +423,11 @@ BenchKit is generally responsible for:
 - handoff into estimation packages
 - unified storage and presentation formats
 
+詳細推定では、さらに次も BenchKit 側で扱うのが望ましい。
+- `estimate.sh` 内の宣言ブロックの読込み
+- package metadata を見た追加採取実行の組立て
+- `bk_emit_*` で与えられた値と追加採取結果の合流
+
 ## 9. 現時点で固定しないこと / Items Intentionally Left Open
 
 本書は以下を現時点では固定しない。
 
@@ -166,16 +166,16 @@ At the initial stage, the following order is recommended:
 
 app 側 `estimate.sh` は、将来的には少なくとも以下だけで済むことが望ましい。
 
-- package の選択
-- package の読み込み
-- 必要なら app 固有パラメータの設定
+- section / overlap と `estimation_package` の割当て宣言
+- target system や target nodes など、app 固有の既定値の宣言
+- 必要に応じた `run.sh` からの読込み
 - 共通の呼び出し順序に従った実行
 
 In the future, application-side `estimate.sh` should preferably be limited to:
 
-- selecting the package
-- loading the package
-- setting app-specific parameters if needed
+- declaring section / overlap to `estimation_package` assignments
+- declaring minimal app-specific defaults such as target system or target nodes
+- being sourced from `run.sh` when needed
 - executing according to the common invocation order
 
 ## 7. 参照イメージ / Reference Shape
 
@@ -438,6 +438,16 @@ Here, input means not only the presence of a Result JSON, but at least:
 - `not_applicable_when`
   - 例: `["missing required section artifact", "unsupported source system"]`
 - `fallback_to`
+
+上位パッケージでは、必要であれば次のような項目も持ってよい。
+- `supported_section_packages`
+  - その上位パッケージが受け持てる区間パッケージ名の一覧
+- `supported_overlap_packages`
+  - その上位パッケージが受け持てる overlap パッケージ名の一覧
+
+ここで重要なのは、これらは「使える配下パッケージの集合」を表すものであり、app 固有の section 名そのものを固定で期待するための項目ではない、という点である。どの section にどの package を割り当てるかは app 側 Result JSON の `estimation_package` で表す。
+
+また、区間パッケージ側が `required_artifact_kinds` や system 範囲を定義している場合、それと実際の section / overlap の割当て、必要なデータ採取、採取済みデータの保存・復元との照合は BenchKit 側で扱う。app 側は原則として「section 名」と「どの推定 package を使うか」を決めればよく、採取手順や保存形式の具体記述を直接抱え込まない方がよい。
   - 例: `"interval_time_simple"`
 
 For practical use, the package metadata or equivalent documented definition should preferably be able to express at least:
@@ -487,6 +497,11 @@ BenchKit should preferably provide the following:
 - Estimate JSON standardization
 - retention of package identity metadata
 
+詳細推定では、BenchKit 側が次も扱うのが望ましい。
+- 区間パッケージ metadata と section / overlap への割当ての照合
+- `required_artifact_kinds` に応じた採取手順の共通化
+- 採取済みデータの保存先と復元方法の共通化
+
 ### 5.2 app 側責務 / Application-Side Responsibilities
 
 app 側の責務は、原則として以下に留めることが望ましい。
@@ -500,9 +515,12 @@ The application side should preferably be limited to:
 
 - selecting the estimation package to use
 - mapping application-specific FOM or section names
-- specifying application-specific auxiliary inputs
+- assigning an estimation package to each section / overlap
+- specifying application-specific auxiliary inputs only when truly necessary
 - minimal special handling
 
+特に詳細推定では、app 側は section 名と `estimation_package` の割当てを決めるところまでに責務を寄せ、PAPI の counter set 分割や trace 採取方法、保存形式のような共通化可能な処理は BenchKit 側へ寄せるのが望ましい。
+
 ### 5.3 推定パッケージ開発者側責務 / Estimation-Package-Developer Responsibilities
 
 推定パッケージ開発者の責務は、原則として以下を定義することにある。
@@ -569,29 +587,37 @@ These are suitable for deeper analysis and future-system evaluation.
 
 ## 7. 参照実装イメージ / Reference Implementation Direction
 
-BenchKit においては、将来的に app 側の `estimate.sh` が毎回すべてを書くのではなく、例えば以下のような形へ寄せることが望ましい。
+BenchKit においては、将来的に app 側の `estimate.sh` が毎回すべてを書くのではなく、section / overlap と `estimation_package` の割当て、必要最小限の既定値、共通入口の呼出しだけを書く形へ寄せることが望ましい。
 
 ```sh
-BK_ESTIMATION_PACKAGE=lightweight_fom_scaling
 BK_ESTIMATION_TARGET_SYSTEM=FutureSystemA
+BK_ESTIMATION_TARGET_NODES=256
+
+bk_declare_section prepare_rhs interval_time_simple
+bk_declare_section compute_hopping counter_papi_detailed
+bk_declare_overlap compute_hopping,halo_exchange overlap_max_basic
 
-source scripts/estimation/packages/${BK_ESTIMATION_PACKAGE}.sh
-bk_run_estimation_package
+source scripts/estimation/common.sh
+bk_run_estimation
 ```
 
-この形では、app 側はパッケージ選択と最小限の app 固有設定を担い、推定方式の詳細はパッケージ側へ集約される。
+この形では、app 側は section / overlap への package 割当てと最小限の app 固有設定だけを担い、推定方式の詳細や追加採取は BenchKit と package 側へ集約される。
 
-In BenchKit, a desirable future direction is that application-side `estimate.sh` no longer implements everything each time, but instead looks like:
+In BenchKit, a desirable future direction is that application-side `estimate.sh` no longer implements everything each time, but instead focuses on section / overlap package assignments, minimal defaults, and common entrypoints:
 
 ```sh
-BK_ESTIMATION_PACKAGE=lightweight_fom_scaling
 BK_ESTIMATION_TARGET_SYSTEM=FutureSystemA
+BK_ESTIMATION_TARGET_NODES=256
+
+bk_declare_section prepare_rhs interval_time_simple
+bk_declare_section compute_hopping counter_papi_detailed
+bk_declare_overlap compute_hopping,halo_exchange overlap_max_basic
 
-source scripts/estimation/packages/${BK_ESTIMATION_PACKAGE}.sh
-bk_run_estimation_package
+source scripts/estimation/common.sh
+bk_run_estimation
 ```
 
-In this form, the application side is responsible only for package selection and minimal app-specific configuration, while the details of the estimation method are concentrated in the package.
+In this form, the application side is responsible only for assigning packages to sections / overlaps and providing minimal app-specific defaults, while the details of the estimation method and additional data acquisition are concentrated in BenchKit and the packages.
 
 ## 8. 現時点で固定しないもの / Items Not Fixed Yet
 
 
@@ -491,14 +491,14 @@ When only part of the section / overlap / component chain falls back while the o
 推定は一度きりの計算ではなく、モデルや仮定の更新に応じて再推定できることが重要である。
 BenchKit は、少なくとも以下を扱えるべきである。
 
-- benchmark result を再指定しての再推定
+- `estimate_result_uuid` を起点にした再推定
 - 推定結果の履歴保持
 - 異なる推定方式の比較
 
 Estimation is not a one-time calculation. Re-estimation in response to updated models or assumptions is important.
 BenchKit should be able to handle at least:
 
-- re-estimation from a specified benchmark result
+- re-estimation starting from `estimate_result_uuid`
 - history retention of estimation results
 - comparison of different estimation methods
 
 
@@ -248,6 +248,20 @@ output_fields:
 fallback_to: interval_time_simple
 ```
 
+このとき、上位パッケージと区間パッケージで役割を分けておくと整理しやすくなります。
+- 上位パッケージ
+  - どの区間パッケージ群を使って合成できるか
+  - 何を top-level Estimate JSON に出すか
+- 区間パッケージ
+  - どの system 範囲を受けるか
+  - section / overlap のどちらを受けるか
+  - どの採取種別を必要とするか
+  - 何を出力するか
+
+ここで、上位パッケージは app 固有の section 名を固定で期待しない方がよいです。どの section にどの package を割り当てるかは app 側 Result JSON の `estimation_package` で表します。
+
+PAPI のように複数回の採取が必要な場合でも、package 開発者は「`papi` が必要」と定義するところまでに責務を寄せるのがよいです。どの counter set を何回に分けて取るか、どこへ保存するか、再推定時にどう復元するかは、できるだけ BenchKit 側の共通処理に寄せます。
+
 ここが曖昧なまま実装を始めると、
 - package 自体は動く
 - でもどの system で使えるのか分からない