What Sera Extracts From Every Meeting

What Sera Extracts From Every Meeting

When Sera reads a meeting transcript or notes, she does not just summarize it. She dismantles it into structured, individually useful records and files each one where it belongs. Here is the full inventory of what comes out and where it lands.

---

The meeting summary

Every processed meeting gets a Meeting Summary with three parts:

• A one-line summary so anyone can grasp the meeting at a glance.
• A short narrative capturing the arc and the substance.
• The list of participants who took part.

This is the human-readable anchor that everything else links back to.

---

The records Sera extracts

• Tasks — concrete action items. Each captures an owner, the assigned role (with the role's current holder auto-resolved so you know who that is today), a due date, a priority, and the related project.
• Decisions — marked as either confirmed or candidate, with the decision-maker role and a canon-impact flag noting whether the decision touches governance canon.
• Risks — each with a severity, a category, an owner, and a review date so nothing flagged simply fades away.
• Canon Change Candidates — proposed changes to governance canon. These route to admin review and are always Pending Review. Sera never applies them.
• Memory Candidates — durable pieces of institutional knowledge worth keeping. These route to the Memory Review Queue for human approval.
• Sensitive Flags — anything sensitive is routed to the admin-only Sensitive Review area, kept apart from general records.
• Profile updates — new or changed information about the people and organizations involved.
• Knowledge Base article drafts — reference-worthy material captured as a Draft for human review.
• CCOS Ledger entries — governance actions recorded as Draft only.

---

The nuances that keep records clean

Sera's value is not just in what she captures, but in the judgment built into how she captures it.

Needs Owner is used sparingly. A task is flagged Needs Owner only when neither a role nor a person can be identified. This is an important distinction: a role with no current holder is still accountable, because the accountability lives with the role, not the individual. So a task assigned to a currently-vacant role does not get flagged Needs Owner; the role owns it, and whoever steps into that role inherits it.

Tasks are commitments, not intentions. Sera extracts a task only when there is a concrete commitment, something someone will actually do. Vague aspirations like "we should think about marketing sometime" do not become tasks. This keeps your task list real and actionable rather than clogged with wishful noise.

---

Everything links back to the source

This is the feature that makes the extracted memory trustworthy: every extracted Task, Decision, and Risk carries a Source Document link. That link is a direct URL to the transcript document the record came from.

So when you are reviewing a decision weeks later and want to know exactly what was said, you do not have to hunt for the original meeting. You click straight through to the source and read the actual words in context. Nothing Sera extracts is a claim you have to take on faith; the receipts are always one click away.

---

Why this structure matters

A pile of meeting notes is nearly useless three months later. A structured set of tasks, decisions, and risks, each owned, dated, reviewable, and linked to its source, is institutional memory you can actually run an organization on. That transformation, from raw conversation into structured, accountable, verifiable records, is exactly what Sera does with every meeting you feed her.

Key points

From every meeting Sera extracts: a Meeting Summary (one-line plus short narrative plus participants); Tasks with owner, assigned role with auto-resolved current holder, due date, priority, and project; Decisions marked confirmed or candidate with decision-maker role and a canon-impact flag; Risks with severity, category, owner, and review date; Canon Change Candidates routed to admin review and always Pending Review; Memory Candidates routed to the Memory Review Queue for human approval; Sensitive Flags routed to admin-only Sensitive Review; Profile updates; KB article drafts; and CCOS Ledger entries as Draft. Nuances: Needs Owner is set only when neither a role nor a person is identifiable, since a role with no current holder is still accountable; Tasks capture concrete commitments only, not vague intentions; and every extracted Task, Decision, and Risk carries a Source Document link straight to the transcript.