Where things live.

From today to three possible targets.

The last three are alternatives rather than a sequence: keep the split, consolidate onto Salesforce, or consolidate onto Airtable. All three came out of the team's own thinking, and choosing between them is a live decision we should make together.

The headline: Across every state the desktop storage empties, the shared workshop fills, and Box moves over to Drive. The website column shows that visible things pull data into shape: fields got added to Salesforce because something public depended on them. It is also the caution though, because a few of those fields were typed straight into the website instead AFAIK, so the one-way arrow can leak.

Where the three targets differ. They are the three best answers to one question: how many systems of record should there be, and which?

Target A keeps the split. Airtable is the working layer for funder engagement and impact numbers, Salesforce holds the funding record. Closest to how the team works today, and the fastest to reach.

Target B consolidates onto Salesforce. Rahila's proposal: one data layer, with good front ends on top, so the dashboards stay presentation and none of them quietly becomes a fourth source of truth. The safest answer to the risk she named.

Target C consolidates onto Airtable. Also discussed with Rahila. Asked whether Salesforce does anything Airtable could not, her answer was no, that Airtable has the easier interface, and that most of the team is more comfortable in it. She hadn't yet considered the move, and on reflection thought it could work. The prize here is the fellows-to-portfolio handoff: today a fellow is exported out of Airtable at selection and re-created in Salesforce, so the sourcing history and years of context stop at the boundary. Under C that boundary disappears.

One thing B and C agree on. Sourcing stays in Airtable either way. Rahila was unambiguous that she would never move it to Salesforce, so "consolidate onto Salesforce" means the funding and portfolio side, not literally everything.

Three things weigh against C, and they should be on the table. Salesforce keeps a long, configurable field history, whereas Airtable's revision history runs one year on Team, two on Business and three on Enterprise, which sits awkwardly against investment records going back to 2002 and compliance records kept indefinitely. Salesforce enforces validation rules that block a bad save, and Airtable largely does not, which is the concrete thing behind Rahila's instinct that Airtable "feels more breakable". And the cost runs the opposite way to intuition: ten Salesforce seats is exactly the Power of Us nonprofit donation, so it is likely costing nothing, whereas Airtable seats are paid. Worth confirming both before we get attached to an answer.

Where I land. My rec is still Target C. The handoff prize is the one aligned with where the team says it wants to go and already feels comfortable enough to build dashboards on, the volumes are comfortably within Airtable's range, and the three cautions above are all manageable: history by stepping up the Airtable plan, validation by adding checks where money is involved, and cost by confirming the SF position before committing. The layer underneath draws the end state on that basis. The decision is still one to make together, and the audit and the mirror below are how we check my rec against evidence rather than taking it on trust.

The good news is that one cheap experiment tests both B and C at once. Rahila and I discussed a one-way, read-only mirror from Salesforce into Airtable for a single cycle. Nothing writes back, nothing is committed. If people go and use it, that is the case for C. If they carry on ignoring it, the interface was never the problem and B is the answer. Either way we learn it from behaviour rather than preference, and the audit finishing in September is the natural moment to start.

One finding worth sitting with. Salesforce is described by everyone as the source of truth, and largely because of that, almost nobody opens it. Airtable holds data that would be just as painful to lose, and people edit it happily every day. The caution around Salesforce is protective rather than functional, and it's the reason a genuinely decent database is carrying stale financials, empty site visits and abandoned profile fields. Whichever target we pick, that gap is the thing to close.

Three kinds of build, and only one of them needs AI to run.

Rahila put her finger on this first, describing Spotlight as a deterministic pipeline with one agentic step inside it. Almost everything else the team has built used AI to get made and then runs without any AI in it at all. That sounds like a technicality. It decides what each build costs, what infrastructure it needs, who can look after it, and which parts of the Feb guidance apply.

Why the distinction matters. Four things follow from it, and each one changes a decision we could otherwise get wrong.

Cost behaves completely differently. A type 1 dashboard costs the same whether one person opens it or fifty. Spotlight's cost moves with the number of candidates, and 1,300 a cycle is a significant number. Budgeting for AI as a single line item hides that recurring, predictable cost.

Only type 3 needs evaluation. Type 1 fails the way software fails: the same input gives the same output and a bug can be reproduced. Type 3 can give two different answers to the same candidate. That is why Rahila is holding the autonomous sourcing half back until this cycle has been properly evaluated, and I think it is the right instinct.

The guidance applies unevenly. "AI screens and suggests, humans decide" is written for type 3 and Spotlight already honours it. Applying the same weight of review to a dashboard that does basic or even complex arithmetic would slow down the thing we want people doing more of.

They need different people. Looking after a type 1 build means being able to read the code, or being able to ask AI to change it. Looking after type 3 means being able to judge whether a model is behaving. Those are two different skills and it is worth being deliberate about who holds each.

The part that is easy to misread. Type 1 builds still need AI to be developed and changed, and keeping their documentation current is a good use of it. What they don't need is a model running inside them, and saying so stops us buying infrastructure for a problem we don't have.

There is a quieter risk in here too. Because type 1 builds don't feel like AI, they can slip past the attention that AI work attracts. Nobody asks a dashboard where it keeps its credentials or who is allowed to write through it.