Linking meeting notes to a client and a project is two different problems wearing one name.

A call with a client rarely stays inside one project. Twenty minutes in, the conversation drifts from the workstream on the agenda to a renewal date, then to a completely different engagement the same stakeholder happens to sponsor. Writing that up afterwards exposes a question most note systems never answer: does this note belong to the client, or to the project? Linking meeting notes to both client and project sounds like a small modelling detail. It is the point where most systems, Notion databases included, quietly ask the user to pick one and accept that the other view will be missing something.

What Notion's relation model gets right

Notion's answer to this problem is clever. A relation property lets one database row point at rows in another database, and a rollup can then pull fields across that relation, so a client page can show a rolled-up list of every linked meeting note without anyone maintaining a second copy of the list by hand. Add a second relation property and, in principle, one note page can link to a client database and a project database at the same time. For a single note about a single topic, this works about as well as anything on the market. It earned its reputation. It's the reason Notion became the default for consultants who outgrew a folder of Google Docs in the first place.

Coda and Airtable offer versions of the same idea with slightly different mechanics, two-way relations and lookups instead of Notion's relation-and-rollup pair, but the underlying bet is identical: model the connection explicitly, once, and let the database compute every view from it. That bet is correct for a huge range of information architecture problems. Anyone building a content calendar or a single-owner project tracker gets real value from this pattern, and it would be dishonest to pretend otherwise because it strains under a different kind of load.

The trouble specific to consulting work is narrower. A meeting note is an event that can touch a client relationship and several of that client's active projects in the same twenty minutes, and the relation model was built to represent one connection cleanly rather than several shifting ones inside a single entry.

Where a two-dimension link breaks

A meeting note that concerns both a client and several of that client's projects carries several relations at once, all of which need to stay true. The burden of keeping them true falls on whoever wrote the note.

Pick a parent, lose a view.

A note filed under the client database shows up cleanly on the client's page but not on any individual project's page, unless a second relation is added and maintained by hand. A note filed under a project shows up there but is invisible from the client's page unless someone builds a rollup that reaches across every project the client owns. Either choice optimises one view at the cost of the other, and most people choose the view they'll need today, then lose the one they'll need in three months.

Two relations that agree today and drift by the sixth edit.

Tagging a note to both a client and a project through two separate relation properties works, right up until the note gets edited, split, or reused, and one of the two relations doesn't get updated to match. Nothing in Notion enforces that the client relation and the project relation stay consistent with each other. A note can end up linked to a project belonging to a different client entirely, and nobody's job is to check.

The maintenance tax that shows up around client fifteen.

At three or four clients, maintaining two relations per note by hand is a minor discipline. Past roughly fifteen active clients and their projects, the number of relation pairs to keep straight grows faster than one person's attention does, and the workspace starts to feel like a second job rather than an asset. Search the Obsidian and Notion forums for a consulting vault structure that handles this and the threads tend to trail off, because there is no clean answer to the two-relation problem at scale.

A meeting note about client work almost always has two true parents at once. A system that only lets it choose one is not simplifying the note. It's deferring the cost of the second relation to whoever has to remember it later.

Linking meeting notes to a client and a project is a tagging decision

The alternative to maintaining two relations per note is to stop treating "client" and "project" as two separate databases that need connecting in the first place. In Callisto a note is a row, and that row carries a project reference, an account reference, a person reference and a meeting reference at the same time. The underlying table was built to represent an entry that is at once a project activity item, an account note, a person's discussion entry and a segment of a specific meeting. No rollup computes the connection after the fact. The connection is what the row is.

A meeting split by what it's about

In practice this shows up as segments. Writing up the call described at the top produces more than one: the first tagged to the project on the original agenda, a second tagged to the different engagement the stakeholder mentioned in passing, and, if the renewal conversation concerned the commercial relationship rather than any single workstream, a third tagged to the account. Three segments, one meeting, written in the order the conversation happened. Not a relation property in sight.

Meeting notes linked to client and project fan out from a single save

The mechanism behind this happens in one atomic save. Each segment writes to the entity it's tagged to, and a segment tagged to a project also back-fills the meeting itself with that project's tag, so that anyone else sharing the project sees the meeting appear in their own view without having to be told about it separately. A project-tagged segment appears in that project's own activity feed; a person-tagged segment appears in their ongoing discussion thread; an account-tagged segment lands on the account's Notes tab. None of these are copies. Editing the segment from any one of those surfaces updates it everywhere it appears, because it was never duplicated to begin with.

Draft segments are also saved as they're typed, locally, so a modal closed by accident mid-write doesn't cost the consultant the whole call. And if two people share a project, a segment arriving while one of them has the meeting open merges into their view live rather than waiting for a manual refresh. Small details. Together they decide whether a consultant trusts the notes model enough to keep using it, or stops bothering after the second lost draft.

A project's account is not a separate fact to maintain

The client-and-project link goes further than notes, and it rests on the same structural bet examined at length in how a graph rather than a folder carries several clients at once. Every project already belongs to an account and rolls up into that account's Engagements view without anyone maintaining the mapping by hand. A stakeholder added to a project's team is the same underlying record as that person's node on the account's org chart; move them on one side and the other reflects it. Same principle, one level up. The relationship between a project and its client was never a fact two databases had to agree on, because there was only ever one database.

Where a note without a project still belongs to the client

Not every account-relevant remark concerns a specific project, and forcing one would be its own kind of distortion. A note about a renewal date, or a change in the client's internal sponsor, belongs on the account directly, tagged there rather than bolted onto whichever project happens to be active that week. The Notes tab on an account holds exactly this kind of entry alongside the project-derived ones, in the same chronological stream. One list, in date order. A colleague preparing for a call reads the client's whole history in order rather than reconstructing it from several project feeds.

Why this holds past the fifteenth client

Relations are a good idea. They fail at scale because every relation is an assertion someone has to keep true by hand, and the number of assertions grows with every client, every project and every note. A model where the connection is the record itself accumulates no such debt. The hundredth note tagged this way costs what the first one did: the ten seconds it takes to pick where each segment belongs.

A better template does not fix this. Templates standardise how a relation gets built; they don't remove the need to build and re-verify one for every note. By the time a workspace has decayed past the fifteen-client mark, two or three template revisions have usually already been tried in search of the version that finally holds. The template's design was never the problem. The note and its two relations were always three separate facts pretending to be one.

What Callisto does not do here

Nothing in Callisto detects which project a sentence is about. The tagging is manual. That is deliberate: deciding what a remark concerns is a judgement call, not a pattern a system should be guessing at on someone's behalf. There is also no general-purpose relation or rollup builder the way Notion, Coda or Airtable offer, so a consultant who wants to model a connection between two kinds of object this piece hasn't described won't find that flexibility here. The offer is narrower and, for this problem, sufficient: the four relationships that recur in client work, project, account, person and meeting, modelled once so nobody has to model them again per note.

Getting started

After the next call that touches more than one thing, resist the urge to summarise it as a single paragraph and write it up as segments: one per project discussed, and a separate one for anything that concerns the account rather than a specific workstream. Then check both ends. Open the project and find its segment sitting in the activity feed; open the account and find the relationship-level note on its own Notes tab, where the filing routine after a call should have put it. Nothing needs linking twice, because it was only ever written once.