knowledge-meeting-ingest skill

Meeting ingestion

Turn one transcript into a sourced meeting page, updated entity profiles, and structured claims, then verify them. Read a reference only when its step needs it, and don't reread one after compaction unless you are about to use it again:

through its plugin

• setup: always, first (status, ontology, search)
• source acquisition: fetching from an API, including Granola

entity's type: creating or updating a profile or entity page

• sources: retaining originals; citation format
• speakers: possible split, duplicate or unclear speaker
• identity: resolving a person, company or project
• writing: before writing any page prose
• meeting page: writing the meeting page
• subject pages, plus only the layout for the

• source notes: the attended and discusses edges
• assertions: claims, attendance edges, reruns
• publish: batch or page writes
• recovery: any uncertain, rejected or conflicting write
• verify: verification and report

Contract

claims, not facts.

• One page per real meeting. Retain the full transcript; recorder summaries are

real signal; leave a speaker unresolved only when there is none.

• Speakers are resolved on evidence with a confidence, never guessed. Use every

profile and an attended edge whose body is their source note. Invite-list-only names get neither.

• Every participant (spoke, was addressed, or otherwise took part) gets a

about gets a page (found or created), a link from the meeting, and a discusses edge (meeting → entity) whose body is its source note. Passing mentions don't. Entity pages get no Timeline line; their Timeline is derived.

• Every company, project or concept the meeting says something substantive

existing page, State is rewritten in place, and a page gets no section or topic per meeting. A page that is already current gets only the new facts and its source note. Every existing citation stays.

• Entity pages stay current explanations: each fact goes to the most specific

commentary.

• Pages read like good human notes: names first, few caveats, no process

spread to other pages.

• Decisions, commitments and events become claims. Unverified claims don't

• Never call a meeting fully ingested until verification passes.

Steps

1. Acquire and normalize

Get the complete transcript. Empty, summary-only or in-progress input fails this step: report it. If the user only wants notes saved, use knowledge-capture and say the meeting ingestion is not complete.

Normalize in working context to: source, sourceid, title, date, time, duration, attendees (source claims), ordered segments with speaker, speakerraw and text, source summary, URL. Unknown values are null. Recorder-specific handling ends here; every recorder runs the same steps after this.

Retain the original export and the transcript (sources). Normalized text is a labeled derivative. Report acquisition, retention and publication separately, with real counts ("9/16 originals retained").

Read the normalized transcript once, in sections of about 150 lines. After each section, append to a working digest file: the line range, who spoke, topics, candidate decisions, commitments and facts with exact line citations, quote candidates, and new proper nouns. Later steps draft from the digest. Return to the transcript only for specific line ranges (to check wording or a quote), never for a full reread.

Done when: complete transcript retained; evidence receipts in hand; digest covers every line.

2. Split, dedup, resolve speakers

Check for a multi-meeting recording, an existing page for this meeting, and the speaker map (speakers).

Done when: each real meeting has its segment range; duplicates found; every speaker label is mapped or explicitly unresolved, with basis.

3. Gate each claim

Check every proposed assertion against the transcript and earlier Knowledge about the same entity.

spelling; otherwise write it as Name (unverified spelling) and give it no page or link.

• Role or relationship: explicit passage, not implication.
• Ownership: explicit ownership language; mentioning a name is not owning it.
• New proper noun: search Knowledge, then the web if allowed, for the canonical

• Major life or deal event: verbatim support, checked against existing chronology.

Transcript support is not enough on its own. Also check:

Established content wins by default. Don't write the conflicting claim into profiles; keep it on the meeting page with both citations and list it in the report for the user to resolve. Override only with explicit, verbatim support, and still report the change.

• Contradiction: does it conflict with what Knowledge already establishes?

both have started the same project; a company founded last year wasn't acquired five years ago.) An impossibility usually means a garble.

• Plausibility: is it possible given what else is known? (Two people can't

the surprise as a question; don't explain it away.

• Surprise: if the user would say "wait, what?", apply every check. Surface

Inferences and uncertain identities stay labeled on the meeting page and never enter profiles, timelines, metadata or relationships as fact.

Done when: each claim is marked publish, label-as-uncertain or withhold.

4. Publish

Order: meeting page → entity pages → claims and edges → link edits. Batch related records (publish).

knowledge-entities' SKILL.md: it resolves the entity, decides whether it gets a page, and writes the profile and source note. Its references with the same names as this skill's are identical copies; use the ones you already read and don't reread them. Its only extra reference is enrichment (read its "During ingestion" section).

• Meeting page per meeting page.
• For each participant and substantive entity, follow the steps in

facts and one source_event: true event for the meeting itself, with all relevant entities. Other events keep their own dates.

• Claims per assertions: decisions, commitments,

runs participant → meeting; confirm in the definition. Set source_page. Its body is one sentence on what this person did or said in the meeting.

• An evidenced attended relationship per participant. In the shipped ontology it

non-participant, including mentioned people with pages, with the same kind of one-sentence body. Don't create pages for unknown speakers.

• An evidenced discusses relationship (meeting → entity) for each substantive

to profiles; ask if scope is unclear.

• For legal or personal content, keep the meeting page factual and limit spread

Done when: every planned record has a published receipt in your work log.