Skip to content
Phase 3 Benefits
App Store deployed · Preparing for commercial launch

Phase 3 BenefitsCase study

A second brain that keeps the plan honest.

Requirements, decisions, schedule, budget and the answers given to partners for Phase 3 Benefits live in one system that rewrites itself when something changes. It exists because one person cannot hold a regulated financial product in their head, and should not try.

The problem it solves

A benefits product with a sponsor bank behind it accumulates commitments in meetings: what the card can do, when funds load, which disclosures appear where, what the partner needs before launch. Each one changes something else, and several depend on what a partner's API can actually do. In most organisations those consequences are discovered later, by whoever happens to notice.

The second brain was built so that no commitment made in a conversation can quietly contradict the plan or the partners' documentation, and so that the consequences of each decision are visible on the day it is made.

How it keeps itself true

One loop, run every time there is a new conversation. The decision step is the only place a person is asked to stop.

  1. Input

    Sponsor-bank conversations

    Calls are recorded and transcribed. The transcript is the raw material; nobody has to take notes.

  2. Extraction

    Facts and decisions

    Each transcript is reduced to the facts it established and the decisions it made, filed against the parts of the product they touch.

  3. Comparison

    Prior knowledge and partner documentation

    New facts are compared with everything already known and with the partners' documentation, including their APIs. Two things that cannot both be true, or a dependency nobody has settled, become a decision.

  4. Rewrite

    Narrative guide

    Once a decision is made in a short-lived decision screen, every affected section is rewritten and shown as a diff against its previous wording.

  5. Recalculate

    Dependency graph

    The critical path, schedule and budget are recomputed from the updated dependencies. New information updates the plan as its implications are resolved.

Back to the start with the next transcript

The comparison step is what makes the rest trustworthy. Extraction alone would only produce more notes.

What comes out of it

The same source answers the partners' questions and asks the ones nobody has thought of yet.

Answers to partner questionnaires. Sponsor-bank, processor and vendor questionnaires are answered from the source of truth rather than from memory. What a partner is told is what the plan is built on, and when the plan changes, the answers that depend on it change with it.

Genuinely novel questions. Because the graph knows what every section depends on, the system raises questions nobody has asked: a gap between a commitment and the API it relies on, or between two partners' assumptions. They surface before the meeting where they would otherwise have become a surprise.

What a review looks like

Every decision leaves the same record, reviewed in the same order. Nothing is accepted into the plan without passing through it.

What came in
The fact or decision, and the conversation it came from.
What it was compared with
The prior knowledge or partner API documentation it agrees with, contradicts, or leaves a gap against.
The decision
Made once, in a decision screen that exists only until it is answered.
What was rewritten
Each affected section of the narrative guide, as a diff against its previous wording.
What moved
Critical path, schedule and budget after the dependency graph recalculates.
What else changed
Partner questionnaire answers that depend on it, and any new question the change raises.

Every commitment made in a meeting is in the plan the same day, with its consequences attached.

That is what lets one person run product, engineering and compliance for a regulated product without the plan going stale underneath them. The point is not automation.

If you are about to do this

  1. Capture decisions where they are made, not where they are written up.

    The transcript is the record. Anything that relies on someone remembering to update a document will drift.

  2. Build the comparison before the summariser.

    Extraction without a comparison against prior knowledge and partner documentation produces a tidy pile of contradictions. The comparison is the product.

  3. Show changes as diffs and attach the consequences.

    People trust a rewrite they can see. They act on one that tells them what it did to the schedule and to the answers already given to partners.

Need a leader who can
build with AI?

Let's talk about the product challenge, the team, and the outcomes you need—whether you're improving how your business runs or building something new.