A quick introduction before I get into the week. My name is Vedant. I'm a second-year electrical engineering student at the University of Toronto, and for the last while most of my time outside class has gone into building a startup with three friends. We make software that runs lighting at live events. It's fun work, and I've learned a lot from it, but it is commercial work. You build something, you sell it, and the measure of whether it worked is whether people pay for it.

This project is the first time I've been able to point my skill set at something where the measure is different. In the internal note I wrote for my supervisor this week, I listed three things I want out of this summer: build a tool that actually creates measurable impact for affected communities, get our findings out to a wider audience, and fulfill the Laidlaw requirements. I put them in that order on purpose. I'm also aware that I'm here because a group of people I've never met decided to fund students like me, and I don't want to waste that.

I spent the whole of Week 1 in Toronto. The Malta leg comes later. That turned out to be useful, because the first week was mostly reading, and reading is easier when nothing else is happening.

What went well

The first thing I did was set up how Alex and I would actually work together, which felt boring at the time and turned out to be one of the better decisions of the week. We agreed on weekly calls, Signal and email for everything in between, GitHub for code, and a Google Drive with folders split by purpose — reports, paper drafts, logistics, contracts, literature review, media. We agreed to run development in an agile way, in short cycles, rather than disappearing for a month and coming back with something finished. Alex works out of London and I'm in Toronto, so there's a five-hour gap. Having a shared place to put things mattered more than I expected.

Then the reading. Five things shaped my thinking this week:

• ETH Zurich's material on ACCP analysis (Actors, Context, Content, Processes). This was the simplest framework I found, and simple was what I needed. I printed two GI-TOC case studies, sat on my floor with sticky notes, and worked through them by hand using ACCP. Doing it manually first was the most valuable hour of my week. The prototype I later sketched is basically that sticky-note exercise turned into software.
• Alex's PhD thesis on studying irregular migration through crime science. It's a genuinely good example of agent-based modelling. He models the Libya-to-Malta route. My immediate thought was: if this methodology could be scaled to many more routes and many more studies, that would be enormously useful. (Side note, it has the funniest acknowledgements section I have ever read in an academic document. I'd like to know the story behind it.)
• "Anatomy of a Route," on crime script analysis of irregular migration and harm on the Central Mediterranean route. A good introduction to crime scripts. I haven't managed to work any of it into the software yet, which I'm noting so I don't quietly forget.
• GI-TOC's own case studies and yearly updates on illicit activity in the Sahel. Practically, these are excellent sample data for anything RAG-based. I read through them partly as evidence and partly as material.
• Conflict sensitivity and "Do No Harm" literature — the World Bank's Conflict Assessment Framework, and Mary Anderson's 1999 work on connectors and dividers. This was the least familiar territory for me and I think the most important. The core idea is that any outside intervention lands inside a community that already has things holding it together and things pulling it apart, and a badly designed intervention strengthens the dividers. That reframed the project for me. I came in thinking about prediction. This week I started thinking about harm.

By the end of the week I had a first block diagram on Lucid: an input stage that takes a link, PDF, text blurb or interview transcript; an intelligence stage where the model does an ACCP pass and fills four cards, tagging elements as connectors or dividers; a user check where an analyst confirms or edits the facts; then agent-based modelling and a feasibility, effectiveness and ethics pass that proposes interventions with their first and second-order impacts; then a feedback loop where an analyst changes the plan and gets a fresh forecast. The user check step in the middle is the part I care most about.

What could have been done differently

I read too widely and narrowed too late. By Thursday I had a folder of PDFs and no clear sense of which case study I was building against. I also drew the concept diagram before Alex and I had formally agreed on project goals, KPIs or success metrics. It worked out because the diagram gave us something concrete to argue over, but the order was luck, not judgement. Next time I'd ask "what does success look like" before I open the drawing tool.

What I learned about myself when working with others

My instinct is to build. When something is unclear, my body wants to open an editor and write code, because code is a thing I'm good at and reading policy literature is a thing I'm slow at. I noticed myself doing that a few times this week and had to sit back down with the reading. I think the impatience is useful in a startup and dangerous here.

What I learned about leadership

I'm the most junior person in the room by a wide margin, working with someone who has spent years on exactly this problem. There's no authority to fall back on, which means the only thing I have to offer is preparation. Turning up to the first call with a written document, a diagram and a list of open questions was worth far more than turning up with enthusiasm. Doing the homework is a form of respect.

What I want to focus on next

Read the logistics document properly. Get alignment with Alex on software and project goals. Set KPIs and a north star metric.