Project Navigation & the Art of Triangulation

A project is not a linear march from A to B; it is an exploration of an unmapped space. Students most often get lost not because they lack ability, but because they stop checking where they are. The literature review, treated as a chore to tick off in week 3, is actually the project's compass — and a compass is only useful if you keep looking at it.

The Concept of Triangulation

A navigator fixes a position by sighting multiple known landmarks; any single bearing leaves you somewhere on a line, but two or three intersecting bearings pin you to a point. An academic or industrial project has exactly three such landmarks:

• Your current implementation and data — what you have actually built and measured, not what you intended to build.
• The existing literature — what has been proven, built, or refuted before you started.
• The broader domain problem — the industry or theoretical need that made this project worth doing.

Check your position against only one landmark and you drift. Code-only navigation produces a technically interesting artefact that answers no question anyone asked. Literature-only navigation produces a beautifully cited plan that was never de-risked by contact with reality. Problem-only navigation produces enthusiasm and a demo that cannot survive a viva. The position fix needs all three bearings, taken regularly.

The Iterative Literature Review

The single most damaging myth in project work is the "static chapter" — the idea that the literature review is written once, early, and then preserved like a fossil while the real work happens elsewhere. Treat it instead as a living instrument:

• Every implementation snag is a literature query. When the code refuses to behave, someone has probably hit this wall before — and either documented a route around it or proven it impassable. Both answers save you weeks.
• Every scope shift invalidates part of your map. If the project pivots from CNNs to transformers, or from one dataset to another, a slice of your review is now describing terrain you no longer occupy — and terrain you now occupy is unreviewed.
• New work keeps appearing. A project spanning an academic year overlaps several publication cycles; the field will not politely wait for your submission date.

How to Re-Triangulate

When the code works: resist the temptation to sprint on. Does your result actually match the performance and claims in the literature? If your implementation of a published technique dramatically outperforms the original paper, the most likely explanation is not genius but a bug in your evaluation — a leaked test set, an unfair baseline, a metric computed differently. Agreement is evidence you are where you think you are; surprising disagreement is a navigation alarm, in either direction.

When the code fails: two hypotheses, in order:

1. You misread an assumption in the papers. Published methods carry quiet preconditions — dataset scale, hyperparameter regimes, hardware, i.i.d. assumptions. Re-read the methods section of your key sources after a failure; it is astonishing how different they look when you know what to look for.
2. You are reading the wrong branch of the literature. Fields fork. If the approaches you are following keep failing on your problem, there may be a parallel community (different venue, different vocabulary) that solved your actual problem under a different name. One well-chosen review paper from an adjacent field can re-orient an entire project.

The Discovery Log

Version control records what you changed in the code; nothing, by default, records what changed in your understanding. Keep a discovery log beside the commit log — one dated entry each time a paper, result, or conversation alters the project's direction:

## 2026-02-14 — direction shift
Read: Nakamura et al. (2025), "Sparse attention at long context"
Was assuming: full attention required for our sequence lengths
Now believe: block-sparse achieves 97% of quality at 1/8 memory
Action: evaluation plan reworked; added ablation vs. dense baseline
Affects: report §2.3 (lit review), §4.1 (method), risk register R-07

The log costs minutes and pays twice: during the project it makes drift visible while it is still cheap to correct, and at write-up time it is the narrative of your project's reasoning — the thing assessors mean when they ask for "critical evaluation" (see The Report as the System Front-End).

Triangulation as Acceptance Criteria

There is a satisfying software-engineering reading of all this: the literature review defines the behavioural boundaries of your project before deep implementation begins — what "working" means, what baselines must be beaten, what assumptions hold. That is precisely the role acceptance criteria play in behaviour-driven development, and the parallel runs deep: our article on Project Marking as BDD shows how assessors themselves can frame project quality as Given/When/Then scenarios. Write your literature review as if it were the Given clauses of your project, and re-triangulation becomes simply re-running the acceptance suite.

A Cadence That Works

• Weekly (5 minutes): skim your discovery log's last entry. Is the current week's work still pointed at the same destination?
• At every milestone (an hour): take a full three-landmark fix — implementation vs. literature vs. problem. Write the fix down.
• At every surprise (immediately): a result too good, too bad, or too weird is a bearing you didn't expect. Stop and re-triangulate before building on it.