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 idea of "triangulating" against sources with independent origins to fix a position is itself a borrowed one — it comes from research methodology, where combining independent methods or data sources is used to check a finding rather than trust any single one of them [1]. Applied to a project rather than a single measurement, the same discipline of cross-checking against independent evidence turns out to describe the literature review's real job.

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.
graph TD L1["Your implementation
& data"] --- P(("Where the
project actually is")) L2["The literature"] --- P L3["The domain problem"] --- P style P fill:#FFC857

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). It is also, in its own right, the single most valuable habit for treating your working process as an asset rather than an afterthought — see Process Over Product.

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.

The Literature as Scaffolding, Not Just a Landmark

There's a second, complementary way to think about the literature landmark beyond "a bearing to check position against": a well-chosen source doesn't just tell you where you are, it can lift you toward what you couldn't yet do alone. That's the idea of the zone of proximal development — the gap between unaided and supported performance — and of scaffolding as the temporary, fading structure that closes it [2] [3]. A paper solving a nearby problem is exactly this kind of scaffold when it's read for understanding rather than copied for content — and the same distinction applies, more sharply, to how you use a GenAI assistant while navigating a project. See Scaffolding, the ZPD, and Using GenAI Well for the full argument, including a practical check for whether a given use of AI is scaffolding your understanding or just replacing it.

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.

References

  1. Jick, T. D. (1979). Mixing qualitative and quantitative methods: Triangulation in action. Administrative Science Quarterly, 24(4), 602–611. https://doi.org/10.2307/2392366
  2. Vygotsky, L. S. (1978). Mind in Society: The Development of Higher Psychological Processes. Harvard University Press.
  3. Wood, D., Bruner, J. S., & Ross, G. (1976). The role of tutoring in problem solving. Journal of Child Psychology and Psychiatry, 17(2), 89–100. https://doi.org/10.1111/j.1469-7610.1976.tb00381.x