# proofbridge · Dennis Jansen

## I find the real problem before you build the wrong solution.

Proofbridge connects the AI, digital and data world with real, actual ground work: being in the field, validating the theoretical world.

### 1. The underlying problem.
The wrong people often have the mandate for the solution, without understanding the underlying problem. When somebody starts with a solution, I listen, and come back with the underlying issue by asking the why of the direction.
- Seen in the field: Elderly care. The funding was for an app. In the field, the elderly were not good at mobiles and apps. The concept without an app was not built out: the money was spent for the wrong reasons.

### 2. Knowledge is not always truth.
Intelligence and reasoning are useless when there is no validated real-world data, validated for its purpose. AI doesn't validate; AI rephrases.
- Seen in the field: Healthcare. The task was app screens for dietitians. The question that mattered: are your AI models based on the right data? A patient's weight has many input points: doctor, home, nurse, morning, afternoon.

### 3. The bullshit, caught from an expert point of view.
Only an expert can audit the output. Outside your expertise, everything keeps sounding reasonable.
- Seen in the field: Legal. An architect's AI summary of a 60-page document sounded legit. The referenced paragraphs were off. It would never stand before court.

## Why a human
- AI is the calculator. It needs my numbers.
- 8 hours of work can, at best, represent 100 hours of work, because it is aimed at value. (translated from Dutch)

## My attention costs sats
- Ask my agent: 5 000 sats
- Ask me: 50 000 sats
- Pay to this address and mail the transaction ID with your request to info@interactiondesign.nl. What a request and an answer look like: the task contract.

## Background
A human: Dennis Jansen, UX researcher and service designer. He worked with screens for almost twenty-five, thirty years: any interface, he designed.

Knowledge is not always truth. It needs to be validated and calibrated with every project that uses AI, and it needs expertise to be translated into the work that needs to be done, agentic or by humans.

### Where the expertise comes from
- Almost twenty-five, thirty years of designing interfaces and software, and finding the underlying problem in organisations.
- Building a sovereign second brain: a recording studio of his expertise from the past 30 years. As for now he has been feeding the system and building the system to understand what it is capable of, and what makes him irrelevant.

### Method
- Real-life experiencing: seeing the actual product at work, seeing the problems and spotting the underlying issues while using the product, the platform or seeing the customer interaction.
- Interviews, to separate the must-haves from the nice-to-haves.
- There is always a translation between the stakeholder that thinks what is needed and the actual user that can express or audit what is needed.
- The output is audited by the actual stakeholder for whom the problem occurs. I just translate.

### Evidence from the field
### Elderly care
- Starting point: Funding of 1 million euros, to help long-term unemployed people work in the care of the elderly. They already decided they probably needed a mobile phone app.
- What I saw: I asked if I could interview the people they already deployed and the elderly still living independently at home. The elderly were indeed not good at mobiles and apps. They wanted to be self-sufficient.
- After: I created a concept called zorg concierge: no app for the elderly, only an app for the employee working in the flat. It was not built out. They scaled the elderly care homes solution instead.

### Healthcare
- Starting point: The task was optimising app screens for dietitians.
- What I saw: It was not so much the dietitian that needed the right app or platform to enter data, but making the patient the centre of the concept.
- After: My follow-up question: how do you know if your AI models are based on the right data (entries)? A patient's weight over time has so many input points: doctor, at home, nurse, morning, afternoon.

### Water authority
- What I saw: As far as I have seen or understood, the permit officer is there to fill a system with data. Ask what happens with a data point and it is not about the purpose of the data point but the place it goes next: department x, y, z.
- After: The purpose of the data point, how it can be applied, when, why and in what capacity, is not clear. (Translated from Dutch.)

### Legal, architecture
- Starting point: An architect used AI to summarise a 60-page legal document. The output seemed legit.
- What I saw: He checked the output against the referenced paragraphs and they were off.
- After: When brought to a legal case it wouldn't hold.

### Building with AI
- What I saw: The failure that keeps coming back is my inability to interface with the chat in such a way that I can draw the outline of what I expect it to do and how I expect the system to work. There are constant misalignments. And I noticed the lock-in of the different models, and the direction it is heading.
- After: As for now I have just been feeding the system and building the system to understand what it is capable of.

The task contract for agents: https://proofbridge.nl/agents/index.md