Report structure, confidence scoring, and a full worked capstone example.
Every chapter before this one builds collection and analysis skill. This final chapter is the most important and the most often neglected: turning a pile of findings into a report that someone will actually read, trust, and act on. The Intelligence Cycle from Chapter 2 is worthless without intelligible reporting — if you can't give a reader, regardless of their technical background, a coherent and complete picture, you've failed as an analyst, no matter how good your collection was.
Real investigations rarely produce one clean thread — you'll often end up with several partially-developed leads competing for your limited time before a deadline. A simple, fast triage: score each lead on three axes — Credibility (how much do you already trust this lead's source and evidence), Urgency (does the value of this lead decay if you wait), and Impact (how much does this lead actually matter to the questions you set out to answer, back in Chapter 2's Planning phase) — and work whichever leads score highest across all three first.
Just as important as ranking what you will act on: explicitly name what you're deliberately not pursuing, and why, rather than letting weak leads quietly consume time by default. A short "leads not pursued" line in your working notes (not necessarily the final report) protects you later if someone asks why you didn't chase every possible thread, and stops you from anchoring on whichever lead you happened to encounter first. When two leads don't just compete for attention but actively conflict with each other, that's a different problem — see the contradictory-sources framework in Chapter 13, §13.4.
Borrowed from journalism: lead with the most important information (executive summary/BLUF), then supporting detail, then the least critical material (appendix/index) — the opposite of how an academic paper is structured, deliberately, because the reader of an operational report rarely has time to read everything.
Compare: "We are researching the overall effectiveness of OSINT within government" (no analysis, pure description) versus "Government struggles to implement OSINT effectively" (active, persuasive, with a clear takeaway). The second version drives the reader toward a conclusion; the first just logs an activity. A good OSINT report is written with an active, persuasive, analytical tone — but never in absolute terms where the evidence doesn't support it: write "it is highly likely this email belongs to the subject," not "we found the subject's email," unless your evidence is genuinely that strong.
Use the NATO Admiralty Code (Chapter 2) and the confidence levels — Low/Medium/High/Confirmed — introduced in Chapter 4. Every finding in a serious OSINT report needs an explicit confidence level and the reasoning behind it. A report that states only a final verdict with no reasoning or per-finding confidence does not meet a professional bar, regardless of whether the final conclusion happens to be correct.
One of the most instructive traps in identity investigations: two independent signals that appear to converge on the same conclusion might just be coincidence — a namesake in a completely unrelated profession or city who happens to match one piece of data. The correct habit is to acknowledge this possibility explicitly in the report — to show you considered the "innocent explanation" and explain why you ruled it out (or why it remains possible). A report that ignores the possibility of a false positive entirely is weaker than one that names it and disproves it with evidence.
A clean, organized, readable layout matters — a report with inconsistent fonts and spacing risks burying its own key points. Think about the reader first: a CEO needs a different format from a law-enforcement recipient or a private client. Use readable colors (blues, greens, black) and consistent font pairings. Divide sections with bold headers or a divider line. Number figures and tables, cite sources (APA/MLA/footnotes). Title the report briefly but descriptively, and always date it.
Good reporting starts long before you write the first sentence — it starts with disciplined documentation throughout collection. Good habits: assume your notes will eventually be shared; include captioned screenshots; record every URL and source; defang or disable links to source pages in shared notes; use tables to organize your selectors; document your process and pivoting steps; record dates and times; and articulate what you did and how, not just what you found.
Before the walkthrough itself, a condensed checklist for opening a case like this one — five angles worth checking from the start, each pulling on a technique already covered elsewhere in this manual: the claimed email/identity (Chapter 4), any attached photo (Chapter 6), username reuse across platforms (Chapter 4), the overall social/professional footprint (Chapters 5 and 9), and whether the specific claims match the public record (cross-checked against registries, filings, or independent reporting, as in Chapters 9 and 12). None of these five is individually new — the value here is having them as one short list to open with, rather than reasoning out which techniques apply from scratch each time.
This is a real capstone-style investigation: verifying whether a job applicant's claimed background is genuine.
Tasking: determine whether the applicant's identity is genuine or misleading.
BLUF: The candidate's claimed identity is misleading/fabricated. The subject's digital footprint was created entirely within a two-month window to manufacture a cybersecurity persona, while older, unrelated accounts sharing the same name belong to a graphic designer in a different city. Overall confidence: High.
Claims tested: name, location, "10+ years security experience," a specific past employer, and a professional web portfolio — each with its source (application, CV, public profiles) recorded in a table before any finding is written.
Independent agreement: the professional-network account creation date, the code-hosting account creation date, and the portfolio domain's registration date (Chapter 9) all independently point to the same narrow window — strong, mutually-reinforcing evidence, not a single data point stretched too far. Innocent explanation considered and rejected: a sparse professional profile could theoretically belong to a genuinely secretive practitioner — but that explanation doesn't survive contact with someone actively applying for a public corporate role using an attached public portfolio link and zero code contributions; the behavior is inconsistent with the claimed profile. Correlation vs. coincidence, made explicit: the older, unrelated design-industry accounts sharing the name are exactly the kind of false positive Section 15.6 warns about — they prove a different real person exists with that name, which the applicant appears to be either accidentally or deliberately overlapping with to borrow the appearance of seniority.
Misleading/fabricated identity. Overall confidence: High. Recommendation: reject the candidate; request formal identity documentation if a legal confirmation is required before formal rejection.
All research was conducted passively, without contacting the applicant or interacting with his profiles. Professional-network and code-hosting profiles were viewed logged out, or through an isolated investigative browser session, specifically to avoid passing referrer headers or triggering profile-view notifications (Chapter 14). Attached files (the email and the headshot image) were analyzed in an isolated virtual-machine environment, without opening any external links on a primary machine.
Notice how every technique from earlier chapters shows up here doing real work: email forensics and username enumeration (Chapter 4), domain registration timing (Chapter 9), confidence scoring and false-positive awareness (this chapter and Chapter 2), and OPSEC discipline throughout the collection process (Chapter 14) — this is what it looks like when the whole manual comes together on one real case.
Everything else in this chapter is about analyzing what you've already found regarding a specific target. A different, complementary analytical skill is watching for the first indicators that something is starting to develop, before it becomes obvious — the difference between confirming a known problem and noticing the early signs of an emerging one.
A weak signal is a small, easy-to-dismiss data point that only becomes meaningful in hindsight, or in combination with other small data points — individually ambiguous, collectively suggestive. The practical discipline has three parts. First, timeline-based tracking: log small observations with dates as you encounter them, rather than only noticing a pattern in retrospect — this is the only way to tell whether a cluster of minor signals is actually accelerating or was just noise you're pattern-matching after the fact. Second, treat repetition and clustering, not any single data point, as the actual signal — the same "one post proves nothing, a pattern across time is what matters" logic already established for pattern-of-life analysis in Chapter 5 and for verification in Chapter 13, now applied to spotting an emerging situation rather than confirming an existing hypothesis. Third, be explicit about the false-positive cost: because weak-signal analysis by nature works from incomplete information, communicate an early-warning finding with appropriately hedged confidence — tying directly back to this chapter's own confidence-scoring discipline in §15.5 — rather than either overstating an early hunch as a confirmed finding, or dismissing a genuine pattern because no single piece of it looks alarming alone.
Chapter 16 §16.2 walks through one domain-specific application of exactly this weak-signal logic — tracking escalating language and narrowing social engagement as early radicalization indicators — so you can see this as a general analytical skill with at least one worked specialty application elsewhere in this manual, not an isolated concept.
For exercise 1, the most common failure is writing a confident verdict with no stated confidence level at all — force yourself to include the word "confidence" and a level explicitly, every time, even in a two-sentence exercise answer. That habit, more than any tool in this manual, is what separates an amateur write-up from a professional one. For exercise 4, resist the urge to cherry-pick only the moments that look obvious in hindsight — the exercise is more honest, and more useful, if you also note which early moments were genuinely ambiguous at the time, since that's the realistic experience of weak-signal analysis as it's actually happening, not after the outcome is already known.
If you take one thing from this entire manual, let it be this: OSINT is not the collection of tools you happen to know. It's the discipline of Hypothesis → Collection → Verification → Correlation → Report, applied honestly to what your evidence actually proves. The tools will change — many will have already changed by the time you reread this chapter — but that discipline won't.