23.4 Building a searchable "knowledge log"

Goal: make meetings retrievable and useful over time

Most teams repeat the same conversations because they can’t find what was decided and why.

A searchable knowledge log turns meetings into a system:

• what we learned,
• what we decided,
• what we tried,
• what remains open.

It also creates a corpus you can later ground Q&A on (Section 22 and Part VIII).

A simple data model for a knowledge log

Keep it simple and consistent. A useful log entry includes:

• Metadata: date, attendees/roles, project, tags.
• Summary: 5–10 bullets of what happened.
• Decisions: with evidence quotes and status.
• Action items: owners/dates or explicit unknowns.
• Risks/open questions: what needs follow-up.

Store entries as markdown or JSON in a folder that’s easy to version and search.

Workflow: transcript → log entry → index

1. Clean transcript (23.2).
2. Extract decisions and action items (23.1 and 23.3).
3. Generate a log entry: structured summary + links to tickets.
4. Index: create an index page or JSON catalog for search.
5. Review: human checks for hallucinated commitments.

Search and retrieval options

Start simple, then upgrade:

• Phase 1: filename conventions + keyword search (ripgrep, editor search).
• Phase 2: a small index (JSON) with tags and summaries.
• Phase 3: retrieval (embeddings) once the corpus grows and Q&A becomes valuable.

Don’t jump to vector search if your team can’t maintain a simple log consistently.

Governance: privacy, access, retention

Meeting logs may include sensitive content. Decide:

• who can access the log,
• what must be redacted,
• how long entries are retained,
• what gets excluded entirely (e.g., customer PII, security incidents).

Write these rules down and encode them into your prompt templates and review checklist.

Copy-paste prompts

Prompt: transcript → knowledge log entry

Create a knowledge log entry from this meeting transcript.

Rules:
- Do not invent decisions or action items.
- Every decision/action item must include a direct quote as evidence.
- Redact any PII (names/emails) if present, replacing with [REDACTED].

Output as markdown with sections:
1) Metadata (date, project, tags)
2) Summary (bullets)
3) Decisions (with evidence)
4) Action items (owner/due_date may be null)
5) Open questions / risks

Transcript:
```text
...
```

Where to go next

• Section 22: long-text workflows
• Part VIII: retrieval and grounding