@@ -169,7 +169,7 @@ Once the estimation specification is clarified, many other design decisions beco
 
 現状は `qws` が先行 app として、
 
-- `lightweight_fom_scaling`
+- `weakscaling`
 - `instrumented_app_sections_dummy`
 - 推定元 result の UUID / timestamp 引き回し
 - side ごとの `model` 表現
@@ -184,8 +184,8 @@ Once the estimation specification is clarified, many other design decisions beco
 | 項目 | 仕様上の期待 | 現状実装 | GAP | 優先度 |
 |---|---|---|---|---|
 | 共通推定エントリ | 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 | section ごとの時間を app 側が出し、`identity` と `logp` で weak scaling を構成できること | `weakscaling` の実装を整理中 | app / package / BenchKit の責務分離、他 app への横展開、表示整合は未完 | 高 |
+| 適用可能性判定 | 不足入力を `applicable/fallback/not_applicable/needs_remeasurement` で扱うこと | `weakscaling` と `instrumented_app_sections_dummy` はこれらを扱う方向で整理中。final Estimate JSON では `applicable`、`partially_applicable`、`fallback`、`not_applicable` を表現できる | 複数 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 の整理が未完。app 側が実行前に宣言する形は設計整理済みだが未実装 | 最優先 |
 | app 側推定宣言 | app 側が実行前に section / overlap と `estimation_package` をまとめて宣言できること | `estimate.sh` に宣言ブロックを寄せる方向性は整理済み | 宣言 API、既定値の与え方、`run.sh` からの読込み方は未固定。実装も未着手 | 最優先 |
@@ -201,7 +201,7 @@ Once the estimation specification is clarified, many other design decisions beco
 この表から、現在の最小核は以下と整理できる。
 
 1. `scripts/estimation/common.sh` を中心とした共通呼び出しと Estimate JSON 出力
-2. `lightweight_fom_scaling` による FOM-only 軽量推定
+2. `weakscaling` による `identity` / `logp` ベースの軽量推定
 3. `instrumented_app_sections_dummy` による区間時間ベース詳細ダミー推定
 4. 推定元 result UUID / timestamp の引き回し
 
 
@@ -157,7 +157,7 @@ In addition, `target_nodes` represents the estimated node count on each system s
     "system": "FugakuNEXT",
     "fom": 246.912,
     "target_nodes": "4",
-    "scaling_method": "scale-mock",
+    "scaling_method": "weakscaling",
     "benchmark": {
       "system": "MiyabiG",
       "fom": 123.456,
@@ -225,7 +225,7 @@ Estimate JSON may include the following extension fields:
     "method_class": "lightweight",
     "detail_level": "basic",
     "source_result_uuid": "00000000-0000-0000-0000-000000000000",
-    "estimation_package": "lightweight_fom_scaling",
+    "estimation_package": "weakscaling",
     "estimation_package_version": "0.1",
     "requested_estimation_package": "instrumented_app_sections_dummy",
     "requested_estimation_package_version": "0.1"
@@ -290,7 +290,7 @@ This field stores how the measurement inputs used for estimation were obtained.
 {
   "model": {
     "type": "scaling",
-    "name": "scale-mock",
+    "name": "weakscaling",
     "version": "0.1",
     "implementation": "programs/qws/estimate.sh"
   }
 
@@ -389,6 +389,8 @@ The application developer should generally only need to ensure:
 
 詳細推定では、これに加えて app 側が `estimate.sh` の宣言ブロックで section / overlap と `estimation_package` の割当てを先に示せるようにしてよい。ただし、採取手順の詳細や保存形式の詳細まで app 側へ押し込めない方が望ましい。
 
+`weakscaling` のように artifact を要求しない package では、app 側は通常実行の中で section / overlap 時間を出し、その item ごとに `identity` または `logp` を割り当てるところまででよい。
+
 ### 8.2 推定パッケージ開発者の責務 / Estimation Package Developer Responsibility
 
 推定パッケージ開発者は、原則として次を定義する。
@@ -428,6 +430,8 @@ BenchKit is generally responsible for:
 - package metadata を見た追加採取実行の組立て
 - `bk_emit_*` で与えられた値と追加採取結果の合流
 
+一方で `weakscaling` のような artifact 不要 package では、BenchKit 側は追加採取を組み立てるのではなく、app 側が出した section / overlap 時間に対して `identity` / `logp` を dispatch し、top-level FOM を合成する責務を持つ。
+
 ## 9. 現時点で固定しないこと / Items Intentionally Left Open
 
 本書は以下を現時点では固定しない。
 
@@ -82,7 +82,7 @@ Estimation-package metadata must contain at least:
 
 例:
 
-- `lightweight_fom_scaling`
+- `weakscaling`
 - `section_breakdown_scaling`
 
 This is the name used to identify the package.
@@ -271,7 +271,7 @@ Examples:
 
 ```json
 {
-  "name": "lightweight_fom_scaling",
+  "name": "weakscaling",
   "version": "0.1",
   "method_class": "lightweight",
   "detail_level": "basic",
 
@@ -181,7 +181,7 @@ In the future, application-side `estimate.sh` should preferably be limited to:
 ## 7. 参照イメージ / Reference Shape
 
 ```sh
-BK_ESTIMATION_PACKAGE=lightweight_fom_scaling
+BK_ESTIMATION_PACKAGE=weakscaling
 source scripts/estimation/common.sh
 source scripts/estimation/packages/${BK_ESTIMATION_PACKAGE}.sh
 
 
@@ -448,7 +448,7 @@ Here, input means not only the presence of a Result JSON, but at least:
 ここで重要なのは、これらは「使える配下パッケージの集合」を表すものであり、app 固有の section 名そのものを固定で期待するための項目ではない、という点である。どの section にどの package を割り当てるかは app 側 Result JSON の `estimation_package` で表す。
 
 また、区間パッケージ側が `required_artifact_kinds` や system 範囲を定義している場合、それと実際の section / overlap の割当て、必要なデータ採取、採取済みデータの保存・復元との照合は BenchKit 側で扱う。app 側は原則として「section 名」と「どの推定 package を使うか」を決めればよく、採取手順や保存形式の具体記述を直接抱え込まない方がよい。
-  - 例: `"interval_time_simple"`
+  - 例: `"identity"`
 
 For practical use, the package metadata or equivalent documented definition should preferably be able to express at least:
 
@@ -521,6 +521,8 @@ The application side should preferably be limited to:
 
 特に詳細推定では、app 側は section 名と `estimation_package` の割当てを決めるところまでに責務を寄せ、PAPI の counter set 分割や trace 採取方法、保存形式のような共通化可能な処理は BenchKit 側へ寄せるのが望ましい。
 
+`weakscaling` のように artifact を前提としない section-wise package では、さらに app 側責務は明確になる。app 側は通常実行から section / overlap 時間を Result JSON へ出し、各 item に `identity` または `logp` を割り当てればよい。
+
 ### 5.3 推定パッケージ開発者側責務 / Estimation-Package-Developer Responsibilities
 
 推定パッケージ開発者の責務は、原則として以下を定義することにある。
@@ -534,6 +536,18 @@ The application side should preferably be limited to:
 
 すなわち、BenchKit が共通ルールを提供し、app 側が package を選択し、package 開発者が推定方式の具体的意味を定める、という責務分離を基本とする。
 
+`weakscaling` の場合は、少なくとも次のように読めるのが望ましい。
+- app 側
+  - section / overlap 時間を書く
+  - `identity` / `logp` の割当てを決める
+- 推定パッケージ開発者側
+  - `identity` と `logp` の意味
+  - `weakscaling` の合成規則
+- BenchKit 側
+  - section package dispatch
+  - current / future breakdown 合成
+  - top-level `applicability` と Estimate JSON への正規化
+
 The estimation-package developer is primarily responsible for defining:
 
 - the measurement method assumed by the package
@@ -551,14 +565,14 @@ In other words, the intended separation is that BenchKit provides the common rul
 
 例:
 
-- `lightweight_fom_scaling`
+- `weakscaling`
 - `baseline_ratio_estimation`
 
 これらは、高頻度実行や PoC に向く。
 
 Examples:
 
-- `lightweight_fom_scaling`
+- `weakscaling`
 - `baseline_ratio_estimation`
 
 These are suitable for high-frequency runs and PoC work.
@@ -593,7 +607,7 @@ BenchKit においては、将来的に app 側の `estimate.sh` が毎回すべ
 BK_ESTIMATION_TARGET_SYSTEM=FutureSystemA
 BK_ESTIMATION_TARGET_NODES=256
 
-bk_declare_section prepare_rhs interval_time_simple
+bk_declare_section prepare_rhs identity
 bk_declare_section compute_hopping counter_papi_detailed
 bk_declare_overlap compute_hopping,halo_exchange overlap_max_basic
 
@@ -609,7 +623,7 @@ In BenchKit, a desirable future direction is that application-side `estimate.sh`
 BK_ESTIMATION_TARGET_SYSTEM=FutureSystemA
 BK_ESTIMATION_TARGET_NODES=256
 
-bk_declare_section prepare_rhs interval_time_simple
+bk_declare_section prepare_rhs identity
 bk_declare_section compute_hopping counter_papi_detailed
 bk_declare_overlap compute_hopping,halo_exchange overlap_max_basic
 
 
@@ -50,10 +50,10 @@
 - top-level:
   `instrumented_app_sections_dummy.sh`
 - section:
-  `interval_time_simple.sh`
+  `identity.sh`
   `counter_papi_detailed.sh`
   `trace_mpi_basic.sh`
-  `trace_collective_logp.sh`
+  `logp.sh`
   `overlap_max_basic.sh`
 
 という分け方になっています。
@@ -94,11 +94,11 @@
 
 たとえば、
 
-- `interval_time_simple`
+- `identity`
   - 区間時間があれば固定比で変換
 - `counter_papi_detailed`
   - PAPI artifact があればそれを前提に変換
-- `trace_collective_logp`
+- `logp`
   - collective 系の区間を logP 扱いで変換
 
 です。
@@ -245,7 +245,7 @@ required_section_artifacts:
 output_fields:
   future_system.fom_breakdown.sections[].time
   current_system.fom_breakdown.sections[].time
-fallback_to: interval_time_simple
+fallback_to: identity
 ```
 
 このとき、上位パッケージと区間パッケージで役割を分けておくと整理しやすくなります。
@@ -260,6 +260,17 @@ fallback_to: interval_time_simple
 
 ここで、上位パッケージは app 固有の section 名を固定で期待しない方がよいです。どの section にどの package を割り当てるかは app 側 Result JSON の `estimation_package` で表します。
 
+`weakscaling` はこの分担を確認する最初の例として分かりやすいです。
+- app 側
+  - section / overlap 時間を出す
+  - 各 item に `identity` または `logp` を割り当てる
+- package 側
+  - `identity` と `logp` の意味を定義する
+  - `weakscaling` として合成する
+- BenchKit 側
+  - 割当てられた package を呼ぶ
+  - current / future の breakdown と top-level FOM をまとめる
+
 PAPI のように複数回の採取が必要な場合でも、package 開発者は「`papi` が必要」と定義するところまでに責務を寄せるのがよいです。どの counter set を何回に分けて取るか、どこへ保存するか、再推定時にどう復元するかは、できるだけ BenchKit 側の共通処理に寄せます。
 
 ここが曖昧なまま実装を始めると、
 
@@ -45,7 +45,7 @@
 #!/bin/bash
 set -euo pipefail
 
-BK_ESTIMATION_PACKAGE="lightweight_fom_scaling"
+BK_ESTIMATION_PACKAGE="weakscaling"
 source scripts/estimation/common.sh
 source "scripts/estimation/packages/${BK_ESTIMATION_PACKAGE}.sh"
 
@@ -70,6 +70,18 @@ bk_run_estimation "$1"
 
 詳細推定では、app ごとの推定宣言を `estimate.sh` にまとめると整理しやすくなります。`estimate.sh` 自身は CI や再推定の入口になり、`run.sh` 側も必要に応じてこれを読み込む形にできます。
 
+`weakscaling` を使う場合は、特に次の分担を前提にすると分かりやすいです。
+- app 側
+  - section / overlap の時間を通常実行で出す
+  - 各 item に `identity` または `logp` を割り当てる
+- package 側
+  - `identity` は補正なし
+  - `logp` は node 数比較にもとづく補正
+- BenchKit 側
+  - section package の呼び分け
+  - current / future の合成
+  - top-level applicability の整理
+
 ここでまず宣言したいのは次です。
 - section 名
 - overlap 名
@@ -79,9 +91,9 @@ bk_run_estimation "$1"
 イメージとしては次のようになります。
 
 ```bash
-bk_declare_section prepare_rhs interval_time_simple
+bk_declare_section prepare_rhs identity
 bk_declare_section compute_solver counter_papi_detailed
-bk_declare_section allreduce trace_collective_logp
+bk_declare_section allreduce logp
 bk_declare_overlap compute_hopping,halo_exchange overlap_max_basic
 ```
 
@@ -119,7 +131,7 @@ bk_emit_result \
 ```bash
 bk_emit_section \
   prepare_rhs 0.42 \
-  --estimation-package interval_time_simple \
+  --estimation-package identity \
   >> results/result
 
 bk_emit_section \
@@ -172,6 +184,8 @@ bk_run_estimation "$1"
 
 詳細推定では、区間パッケージが `papi` や `trace` のような採取種別を要求することがあります。
 
+ただし `weakscaling` の場合は、追加採取を前提にしません。app 側が通常実行の中で section / overlap 時間を書き、`identity` と `logp` だけで推定する前提です。
+
 app 側では、まず section 名と `estimation_package` を決めることを優先してください。採取手順、複数回実行の要否、保存先、再推定時の復元方法は、共通化できるものから BenchKit 側へ寄せるのがよいです。
 
 特に PAPI のように複数回実行が必要になる採取は、app 側に細かく書かせすぎると重くなります。package 側は「`papi` が必要」と定義し、BenchKit 側が採取や保存の共通処理を引き受ける形が自然です。
 
@@ -19,8 +19,8 @@ load_estimation_package() {
   source "scripts/estimation/packages/${package_name}.sh"
   BK_ESTIMATION_PACKAGE_VERSION=$(bk_estimation_package_metadata | jq -r '.version // empty')
   case "$package_name" in
-    lightweight_fom_scaling)
-      BK_ESTIMATION_MODEL_NAME="scale-mock"
+    weakscaling)
+      BK_ESTIMATION_MODEL_NAME="weakscaling"
       BK_ESTIMATION_MODEL_VERSION="0.1"
       ;;
     instrumented_app_sections_dummy)
 
@@ -61,12 +61,12 @@ print_results() {
     create_dummy_estimation_artifact "estimation_inputs/write_result_interval.json" "{\"section\":\"write_result\",\"kind\":\"interval_time\"}"
     create_dummy_estimation_artifact "estimation_inputs/compute_halo_overlap.json" "{\"overlap\":[\"compute_hopping\",\"halo_exchange\"],\"kind\":\"overlap_time\"}"
 
-    bk_emit_section prepare_rhs "$section_prepare_rhs" interval_time_simple results/estimation_inputs/prepare_rhs_interval.json
+    bk_emit_section prepare_rhs "$section_prepare_rhs" identity results/estimation_inputs/prepare_rhs_interval.json
     bk_emit_section compute_hopping "$section_compute_hopping" counter_papi_detailed results/estimation_inputs/compute_hopping_papi.tgz
     bk_emit_section compute_solver "$section_compute_solver" counter_papi_detailed results/estimation_inputs/compute_solver_papi.tgz
     bk_emit_section halo_exchange "$section_halo_exchange" trace_mpi_basic results/estimation_inputs/halo_exchange_trace.tgz
-    bk_emit_section allreduce "$section_allreduce" trace_collective_logp results/estimation_inputs/allreduce_trace.tgz
-    bk_emit_section write_result "$section_write_result" interval_time_simple results/estimation_inputs/write_result_interval.json
+    bk_emit_section allreduce "$section_allreduce" logp results/estimation_inputs/allreduce_trace.tgz
+    bk_emit_section write_result "$section_write_result" identity results/estimation_inputs/write_result_interval.json
     bk_emit_section overlap:compute_hopping,halo_exchange "$overlap_compute_halo" overlap_max_basic results/estimation_inputs/compute_halo_overlap.json --type overlap --members compute_hopping,halo_exchange
 }