C10 Roadmap: From Reconciliation To Structured State

C10의 원래 직관은 "중간 단계 데이터를 prose 덩어리 대신 구조화된 상태로 관리하자"였다. 이 문서는 그 방향을 screen presence 문제에 한정해 실험적으로 검증하는 로드맵이다.

C10 Direction Reframed

현재 결론은 "producer prompt-pack 전체를 선제적으로 object schema로 바꾸자"가 아니다. 더 안전한 C10 방향은 demand-driven structured state다.

Old C10 Temptation	Reframed C10 Direction
All producer text fields become structured objects up front.	Only fields that have real consumers, locks, gates, or editor actions become structured.
Taxonomy first.	Consumer first. The consumer here is validator/render prompt card/editor.
One big migration.	Small experiment, measured, then branch.
LLM/VLM judgment fills ambiguity.	Deterministic reconciliation over existing structured signals; human review for visual quality.

Why Screen Presence Is A Good C10 Pilot

It has a real consumer: visible_entities_validator and render_prompt_card.
It has a real failure: S15_Shot5 blocks the pipeline.
It has existing partial structure: visible_entity_ids, character_angles, pov_character, and subject_reference_policy.
It has measurable outcomes: contract violations, card hash stability, required_refs parity, E2E completion.
It connects directly to future human editing: a user may say "C01 is only mentioned off-screen here, do not force face reference".

Phase Map

Phase	Name	Scope	Commit Now?
0	Contract note	Terminology, detection contract, test matrix, no schema changes.	Yes, first.
1	Deterministic reconciliation	Shared detector plus `build_render_prompt_card` policy override, with `name_by_short_id` threaded through card inputs.	Yes, first implementation.
2	Shared detector adoption	Reuse the detector in diagnostics/gates and possibly telemetry; avoid new hard block by default.	Only after Phase 1 evidence.
3	Explicit screen_presence schema	Add `screen_presence` enum to shot_staging or a sidecar if repeated failures prove need.	Not now.
4	Agentic editing integration	Expose screen presence policy as addressable, patchable state with provenance/lock.	Future product work.

Post Phase 0/1 Decision Point

Phase 0/1이 끝나면 다음 두 갈래 중 하나로 판단한다.

Branch A - Minimal Reconciliation Is Enough

Signal	Decision	Next Work
S15 class resolves; no new false-positive downgrade.	Keep C10 structure demand-driven and stop at Phase 1 for now.	Add telemetry, maybe promote Path 2 diagnostic to shared non-blocking detector consumer.
Full E2E passes without identity/ref regressions.	Do not add `screen_presence` schema yet.	Record this as a C10 pilot success: consumer-first structured reconciliation.
Human review says output is visually coherent.	Proceed to next E2E/generalization scenario.	Collect more examples before schema migration.

Branch B - Reconciliation Is Not Enough

Signal	Decision	Next Work
Repeated false positives or false negatives.	Phase 1 detector is too heuristic.	Open Phase 3 design for explicit `screen_presence` output.
Frequent user corrections like "this character is only referenced off-screen".	Screen presence needs addressable editor state.	Add patchable sidecar with provenance/lock instead of prompt-only fix.
Prompt/validator still disagree after card override.	The policy is too implicit.	Introduce structured `presence_conflict_resolution` or `screen_presence` field with stable IDs.
Name-free off-screen prose produces too many downgrades or too many misses.	The Phase 1 detector is not expressive enough.	Escalate to explicit `screen_presence` schema instead of adding more prose heuristics.

Future Phase 3 Shape, If Needed

Do not implement this yet. This is the likely schema shape if Phase 1 proves insufficient.

{
  "character_screen_presence": [
    {
      "character_id": "C01",
      "presence": "offscreen_referenced",
      "source": "shot_staging",
      "evidence": "camera_direction: off-screen direction where ...",
      "identity_policy": "generic_descriptor_allowed",
      "locked": false,
      "origin": "llm"
    }
  ]
}

Candidate enum: in_frame_foreground, in_frame_background, partially_in_frame, pov_implied, offscreen_referenced, not_present.

This schema should only be added after there is a confirmed consumer: render card policy, validator, editor tool, or rerun invalidation logic.

Agentic Editing Implications

If the future interface is chat-primary hybrid editing, screen presence is a good first addressable state candidate:

It is hard to edit with a form UI, but natural in chat: "S15 shot5에서 수리영은 화면 밖 언급으로만 처리해."
It needs provenance: whether the decision came from shot_director, shot_staging, deterministic reconciliation, or human override.
It needs lock semantics: a human override should survive downstream reruns unless a conflict is surfaced.
It needs stable identity: scene/shot/character IDs are stable enough for this first class of edits.

Recommended Next Action

Approve Phase 0/1 only.
Open a narrow implementation wave with W0 read-only pin, W1 detector, W2 render card consumer, W3 E2E verification.
Do not start Phase 3 schema work until Phase 1 has one clean E2E and no false-positive identity downgrades.
After Phase 1, choose Branch A or Branch B using the measured criteria above.