Build a source-linked founder-led advertising handoff. Work only from the supplied inputs. Do not invent a founder belief, quotation, source, result, customer, approval, owner, destination or performance claim.

REFERENCE MECHANISM
Figma sponsored Dylan Field's public video post about his interview with Jeetu Patel: https://www.linkedin.com/ad-library/detail/1499184766. The post states, “The people closest to the work should present it.” It also says a Cisco design review once moved through VP and SVP layers and took six weeks to reach Patel, after which individual contributors began presenting directly to executives. A marketer can derive angles about who presents, review latency or culture through process. Those interpretations are not new Field or Patel quotations and still require approval. The public record does not prove campaign results or reveal the private interview process. Use this only as a structure example; do not copy its wording into the user's handoff.

REQUIRED INPUTS
1. Buyer and buyer problem.
2. Source ID, type, speaker, speaker's relationship, date or recording ID, exact passage or timestamp, and URL or controlled reference.
3. Publication/permission state: public, private, permission-limited or unknown.
4. What the passage supports and does not support.
5. Marketer interpretation.
6. Three to five proposed angles, if available.
7. Approval owner and current state: pending, approved, revise or rejected.
8. Intended format, speaker, required visual or demonstration, and prohibited claims.
9. Destination URL, CTA and launch owner if launch readiness is being assessed.

STATE RULES
- Keep `source_passage`, `marketer_interpretation`, `proposed_copy`, `approval_state`, `approval_owner` and `unresolved_requests` separate.
- `source_passage` must be exact supplied text or a supplied timestamp. Never reconstruct a missing passage.
- Silence and unknown status mean `pending`, never `approved`.
- A marketer interpretation cannot be returned as the speaker's words.
- An angle without an exact passage is `hold_missing_source`.
- An interpretation that could materially change the speaker's meaning is `hold_ambiguous_interpretation` with a focused question for the source owner.
- An angle with no approval owner is `hold_missing_owner`.
- Candidate angles with the same buyer, problem, decision and promise are duplicates. Merge them under one angle ID and return `merge_duplicate_angle`.
- Draft readiness requires an exact source passage, a materially distinct selected angle, an approval owner and an explicit approval state. Approval may still be pending, but the output must remain Hold until approved final wording exists.
- Launch readiness also requires finished-media review, required factual/brand reviews, a working destination and a launch owner.
- A missing destination can allow provisional production planning. It always blocks launch readiness.

OUTPUT CONTRACT
Return one JSON object. Do not wrap it in Markdown. Set `schema_version` to the exact literal `maestro.founder-source-to-angle.v1`. Use these top-level keys exactly:
`schema_version`, `record_id`, `record_owner`, `source_record`, `interpretation`, `angles`, `selected_angle_id`, `approval`, `recording_brief`, `unresolved_requests`, `draft_readiness`, `launch_readiness`.

Use JSON null for an unavailable scalar. Do not use an empty object, array, placeholder string or freeform prose where the field types below require something else.

- `record_id`: string or null. `record_owner`: string or null. `selected_angle_id`: string or null. A non-null value must match one `angles[].angle_id`. When no angle can safely be selected yet, keep the candidate `angles`, set `selected_angle_id` to null, add a focused selection request, and keep Draft and Launch on Hold.
- `source_record`: an object with `source_id`, `source_type`, `speaker`, `speaker_relationship`, `source_date_or_id`, `source_passage`, `source_url_or_reference`, `permission_state`, `supports`, `does_not_support`. Every value is string or null. `permission_state` is one of `public`, `private`, `permission-limited`, `unknown`.
- `interpretation`: an object, never a string. It has `text` (string or null) and `state` (exactly one of `unreviewed`, `confirmed_by_source_owner`, `revised_and_confirmed`).
- `angles`: an array of objects. Each item has `angle_id`, `label`, `buyer`, `problem`, `decision`, `promise`, `proposed_hook`, `basis`, `state`, `duplicate_of`, `required_action`. Text fields are string or null. `basis` is exactly one of `exact_passage`, `interpretation`, `confirmed_interpretation`; use `exact_passage` only when the proposed hook stays within the supplied passage, `interpretation` when it needs unconfirmed interpretation, and `confirmed_interpretation` only when that interpretation is explicitly confirmed. `state` is one of `candidate`, `selected`, `duplicate`, `rejected`. `duplicate_of` and `required_action` are string or null.
- `approval`: an object with `owner`, `approved_version_id`, `approved_hook`, `approved_supporting_point`, `decision_date`, `required_action` as string or null. `state` is exactly one of `pending`, `approved`, `revise`, `rejected`. Unknown or silent approval becomes `pending`.
- `recording_brief`: an object. `speaker`, `format`, `orientation`, `delivery`, `required_visual`, `destination_url`, `cta`, `launch_owner` are string or null. `target_duration_seconds` is a positive number or null. `prohibited_claims` and `reviewers` are arrays of strings. `finished_media_review` is exactly `not_run` or `passed`. `scenes` is an array of objects. Each scene has `scene` (positive number), plus `approx_seconds`, `spoken_point`, `on_screen_text`, `required_visual`, `source_or_approval` as string or null.
- `unresolved_requests`: an array of objects. Each item has `code`, `request`, `owner` as string or null and `blocks_draft`, `blocks_launch` as JSON booleans.
  Keep each request until its named prerequisite is actually supplied. Field-derived request codes may be removed only when the corresponding field now passes the contract. A source-permission, meaning, approval or other external request stays in the array until a reviewed JSON update explicitly removes it after resolution; filling an unrelated field never resolves it.
- `draft_readiness` and `launch_readiness`: objects with `state` exactly `Ready` or `Hold`, `reasons` as an array of strings, and `next_action` as string or null.

If inputs are missing, ask no more than three focused questions. The three-question limit does not limit `unresolved_requests`: include a separate action row for every missing prerequisite, even if several rows are phrased as direct completion actions instead of questions. Complete the safe parts of the JSON, leave missing scalar values as null, use empty arrays for missing lists, and keep the affected readiness state on Hold. Do not fill gaps with generic copy.