Meetings and evidence
Paste the transcript, turn a sentence somebody said into a countable observation.
On this page
Where this comes from
This guide is distilled from docs/GROWTH-MEETING-INTELLIGENCE.md and src/features/growth-kit/help/content/conversations.ts. When the guide and Growth-OS disagree, that document is the one to trust, and the difference is worth reporting.





The transcript is the evidence base
Prepare a meeting before it happens: set the date and type, write the agenda and the outcome you want, and link the companies involved. Afterwards, paste the transcript as it was said, up to 100,000 characters. Growth-OS does not record calls and does not transcribe audio.
Tidy nothing. A fixed typo, a straightened apostrophe, a removed line break or a changed capital all break the character match that evidence written from this text has to pass. If the transcript needs context, that is what the summary field is for.
The meeting date dates every observation from it. A transcript entered six weeks late still counts in the window of the day the conversation happened, and a wrong date moves counts between windows silently.
Why a quote has to be exact
An evidence record saves only when its quote occurs, character for character, in the transcript of a meeting it links to, and only when the quote reaches at least four words and twenty characters. The check runs on the server inside the same transaction as the write, so no screen and no import goes around it.
That one rule is why any count on any Growth-OS screen can be walked back to a sentence a customer actually said. Copy the line out of the transcript rather than retyping it from memory. A refusal names the rule and your draft stays in the editor.
One record, one claim, one quote
An evidence record carries a claim type, a theme and the quote. Claim type is fact, observation, hypothesis or result, and Growth-OS never promotes one to another. Theme is one of seven declared values: question, pain, objection, use case, competitor, feedback or buying signal. Both are closed lists, because a theme somebody invents in one record is a cluster of one in every count.
Link the company as well as the meeting. The meeting link is what the save checks; the company link is what lets the explorer place the observation by platform and catalog size, and what lets a battlecard count it.
Proposed observations, reviewed by a person
A meeting record carries its own review queue. A model may read the transcript and propose observations: the claim type, theme, title and summary are generated, but the quote is the transcript's own text at a character span the server re-checked before the proposal was stored at all.
Nothing becomes an evidence record until somebody here approves it, and approving goes through the same save and meets the same quote rule as a hand-written record. There is deliberately no second, weaker path into our evidence. An approved proposal cannot be unapproved; edit or archive the record it created instead.
Reading the explorer without over-reading it
The explorer clusters this project's evidence by theme or by claim type over a trailing window, against the same number of days before it. A change is only reported once a cluster holds five dated observations across both windows; below that the cell says how many of the five it has. That is a declared reporting floor, not a significance test.
An observation is dated by the latest meeting it links to, never by when the row was typed. One with no dated meeting is in the total and in neither window. Read limits are printed on screen, so a truncated read is visible rather than quietly low. When you quote a figure, bring the window and the grouping with you, and send the quote as well as the count.
Was this page helpful?
Feedback is stored only in this browser in the starter implementation.