Meetings
A meeting is recorded because you said it happened.
Not because a calendar invite fired, and not because someone joined a call. log_meeting writes a row when you tell Claude what happened — the same conversation you were already having, no separate step to open a form.
One meeting is rarely just one row.
Talk about a call and it's common for four things to move at once — the reason the demo on the front page uses exactly this. A meeting page describes the shape, not the specific sentence.
- MeetingDated when it happened, never invented. If you don't say when, you're asked rather than guessed at.
- ContactMatched to someone already in the record, or created if genuinely new. An ambiguous name is refused outright — a duplicate contact splits a person's history in two, and there is no undo for that.
- DealMoved to its new stage if the call changed one, with the move written to a trail rather than just overwriting the old stage.
- TaskWhatever you said you now owe someone, with a due date if you gave one.
What the record doesn't do
StratOps doesn't listen to calls, join meetings, or pull from a calendar. When Claude reads your calendar in the same conversation, that's Claude's own connector — StratOps neither sees nor stores what comes back. A meeting exists here only once someone describes it in words.
Ask for it back the same way you gave it.
get_dossier pulls together what's known about a person or an initiative — meetings included — rather than making you page through a list. get_today_briefing and get_weekly_review surface the recent ones without being asked by name.
There's no meeting list screen to scroll. Asking is the interface, and it's free — the read tools here never prompt for approval, only the writes do.
Naming this rather than hiding it.
A meeting's status carries two different ideas at once, and the migration kept that rather than inventing a cleaner model that didn't match the real data. One axis is the record's own lifecycle — active or archived. The other is whether an intake pass ever ran against it to pull out entities. They overlap without lining up: some meetings are marked as having gone through extraction and are still active, and one date field is set on some of those and empty on others.
That's a genuine seam in the schema, kept visible rather than smoothed into something that reads better and describes the data worse.