Challenge 2: Consistency and Control¶
Recap:
In Challenge 1, you built the core of your application. It works. But you probably noticed: every time you asked AI to build something similar, the result came out a little different. The approach drifted. The styling was inconsistent. And the backlog of things you want to build kept growing.
Then in Lesson 2, you got three tools to fix that:
- Decomposition: you broke your backlog into independently shippable story-sized pieces, each with its own acceptance criteria. The pile of work became a managed list.
- Skills: you built your first skill, capturing a repeatable process as reusable instructions that AI follows consistently. No more re-explaining the same conventions every conversation.
- Manual review: you reviewed your Challenge 1 output against specific acceptance criteria and made pass/fail calls. You saw the difference between "looks good" and "AC 3 fails because..."
You also saw the honest tradeoff: manual review works, but it's slow. You'll deal with that tension later. For now, you have the tools to build with consistency and verify with discipline.
The Challenge¶
Your vessel traffic display and sanctions screening are working. Now add depth. In Challenge 1, you identified which vessels are sanctioned. In Challenge 2, you investigate whether those vessels (and others) are behaving suspiciously. Use skills to encode your team's repeatable processes (decomposition, domain research, code review patterns) so AI follows them consistently across conversations. Use your decomposed backlog to work systematically through analytical features. And review every feature against specific acceptance criteria before moving on.
The goal isn't just more data on screen. It's turning raw data into analytical findings the analyst can act on.
Delegate one story at a time. Review against your criteria before starting the next.
New Data Sources¶
Challenge 2 introduces two additional data files from your repository:
-
AIS gap events (
ais-gap-events.json): Global Fishing Watch is a nonprofit organization whose mission is to advance ocean governance through transparency. Among other things, they track when and where vessels disable their AIS transponders using their publicly available Events API. Each gap event records where the vessel went dark, where it reappeared, how far it traveled, and whether the disabling was classified as intentional. Events also include the vessel's full identity history: every name and flag it has used over time. Your repository includes a curated set of gap events so you don't need to register for an API account. Ask your AI coding assistant to explain what these events mean and how an analyst would use them. -
Vessel profiles (
vessel-profiles.json): Equasis is a public database maintained by a consortium of maritime authorities that provides vessel ownership, insurance, classification society, and inspection history. Dark fleet vessels show a recognizable pattern: no P&I insurance (Protection & Indemnity, the maritime equivalent of liability insurance) from recognized clubs, withdrawn classification, shell company owners, and frequent name or flag changes. Legitimate commercial vessels show the opposite. Your repository includes manufactured profiles modeled on Equasis data for key vessels in your traffic data, designed to give you clear contrasts between clean and suspicious vessels to uncover.
These are new areas of the domain. Before jumping into building, take the Explore step: "What are AIS gap events and why do they matter for sanctions analysis? What does a vessel's insurance and classification status tell an analyst about whether it's operating legitimately?" Then explore the actual data: "Walk me through the gap events and vessel profiles files: what fields are available, and how do they connect to the AIS and OFAC data we're already using?"
What to Build¶
Items are listed in priority order. If time is tight, focus on the items near the top first.
- Decomposed backlog driving the work: your team is working from the breakdown you created in Lesson 2, picking up analytical features in order, not just building whatever comes to mind
- Gap event history: when the analyst investigates a vessel, they can see whether it has a history of disabling its AIS transponder: how many times, for how long, and whether the gaps were classified as intentional. A vessel with one gap may have had an equipment failure. A vessel with repeated intentional gaps across multiple voyages has a pattern.
- Manual review applied to every feature: your team can point to specific acceptance criteria that passed or failed during the challenge, with specific fix requests for failures
- Vessel legitimacy assessment: when the analyst views a vessel, they can see indicators of whether it is operating legitimately. Does it have P&I insurance from a recognized club? Is its classification society an IACS member? Has it changed its name or flag multiple times? The contrast between clean and dark fleet profiles is itself an analytical signal.
- At least one additional analytical feature added, delegated as a user story with acceptance criteria and verified before moving on
These are options for teams that finish the baseline capabilities. Your team can also define your own stretch goals based on what interests you. Use the Explore step to brainstorm: ask your AI coding assistant about the analyst's workflow, what they watch for during different scenarios, and what would make their triage faster. If you finished Challenge 1 without completing all its stretch goals, consider going back to pick up features from that list as well.
- Skills for your team's processes: beyond your decomposition work, consider creating skills for other repeatable processes your team uses: a domain research skill that guides AI to investigate unfamiliar maritime concepts using authoritative sources, or a code review skill that reminds AI to check for data-handling consistency across your cross-referencing features
- Identity history timeline: the analyst can see a vessel's full history of name changes, flag changes, and ownership transfers in chronological order, revealing reflagging and renaming patterns
- Cross-reference summary: for each vessel, the analyst can see a consolidated view showing what every data source says about it: AIS status, OFAC match, gap history, profile findings. Think about how to bring all of these signals together in a way that supports the analyst's triage workflow.
- Behavioral pattern detection: surface vessels that exhibit combinations of suspicious indicators (OFAC match plus intentional gaps, or no insurance plus multiple name changes) to help the analyst focus on the highest-priority targets
Tips
- Explore before you build. Gap events and vessel profiles are new territory. Before writing a user story for these features, use the Explore step to understand the domain: what does an intentional AIS gap look like? Why does insurance status matter? What does a shell company ownership structure look like? The better you understand the analyst's world, the more useful your features will be.
- Create skills for your team's processes, not application logic. A skill works best when it encodes a repeatable workflow: how to decompose a feature, how to research a new domain concept, how to review code for consistency. Application logic (data lookups, matching algorithms) belongs in your code, not in a skill.
- Watch for "it works" vs. "it's organized." AI optimizes for making things work right now. After each feature, ask: "Is there any duplicated logic or inconsistency you'd clean up before adding more features?" Catching this now is easier than untangling it later.
- Review is not optional; it's the quality gate. When you finish a feature, pull up the acceptance criteria and walk through them. Pass or fail. If something fails, write a specific fix request: "AC 2 fails: expected [X], got [Y]."
- Watch for side effects. When you add a new cross-referencing feature, spot-check that existing features still work. If adding gap history breaks the sanctions display, that's the tension Lesson 2 warned you about.