Discovery shouldn’t end in a static slide pack that gets shelved a few weeks later. A queryable project brain, built with AI, turns the discovery phase into a referenceable, living memory. But it only works if humans stay accountable for the contradictions and trade-offs it surfaces.
As AI speeds up delivery, being able to audit decisions matters more, not less. Every programme has always needed a RAIDD log: risks, assumptions, issues, dependencies and decisions. The decisions taken on day one of discovery carry consequences all the way through to build, and when build moves this fast, a decision no one can account for later is expensive. The record of why has to keep pace with the code produced.
One real project runs through this article, unnamed for confidentiality: an identity service built to one of the highest assurance standards, where traceability mattered as much as delivery. The other examples are illustrative, the kinds of long-lived public service this applies to rather than any single client.
The problem with traditional discovery
Six weeks of workshops, business analysis, data analysis, technical evaluation and user research get condensed into a summary deck, and once delivery starts nobody opens the deck again, or at least very infrequently. The reasoning behind what has been scoped or not goes with it. Our own project foundation workshops, driven by AI, start from exactly this observation: traditional delivery buries its decisions in Jira tickets, Confluence pages and people’s heads, and most projects surface a misalignment early that would otherwise cost weeks to unpick in build.
A project brain is a way to keep that context live. It’s a centralised, searchable store of project context, built with AI agents that ingest workshop notes, user research transcripts, data catalogues, policy documents and architecture decision records. Instead of condensing everything into a summary that ages badly, you keep the source material and make it queryable.
The shift underneath this matters more than the tooling. Discovery stops being a six-week phase that produces a document and becomes continuous capture that stays active across the lifecycle. What you’re building is closer to an audit trail than a document repository, and that’s what separates a project brain from a chatbot pointed at SharePoint.
Beyond discovery: services with many owners
Discovery is only the first place a service loses its memory. The harder case is scale and time. A large service, the kind that counts as critical national infrastructure, outlives every team that touches it. Ownership moves between departments and suppliers rotate on their own cycles, so the people keeping a service running have often inherited it with none of the reasoning that shaped it. No single person holds the whole picture.
Take a licensing service that has passed through several departments and two suppliers since it launched. The check that blocks certain applications was added for a reason, but the reason lived in a policy note and a Product Manager who moved on years ago. Nobody dares remove it and nobody can explain it. Here a project brain is less a discovery aid than shared institutional memory: something that survives each handover, so an incoming team can ask why a control exists instead of guessing or stripping out something load-bearing. A decision taken in one department, under one supplier, stays legible to the next.
Why teams need one
A human analyst gets through a portion of the policy documentation and some of the research transcripts, because there’s only so much time. Agents can read all of it. Point them at a corpus of several hundred policy documents and hours of research transcripts and they surface the patterns a sampling pass would miss, in hours rather than weeks. The gain isn’t speed so much as coverage: nothing important sits unread because we ran out of time. Raw workshop findings and stakeholder inputs turn into user stories in a day.
This is where the payoff shows up over time. A developer joining in month four of a three-year programme, or a department inheriting a service it didn’t build, gets the original reasoning rather than a guess. A mandatory field that blocks progress can turn out to encode an eligibility exception from a policy that changed years ago; a project brain gives you that answer instead of a shrug. An identity service we recently built tracked more than 150 commits automatically and moved from design to developer handover on a single codebase with no handover gap. The record stayed intact as the people around it changed.
“A developer joining in month four of a three-year programme, or a department inheriting a service it did not build, gets the original reasoning rather than a guess.”
A project brain also keeps the friction, which is the part most teams get wrong. Discovery and review both surface conflict: two stakeholders who want incompatible things, a security control that fights a performance target, a user need that cuts against a compliance requirement. Summary decks smooth all of that over, because a deck wants to tell a clean story. A project brain can hold two incompatible truths at once rather than resolving them early. That’s an advantage, but only if you manage the risks below, because the same tool that can keep a contradiction can also bury it.
Where AI can only take you so far
The first risk is hallucinated consensus. Large language models are built to produce a fluent answer, and a fluent answer glosses over gaps in logic. Ask a project brain about a policy contradiction and, without the right guardrails, it will resolve the contradiction itself and hand you a tidy conclusion. What you need is for it to flag the contradiction and leave it flagged. We manage the prompts and context fed to our agents tightly to limit hallucinations, and run prompt clinics and a steering group to keep those guardrails current. That behaviour has to be designed in; it won’t appear on its own.
The second risk is that security and privacy break down without governance. Point AI agents at raw project data and they’ll ingest personally identifiable information (PII), sensitive case data, and everything else in the pile, which in a public sector context is a compliance breach. Across our most governance-sensitive public sector work, the rule was no PII in the AI workflow at any stage, with human review throughout. Curation matters for cost too: feed the brain everything and the useful signal gets buried in the dump, while token usage and overheads climb for no return.
The third risk is the illusion of completeness. A queryable brain feels authoritative: ask it anything and it answers, which can give a delivery team false confidence or a habit of leaning on it too hard. A store of documents isn’t the same as knowing your service. Give it thin or unevidenced material and it will repeat an unfounded rule back with confidence. A team that treats it as the last word rather than a starting point ends up talking to its own captured assumptions.
The fourth risk is trying to capture everything. A project brain earns its keep by holding decisions and the reasoning behind them. Capturing every conversation and making it queryable is a different thing. A total archive of every message and half-formed idea chills the candid debate that good decisions depend on, because people speak differently when they know everything is on the record. In the public sector, effective information governance is therefore essential. Anything queryable is potentially disclosable under Freedom of Information (FOI) or litigation processes. The discipline is deciding what deserves to be remembered and letting the rest go. A decision and its rationale belong in the brain. The Slack thread where someone floated a bad idea at 4pm does not.
How to build one
Start with the decisions, not the documents. Our project foundation workshops put the key people in one room (product, architecture, policy, design and user research) and force the choices into the open: what the service must do, under what rules, and how success is measured. The output is a service logic document readable by a person and by a machine, with the guardrails and decision rules written down. Most projects surface a misalignment in that session that would otherwise have cost weeks in build. Getting the decisions explicit first is what both the team and the AI need.
Then give it a structured memory. A useful project brain has a defined shape. On our AI Software Delivery Lifecycle that means a product vision; conventions recorded against architecture, code and design; assumptions logged as validated, unvalidated or unresolved; and a running knowledge base of the things that bit you. Every change, whether made by a person or an agent, is versioned. Context is kept concise and consistent, because vague or bloated context is what drives hallucination and token cost.
Govern what goes in from day one. Set the rules before the first document lands: no PII in the AI workflow, clear ownership of the guardrails, and a review cadence that looks at how the brain is being used in practice. Treat the prompts and skills that drive it as first-class code, versioned and shared in a repository. Name and tag what goes in so it stays findable as it grows; an unsearchable brain is just a bigger dump.
Keep a person in the loop at every phase. The build runs as a spec, plan, implement and review cycle, with human sign-off at each step. The brain drafts and flags; people decide.
AI surfaces insight at scale, humans call the shots
The value in delivery is moving. It used to be seen in producing the artefacts: writing the documentation, building the personas. AI can do most of that now, faster and in more detail. So the value moves to assurance and judgement: deciding what to do with what the brain surfaces. The split is deliberate: let AI do the execution and keep the judgement with people. On the identity service we built, all design and technical judgement stayed with people, and was reviewed at every stage.
That decision can’t be automated. When the project brain flags a contradiction between what a policy demands and what a user needs, someone has to choose which one wins, for the people using the service and the people building it. That’s a human call. Governed well, the brain finds the friction and the trade-offs. Resolving them isn’t its job.
Does your service need an AI-powered project brain?
A project brain processes context at a scale and depth no sampling can match, and it keeps a programme’s memory intact long after the people who made the decisions have gone. What turns that context into safe delivery outcomes is human assurance.
If you want to stand up a well-governed project brain for your services, with the guardrails and compliance built in from the start, talk to the Hippo AI team or reach out to me on LinkedIn.
