What is a Project Intelligence Platform?
VoxeNova is your organisation's project intelligence layer. Every meeting becomes a live, queryable knowledge graph of decisions, risks, actions, and gaps across every project — automatically, with citation-grade source linking. This post explains what that category actually is, and what it isn’t.
The category, in one paragraph
A Project Intelligence Platform captures the state of your organisation’s projects — the decisions, the risks, the actions, the gaps — and makes that state legible and queryable across every project you run. The substrate that populates it is meetings, because meetings are where project state actually moves. The output is a knowledge graph plus a dashboard: what was decided, by whom, when, in which meeting, and how it links to every other decision your organisation has made.
The problem it solves is the one every VP of Engineering, VP of Product, and Head of Programs already knows: you don’t know what you know. The decisions that shape your projects live in Slack threads, meeting recordings, someone’s Notion page, or nowhere at all. When a senior IC leaves, the memory leaves with them. When a new PM joins, ramp-up takes months. When a post-mortem asks "why didn’t we see this coming?", the honest answer is that nobody could have — the signals were spread across fifty conversations that never got connected.
What it isn’t
Project Intelligence is a distinct category, and the fastest way to explain it is by contrast. Four things it gets confused with:
It’s not a meeting transcription tool. Otter, Fireflies, Rev, Descript, Zoom AI Companion — these produce transcripts. Transcripts are useful raw material, but a transcript is not project state. A Project Intelligence Platform reads transcripts (among other things) and turns them into structured entities: decisions with owners, risks with mitigations, actions with due dates, gaps with severity. The transcript is the input, not the output.
It’s not a note-taker or knowledge base. Notion, Confluence, Craft, and every "AI note-taking assistant" require someone to write things down. That someone rarely captures the whole picture, and the pages go stale the moment the meeting ends. A Project Intelligence Platform captures automatically, structures automatically, and updates itself as the project evolves — no page authoring, no dashboard building.
It’s not a CRM or sales-intelligence tool. Gong, Chorus, Clari, Salesloft — these serve VP Sales / RevOps buyers. They’re optimised for pipeline coverage, forecast accuracy, deal-cycle time. Project Intelligence serves the engineering / product / programs org. Same mechanism (meeting capture, structured extraction) but a different buyer and a different unit of value.
It’s not an engineering-effectiveness platform. Jellyfish, LinearB, Faros, and Swarmia measure what shipped — git commits, PR cycle time, DORA metrics. They’re excellent at turning engineering activity into a dashboard. Project Intelligence measures what was decided. The two are complementary and non-overlapping: the git layer sees what shipped; the meeting layer sees what was chosen to ship.
The eight primitives
What actually makes a Project Intelligence Platform real, not just a category name? Eight capabilities that together produce a queryable project state:
Citation-grade attribution. Every decision, risk, and action links back to the exact speaker, timestamp, and transcript chunk it came from. When someone asks "wait, did we actually decide that?", the answer is one click away.
Cross-project decision linking. A decision made in one project surfaces automatically in related projects. If your payments team already ruled out a payment provider six months ago in another initiative, that decision shows up when a new team starts evaluating the same provider.
Project completeness scoring and gap analysis. A live meter that flags what your project is missing: no risk assessment yet, no rollback plan discussed, ownership unclear for three action items. The gaps become an agenda item on the next meeting.
Executive brief digest. A daily or weekly synthesis assembled from meeting artefacts, not written by hand. The exec team reads the state of the org without anyone spending Sunday night preparing slides.
Decisions board. A queryable, filterable view of every decision the organisation has made, with the context that produced each one.
Bi-temporal knowledge graph. The graph tracks both when a decision was made and when it changed, so you can query "what did we believe about the auth architecture in March?" and get an accurate answer.
Drift detection. When what’s said in meetings stops matching what’s actually shipping, the platform flags it. Silent scope creep, quiet reversals, "we said we’d do X but Y is what got merged" — all surfaced, all with citations.
Contradiction detection. When two decisions conflict — sometimes across projects, sometimes across weeks — the platform flags the contradiction before it becomes a production incident.
Who this is for
Project Intelligence Platforms are built for people whose job is to be the memory of the organisation, and who have started to feel the limits of that role. Concretely: VPs of Engineering running 10–50 concurrent projects; VPs of Product responsible for multi-team roadmaps; Heads of Programs coordinating cross-functional initiatives; Chiefs of Staff at organisations big enough to have real institutional memory but too small to have dedicated PMOs.
The buying trigger is usually one of these: a recent post-mortem that read "we should have seen this coming"; a new head of engineering trying to legibilize a mess in their first 90 days; a senior staff engineer leaving and taking irreplaceable context with them; a board asking for "engineering effectiveness metrics" and the current answer being an embarrassing spreadsheet.
Why "meetings" is the substrate
You might reasonably ask: if the goal is project state, why start with meetings? Isn’t Jira or Linear closer to project state than a Zoom call?
The answer is that Jira and Linear are downstream. A ticket exists because someone decided the ticket should exist — and that decision happened in a meeting, or in a Slack thread that referenced a meeting, or in a hallway conversation that later became a meeting. The ticket captures the outcome, not the reasoning. When you need to know why a project shape looks the way it does — not what shipped, but what was chosen — you have to go back to the meeting where it was chosen. Meetings are the substrate because meetings are where project state gets shaped.
The trade-off is that meetings are expensive to structure by hand, which is why nobody does it well. A Project Intelligence Platform makes the structuring automatic. That’s the whole shift.
What you can expect if you adopt one
After the first month, the practical outputs look roughly like this. Every meeting produces a structured artefact set: decisions with attribution, risks with owners, actions with due dates. The exec brief digest assembles automatically. The decisions board fills in. Gap analysis starts flagging things you knew were missing but hadn’t written down. Cross-project links start firing: "this authentication choice was already litigated last quarter in the payments project."
After three months, the shape of the organisation’s memory changes. Onboarding a new PM takes days instead of months. Post-mortems have a starting point that isn’t "let me try to reconstruct what happened." When someone asks "why is this project blocked?", the answer isn’t "let me ask around" — it’s a query against the knowledge graph.
The category has a name now. That name is Project Intelligence Platform.
See it running on a real scenario
The live tour shows the eight primitives working together against a seeded engineering project. Or read how it compares to adjacent tools.
Try VoxeNova Free