Skip to content
PCE 2.0

Schema: Process Frame

このページは Process Frame の参照スキーマです。
概念的な定義や背景は ontology ページを優先し、このページでは field inventory、validation rules、実装上の切り分けを中心に整理します。

ここで示すスキーマは wire format の唯一の正解 ではありません。
ただし、PCE 2.0 の Process Frame を実装・保存・検証するときに、少なくとも何を持つべきかを明示するための canonical reference として使えます。

このスキーマの役割

Section titled “このスキーマの役割”

Process Frame schema は、PCE 2.0 における「仕事単位の構造」を表します。
ここに入るのは、主に次のものです。

  • その frame が何を達成したいか
  • 何をもって達成とみなすか
  • 誰が参加するか
  • 誰に何の責任が配分されるか
  • どの capability envelope の中で動くか
  • どの approval / evaluation / memory / recovery 条件を持つか

逆に、その時点でいま何状態か は、原則としてこの schema の外です。
たとえば次は別 schema で扱います。

つまり Process Frame schema は、runtime state ではなく structure を表します。

最小 canonical schema

Section titled “最小 canonical schema”

PCE 2.0 の最小形は、次のように置けます。

process_frame:
  frame_id:
  parent_frame_id:
  goal:
  success_criteria:
  scope:
    in_scope:
    out_of_scope:
  actors:
  responsibility_allocation:
  capabilities:
    tools:
    data:
    environments:
    permissions:
  constraints:
  stop_conditions:
  approval_points:
  eval_contract:
  memory_write_policy:
  recovery_strategy:

この最小形で重要なのは、次の点です。

  • goal と success_criteria が分かれている
  • actors と responsibility_allocation が分かれている
  • capabilities は frame-level の outer envelope である
  • approval_points、eval_contract、memory_write_policy、recovery_strategy が frame の内部にある
  • runtime status は入っていない

推奨 expanded schema

Section titled “推奨 expanded schema”

実装や保存を考えるなら、次のような expanded shape が扱いやすいです。

process_frame:
  frame_id:
  title:
  parent_frame_id:
  frame_kind:
    # feature | analysis | implementation | review | evaluation | incident | recovery | memory | integration | custom
  goal:
  success_criteria:
    - criterion_id:
      type:
        # outcome | process | hybrid
      description:
      measurement_ref:
      threshold:
  scope:
    in_scope:
    out_of_scope:
    assumptions:
    non_goals:
  actors:
    - actor_ref:
      role_label:
  responsibility_allocation:
    actor_to_bundle_refs:
      actor_ref:
        - bundle_ref
    retained_authorities:
    delegated_authorities:
  capabilities:
    tools:
    data:
    environments:
    permissions:
    prohibited_capabilities:
  constraints:
    deadlines:
    budgets:
    policy_constraints:
    quality_constraints:
    prohibited_actions:
  stop_conditions:
    - condition_id:
      trigger:
      effect:
        # stop | suspend | escalate | rollback | replan
      escalation_target:
  approval_points:
    - approval_point_ref
  eval_contract:
    - eval_contract_ref
  memory_write_policy:
    allowed_targets:
    prohibited_targets:
    canonical_rules:
    provisional_rules:
    required_reviews:
  recovery_strategy:
    checkpoint_policy:
    rollback_anchor_policy:
    resume_conditions:
    escalation_path:
  tags:
  provenance:
    created_by:
    created_from:
    version:

この shape は、spec と implementation の両方に寄せた参照形です。
実装では ref を使ってもよいし、inline object で持ってもかまいません。

Field-by-field reference

Section titled “Field-by-field reference”

以下、各 field の意味を整理します。

frame_id — required

Section titled “frame_id — required”

その frame を project 内で一意に識別する stable ID です。

期待される性質:

  • project-scoped に一意
  • runtime session をまたいでも変わらない
  • human-readable でも opaque ID でもよい
  • later delta / approval / recovery / audit から参照可能

悪い例:

  • 毎回セッションごとに変わる ID
  • phase 変更のたびに silent に再採番される ID

title — optional but recommended

Section titled “title — optional but recommended”

人間向けの短い表示名です。
frame_id が stable identifier なら、title は readable label です。

例:

  • Checkout coupon combination
  • Spec analysis for coupon combination
  • Incident analysis: rollback uncertainty

parent_frame_id — optional

Section titled “parent_frame_id — optional”

この frame が child frame の場合、その親 frame を指します。
トップレベル frame なら null または省略で構いません。

重要な点:

  • parent_frame_id があるだけでは parent-child semantics は十分ではない
  • retained authority や return contract は別 relation で表現した方がよい
  • 詳しくは Parent-Child Process を参照

frame_kind — optional but useful

Section titled “frame_kind — optional but useful”

frame の主要な性格をラベル付けします。
これは ontology の本質ではありませんが、運用・集計・metrics に有用です。

例:

  • feature
  • analysis
  • implementation
  • review
  • evaluation
  • incident
  • recovery
  • memory
  • integration

注意点:

  • frame_kind は phase ではない
  • frame_kind は Lifecycle の current state でもない

goal — required

Section titled “goal — required”

その frame が何を達成しようとしているかを表す中核目的です。

期待される性質:

  • task 名の列ではなく、達成対象を表す
  • parent goal の局所断面なら、その slice が分かる
  • out-of-scope を内包しない
  • child frame なら parent との relation が説明できる

悪い例:

  • 仕様を見る
  • 実装する
  • がんばる

良い例:

  • checkout にクーポン併用制約を導入し、既存 pricing flow を損なわずに運用可能にする

success_criteria — required, non-empty

Section titled “success_criteria — required, non-empty”

何をもって「この frame は成立した」とみなすかを表します。

推奨:

  • 単なる箇条書きでもよいが、criterion ID を持つと扱いやすい
  • outcome criteria と process criteria を混ぜてもよいが、区別できる方がよい
  • later evaluation と close authority に接続できるようにする

典型例:

  • spec approved
  • required regression suite passed
  • rollback path recorded
  • memory candidates evaluated
  • no unresolved blocking issue remains

詳しくは Outcome vs Process を参照。

scope — required

Section titled “scope — required”

この frame の内側と外側を定めます。

推奨 subfields:

  • in_scope
  • out_of_scope
  • assumptions
  • non_goals

特に重要なのは out_of_scope を explicit に書くことです。
PCE 2.0 では、scope drift は重大な process failure になりやすいからです。

actors — required

Section titled “actors — required”

この frame に enrollment される actor の集合です。
actor は human に限りません。

例:

  • product owner
  • coding agent
  • reviewer
  • CI evaluator
  • memory writer
  • checkpoint manager
  • policy actor

注意点:

  • actor list は participation universe を示す
  • 誰が何を持つかは responsibility_allocation が定める
  • actor と bundle は分ける

詳しくは Actor を参照。

responsibility_allocation — required

Section titled “responsibility_allocation — required”

どの actor にどの責任が割り当てられているかを表します。

最低限必要なこと:

  • actor→bundle の対応がある
  • retained authority と delegated authority の違いが表現できる
  • parent-child で retained されるものが分かる
  • approval / evaluation / memory / incident の非対称性が見える

実装上は、次のどちらでもかまいません。

ref-based

Section titled “ref-based”
responsibility_allocation:
  actor_to_bundle_refs:
    product_owner:
      - bundle.goal_owner
      - bundle.incident_owner
    coding_agent:
      - bundle.executor.impl

inline-based

Section titled “inline-based”
responsibility_allocation:
  product_owner:
    goal_ownership: global
    approval_authority:
      - spec
    incident_ownership: primary

詳しくは Responsibility Bundle を参照。

capabilities — required in reference form, may be sparse in lightweight implementations

Section titled “capabilities — required in reference form, may be sparse in lightweight implementations”

frame-level の capability envelope です。
これは actor-specific grant ではなく、この frame 全体で想定される最大外周 を表すと考えると分かりやすいです。

典型 subfields:

  • tools
  • data
  • environments
  • permissions
  • prohibited_capabilities

重要な点:

  • actor ごとの actual capability は bundle や governance surface で narrower になりうる
  • frame-level capabilities は outer envelope
  • current active scope は runtime / phase により further narrowed されうる

詳しくは Capability Scope を参照。

constraints — required

Section titled “constraints — required”

frame を外形的に制約する条件です。

典型 subfields:

  • deadlines
  • budgets
  • policy constraints
  • quality constraints
  • prohibited actions

注意点:

  • scope は「何を扱うか / 扱わないか」
  • constraints は「どういう条件で扱うか」

として分けると整理しやすいです。

stop_conditions — required

Section titled “stop_conditions — required”

その frame でいつ止まるべきか、何が起きたら suspend / escalate / rollback / replan すべきかを定めます。

推奨 subfields:

  • trigger
  • effect
  • escalation_target

例:

  • scope conflict detected → escalate
  • required evaluator fail → stop and rework
  • missing approval → suspend progression
  • rollback infeasibility → incident path

重要な点:

  • stop condition は mere note ではなく later legal transition に効く
  • execution actor の active context にも反映されるべき

approval_points — required whenever the frame has approval gates

Section titled “approval_points — required whenever the frame has approval gates”

この frame が持つ approval point への参照です。

重要な点:

  • point は構造
  • approve / reject は transition
  • approval authority は bundle / oversight policy 側

詳しくは Approval Points と Approval を参照。

eval_contract — required whenever mergeable / promotable outputs exist

Section titled “eval_contract — required whenever mergeable / promotable outputs exist”

この frame で適用される evaluation contract への参照です。
既存 docs との整合のため field 名は eval_contract としていますが、
値は単数でも配列でもかまいません。実装上は配列に normalize する方が扱いやすいです。

例:

eval_contract:
  - eval.feature.checkout.coupon-combination.artifact.v1
  - eval.checkout.operational-memory.v1

重要な点:

  • frame-level baseline を置く
  • item-specific overrides は delta 側や item-specific contract 側で足す
  • No merge without eval の前提になる

詳しくは Eval Contract を参照。

memory_write_policy — required

Section titled “memory_write_policy — required”

この frame から何を durable state に残してよいか、どの zone / collection を使うか、どんな review を必要とするかを定めます。

最低限欲しいこと:

  • allowed / prohibited targets
  • canonical vs provisional distinction
  • required reviews or approvals
  • target collection semantics

例:

memory_write_policy:
  allowed_targets:
    - decisions
    - failure_memory
    - pending_candidates
  prohibited_targets:
    - raw_working_notes

詳しくは Memory Promotion Rules を参照。

recovery_strategy — required

Section titled “recovery_strategy — required”

この frame が failure・pause・handoff・later resume にどう耐えるかを定めます。

典型 subfields:

  • checkpoint policy
  • rollback anchor policy
  • resume conditions
  • escalation path

重要な点:

  • runtime state そのものはここに入れない
  • ここは「どう recover する方針か」の定義
  • actual recovery point は別 schema

詳しくは Checkpoint and Recovery と Recovery Point を参照。

tags — optional

Section titled “tags — optional”

検索、metrics grouping、docs navigation のための補助ラベルです。
意味論の中心ではありませんが、運用上は有用です。

provenance — recommended

Section titled “provenance — recommended”

この frame 自体が、どの higher-level frame、request、issue、release、incident、replan から生まれたかを記録します。

最低限あるとよいもの:

  • created_by
  • created_from
  • version

特に reframe や supersession を later 追いたいなら重要です。

何をこの schema に入れないか

Section titled “何をこの schema に入れないか”

実装で混ざりやすいので、明示しておきます。

入れない方がよいもの

Section titled “入れない方がよいもの”

1. current lifecycle state

Section titled “1. current lifecycle state”
  • active
  • blocked
  • pending approval
  • completed

これは Lifecycle の側に置くべきです。

2. active actor-local context

Section titled “2. active actor-local context”

現在どの local context が active かは frame structure ではなく runtime state です。

3. emitted delta instances

Section titled “3. emitted delta instances”

frame は delta を生みますが、current delta list 自体は別 layer に置くべきです。

4. concrete recovery point objects

Section titled “4. concrete recovery point objects”

recovery_strategy は持ってよいですが、具体的な recovery point instance は別です。

5. audit records

Section titled “5. audit records”

auditability は重要ですが、frame schema そのものに全 audit event を埋め込むべきではありません。

Validation rules

Section titled “Validation rules”

この schema を Process Frame として扱うための最低限の validation rule を置いておきます。

1. frame_id is required and stable

Section titled “1. frame_id is required and stable”

毎回変わる ID は frame identity として弱すぎます。

2. goal must be present

Section titled “2. goal must be present”

空 goal の frame は frame ではありません。

3. success_criteria must be non-empty

Section titled “3. success_criteria must be non-empty”

達成条件のない frame は close semantics を持てません。

4. scope.in_scope and scope.out_of_scope should both be explicit

Section titled “4. scope.in_scope and scope.out_of_scope should both be explicit”

片方だけだと later drift を防ぎにくいです。

5. Every actor referenced in responsibility_allocation must exist in actors

Section titled “5. Every actor referenced in responsibility_allocation must exist in actors”

参照整合性が必要です。

6. Frame-level capability envelope must not be narrower than actor-level actual grants

Section titled “6. Frame-level capability envelope must not be narrower than actor-level actual grants”

逆に actor-level grant が frame-level envelope を超えてもいけません。

7. Any mergeable / promotable path must have an applicable eval_contract

Section titled “7. Any mergeable / promotable path must have an applicable eval_contract”

評価経路がなければ No merge without eval に反します。

8. Every frame must have stop logic

Section titled “8. Every frame must have stop logic”

stop_conditions がない frame は bounded ではありません。

9. Every frame must have memory policy if it can emit durable-worthy outputs

Section titled “9. Every frame must have memory policy if it can emit durable-worthy outputs”

decision / failure / operational notes を返しうるなら memory path を定義すべきです。

10. Every frame must have recovery semantics

Section titled “10. Every frame must have recovery semantics”

長時間 process では特に必須です。

Serialization guidance

Section titled “Serialization guidance”

この schema は conceptual reference なので、実装ではいくつかの流儀がありえます。
そのときの指針を書いておきます。

ref-first が向く場合

Section titled “ref-first が向く場合”
  • actor, bundle, approval point, eval contract を別エンティティで管理する
  • audit / supersession / versioning を強くしたい
  • graph-like querying をしたい

inline-first が向く場合

Section titled “inline-first が向く場合”
  • docs site や config file として読みやすくしたい
  • small system で entity split がまだ重い
  • early prototyping 段階である

推奨

Section titled “推奨”

小さい実装では inline でもよいですが、次の four things は早めに ref 化した方が伸びます。

  • actors
  • responsibility bundles
  • approval points
  • eval contracts

Example

Section titled “Example”

feature.checkout.coupon-combination の簡潔な参照例です。

process_frame:
  frame_id: feature.checkout.coupon-combination
  title: Checkout coupon combination
  parent_frame_id: release.checkout.spring-2026
  frame_kind: feature


  goal: >
    checkout にクーポン併用制約を導入し、
    既存 pricing / validation flow を損なわずに運用可能な形へ反映する


  success_criteria:
    - criterion_id: spec-approved
      type: process
      description: 制約仕様が承認されている
    - criterion_id: code-merged
      type: outcome
      description: 対象コードと関連テストが merge されている
    - criterion_id: regression-green
      type: outcome
      description: required regression suite が通過している
    - criterion_id: rollback-recorded
      type: process
      description: rollback path が記録されている


  scope:
    in_scope:
      - coupon validation logic
      - checkout pricing flow
      - related tests
      - decision rationale
    out_of_scope:
      - payment gateway changes
      - marketing rule redesign
      - coupon domain model full rewrite
    assumptions:
      - coupon precedence rule remains baseline
    non_goals:
      - release policy redesign


  actors:
    - actor_ref: product_owner
      role_label: Goal owner / incident sink
    - actor_ref: analyst_agent
      role_label: Spec analysis
    - actor_ref: coding_agent
      role_label: Implementation
    - actor_ref: reviewer
      role_label: Review / approval
    - actor_ref: ci_evaluator
      role_label: Blocking evaluator
    - actor_ref: memory_writer
      role_label: Durable memory writer
    - actor_ref: checkpoint_manager
      role_label: Recovery runtime


  responsibility_allocation:
    actor_to_bundle_refs:
      product_owner:
        - bundle.goal_owner.feature
        - bundle.incident_owner.feature
      analyst_agent:
        - bundle.executor.spec-analysis
      coding_agent:
        - bundle.executor.implementation
      reviewer:
        - bundle.evaluator.reviewer
        - bundle.approver.code-review
      ci_evaluator:
        - bundle.evaluator.ci
      memory_writer:
        - bundle.memory_writer.feature
    retained_authorities:
      - global_goal_ownership_by_product_owner
      - final_incident_sink_by_product_owner
    delegated_authorities:
      - local_execution_to_coding_agent
      - code_review_approval_to_reviewer
      - canonical_memory_write_to_memory_writer


  capabilities:
    tools:
      - repository_search
      - code_edit
      - test_runner
      - diff_view
    data:
      - checkout_specs
      - current_tests
      - decision_memory.checkout
    environments:
      - local_repo
      - ci_readonly
    permissions:
      - bounded_local_write
      - read_decision_memory
    prohibited_capabilities:
      - production_deploy
      - payment_gateway_mutation
      - canonical_memory_write_without_gate


  constraints:
    deadlines:
      - before_release_cutoff
    budgets:
      - reviewer_time_bounded
    policy_constraints:
      - no_scope_widening_without_owner_decision
    quality_constraints:
      - pricing must remain deterministic
    prohibited_actions:
      - bypass_code_review


  stop_conditions:
    - condition_id: scope-conflict
      trigger: out_of_scope_change_detected
      effect: escalate
      escalation_target: product_owner
    - condition_id: missing-rollback
      trigger: rollback_path_not_explainable
      effect: stop
      escalation_target: reviewer
    - condition_id: failed-required-eval
      trigger: blocking_eval_failed
      effect: rollback


  approval_points:
    - ap.feature.checkout.coupon-combination.spec
    - ap.feature.checkout.coupon-combination.code-review


  eval_contract:
    - eval.feature.checkout.coupon-combination.artifact.v1
    - eval.checkout.operational-memory.v1


  memory_write_policy:
    allowed_targets:
      - decisions
      - failure_memory
      - pending_candidates
    prohibited_targets:
      - raw_working_notes
      - unverifiable_hypotheses
    canonical_rules:
      - requires_eval_and_authority
    provisional_rules:
      - allow_pending_candidates_with_provenance
    required_reviews:
      - reviewer
      - memory_writer


  recovery_strategy:
    checkpoint_policy:
      - after_spec_approval
      - after_implementation
      - before_merge
    rollback_anchor_policy:
      - keep_last_green_reviewable_state
    resume_conditions:
      - revalidate_gates
      - recompile_stale_contexts
    escalation_path:
      - product_owner


  tags:
    - checkout
    - feature
    - medium-risk


  provenance:
    created_by: release.checkout.spring-2026
    created_from: issue.checkout.coupon-combination
    version: 1

What to implement next

Section titled “What to implement next”

この schema を保存できたら、次に実装・記述するとつながりやすいものは次です。

暫定的なまとめ

Section titled “暫定的なまとめ”

Process Frame schema が言っていることは、最終的には次の一文に集約できます。

仕事単位は、task 名や phase 名だけでは足りない。
何を達成し、何をもって成功とし、誰に何を割り当て、どの capability の中で動き、どの gate と recovery 条件を持つかまで構造として定義されて、はじめて frame になる。

この schema は、その構造を保存・検証・再利用するための最小参照形です。