AI 會議交接設計：在 JSON 輸出中保留未知資訊

An AI meeting handoff should distinguish a source statement from a verified commitment. If your output schema requires an owner and a deadline for every extracted item, it can pressure the extraction step to turn missing information into plausible information. Model the unknowns explicitly instead.

Start with an extraction contract

For a recording-to-handoff pipeline, separate three stages: candidate extraction, source verification, and downstream assignment. The extraction stage finds passages worth checking. Verification confirms what the speakers actually agreed. Assignment happens in the system where someone accepts the work. A fluent summary does not prove that all three stages happened.

Here is an illustrative record, not an export format or API response from a particular product:

{
  "item_id": "decision-001",
  "kind": "conditional_decision",
  "statement": "Prepare for a Friday release if support is ready.",
  "owner": null,
  "due_date": null,
  "conditions": [
    "Support sign-off is required."
  ],
  "evidence": {
    "recording_id": "authorized-example-001",
    "start_seconds": 742,
    "end_seconds": 759,
    "quote": "We could launch on Friday if support is ready."
  },
  "review": {
    "state": "needs_confirmation",
    "reviewer": null
  },
  "external_task_id": null
}

Why null is more useful than a confident guess

Keep owner null when nobody accepted responsibility. A speaker label identifies who spoke; it does not establish task ownership. Keep due_date null when the recording gives a relative date without enough context. “Friday” needs a meeting date and an agreed timezone before it becomes an unambiguous calendar deadline. Preserve the original wording while asking for clarification.

Do not use an arbitrary model confidence score as a substitute for review. A high score can still accompany the wrong speaker or a missing condition. A categorical state such as needs_confirmation makes the unresolved work visible to the next person.

Give the evidence a stable address

Store the recording identifier alongside the time range. A timestamp without a source file is not enough once several meetings have been imported. Keep source permissions separate from the public handoff: sharing the task summary should not automatically grant access to the recording. If you trim or replace audio, retain the original version identifier so the time range still has a meaning.

CoHear is one possible upstream tool for a phone-recorded or imported-audio workflow. It supports transcripts with speaker labels and timestamps, summaries, and action items; tapping a transcript sentence returns to the audio. Those features can support manual source checking before an item enters a handoff. The JSON contract here is a design proposal, not a claim that CoHear provides this schema, a public API, or automatic task-system synchronization.

Validate before you create a task

Treat these as acceptance rules for your own implementation:

• start_seconds must be nonnegative and earlier than end_seconds; the range must fit the referenced audio version.
• An unreviewed candidate cannot silently become a confirmed decision.
• A missing owner cannot be replaced with the nearest speaker label.
• Conditions must survive the transformation into the downstream description.
• Use an idempotency key for task creation so retrying an extraction does not create duplicate assignments.
• A JSON parser validates syntax; a schema validates structure; neither verifies that the recording supports the statement.

The useful outcome is a handoff that tells the next person what is known, what is uncertain, and where to check. More fields are only worthwhile when they preserve that distinction.

CoHear · Recording-first AI notes for iOS and Android.