I flew Toronto to Frankfurt to Malta. The Frankfurt leg was overnight, and I had a five-hour layover on the other side, which I spent in a terminal seat rereading my own requirements document and quietly deciding that most of it was wrong.

What went well

I met the team. Alex introduced me around the office on the first morning — Matt, Tasnim, Mark and others whose names I wrote in my notebook. Everyone was warmer about it than they needed to be with a second-year undergraduate showing up with a half-working prototype. By the end of day one I had office keys and a desk of my own. That sounds small. It did not feel small. Three weeks of working alone in Toronto, and suddenly there was a room where the work belonged.

I also met Alisa, another Lester B. Pearson and Laidlaw Scholar who happens to be in Malta this summer. We got coffee and it was the strangest kind of relief, talking to someone who understood both halves of this without needing either explained. We're on completely different projects, so most of what we talked about was the shape of the experience rather than the content, and that turned out to be exactly what I needed after a week of trying to describe this to people back home.

The core of the week was conversations. I booked coffee chats with as many analysts as would say yes, and I deliberately ran them as Mom Test interviews rather than demos. The rule I set for myself was simple: don't describe the tool, don't ask whether they'd use it, and don't ask any question that starts with "would you." Ask what they actually did last week. Ask what took the longest. Ask what they had to redo.

That constraint was hard to hold to. I had a working prototype in my bag and every instinct told me to open the laptop and show it. I managed to keep it shut for the first four conversations, and those four were worth more than everything I had built to that point.

Some of what came out of them:

• Nobody described their problem as prediction. Not once. When I asked what took the longest, the answer was almost always some version of finding things again — the report from eighteen months ago that had the detail they now needed, the thread where someone had already worked out who controlled which stretch of road. The knowledge exists. Retrieving it is the tax.
• The trust threshold is much higher than I had assumed. An analyst putting their name on a piece of published research is staking their credibility on every claim in it. A tool that is right most of the time and confidently wrong occasionally is worse than no tool, because the cost of the rare error lands on a person, not on a system.
• The traceability constraint I wrote in Week 3 as an ethical principle turned out to also be the adoption requirement. Two separate people, unprompted, said some version of: if I can't see where it came from, I can't use it. I had thought of source-linking as the responsible thing to do. It's also the only version anyone would touch.
• And my open question from last week got answered. "Useful to whom" is the researcher writing the piece, not the donor and not the policymaker. Those are downstream readers of the output, not users of the tool. Getting that wrong would have cost me the rest of the summer building the wrong interface.

I also sat with the actual material — the cases and incidents the team works through week to week. I'm going to be careful here, because a lot of it is not mine to describe. What I can say is that reading how a route shifts after an enforcement action, in real reporting rather than in a framework, does something that no amount of literature review does. The four structural features I listed in my requirements document last week — fragmented authority, crime adapting to suppression, migration income being tied into local livelihoods, effects surfacing late — stopped being bullet points. There were dates attached to them, and places, and consequences for people who had no say in any of it.

The lag one hit hardest. In a document, "effects unfold over time" is a line. In the reporting, it's the gap between an intervention being called a success and the harm becoming visible, and the gap is long enough that the two rarely get connected by anyone.

On Saturday I took the bus up to Mdina. The old walled city, up on the hill, that people call the Silent City. I walked the lanes for a couple of hours mostly without a plan. It's very quiet inside the walls once the day-trip crowds thin out, and the thing that stayed with me was how much of what I was looking at was built by people responding to threats arriving across the same stretch of water this office now studies. Different century, same sea. I don't want to over-read a nice afternoon into a profound insight. But it was the first time all week that I stopped thinking about the tool and thought about the place.

What could have been done differently

I should have come earlier, or found a way to have some of these conversations remotely in Weeks 1 to 3. Three weeks of solo building produced a prototype aimed at a problem the users don't have. Nothing I built is wasted, but the ordering was backwards, and it was backwards because talking to people is uncomfortable and building is comfortable.

I also broke my own rule in the last two conversations of the week. I opened the laptop, showed the prototype, and immediately the conversation changed from what they do to whether my thing is good. Both people were polite about it. Politeness is not data. I could feel the quality of the information drop in real time and I kept going anyway, because I wanted to hear that it was good.

What I learned about myself when working with others

I'm more attached to my own work than I would like to be. The moment I opened the laptop was not a strategic decision, it was a need for reassurance, and I recognised it as it was happening and did it anyway. Worth knowing about myself.

I also noticed that I default to talking when I'm nervous. In the first couple of chats I filled silences that I should have let sit. By the fourth I'd worked out that if I waited five seconds after someone finished a sentence, they usually kept going, and the second half was better than the first.

What I learned about leadership

The main thing is about proximity. I've spent this project trying to design for people whose realities I was reading about at one or two removes. This week collapsed some of that distance for the analysts, and it did not collapse it at all for the communities in the reporting, who remain the group most affected by all of this and the group furthest from the room. Being honest about that gap feels more useful than pretending a week in Valletta closed it.

The second thing is that a good question is a leadership act. I had no authority in that office and nothing to offer except attention. Asking someone what their last week actually looked like, and then shutting up, got me further in five days than three weeks of building did. It also, I think, earned more trust than a polished demo would have.

The third is smaller and more practical. Handling sensitive material carries obligations that don't get spelled out. Nobody sat me down and gave me rules about what to repeat and what not to. You work it out from how people around you talk, and from the fact that the material describes people who are not in a position to consent to how it's used. That's a cultural norm rather than a written policy, and picking it up correctly is part of being a useful person in the room.

What I want to focus on next

Rebuild the retrieval and traceability layer as the core of the tool rather than as a feature attached to the side of it. Apply the framework to the Agadez case. Get the same analysts I spoke to this week to break it, and then write down what they broke rather than what they liked.