Pattern of Life from Socials

Pattern-of-life analysis turns scattered public posts into a model of where someone is, when, and with whom. It is the most abusable technique in this repo: the same method produces a due-diligence report and a stalking dossier. The difference is authorization and scope, not tradecraft. The beginner error is collecting posts instead of analysing them — screenshots of a feed are not intelligence. Work four layers: account metadata, network, content, temporal behaviour. The first and last are the two everyone skips, and the two the subject can't curate.

Step 1 — Authorized scope

Read ../../ETHICS.md, then write down before opening a single profile:

• Subject — the account(s) and the real-world entity you believe is behind them.
• Objective — the question that ends the investigation. "Pattern of life" is not one. "Does this vendor's EU lead actually live in the EU" is.
• In / out of bounds — explicitly. Minors, uninvolved family, home address, health, religion, sexuality and immigration status are out unless the objective requires them and you can defend that.
• Posture — observation only, or authorized interaction. Following, liking, messaging and viewing stories are all interaction.
• Jurisdiction — yours, the subject's, the platform's.
• Stop condition — you stop when the objective is answered, when the trail lands on an uninvolved third party, or when the only question left is "where do they sleep."

Done when all six are recorded in the case file.

Step 2 — Choose a viewing identity, then preserve

Logged-out leaks less and sees less; logged-in sees more and leaks more. Platforms variously report story views and profile visits to the subject, and recommendation systems surface accounts that look at each other — so merely viewing can put your research account in the subject's suggestions. Decide the tradeoff using investigate-without-getting-made; never browse a subject from a personal or employer account.

Then capture before you analyse. Accounts get locked or scrubbed mid-investigation, often because someone noticed. Archive the profile and every post you may cite via read-deleted-pages, and pull older snapshots — they routinely show a previous bio, link, or handle. Save media locally.

Done when the viewing identity is recorded and everything you intend to cite exists as an archive URL or a local file with a capture timestamp.

Step 3 — Layer one: account metadata

Go after what the subject never chose. Full per-platform behaviour is in the platform disclosure matrix (reference/platform-disclosure.md).

• Creation date. Shown outright on some platforms, derivable on others. Snowflake-style 64-bit IDs encode a millisecond timestamp in their high bits, offset from a platform-specific epoch — the ID is the signup time. Plain sequential IDs give registration order, so you can bracket a date against accounts of known age.
• The numeric ID. It survives handle changes, so it — not the handle — is the durable selector. Record it.
• Handle history. Seldom a feature, usually recoverable from old mentions, inbound links, archived snapshots and abandoned cross-posts. A freed handle can be reclaimed by a stranger, so an old link proves nothing about current control.
• Verification and linked accounts. Whether a badge is paid or identity-checked changes what it's worth. Linked sites and business-account contact fields expose emails and phone numbers the personal profile wouldn't.

Done when ID, creation date, handle history and every linked selector are recorded with sources.

Step 4 — Layer two: network

A subject's OPSEC is nearly irrelevant if their relatives tag them.

• Early followers. The first accounts to follow a personal account are overwhelmingly family, school friends and coworkers — it spread by word of mouth before it had reach. Where follower ordering is observable, the oldest tail is the highest-value segment on the page.
• Mutual-follow clusters. Reciprocal edges map real-world communities: employer, school cohort, hometown, club. The cluster is the finding; a single edge isn't.
• Tag direction. Who the subject tags is curated. Who tags the subject is not. Inbound tags from an open-book cousin routinely deliver the birthday, the house, the car and the workplace the locked-down subject withheld.
• Reply latency. Accounts that reliably comment within minutes are the inner circle, regardless of follower counts.

Build this in graph-the-network, not as a list.

Done when the inner circle, one real-world cluster, and the third parties who leak about the subject are identified and graded.

Step 5 — Layer three: content

Read past the subject of each photo to the accidental content: reflections in windows, mirrors, glasses and dark screens; laptop and phone displays in frame; paperwork such as boarding passes, parcel labels and event badges; vehicles, plates, dealer frames and parking permits. Repeated backgrounds are what upgrade a room from "somewhere" to "home" or "workplace" — count occurrences and note the date span.

Run secrets-in-file-metadata on everything you downloaded: platforms differ in whether they strip EXIF, and the same platform may strip it from an inline image while preserving it in a file attachment or an original-quality download.

Do the geolocation itself in geolocate-from-pixels. Sanity-check anything that looks too convenient with is-this-photo-real.

Done when each location-bearing artefact is logged with post URL, date, and a pointer to the geolocation work.

Step 6 — Layer four: temporal behaviour

Extract every post timestamp into a table and plot hour-of-day and day-of-week. The extraction schema is in the analytic checklist (reference/analytic-checklist.md).

A contiguous gap of roughly seven to nine hours is the sleep window, and its position gives a UTC offset — enough to separate continents, not neighbours. A weekday dip through business hours suggests employment with restricted device access; the inverse suggests shift work or a job spent online. Sudden multi-day offset shifts are travel.

What wrecks this: scheduling tools post at fixed wall-clock times regardless of where the human is, so a scheduled account measures the scheduler; platforms may render timestamps in the viewer's locale; edits can carry the edit time; and cross-posting bridges or shared team accounts blend several humans into one histogram. Establish that posting is manual before reading anything into shape.

Done when both distributions exist over a stated sample window, with an explicit inferred UTC offset and its confidence.

Step 7 — Consolidate and report

Link accounts on evidence: the same avatar file, the same link-in-bio target, follower-set overlap, aligned histograms. Writing style alone is a lead, not a link. Then run write-the-intel-brief. Every claim cites a post or archive URL and a date; every temporal conclusion states sample window and sample size.

Done when no claim lacks a citation and no inference lacks a grade.

Where this goes wrong

• Sample bias. You're reading a self-published subset of a life. Silence means "didn't post," never "wasn't there."
• Backdating. A post date is an upper bound on the event date. Photos get posted months late, reposted, or lifted from someone else entirely.
• The account is not the person. Handles are sold, inherited, hacked and recycled; a long history may have changed hands. Partners, assistants and agencies post as the subject — two behavioural signatures in one histogram usually means two humans.
• Curated self-report. Location, job title and relationship status are marketing copy, and a common name plus a matching city is a coincidence generator, not a match.
• Rendering differences. Timestamps, follower ordering and mutual indicators change with login state, and are often approximate ("2h", "last week") rather than exact.
• Observation changes the subject. One who locks down mid-case may have been tipped off by you.

Grading a finding

• Confirmed — an authoritative record or the subject states it, or two independent artefacts of different types agree (an inbound tag from a separate account plus a geolocated background). Both archived.
• Probable — several consistent signals of the same type, or one strong signal with nothing contradicting it: a repeated background plus a temporal pattern consistent with living there.
• Unconfirmed — single-source, self-reported, style-based, or drawn from too small a sample. A timezone from a few dozen posts or fewer is unconfirmed, full stop.

Downgrade anything resting on an assumption you can't state in one sentence.

Worked example

Objective: confirm a supplier's "EU operations lead" is in Europe, as the contract requires.

Bio says Lisbon. The numeric ID decodes to a signup years before the company existed — so the bio says nothing about the present. Four months of timestamps cluster 14:00–05:00 UTC with a dead zone 06:00–13:00: a sleep window centred near 09:00 UTC, wrong for Lisbon, consistent with the Americas. Dead end: no geotags anywhere, and the platform stripped EXIF from every download.

The network layer breaks it. Early followers cluster around one US state university, and a relative tags the subject at a named local restaurant on a date the subject publicly claimed to be in Portugal; a repeated kitchen background appears on both sides of that date. Graded probable — no authoritative record places the subject anywhere, and a histogram can't separate adjacent countries. Reported with the sample window stated.

Pivots

Legal and ToS

Automated collection of profile and follower data breaches the terms of service of essentially every major platform and has been litigated as a computer-misuse matter in some jurisdictions; manual viewing of public content generally has not. Creating an account to view a subject is at minimum a ToS problem, and a fraud problem if you misrepresent identity to gain access.

Under GDPR and comparable regimes "publicly available" is not itself a lawful basis, and profiling a person's location and routine is high-risk processing. Political opinion, health, religion, sexuality and union membership are special categories — if they surface incidentally and aren't in scope, don't record them. And the one that matters: sustained monitoring of an individual's location and routine meets the statutory definition of stalking in many jurisdictions, and sourcing it publicly is not a defence. Authorization, a written objective and a stop condition are what make this work lawful.

---

Supporting file: reference/analytic-checklist.md

Pattern-of-life analytic checklist

Work top to bottom. Every line either produces a recorded artefact or gets marked "not available" with a reason. A blank is not the same as a negative finding, and six months later you won't remember which it was.

Layer 0 — Case setup

• Subject, objective, in/out of bounds, jurisdiction and stop condition written down and dated.
• Viewing identity chosen and its exposure documented.
• Evidence store created: one folder per platform, capture log with UTC timestamps, hashes of downloaded media.
• Collection window declared (e.g. "posts from the last 18 months"). State it in the brief; every temporal conclusion depends on it.

Layer 1 — Account metadata

• Profile URL, captured and archived.
• Handle, exactly as spelled, including case and separators.
• Display name, and any prior display names visible in archives.
• Numeric / immutable account ID.
• Creation date — stated, decoded from ID, or bracketed by ordering. Record the method.
• Handle history: prior handles plus the source for each (old mention, inbound link, archive snapshot, cross-post).
• Verification status and what kind of verification it is.
• Bio text verbatim, plus every link, including link-aggregator destinations expanded one level.
• Business/creator contact fields (email, phone, category, address).
• Profile and banner images downloaded, hashed, run through find-the-original-image.
• Pinned or featured content — usually the subject's own summary of what matters to them.
• Language, locale and script conventions used in the interface-facing fields.

Layer 2 — Network

• Follower and following counts, with capture date.
• Follower list ordering determined (insertion order vs affinity-ranked) using a control account.
• Earliest-cohort followers captured, where ordering allows. These are the family-and-close-friends layer.
• Mutual follows enumerated and clustered.
• Clusters labelled with the real-world community they appear to represent (employer, school, hometown, congregation, hobby) and the evidence for that label.
• Inbound tags and mentions collected separately from outbound ones.
• Accounts that appear in comments within minutes, repeatedly — the inner circle.
• Accounts that leak about the subject: relatives, colleagues and friends whose own accounts are open. Note which specific facts each one leaks.
• Third-party minors and uninvolved parties identified and excluded per the scope gate. Record the exclusion.
• Graph exported to graph-the-network.

Layer 3 — Content

For each post in the collection window:

• Post URL, archive URL, post ID.
• Timestamp, normalised to UTC, with the source of the timestamp.
• Text verbatim.
• Media downloaded and hashed.
• Location claims: geotag, check-in, place name in text, place name in hashtags.
• Inadvertent disclosure sweep, per image:
  • Reflections — windows, mirrors, glasses, screens, glossy surfaces, vehicle paint, cutlery.
  • Screens in frame — laptop, phone, TV, monitors, ATMs, departure boards.
  • Paper — boarding passes, parcel labels, receipts, prescriptions, event badges, name plates, whiteboards, calendars, post.
  • Vehicles — plates, dealer frames, inspection stickers, parking permits, toll transponders, distinctive damage.
  • Building detail — house numbers, intercom panels, letterboxes, utility markings, street furniture, signage, language of signage.
  • Uniform, badge, lanyard, branded clothing.
  • Pets, children's school uniforms, sports club kit. Note that these are commonly out of bounds; record only if the objective requires.
• Repeated-background register: assign each recurring interior or view an ID, count appearances, record first and last seen dates and the times of day. Repetition plus timing is what distinguishes home from workplace from a friend's house.
• EXIF extracted via secrets-in-file-metadata, recording which upload path the file came from.
• Any image worth geolocating handed to geolocate-from-pixels with the specific question you want answered.
• Any suspiciously convenient image checked with is-this-photo-real.

Layer 4 — Temporal

Extraction schema — one row per post, CSV or equivalent:

post_id, platform, timestamp_utc, timestamp_source, local_hour_assumed_utc,
weekday, post_type, has_media, is_reply, client_or_source_label, notes

Then:

• Sample size and window recorded. Under a few dozen manual posts, do not draw a timezone conclusion at all.
• Hour-of-day histogram in UTC.
• Day-of-week histogram.
• Hour-by-weekday heat map — this separates work schedule from sleep, which the two one-dimensional plots cannot.
• Sleep window identified: the longest contiguous low-activity block, typically seven to nine hours.
• Inferred UTC offset, stated as a range, with the reasoning.
• Weekday-versus-weekend difference characterised.
• Offset shifts flagged as candidate travel, with dates.
• Automation check completed before any of the above is believed:
  • Are post times suspiciously round (top of the hour, fixed minutes)?
  • Is the interval between posts unnaturally regular?
  • Does the platform expose a client or source label indicating a scheduler or API client?
  • Do replies — which are hard to schedule — show a different distribution from top-level posts? If they do, trust the replies.
  • Is there evidence of cross-posting from another platform, which would make this histogram a copy of that one?
• Multi-operator check: does the distribution look like one human or like two overlapping schedules?

Layer 5 — Consolidation

• Every cross-platform link listed with its evidence type and grade.
• Every location claim listed with grade and the artefacts supporting it.
• Contradictions listed explicitly. A contradiction you found and explained is a strength; one the reader finds is a failure.
• Coverage gaps stated: platforms not examined, date ranges with no posts, content types not accessible.
• Out-of-scope material identified and deleted, with the deletion recorded.
• Handoff to write-the-intel-brief.

Analytic conclusions worth making explicit

Write these as sentences in the brief, or say you couldn't establish them:

• Home location, at the resolution you can actually defend — country, region, city, neighbourhood. Do not report a resolution finer than your evidence supports.
• Work location and employer, and whether the two are separable in the data.
• Daily rhythm: wake window, work window, sleep window.
• Weekly rhythm: which days differ and how.
• Travel events with dates and, where possible, destinations.
• Inner circle: who, and the basis for calling them that.
• Community memberships.
• Devices and platforms used, from client labels and media characteristics.
• What changed over the collection window — a shift in rhythm, location, or network is often the actual finding.

---

Supporting file: reference/platform-disclosure.md

Per-platform public disclosure matrix

What an observer can see without a relationship to the subject, described by mechanism rather than by menu location. UI moves constantly; the mechanisms below change slowly. Verify current behaviour on a control account you own before relying on any row.

Three observer postures matter throughout:

• Logged out — no account, no cookies. Lowest exposure, most gating.
• Minimally authenticated — a research account with no history, no followers, no profile photo. Sees more, but is itself a signal: brand-new empty accounts are what platforms and cautious subjects both watch for.
• Established research persona — an aged account with plausible activity. Sees the most, costs the most to build, and loses the most when burned. See investigate-without-getting-made.

The disclosure axes

For each platform, ask the same seven questions:

1. Can the profile be read at all while logged out, or is there an auth wall?
2. Is the follower/following list enumerable, and in what order?
3. Are exact post timestamps exposed, or only relative ("3h ago")?
4. Is there a stable numeric ID, and does it encode a creation time?
5. Does the platform tell the subject that you viewed them?
6. Is EXIF stripped from uploaded media, and does that differ by upload path?
7. Does the platform expose an engagement graph (likes, reactions, comments) to non-connections?

Cross-cutting mechanisms

Auth walls are partial and inconsistent. Most large platforms gate some surfaces (search, follower lists, media tabs) while leaving the base profile readable to crawlers, because they want search-engine indexing. That gap is the reason a site's own search may show you nothing while a web search operator scoped to the site shows you plenty — see google-like-a-spy. Search-engine caches and archives also preserve the pre-gate version of a profile; see read-deleted-pages.

Numeric IDs outlive handles. Platforms need an immutable primary key. Where the ID is exposed in API responses, page source, or media URLs, capture it: it survives renames, and it's how you prove a renamed account is the same account.

Snowflake-style IDs leak the signup time. A 64-bit ID whose high bits are a millisecond counter since a platform epoch decodes directly to a creation timestamp. Where a platform uses plain auto-increment integers instead, the ID gives you ordering, which you convert to a date range by finding accounts with known creation dates on either side.

Follower list ordering is an implementation detail with intelligence value. Where a platform returns followers in insertion order (oldest first or newest first), the tail of the list is the earliest cohort. Where it returns them ranked by an affinity model, ordering tells you about the viewer, not the subject. Determine which you're looking at using a control account before drawing conclusions.

Relative timestamps defeat temporal analysis; absolute ones enable it. Where the UI shows "5h", the exact value is usually still present in the page source or in the API response backing the view. Where it isn't, you can bracket it by observing the same post repeatedly. Also check whether the rendered time is localised to your session timezone — if it is, your histogram silently measures your own offset unless you normalise to UTC.

Read receipts and view telemetry. Ephemeral content (stories, fleeting posts) generally reports viewers to the poster by design, because that's the product. Professional networks often report profile visits, sometimes with an opt-out that also blinds you to who visited you. Ordinary feed posts generally do not report views individually, but liking, following, saving or replying always does. Assume any interaction is attributable and any ephemeral-content view is logged.

Recommendation feedback. Even pure viewing feeds the graph. Repeatedly loading one subject's profile can cause the platform to suggest your research account to them, or them to your other accounts, because co-viewing is a similarity signal. Separate personas across separate browser profiles, separate egress IPs, and separate devices where the stakes justify it.

EXIF handling differs by upload path, not just by platform. The common pattern: images posted through the normal media pipeline are re-encoded and stripped; the same file sent as a generic file attachment or document is stored byte-for-byte and retains everything. Profile pictures and banners are often processed differently from feed media. Always test the specific path rather than assuming "platform X strips EXIF."

Platform-family notes

Microblogging / short-post platforms. Historically the most open to logged-out reading; increasingly gated behind authentication, with the depth of gating varying by surface and by region. Snowflake-style IDs are common, so account age is derivable from the post or user ID even when the profile hides it. Post IDs are also snowflakes, which means a post's ID gives you its creation time independently of the displayed timestamp — useful when the displayed time is relative or when the post was edited.

Photo and short-video platforms. Base profile and post grid frequently readable logged-out; follower lists, tagged-media tabs and search usually gated. Stable numeric user IDs are exposed in API responses and sometimes in media URLs; the handle is mutable, the ID isn't. Ephemeral story viewing is always attributable. Media is aggressively re-encoded, so EXIF is generally gone, but the filename and CDN path can still carry structure worth reading.

Full social networks with bidirectional friendship. Friend lists are commonly restricted, but the restriction is one-sided: a locked-down subject appears in the open friend lists, tagged photos and public check-ins of their less careful contacts. Mutual-friend enumeration from the outside in is often the only route. Public pages, groups, marketplace listings and event RSVPs under the same account are frequently far more open than the personal profile.

Professional networks. Employment history, education, and skills are self-reported and semi-verified at best, but the timeline is high-value: date ranges bracket where someone lived. Profile-view telemetry is a first-class feature here — use the privacy mode that anonymises you, and understand it is a platform-controlled promise, not a technical guarantee. Connection-degree labels leak network structure even when the connection list is hidden.

Pseudonymous discussion platforms. Handles are the identity, real names are rare, and the intelligence is in aggregate posting behaviour: subreddit or board membership maps interests and geography, and a full comment history is usually enumerable and timestamped, which makes these the best possible source for temporal analysis. Usernames are typically immutable, which makes them excellent selectors for hunt-a-handle. Deleted comments frequently survive in third-party mirrors and archives.

Messaging platforms with public surfaces. Public channels, groups and username lookups expose far more than users assume: joining a public channel is usually not reported to other members, but posting is, and member lists may be enumerable depending on group type and size. User IDs are numeric and broadly increasing, so a raw ID brackets registration order. File-send paths commonly preserve original metadata intact.

Community chat platforms. Snowflake IDs throughout, so account and message creation times are derivable. Server membership is the network layer, and membership overlap across servers is a strong linkage signal. Presence, activity status and voice-channel occupancy are real-time pattern-of-life data if you're already in the server — which is interaction, not observation, and needs authorization.

Recording template

For each platform in scope, record:

platform:
observer posture used:
profile readable logged-out:      yes / partial / no
numeric ID:                        value
ID encodes creation time:          yes / no / derived-by-ordering
creation date:                     value + how obtained
handle history observed:           values + sources
follower list enumerable:          yes / no / partial; ordering =
exact timestamps available:        yes / no; source = UI / page source / API
timestamps rendered in:            UTC / viewer locale / poster locale
view telemetry to subject:         none / stories / profile visits / unknown
EXIF retained on tested path:      yes / no; path tested =

Keep the "how obtained" column populated. In six months you will not remember, and an unsourced creation date is not evidence.

---

Supporting file: ETHICS.md

Ethics, Legality & Authorized Scope

OSINT is powerful. These skills are built for lawful, authorized, defensive work: threat intelligence, fraud investigation, due diligence, journalism, missing-persons research, penetration-test reconnaissance, and personal digital self-defense.

Every workflow skill opens with an authorized scope gate. Honor it.

The rules

1. Passive by default. Prefer observation over interaction. Never log in to, probe, exploit, or send traffic to a target's private systems without written authorization. Reading a public profile is OSINT; brute-forcing a login is a crime.
2. Stay legal in your jurisdiction. Computer-misuse, wiretap, stalking, harassment, and data-protection laws (GDPR, CCPA, etc.) all apply to research. When unsure, stop and get counsel.
3. No harassment, doxxing, or stalking. Do not use these skills to locate, intimidate, or expose private individuals for harm. Aggregating someone's personal data to threaten them is abuse, full stop.
4. Minimize and protect data. Collect only what the objective requires. Store case data encrypted, share on need-to-know, and delete when done.
5. Corroborate before you conclude. A single selector match is a lead, not a fact. Attribution requires multiple independent, corroborating sources.
6. Respect terms of service and rate limits. Automated scraping can be illegal or get you banned. Use official APIs where they exist.

Not for

Stalking, harassment, doxxing, unauthorized access, or any activity prohibited by law. If your objective is to harm a person, these skills are not for you.

By using this repository you accept full responsibility for how you apply it. The authors provide it "as is" with no warranty (see LICENSE).