This was the week the project stopped being a reading list and became a piece of software with a shape.
What went well
I wrote an engineering requirements document, built on the project report Alex had sent across, with the leaf nodes mapping directly to features. The point was to make the development work legible to both of us and to give him something specific to disagree with.
Writing it forced three decisions I had been avoiding.
The first was scope. My original proposal talked about the North Sahel broadly, which sounds ambitious and is actually a way of not choosing. The requirements document narrows the problem to Libya, where the Libyan government, donors and the EU are all actively trying to curb irregular migration, and which sits as a central node in organised immigration crime. Four structural features make interventions there prone to going wrong, and I found writing them out clarifying:
- Fragmented authority. Control is spread across state, militia and criminal actors, so there isn't one lever to pull.
- Crime adapts quickly. Suppression tends to displace activity rather than remove it.
- Migration and livelihood are coupled. Migration-related income is woven into local economies, so disrupting the route disrupts households.
- Effects unfold over time. A lot of the harm surfaces later, in the lag between the action and the consequence, which is exactly where it escapes notice.
The gap follows from that: the information needed to anticipate first and second-order effects already exists in field reporting, it's just scattered. There's no consistent way to think through displacement, protection consequences, or the risk of strengthening the wrong actors. So the need is a tool that pulls fragmented field data together and suggests plausible first and second-order effects of a proposed intervention, under stated assumptions about timeframe, resources and target outcome.
The second decision was constraints, and these are the lines I feel most strongly about:
- Pre-intervention only. This is a research and analysis tool used before a decision. It is not a real-time or operational targeting system, and it never becomes one.
- No black-box output. Every result traces back to source data and an explicit line of reasoning.
- Human-in-the-loop validation. An analyst reviews and verifies before anything is used.
- Grounded in evidence. Behaviour comes from field data and historical precedent, not from the model's intuition.
The third was measurement. I wrote out four objectives with metrics and targets: analyst usefulness and trust rated on a 1–5 scale with a target mean of 4 or better; at least 3 of 5 proposed interventions judged plausible and decision-relevant by an analyst; at least 80% of claims and ACCP fields traceable to a cited source; and recall against the documented effects of a known Libyan intervention case, where the tool should surface the majority of what actually happened. That last one is the one I care about. It's the Do No Harm principle turned into something that can fail a test.
I also mapped the stakeholders honestly, which was uncomfortable in a good way. GI-TOC is the owner and primary user. The EU is the donor and policy driver. The Libyan government commissions and implements. The Libyan police are an enforcement actor whose behaviour the model represents. Field analysts are the direct end users and the human verification step. And then, at the bottom of the table, migrating individuals and migration-prone communities, who are not users at all. They are the people whose harm, displacement, livelihoods and stability are the output variables. They will never see this interface. Writing that row was the moment the stakes stopped being abstract.
And I built Prototype v1. It takes a source document, runs an ACCP pass, populates the four cards, tags elements as connectors or dividers, links each field back to where it came from, and stops for a human to confirm or correct before going any further. It is rough and it is slow and about a third of the source links are wrong. But it does the thing I sketched on Lucid in Week 1, and I could put it in front of someone.
What could have been done differently
I spent longer on the interface than I should have this early. The gamified, Democracy 3-style view for interventions is a good idea for later and a distraction for now, because the quality of the extraction is what determines whether any of the downstream analysis is worth anything, and a nice interface makes bad extraction look trustworthy. That's the opposite of what I want.
There's also a note in my own requirements document, in the metrics table, that says "analyst usefulness (to who?)". I wrote that question to myself and then left it in rather than resolving it. Useful to a GI-TOC researcher, a donor, and a policymaker are three different targets with three different failure modes. I'm taking that question to Malta rather than answering it alone in Toronto.
What I learned about myself when working with others
I enjoyed writing the requirements document far more than I expected. I had assumed the specification work was the tax you pay before the interesting part. It turned out to be where most of the actual thinking happened, and the code afterwards was comparatively mechanical.
I also caught myself writing the document to justify what I had already decided to build, rather than to test it. I rewrote the problem statement once I noticed. I don't think I fully fixed it.
What I learned about leadership
Writing something down and sending it to someone who knows more than you is a small act of exposure, and it's the most useful thing I've done so far. A vague plan can't be corrected. A specific one, with numbers and targets in it, hands the other person the ability to tell you you're wrong. Alex's sharpest feedback has always come in response to my most specific documents.
The other thing: putting constraints in writing before there is any pressure on them is the only time it's easy. Nobody is asking me to make this a real-time system today. Deciding now, while it costs nothing, is the whole point.
What I want to focus on next
I fly to Malta next week for on-site validation. The goal is to get the framework in front of GI-TOC analysts and test it against real cases rather than against my own assumptions. I want to come home with the "useful to whom" question answered by someone other than me, and with a list of everything the prototype got wrong.