tancho / docs /ARCHITECTURE.md

Bundle the synthetic final pack, thresholds and raw outputs for offline scoring reproduction

f635a54 verified 19 days ago

33.5 kB

Tancho Observation Program 詳細実装設計

項目	内容
文書版	1.0
日付	2026年9月21日
状態	Release 1実装用
上位要件	Tancho PRD
対象範囲	`slope_failure_v1`、`access_clearance_v1`を初回実装。後続profileの拡張点も定義

対象ミッションの正本は Tanchoのミッション台帳、製品要件の正本は Tancho PRD、開発順と採用条件の正本は Open-weight Cosmos 3 Edge Generator計画とする。本書は、その方針をコードへ実装できる粒度まで落とした詳細設計である。

1. 設計の不変条件

対象の発見と範囲抽出は、物体検出器、面分類器、地図照合が担う。
同じCosmos 3 Edge派生checkpointを、Reasoner roleとGenerator roleの別呼出しで使う。
Reasonerは未回答の運用上の問いを選ぶ。Generatorは検査済みの問いに必要な観測関係を組む。
モデルは座標、角度、距離、速度、滞在時間、緯度経度、PX4命令、安全制約を出さない。
観測コンパイラ、軌道計画器、RFLが数値の視点と経路を決める。
モデルの生出力を補修、丸め、近い列挙値へ置換しない。不正出力はそのまま拒否する。
決定論的fallbackで飛行できても、モデルの採用成績には数えない。
旧 tancho-viewpoints-1.0 と固定場面SITLの意味を変更しない。新しい版からadapterで接続する。

2. データフロー

FrameBundle + telemetry + detector/classifier/map outputs
                         │
                         ▼
             build_mission_context()
                         │ MissionContext（trusted）
                         ▼
          Cosmos 3 Edge / Reasoner role
                         │ raw ObservationIntent
                         ▼
             validate_and_bind_intents()
                         │ VerifiedIntentSet（trusted IDs/revision）
                         ▼
          Cosmos 3 Edge / Generator role
                         │ raw ObservationProgram
                         ▼
             validate_observation_program()
                         │ VerifiedObservationProgram
                         ▼
               compile_observations()
                         │ CompiledViewPlan
                         ▼
             adapt_to_viewpoints_v1()
                         │ tancho-viewpoints-1.0
                         ▼
          trajectory planner → RFL → PX4 → capture
                         │
                         ▼
            verify_observation_result()

モデル呼出し間で渡すのは、生のReasoner JSONではなく VerifiedIntentSet である。アプリケーションがcanonical JSONのSHA-256から intent_id と intent_revision を作り、内部で固定する。Generator promptでは各intentを安定した sequence で示し、生出力の intent_sequence を検証器がopaque IDへ束縛する。

3. MissionContext 1.0

3.1 生存期間と上限

項目	値
schema	`tancho-mission-context-1.1`
最大対象数	32
最大根拠画像数	8
最大完了済みquestion数	対象ごと32
最大センサー数	8
時刻	同期済みの整数milliseconds
有効期限	アプリケーションが設定。モデルは延長不可

上限はメモリ使用量と攻撃面を閉じるための契約上限であり、運用上必要な件数を示す値ではない。上限を超えた入力は分割し、同じcontextとして黙って切り捨てない。

3.2 JSON形状

{
  "schema_version": "tancho-mission-context-1.1",
  "context_id": "ctx-...",
  "mission_id": "mission-...",
  "mission_profile": "slope_failure_v1",
  "captured_at_ms": 0,
  "expires_at_ms": 0,
  "input_sha256": "64 lowercase hex",
  "model_revision": "...",
  "profile_revision": "...",
  "map_revision": "...",
  "calibration_id": "...",
  "envelope_revision": "...",
  "evidence_ids": ["frame-1"],
  "sensor_capabilities": ["rgb"],
  "targets": [
    {
      "target_id": "target-1",
      "category": "landslide_area",
      "source": "area_classifier",
      "geometry_ref": "geometry-1",
      "map_relations": ["intersects_road"],
      "required_questions": ["landslide_road_connection"],
      "completed_questions": []
    }
  ],
  "policy": {
    "max_intents": 4,
    "max_observations": 8,
    "max_viewpoints": 8,
    "max_reobservation_cycles": 1
  }
}

input_sha256 は画像bytesのhash、対象レジストリ、センサー能力、各revision、policyを含むcanonical入力からアプリケーションが計算する。context_id もアプリケーションが発行し、モデル出力との照合にだけ使う。

3.3 列挙値

sensor_capabilities は初版で rgb と thermal のみを許す。SIYI A8 miniだけの構成は rgb だけになる。thermal をモデルが出力に追加しても能力が増えたとは扱わない。

source は object_detector、area_classifier、map、map_difference、telemetry のいずれか。category と map_relations は §7 のprofileで許可されたものだけを受ける。

4. Reasoner role

4.1 モデル生出力

{
  "schema_version": "tancho-observation-intent-1.0",
  "context_id": "ctx-...",
  "mission_id": "mission-...",
  "outcome": "inspect",
  "evidence_ids": ["frame-1"],
  "intents": [
    {
      "sequence": 0,
      "target_id": "target-1",
      "question": "landslide_road_connection",
      "priority": 1,
      "evidence_ids": ["frame-1"]
    }
  ],
  "reason_code": "unanswered_question"
}

4.2 outcomeと整合条件

outcome	intents	evidence_ids	reason_code
`inspect`	1以上、policy以下	1以上	`unanswered_question`
`satisfied`	0	1以上	`all_required_questions_completed`
`unsupported_sensor`	0	1以上	`required_sensor_unavailable`
`insufficient_evidence`	0	0以上	`target_unresolved` または `evidence_unusable`

priority は1が最優先で1〜3。sequence は0から欠番なし。question はprofileの許可表にあるだけでなく、そのtargetの required_questions に明示され、completed_questions に無いことを要求する。同じ target_id + question の重複は拒否する。completed_questions は required_questions の部分集合でなければならない。satisfied は全targetで両集合が一致した場合だけ許可する。これにより、Reasonerは画像だけから任務目的を推測して質問を増やせず、旧 no_action の移行も具体的な完了対象に束縛される。

4.3 検証後の内部表現

validate_and_bind_intents(raw, context, now_ms) は生出力を変更せず検査し、成功時だけ次をアプリケーション側で追加する。

intent_id = sha256(context_id + sequence + target_id + question) の64文字lowercase hex
intent_revision = sha256(canonical verified intent set)
source_output_sha256 = sha256(raw model bytes)

これらは次のモデルに渡す信頼済みIDであり、Reasoner自身には生成させない。

5. Generator role

5.1 入力

Generatorは同じFrameBundle、MissionContext、VerifiedIntentSetを受ける。Reasonerの自由文や未検証JSONをプロンプトへ連結しない。プロンプトには、アプリケーションが検証したintentの sequence、対象、question、priority、根拠画像IDを渡す。intent_id、intent_revision、context/mission IDなどのopaqueな値はモデルに再生成させない。

5.2 モデル生出力

{
  "schema_version": "tancho-observation-program-1.1",
  "outcome": "observe",
  "observations": [
    {
      "sequence": 0,
      "intent_sequence": 0,
      "view_relation": "along_axis",
      "coverage": "both_sides",
      "detail_level": "damage",
      "sensor": "rgb",
      "stop_condition": "corridor_continuity_visible"
    }
  ],
  "reason_code": "program_created"
}

5.3 outcomeと整合条件

outcome	observations	reason_code
`observe`	1以上、policy以下	`program_created`
`uncompilable_intent`	0	`unsupported_observation_primitive`

Generatorは satisfied を返せない。問いが既に満たされたかを決めるのはReasonerである。Generatorはセンサー能力を変更できず、入力intentを追加、削除、改名できない。observe の場合は各intentが少なくとも1回参照される。完了済みquestionに結び付くintentは入力段階で存在できない。

5.4 共通の観測語彙

field	初版の列挙値
`view_relation`	`overview`, `nadir`, `oblique`, `cross_section`, `along_axis`, `context`, `intercept`, `search_sweep`
`coverage`	`full_target`, `boundary`, `upper_lower_edges`, `both_sides`, `connection`, `upstream_downstream`, `target_and_context`, `facade_foot`, `approach_corridor`, `search_region`
`detail_level`	`detect`, `identify`, `state`, `damage`
`sensor`	`rgb`, `thermal`

検証器は intent_sequence をVerifiedIntentSetの同じsequenceへ決定論的に結び、そこで初めてopaqueな intent_id、context/mission ID、intent_revision を付与する。未知sequence、欠落intent、同じ intent_sequence + view_relation + coverage + detail_level + sensor + stop_condition の重複は拒否する。旧1.0入力は保存済み証拠の検証用に読み取れるが、新しいpromptと教師は1.1だけを生成する。順序違いだけの重複教師を別正解として数えない。

6. アプリケーション状態機械

CAPTURED
  → CONTEXT_VALIDATED
  → INTENTS_PENDING
  → INTENTS_VERIFIED
  → PROGRAM_PENDING
  → PROGRAM_VERIFIED
  → COMPILED
  → SAFETY_VALIDATED
  → EXECUTING
  → RESULT_CAPTURED
  → RESULT_VERIFIED
       ├─ COMPLETE
       └─ CAPTURED（policyのcycle上限内だけ）

どの状態からも ABORTED へ移れる。状態を飛ばさない。context、intent、program、compiled plan、trajectory、実測結果のhashを同じ監査recordへ結び付ける。

max_reobservation_cycles はアプリケーションpolicyであり、モデルは変更できない。固定場面baselineは1を維持する。ミッション別の別値は、飛行時間と帰還余力を測定してからprofile revisionとして固定する。

6.1 失敗時の処理

失敗	処理	モデル成功に数えるか
JSON・schema・ID・revision違反	生出力を保存して停止	数えない
推論timeout・provider不一致	停止または明示的fallback	数えない
context期限切れ	全出力を破棄し再撮影	数えない
未搭載センサー要求	program拒否	数えない
compiler解なし	`uncompilable` として停止または人へ返す	数えない
RFL拒否	拒否理由を保存して停止または明示的fallback	数えない
実行中に対象消失・地図更新	実行を中止し、新contextからやり直す	数えない
撮影品質未達	cycle上限と資源内だけReasonerへ戻す	最終達成時だけ閉ループ成功

fallbackを使う場合は decision_source = deterministic_fallback と記録する。モデル出力をfallbackの入力に使わず、モデル採用ゲートの分母から除外もしない。

7. ミッションプロファイル

profileは、許可された対象、問い、観測語彙、停止条件の組合せをコード上の定数として持つ。ここで正解の観測セットを一意に規定しない。questionから常に同じprogramが出るなら画像不要のlookup課題になるため、可視状態、遮蔽、既観測範囲によって必要な観測が変わる評価対を必須にする。

7.1 `slope_failure_v1`

category	question
`landslide_area`	`landslide_extent`, `landslide_road_connection`, `landslide_river_connection`, `landslide_occluded_region`, `slope_precursor_detail`

許可する停止条件は full_boundary_visible、upper_lower_edges_visible、connection_visible、occluded_region_resolved、precursor_detail_visible。thermal は許可しない。

7.2 `access_clearance_v1`

category	question
`road_segment`, `rail_segment`, `obstruction_area`, `bridge`	`corridor_continuity`, `obstruction_material`, `obstruction_extent`, `roadbed_loss`, `bridge_damage`, `approach_access`

停止条件は corridor_continuity_visible、obstruction_type_and_extent_visible、roadbed_edges_visible、bridge_damage_context_visible、approach_corridor_visible。道路の「覆われる型」と「路体が失われる型」を別caseにする。

7.3 `flood_river_v1`

category	question
`flood_area`, `river_segment`, `embankment`, `building`, `debris_area`	`flood_extent`, `flood_boundary`, `building_waterline`, `embankment_damage`, `channel_blockage`, `debris_accumulation`

停止条件は flood_boundary_visible、facade_waterline_visible、bank_damage_context_visible、channel_cross_section_visible、upstream_downstream_context_visible。

7.4 `rescue_v1`

category	question
`person`, `vehicle`	`person_state`, `person_surrounding_hazard`, `rescue_access`, `notification_frame`, `vehicle_state`, `vehicle_occupant_evidence`

停止条件は person_state_and_context_visible、rescue_approach_visible、notification_frame_sufficient、vehicle_state_and_context_visible。RGBで状態を判定できる必要画質は現時点で未測定なので、profileの画質値を運用値として固定しない。

7.5 `building_earthquake_v1`

category	question
`building`, `fire_region`, `person`	`building_collapse_extent`, `facade_damage`, `entrance_access`, `road_encroachment`, `fire_context`

停止条件は roof_and_collapse_extent_visible、required_facades_visible、facade_foot_visible、entrance_access_visible、fire_perimeter_context_visible。熱画像を必須とするcaseで thermal が無ければReasonerは unsupported_sensor を返す。

7.6 `orbitpod_recovery_v1`

category	question
`orbitpod_track`, `river_search_region`	`intercept_region`, `cross_river_search`, `detector_handoff`

停止条件は intercept_region_covered、search_region_covered、orbitpod_detector_handoff。許可するview relationは intercept と search_sweep を中心とする。物体検出後の並走、索の位置合わせ、吸着、吊り上げは本profileの外である。

7.7 未実装profile

山岳遭難、森林火災、野生動物は初版registryへ登録しない。未知profileとして拒否する。センサー、運用上の問い、独立素材、停止条件が揃ってから新しいversionで追加する。

8. 観測コンパイラ

8.1 入力と出力

compile_observations(
    program: VerifiedObservationProgram,
    context: MissionContext,
    scene: SceneSnapshot,
    vehicle: VehicleSnapshot,
) -> CompiledViewPlan

SceneSnapshot は対象geometry、地形mesh、占有・自由・未知を区別した障害物地図、道路・河川・建物等のmap geometry、各revisionを持つ。VehicleSnapshot は現在位置、速度、残電力、時刻を持つ。どちらもモデル出力から作らない。

CompiledViewPlan は tancho-compiled-viewplan-1.0 とし、各視点に observation_sequence と intent_id を残す。既存の tancho-viewpoints-1.0 へ渡すadapterは飛行用フィールドだけを変換し、元planと出力のhashを監査recordへ残す。

8.2 コンパイル手順

profileの view_relation + coverage + detail_level + sensor + stop_condition を幾何制約へ変換する。
対象surface、boundary、connection、axis、search regionを信頼済みgeometryから取り出す。
カメラ校正とdetail levelから必要GSDまたは画素条件を取得する。未測定の条件は推測せず missing_quality_requirement で失敗する。
承認領域内に、profile固定の角度・距離samplingで視点候補を作る。この候補はモデルへ見せない。
視錐台、遮蔽、未知空間、地形・障害物離隔、ジンバル可動域、画質余裕を検査する。
1つの観測要求に複数視点が必要なら、必要coverageを満たす最小集合を決定論的に選ぶ。
programのsequenceとintent priorityを保ち、同順位内だけ移動時間を短くする。
全視点を既存の範囲、期限、帰還検査へ渡す。総視点数がpolicy上限を超えたら切り捨てず失敗する。

8.3 決定規則

複数の成立解は、次のlexicographic keyで一意に選ぶ。

(
  uncovered_required_area,
  unknown_space_intersection,
  collision_clearance_penalty,
  sensor_resolution_deficit,
  number_of_viewpoints,
  total_travel_seconds,
  canonical_quantized_coordinates
)

前4項目は0が必須で、満たさない候補は採用しない。後3項目が同じ場合は1cm単位に量子化したENU座標の辞書順をtie-breakに使う。量子化は選択の再現性のためだけに使い、危険な座標を範囲内へ丸める処理には使わない。

8.4 OrbitPodの分岐

orbitpod_recovery_v1 は静止対象コンパイラへ入れない。位置列、時刻、流向、川幅geometryから待受け領域と探索走査を作る compile_dynamic_search() へ送る。OrbitPod検出後は状態機械を DETECTOR_HANDOFF で終了し、低遅延tracking controllerへ移す。Generatorを追跡loop内で再呼出ししない。

9. モデルpromptとdecode

roleごとにsystem instruction、schema、許可語彙を分ける。Reasoner promptへGeneratorの列挙値を、Generator promptへReasonerの未検証文章を入れない。画像は同じbytesをrole間で再利用し、processor後のpixel hashも記録する。

decodeはtemperature 0、1回だけ、修復・再試行なしを評価条件とする。運用で再試行を導入する場合は、評価値と分け、attemptごとのraw出力を残す。可能ならgrammar constrained decodingを使うが、grammarが正しい意味を保証したとは数えない。

9.1 実行provider

新規学習は deploy/modal_training/ からModal H100 1基で実行する。payloadは学習コード、固定Cosmos Framework revision、親model revision、training pack、save/resume/finish設定をファイル単位のSHA-256で固定する。成果物は tancho-observation-program-artifacts Volumeのrun ID別directoryへ保存し、同じrun IDを上書きしない。起動は既定でdry runとし、明示した --execute だけがcloud resourceを作る。

fresh model-in-loop SITLは deploy/modal_observation_program/pipeline.json の順序で実行する。PX4/Gazeboはnested Dockerを必要とするためModal VM Sandbox、ReasonerとGeneratorはModal H100、compilerとRFLは決定論的CPU stageとする。全stageは同じcontext、画像hash、公開checkpoint revision、監査chainをModal Volumeで受け渡す。Nebius call、保存済みmodel出力のfallback、Generator生出力の修復を含む試行はRelease 1証拠として拒否する。

既公開v4を作ったNebius job IDとarchive hashは履歴provenanceとして保持する。providerを遡及的にModalへ書き換えない。2026年9月22日以降に作る学習・SITL receiptは deploy/execution-provider-policy.json と tancho/execution_provider.py でModal以外をfail-closedにする。

10. 学習データ

10.1 1レコード

sample_id
leakage_group_id
split
role = reasoner | generator
mission_profile
context.json
frames/*
verified_intents.json       # generator roleだけ
target.json
provenance.json

target.json はモデルの厳格JSONだけを持つ。chain-of-thoughtを教師や公開物へ入れない。教師の作成理由、代替正解、レビュー記録は別ファイルに保存する。

10.2 分割

world、災害イベント、地点、関連飛行、遮蔽物配置、元画像hashのいずれかが同じものを同じ leakage_group_id に入れる。回転、左右反転、色変更、同一sceneの別カメラを独立現場として数えない。実写に位置・姿勢・校正が無ければ、Reasonerと意味的なGenerator教師には使えても、コンパイラの正解座標には使わない。

10.3 必須対照

同じ画像でquestionを変え、必要観測を変える
同じquestionで遮蔽・可視範囲だけを変え、必要観測を変える
同じpromptと数値条件で画像だけを交換する
灰色、欠損、古い画像を入れる
RGBだけのcontextでthermal必須の問いを出す
completed questionを含むcontextを入れる
mission profileと対象categoryを意図的に食い違わせる
questionから固定表を引くだけのrule baselineを先に測る

画像を見ないruleが最終評価の正解へ到達したprofileは、Generatorの学習課題として不成立と判定し、GPU学習へ進めない。

10.4 段階追加

schemaとrole分離のsynthetic smoke
slope_failure_v1
access_clearance_v1
flood_river_v1
rescue_v1 と building_earthquake_v1
orbitpod_recovery_v1

各段階は以前のprofileをreplayし、role比とprofile比をmanifestへ固定する。データ数、学習率、更新数、checkpoint間隔、費用上限はdevelopment dataと検出力設計から事前固定し、本書では根拠のない件数を置かない。

11. 評価

11.1 Reasoner単体

strict schema valid率
questionのmicro/macro precision、recall、F1
不要なinspect率
completed question再要求率
unsupported_sensor recall
evidence grounding率

11.2 Generator単体

必要観測primitiveのmicro/macro precision、recall、F1
不要観測数
全intent coverage率
sensor/profile違反率
strict schema valid率
rule baseline、base Cosmos 3 Edge、公開v5との比較

複数の観測セットが同じ目的を満たす場合は、finalを開く前に許可した同値集合をgoldへ記録する。結果を見てから同値扱いを追加しない。

11.3 コンパイラ

gold programのcompile成功率
coverage、遮蔽、画質、衝突、envelope、期限、帰還の各条件
同一入力のbyte-identical出力
1条件だけを変えたときの期待された差
解なしを解なしとして返す率

11.4 閉ループ

モデル生出力に由来する観測達成率
実画像の有効率
mission完了時間、移動距離、消費電力
不要な再観測数
fallback率と人の介入数
対象消失、古い地図、推論停止、通信断での停止結果

12. テスト設計

12.1 unit

全schemaの正常例と、未知・欠落・重複key
NaN、Infinity、bool-as-number、長過ぎる文字列、件数超過
未知context・target・evidence・intent ID
古い時刻、異なるrevision、変更された画像bytes
profile/category/question/primitiveの全許可・拒否matrix
completed questionの復活、同一観測の重複
unavailable sensor、role間schema取り違え

12.2 compiler property/golden

同一入力の決定性
targetの平行移動・90度回転でplanも対応して変換される
障害物追加で貫通経路を作らない
狭いenvelope、未知空間、画質不足、帰還余力不足で失敗する
道路を覆う型と路体流失型が別のcoverageを要求する
OrbitPodを静止対象compilerへ渡すと拒否する

12.3 integration

raw Reasoner → verified intent → raw Generator → verified program → compiled plan → viewpoints v1
各境界でhashとrevisionが保持される
fallbackをモデル成功として記録しない
cycle上限、return reserve、対象消失、provider不一致で停止する
旧viewpoint/PX4/SITLテストの結果を変更しない

モデルの文章をそのまま写しただけのテストは作らない。安全境界、role混同、画像依存、決定性を壊す変更を検出できるテストに限る。

13. コード配置と公開API

file	公開関数・型
`tancho/mission_profiles.py`	`MissionProfile`, `profile(name)`, `validate_profile_relation(...)`
`tancho/mission_context.py`	`build_context(...)`, `validate_context_v1(...)`, `MissionContext`
`tancho/observation_intent.py`	`parse_intent_output(raw)`, `validate_and_bind_intents(...)`, `VerifiedIntentSet`
`tancho/observation_program.py`	`parse_program_output(raw)`, `validate_observation_program(...)`, `VerifiedObservationProgram`
`tancho/observation_program_prompts.py`	`reasoner_prompt(...)`, `generator_prompt(...)`
`tancho/observation_program_inference.py`	`infer_role(...)`、1回・期限付きのrole呼出しとreceipt
`tancho/observation_compiler.py`	`compile_program(...)`, `compile_observations(...)`, `CompiledViewPlan`, `CompileError`
`tancho/dynamic_search_compiler.py`	`compile_dynamic_search(...)`
`tancho/viewpoint_adapter.py`	`adapt_to_viewpoints_v1(...)`
`tancho/observation_program_runtime.py`	状態機械と監査record
`tancho/observation_result.py`	`verify_observation_result(...)`
`tancho/observation_flight.py`	`prepare_px4_mission(...)`、RFL合格後の未送信mission生成
`training/build_observation_program_pack.py`	role別pack生成・分割検査
`training/observation_program_loader.py`	native Cosmos SFT loaderとpack再検査
`training/build_observation_program_review.py`	旧素材からの未承認review queue生成
`training/promote_observation_program_review.py`	人レビューexportの改ざん・権利・契約検査とSFT packへの昇格
`training/build_observation_program_synthetic_r1.py`	scene ground truthへ結び付いたRelease 1合成教師と独立validation生成
`training/score_observation_program.py`	単体・paired・profile回帰評価
`training/check_observation_program_release.py`	学習、評価、SITL、Orin、匿名公開の最終hard gate
`deploy/modal_training/`	immutable payload作成、Modal H100 dry run／明示実行、Volume成果物receipt
`deploy/modal_observation_program/`	Modal VM＋H100のfresh SITL stage契約と準備record
`tancho/execution_provider.py`	新規学習・SITLのModal provider policyとreceipt検査

既存 tancho/contracts.py、tancho/reasoner_mission.py、tancho/viewpoint_plan.py、tancho/px4_mission.py は初版で変更しない。新runtimeからadapter経由で呼び、既存の評価と履歴を保持する。

14. 実装PRの分割

Contracts: profile registry、MissionContext、Reasoner/Generator validator、unit tests
Compiler: 静止対象compiler、compiled plan、viewpoints v1 adapter、golden/property tests
Slope and access data: 合成world、teacher、rule floors、凍結split
SFT and evaluation: role別pack、学習recipe、単体評価、回帰評価
Closed loop SITL: 新runtime、監査record、fresh inference、失敗注入
Additional profiles: flood、rescue、building、OrbitPodを1profileずつ追加
Open-weight release: checkpoint、hash、model card、schema、compiler、全評価

PR 1と2はGPUを使わない。PR 3で画像不要のrule floorを測り、課題が成立した場合だけPR 4の有料学習へ進む。

14.1 既存ラベルから学習packへの昇格

既存の人レビュー済みdecisionは再レビューしない。Release 1に一意対応する山王谷34件だけを対象にし、元の inspect、no_action、abstain を、それぞれ inspect/unanswered_question、satisfied/all_required_questions_completed、insufficient_evidence/evidence_unusable へ固定写像する。元decision、observation goal、source manifest、frame bytes、ontology crosswalk、期待Reasoner targetをproof JSONへ束縛し、label_authority=deterministic_legacy_migration とする。新しい構造化target自体を人が再確認したとは記録しないため human_reviewed=false を維持する。

旧ラベルのscreen pointやrangeは、Generator 1.1のview relation、coverage、detail level、stop conditionを一意に含意しない。そのため実写34件はReasoner教師だけに使い、旧数値からGenerator教師を推定しない。Generator教師は§14.2の決定論的scene ground truthから供給する。loaderはproof欠損、source bytes変更、旧decision変更、crosswalk変更、期待target変更をすべて拒否する。

新規素材を人がレビューする場合だけ review.html と promote_observation_program_review.py の経路を使う。この経路は元queueの非review部分、source manifest、全frame bytes、reviewer、timezone付き時刻、利用許諾、profile relation、両role契約を検査し、1件でも未確認・改ざん・禁止があればpackを作らない。既存34件の再ラベリングには使わない。

14.2 決定論的scene ground truth

合成教師は人レビュー済み実写と同じ権限を名乗らない。source_kind=synthetic、human_reviewed=false、label_authority=deterministic_scene_ground_truth を設定し、renderer、world seed、target geometry、visibility、profile、role、question、期待するstrict targetを含むproof JSONのcanonical SHA-256へ各recordを結び付ける。packは対応する proofs/<sha256>.json が無い、hashが違う、split/profile/role/targetが一致しない場合に学習用途で開けない。AI生成文、keyword候補、画像だけから推定したgeometryはこの権限を使えない。

Release 1のprocedural packは法面と道路について、明瞭、樹木遮蔽、利用不能のsceneを固定投影で描画する。同じ非画像入力のvisual pairでReasonerの inspect / insufficient_evidence とGeneratorの観測primitiveを変え、画像を無視するshortcutを検出する。world seedはカメラ座標として直接使わず、SHA-256から固定範囲のcamera/look-at parameterへ写像する。これによりtrain、development、finalのseed番号が異なっても同じ宣言済みcamera envelopeに入り、各splitはworld、event、site、flight、画像hashで分離される。v4ではtrain seed 1〜24、validation seed 101〜104、development seed 201〜204、final seed 301〜304を用いた。これは実写独立評価を代替せず、合成成績と実写成績を分けて報告する。

15. 未確定値

次は実装漏れではなく、測定または運用判断が必要な未確定値としてmanifestに空で持つ。

人、車両、外壁、亀裂、護岸損傷ごとの必要画質
missionごとの再観測cycle上限
観測primitiveの最終採用閾値
Orin NX上のReasoner・Generator各roleのdeadlineと同時負荷
thermal sensorの機種、校正、利用可能profile
OrbitPodの位置更新周期、探索高度、tracking controllerへの引渡し条件

これらを仮の数値で埋めた教師を作らない。値が無いprofile/caseは unsupported_sensor、missing_quality_requirement、または未実装として明示的に止める。

16. PRD要件との対応

PRD要件	詳細設計	主な実装
FR-CTX-001〜004	§3	`mission_context.py`
FR-REA-001〜004	§4	`observation_intent.py`
FR-GEN-001〜005	§5、§7	`observation_program.py`, `mission_profiles.py`
FR-CMP-001〜005	§8	`observation_compiler.py`, `dynamic_search_compiler.py`, `viewpoint_adapter.py`
FR-FLT-001〜003	§6、§8	`observation_program_runtime.py`, 既存RFL/PX4経路
FR-RES-001〜002	§6、§11.4	runtimeと結果検証器
FR-AUD-001〜002	§2、§6	runtime監査record
FR-PUB-001〜002	§10、§11、§14	pack、評価、release package
NFR-SAF-001〜004	§1、§6、§8、§12	validator、compiler、runtime
NFR-DET-001〜002	§4.3、§8.3、§12	canonicalizationとgolden tests
NFR-REP-001〜003	§9.1、§10.2、§11	provider policy、split validatorとfinal runner
NFR-PER-001〜003	§6、§9、§15	runtime metricsとdeadline guard
NFR-DAT-001〜003	§10、§14	provenance manifestとrelease builder
MR-001〜008	§9〜§11	training pack、recipe、score report

17. 実装完了の定義

各PRは対象要件ID、変更schema、migrationの有無、正常系・拒否系テスト、既存回帰結果を記録する。Release 1の実装完了はPRD §12の全項目が証拠artifactへ結び付いた時点とする。schemaとprofileの変更はversionを上げ、保存済み評価入力の意味を上書きしない。