Building a Lightweight Evidence Capture Workflow

Evidence capture fails surprisingly often for one simple reason:

the workflow is either too casual to be reproducible or too complicated to be used consistently.

A screenshot lands on the desktop with no source URL.

A page is saved but nobody records why it mattered.

A public archive is created but the analyst assumes the archive proves more than it actually does.

A local file is hashed, but there is no record of when or how the file was captured.

A case folder contains hundreds of artifacts with filenames such as:

Screenshot 2026-08-18 at 21.14.32.png

and nobody can reconstruct which research question each artifact answered.

The solution is not automatically a forensic laboratory.

For most public-source research, a strong starting point is a lightweight, repeatable evidence package that preserves enough context to let another person understand:

• what was observed;
• where it was observed;
• when it was observed;
• how it was captured;
• what was preserved;
• what the analyst believes it shows;
• what the artifact does not prove.

That is the workflow this guide builds.

---

Capture, preservation, integrity and interpretation are different things

These terms are often collapsed into one idea: "save the evidence."

They should be separated.

Capture

Capture is the act of recording a representation of what you observed.

Examples:

• screenshot;
• saved HTML;
• SingleFile document;
• MHTML page;
• PDF;
• WARC record;
• exported JSON;
• saved response headers.

Capture answers:

What did I preserve from this observation?

Preservation

Preservation is the process of keeping the captured material usable over time.

It includes questions such as:

• where is the artifact stored?
• can it still be opened later?
• is there a second copy?
• are filenames and metadata understandable?
• is the format appropriate for the intended retention period?

Preservation answers:

Will this artifact remain available and interpretable later?

Integrity

Integrity concerns whether the preserved artifact changed after a known point.

Cryptographic hashes can help here.

If you calculate a SHA-256 digest for a file and later calculate the same digest again, you have strong evidence that the file bytes are unchanged between those checks.

That does not prove that the file represented the genuine original page before the first hash was calculated.

Integrity is not authenticity.

Interpretation

Interpretation is the analytical claim attached to the artifact.

Example:

The page identified Alice Example as a director of Example Ltd at the time of capture.

That claim must be supported by the artifact and its context.

A capture does not interpret itself.

The analyst still needs to distinguish:

• observation;
• inference;
• conclusion.

---

The minimum viable evidence package

For ordinary public-web research, a useful evidence package can be small.

At minimum, record:

1. research question
2. source URL or identifier
3. UTC capture timestamp
4. capture method
5. preserved artifact
6. short observation note
7. short interpretation note
8. limitations
9. integrity hash when appropriate
10. storage location or case identifier

That is enough to make a large amount of OSINT work reproducible.

A compact record might look like:

Case: ACME-2026-08
Question:
Did example.com identify Company A as the operator of the service?

Source:
https://example.com/terms

Observed:
2026-08-18T19:42:11Z

Capture:
SingleFile HTML + screenshot

SHA-256:
<digest>

Observation:
The Terms page states "Service operated by Company A Ltd"
and displays company number 12345678.

Interpretation:
The page provides first-party evidence that the website identified
Company A Ltd as the service operator at the time of capture.

Limitations:
First-party statement. Registry verification required.

Stored:
cases/ACME-2026-08/evidence/EV-0042/

The goal is not bureaucracy.

The goal is that the artifact still makes sense six months later.

---

Start with the question, not the capture button

Capture should follow relevance.

Before saving something, ask:

Why might this matter?

A useful answer can be short:

This page connects the domain to a legal entity.

or:

This redirect may document a domain migration.

or:

This post contains the original version of the claim.

That note determines:

• what needs to be captured;
• which context must be preserved;
• whether a screenshot is enough;
• whether a local copy is needed;
• whether a public archive is useful;
• whether additional corroboration is required.

Without the research question, capture turns into hoarding.

---

Capture before deep interpretation when the source is volatile

Some public information is stable.

Some can disappear in minutes.

Examples of volatile material include:

• social posts;
• live pages;
• press releases;
• product pages;
• corporate team pages;
• public documents later replaced;
• temporary announcements;
• dynamically generated results.

When the material is relevant and lawful to preserve, the safe sequence is often:

observe → capture → document → analyze

not:

analyze for twenty minutes → return to capture → discover the page changed.

Preserving early does not mean accepting the content as true.

It means preserving the state you intend to evaluate.

---

Record time precisely

"Today" is weak metadata.

Use an absolute timestamp.

Prefer UTC for investigative records:

2026-08-18T19:42:11Z

You may also record local time when operationally useful.

The important requirement is clarity.

Time matters because public web evidence changes.

A page captured on 18 August does not prove it contained the same content on 10 August.

Likewise, an archived page dated 10 August does not prove the current page still matches it.

Every observation belongs to a time.

---

Preserve the exact source

Record the exact URL you observed.

Do not reduce:

https://example.com/reports/2026/result?id=42

to:

example.com

unless the shorter form is genuinely the object of the research.

Useful source fields include:

• requested URL;
• final URL after redirects;
• document identifier;
• query parameters when relevant;
• file name;
• platform post identifier;
• registry record identifier.

Be careful with sensitive query strings.

URLs can contain:

• session tokens;
• reset links;
• personal identifiers;
• access keys.

Preserve only what is necessary and protect sensitive values appropriately.

---

Screenshots are useful — but incomplete

Screenshots are excellent for:

• fast visual capture;
• showing what a human saw;
• preserving layout;
• documenting a visible claim;
• reporting.

They are weak when used alone.

A screenshot may not preserve:

• exact source URL;
• HTTP response;
• page source;
• hidden metadata;
• linked resources;
• interactive context;
• the full page;
• the capture time in a reliable way.

A screenshot is often best treated as a presentation artifact attached to a richer evidence record.

If a screenshot is all you need, still pair it with:

URL
timestamp
short note

---

Saving the page preserves a different kind of evidence

A saved page can preserve more structure than a screenshot.

Possible formats include:

• HTML;
• SingleFile HTML;
• MHTML;
• WARC;
• PDF.

Each format has different strengths.

There is no single universally best capture format.

Choose based on the research need.

---

SingleFile: convenient self-contained page capture

SingleFile is designed to save a complete web page into a single HTML file.

That is useful because many ordinary "Save Page" workflows create:

page.html
page_files/

with separate dependencies.

A single self-contained HTML artifact is easier to:

• name;
• move;
• hash;
• attach to a case;
• reopen later.

SingleFile is especially useful for quick local preservation during research.

What SingleFile does not prove

A SingleFile document does not automatically prove:

• the page was authentic;
• every dynamic network request was preserved;
• the server response was unchanged before capture;
• the page looked identical in every browser;
• the content was visible at another time.

It preserves a representation produced by the capture process.

Document that process.

---

MHTML: browser-oriented page packaging

MHTML packages a web page and related resources into a multipart document.

Tools such as Hunchly use MHTML as part of their evidence-capture approach.

MHTML can be convenient for preserving a browsable page representation together with embedded resources.

But the same principle applies:

file format alone does not create provenance.

You still need:

• URL;
• timestamp;
• capture context;
• integrity metadata;
• case documentation.

---

WARC: preservation-oriented web archiving

WARC is a standard web-archive format widely used by web-archiving institutions.

The Library of Congress describes WARC records as containers that can preserve harvested resources together with record headers containing metadata such as:

• record type;
• date;
• content length.

WARC is valuable when you want a more preservation-oriented record of web retrievals.

Tools such as ArchiveBox can produce WARC alongside other representations.

WARC is powerful, but not mandatory for every case

A single relevant public page does not always justify building a WARC-centered pipeline.

Use complexity proportionately.

For a small research task:

SingleFile + screenshot + metadata

may be enough.

For systematic archiving:

WARC + indexes + screenshots + derived formats

may be more appropriate.

The format should serve the evidence requirement.

---

ArchiveBox: archive ownership and multiple capture formats

ArchiveBox is a self-hosted web-archiving system.

Its current documentation describes capture methods including:

• original content;
• SingleFile;
• screenshot;
• PDF;
• WARC;
• metadata.

This makes it useful when the objective is:

maintain your own organized archive of URLs over time.

That is different from simply saving one page during an investigation.

ArchiveBox is especially useful when you need:

• repeat collection;
• self-hosted storage;
• multiple representations;
• an archive you control.

That power creates operational responsibility.

You need to manage:

• storage;
• backups;
• updates;
• permissions;
• privacy;
• retention.

Owning the archive also means owning its maintenance.

---

Hunchly: capture integrated into investigative browsing

Hunchly takes a different approach.

Instead of asking the investigator to decide manually when to save every page, it can document browsing activity inside a case-oriented workflow.

Hunchly currently describes features including:

• URL collection;
• timestamps;
• page capture;
• hashing;
• case organization;
• tags;
• notes;
• reports;
• audit-trail support.

Its evidence documentation also discusses:

• MHTML;
• SHA-256 hashing;
• GPG signing;
• deletion logging;
• potential challenges to captured evidence.

That last point is important.

A mature evidence tool should not pretend that hashing magically solves authenticity.

Hunchly's own evidence guidance explicitly discusses ways evidence can still be challenged even when a hash verifies.

This is the correct analytical model.

---

Wayback Machine: third-party historical preservation

The Wayback Machine solves another problem:

Has a public archival service preserved a previous state of this resource?

This can be extremely valuable because the capture is not stored only inside your own investigation.

Historical captures can help:

• corroborate older page content;
• establish that a public representation existed at an earlier time;
• compare site changes;
• reconstruct migrations.

The Memento framework formalizes the concept of accessing prior states of web resources through time-based web architecture.

A Wayback capture is not equivalent to your own capture

A third-party archive has its own:

• collection method;
• coverage;
• timestamp model;
• rendering limitations;
• missing resources;
• crawl policies.

Do not say:

The Wayback Machine proves the page looked exactly like this to every user.

Prefer:

The archive preserved this representation of the page associated with this capture time.

Third-party archive evidence and investigator-controlled capture complement each other.

---

Use more than one capture when the finding matters

For high-value public-web evidence, a small capture stack can be stronger than one artifact.

Example:

1. screenshot
2. self-contained page capture
3. source URL + timestamp
4. SHA-256 hash of the local artifact
5. public archive request or existing archive reference
6. short analyst note

Each component solves a different problem.

• screenshot → visual communication
• local HTML/MHTML → local preservation
• URL → provenance
• timestamp → temporal context
• hash → later integrity check
• public archive → independent historical reference
• note → interpretation

Do not describe this as "seven copies of the same evidence."

They are different evidence functions.

---

Hashes: what they prove and what they do not

A cryptographic hash function maps data to a fixed-size digest.

NIST's Secure Hash Standard defines SHA-2 functions including SHA-256.

A common evidence workflow calculates:

SHA-256(file)

at capture time.

Later, calculate it again.

If the digest matches, you have strong evidence that the file bytes have not changed.

Hashes support integrity

Suppose:

capture.html
SHA-256 = ABC...

Six months later:

capture.html
SHA-256 = ABC...

The matching digest supports:

The file being checked is byte-for-byte consistent with the file represented by the recorded digest.

Hashes do not establish original truth

A hash cannot tell you:

• whether the page was genuine;
• whether the page was manipulated before capture;
• whether the browser rendered the page correctly;
• whether the capture tool omitted content;
• whether the analyst altered the page before creating the first hash.

This is why integrity must sit inside a broader provenance record.

Hunchly's own evidence guide makes this limitation explicit: a hash can validate a captured file against a recorded value while still leaving questions about what happened before that evidence package was created.

---

Signatures and audit trails add context, not magic

Digital signatures and signed audit records can make tampering harder and provide additional evidence about how a package was produced.

They can help answer:

• which system produced the record;
• whether metadata changed;
• whether the package corresponds to a signed manifest.

But no mechanism makes investigator-controlled evidence immune from challenge.

Good evidence systems therefore combine:

• capture;
• metadata;
• integrity checks;
• audit trail;
• independent corroboration.

Do not rely on one mechanism.

---

Separate source metadata from analyst metadata

This is a useful design habit.

Source metadata

Information about the thing observed:

source URL
page title
response timestamp
archive URL
document identifier
platform post ID

Capture metadata

Information about how you preserved it:

capture time
capture tool
tool version
file name
file format
hash
operator

Analyst metadata

Information about why it matters:

case
research question
observation
interpretation
confidence
limitations
tags
related evidence

Keeping these groups separate makes later review much easier.

---

Use stable evidence identifiers

Do not make the filename carry the entire case.

Create a stable evidence ID.

Example:

EV-0001
EV-0002
EV-0003

Then store:

EV-0042/
  metadata.json
  screenshot.png
  page.html
  notes.md

or the equivalent inside your investigation platform.

The important part is consistency.

Evidence IDs make it easier to:

• cite artifacts in notes;
• cross-reference findings;
• rename files without breaking the reasoning;
• prepare reports.

---

A practical naming convention

If you work directly with files, use a predictable pattern.

Example:

20260818T194211Z_EV-0042_example-com_terms_singlefile.html
20260818T194211Z_EV-0042_example-com_terms_screenshot.png
20260818T194211Z_EV-0042_metadata.json

Avoid characters that create cross-platform problems.

Do not use filenames as the only metadata store.

The filename should help navigation.

The metadata record should carry the actual evidence description.

---

Preserve the original artifact

When analysis requires transformation, keep the original capture.

Examples of transformations include:

• image crop;
• OCR;
• PDF conversion;
• metadata extraction;
• translation;
• redaction;
• annotation.

Use a structure such as:

original/
derived/
notes/

For example:

original/EV-0042_page.html
derived/EV-0042_text.txt
derived/EV-0042_annotated.png

Then hash the original independently.

A derived artifact is useful for analysis.

It should not silently replace the original evidence object.

---

Document transformations

If you:

• crop an image;
• normalize audio;
• convert a file;
• extract text;
• translate text;
• redact personal data;

record that action.

A small transformation log can be enough:

2026-08-18T20:02Z
Created EV-0042-D01 from EV-0042.
Operation: cropped visible footer for report.
Original unchanged.

This preserves analytical transparency.

---

Evidence capture is not chain of custody by default

The phrase "chain of custody" has legal and procedural meanings that vary by context and jurisdiction.

A lightweight OSINT workflow should not claim formal evidentiary status it has not actually established.

Prefer describing what you do precisely:

• capture log;
• audit trail;
• integrity record;
• handling history;
• provenance record.

If your work will be used in:

• litigation;
• law enforcement;
• regulatory proceedings;
• human-rights investigations;

follow the applicable professional and legal procedures.

The Berkeley Protocol provides a rigorous framework for digital open-source investigations, including preservation and documentation considerations.

This article provides a practical baseline, not a substitute for those standards.

---

Minimize unnecessary personal data

Evidence preservation can create privacy risk.

A web page may contain:

• names;
• addresses;
• photographs;
• user IDs;
• comments;
• unrelated personal information.

Do not preserve more than the research purpose requires.

Ask:

Is the full page necessary?

Sometimes it is.

Sometimes a narrower artifact plus context is sufficient.

If you must retain sensitive information:

• restrict access;
• document the reason;
• define retention;
• protect backups;
• avoid unnecessary sharing.

Preservation is not an excuse for unlimited collection.

---

Public archive or local capture?

Use the tool that matches the evidence requirement.

Use a public archive when

• historical public availability matters;
• you want a third-party reference;
• the page is suitable for public archival;
• you need to compare past states.

Use a local capture when

• you need control of the artifact;
• the material may not be appropriate for public submission;
• the investigation needs a private working copy;
• you need to hash and manage the exact captured file.

Use both when

• the material is important;
• public archival is appropriate;
• independent corroboration adds value.

Do not upload sensitive or restricted material to a public archive merely to create "independent evidence."

---

Fast capture and durable preservation are different stages

A lightweight workflow can operate in two stages.

Stage A — Immediate capture

During active research:

save page
screenshot
URL
timestamp
quick note

Goal:

do not lose the observation.

Stage B — Evidence packaging

For material that becomes important:

stable evidence ID
clean metadata
hash
archive reference
structured notes
backup
relationship to findings

Goal:

make the artifact understandable and durable.

This staged model reduces friction.

You do not need to package every page like a court exhibit while browsing.

You upgrade the artifacts that matter.

---

Build a capture threshold

Not everything deserves preservation.

A simple threshold can be:

Capture if the material is:

• directly relevant to a research question;
• volatile;
• likely to be disputed;
• necessary to support a finding;
• an important source document;
• a unique observation you may not be able to reproduce.

Do not capture merely because:

it is interesting.

Otherwise evidence stores become unusable archives of curiosity.

---

Capture linked context when necessary

Sometimes the claim cannot be understood from one page.

Example:

Page A says:

See our ownership disclosure.

and links to Page B.

If Page B contains the actual evidence, preserving only Page A may be insufficient.

Likewise, a social post may depend on:

• reply context;
• thread;
• quoted post;
• attached image.

Preserve enough context to make the observation understandable.

Still minimize unrelated information.

---

Record redirects when provenance depends on them

Suppose you capture:

https://old.example.com/report

but it redirects to:

https://new.example.com/report

The final page is not the complete provenance story.

Record:

• starting URL;
• redirect path when relevant;
• final URL.

This can be especially important for:

• rebrands;
• domain migrations;
• campaign links;
• third-party document delivery.

OSINT.dev's Redirect Chain & Response Inspector can help document that technical path separately from the visual page capture.

---

Dynamic pages need special caution

Modern pages may change based on:

• JavaScript;
• login state;
• location;
• cookies;
• personalization;
• A/B testing;
• time.

One captured representation may not be universal.

Record relevant context such as:

authenticated: no
browser:
locale:
capture tool:

when those fields affect the finding.

Avoid claiming:

The website displays X.

when the evidence supports only:

The unauthenticated page captured from this context displayed X at this time.

Precision improves defensibility.

---

Evidence packages should survive tool changes

Tools disappear.

Formats and proprietary systems change.

Do not design a workflow that becomes unreadable if one vendor closes.

Good preservation practice includes exportable artifacts and open or widely supported formats where practical.

For example:

• image files;
• HTML;
• MHTML;
• PDF;
• WARC;
• JSON/CSV metadata;
• plain-text notes.

A proprietary case database can be useful.

It should not be the only place the important evidence exists.

---

Backups matter more than elaborate folder aesthetics

An immaculate case folder on one laptop is not durable preservation.

For important research, think about:

• second copy;
• separate storage device;
• encrypted backup;
• access controls;
• recovery testing.

The appropriate level depends on:

• sensitivity;
• duration;
• professional requirements.

The principle is simple:

An evidence workflow that cannot survive storage failure is incomplete.

---

A worked example

Suppose you are researching a company website.

The current Terms page states:

Example Service is operated by NewCo Ltd.
Company No. 98765432.

Historical records suggest the website used to be operated by another company.

Step 1 — Research question

When did the website begin identifying NewCo Ltd as the operator?

Step 2 — Immediate current capture

Record:

URL
UTC timestamp
screenshot
SingleFile capture

Create:

EV-0101

Step 3 — Integrity

Calculate:

SHA-256(EV-0101_page.html)

Record the digest.

Step 4 — Analyst note

Observation:

The captured Terms page identifies NewCo Ltd and company number 98765432 as the operator.

Interpretation:

This is first-party evidence of the operator identity declared by the website at the capture time.

Limitation:

Does not establish the historical start date of that relationship.

Step 5 — Historical evidence

Search the Wayback Machine.

Find an older capture that identifies:

OldCo Ltd

Create a separate evidence record:

EV-0102

Record:

• archive URL;
• Memento/capture time;
• source URL;
• relevant statement.

Step 6 — Transition window

Compare captures across time.

Do not say:

NewCo took over on 1 June.

unless the evidence specifically establishes that date.

Prefer:

Archived captures show OldCo identified as operator on date A and NewCo identified as operator by date B, narrowing the public transition window to A–B.

Step 7 — Registry corroboration

Verify both entities in the relevant corporate registry.

Now the evidence package supports a stronger timeline.

The capture workflow did not create the conclusion.

It preserved the pieces needed to establish it.

---

A second worked example: volatile social content

Suppose a public social post contains a claim relevant to your investigation.

Minimum package

Record:

platform
post URL/ID
account identifier
UTC time
screenshot
page capture if technically possible
media attachment
short context note

If the post is later deleted, your local capture preserves what you observed.

But be precise:

The investigator captured a page representing the post at time X.

Do not claim:

The platform certifies this file as the original post.

unless you have platform-provided evidence supporting that statement.

---

Common mistakes

Mistake 1 — Screenshot without URL

Visual content loses provenance.

Mistake 2 — URL without timestamp

Public content changes.

Mistake 3 — Hash without capture context

Integrity is not authenticity.

Mistake 4 — Archive URL without understanding archive limits

Third-party archives are observations, not omniscient historical records.

Mistake 5 — Preserving only derived artifacts

Keep the original.

Mistake 6 — Capturing everything

Volume destroys usability.

Mistake 7 — No research question

Nobody remembers why the artifact mattered.

Mistake 8 — No limitation note

First-party and third-party evidence silently become "facts."

Mistake 9 — Publicly archiving sensitive material

Choose preservation destination according to sensitivity.

Mistake 10 — Assuming one file format solves evidence

Evidence quality comes from the whole provenance package.

Mistake 11 — Relying on proprietary storage only

Keep exportable copies of important artifacts.

Mistake 12 — No backup

Preservation requires resilience.

---

A lightweight operational checklist

For every important web artifact:

Before capture

• What research question does this support?
• Is the source public and appropriate to preserve?
• Is the page volatile?
• Is sensitive personal data present?

Capture

• exact source URL;
• UTC timestamp;
• screenshot when visual appearance matters;
• local page/document capture;
• relevant attachments;
• capture method.

Document

• evidence ID;
• observation;
• interpretation;
• limitations;
• related evidence.

Integrity

• hash important local artifacts;
• preserve original;
• log transformations.

Corroborate

• public archive where appropriate;
• second source;
• official record;
• historical version.

Preserve

• organized storage;
• backup;
• access control;
• retention decision.

Review

Ask:

Could another analyst understand why this artifact exists and reproduce the reasoning from the package alone?

If not, the package needs more context.

---

Choosing among the four main tools

OSINT.dev currently connects this workflow to four different preservation approaches.

SingleFile

Choose it when you need:

• fast local page capture;
• one portable HTML file;
• low friction during active research.

Wayback Machine

Choose it when you need:

• historical public states;
• a third-party archival reference;
• comparison across time.

ArchiveBox

Choose it when you need:

• self-hosted archive ownership;
• repeated URL preservation;
• multiple output formats;
• long-running collection.

Hunchly

Choose it when you need:

• case-oriented investigative browsing;
• automatic documentation;
• notes and tags;
• hashing and evidence-oriented audit features;
• reporting workflow.

These tools overlap.

They are not interchangeable.

The correct choice depends on:

capture speed, archive ownership, third-party independence, case organization, privacy and long-term preservation requirements.

---

What OSINT.dev should record when it eventually adds native evidence capture

OSINT.dev does not currently provide a general native evidence-capture runner equivalent to these tools.

When that capability is designed, a minimum structured record should include:

evidence_id
user_id / case_id
source_url
requested_url
final_url
captured_at
capture_method
tool_version
artifact_format
artifact_hash
mime_type
artifact_size
observation_note
interpretation_note
limitations
parent_evidence_id
retention_policy

This is not a commitment to a specific schema today.

It is the evidence contract the product should preserve conceptually.

The important principle is:

provenance should be structured from the moment of capture, not reconstructed later from filenames.

---

The core principle

A lightweight evidence workflow is successful when it disappears into the research process.

It should make the disciplined action easier than the careless one.

Use this sequence:

question → capture → source + time → preserve original → integrity record → observation → interpretation → limitations → corroborate → backup

Not every artifact needs a forensic package.

Every important artifact needs enough provenance to remain understandable.

A screenshot is useful.

A hash is useful.

An archive is useful.

A case tool is useful.

None replaces the others automatically.

Reference-grade evidence comes from knowing which problem each mechanism solves and documenting the gaps between them.

---

References

Authoritative standards and official tool documentation used in this guide:

• OHCHR / Human Rights Center, UC Berkeley — Berkeley Protocol on Digital Open Source Investigations
  https://searchlibrary.ohchr.org/record/30334

• Library of Congress — WARC, Web ARChive File Format
  https://www.loc.gov/preservation/digital/formats/fdd/fdd000236.shtml

• Library of Congress — Quality and Functionality Factors for Archived Web Sites and Pages
  https://www.loc.gov/preservation/digital/formats/content/webarch_quality.shtml

• NIST — FIPS 180-4, Secure Hash Standard
  https://csrc.nist.gov/pubs/fips/180-4/upd1/final

• IETF RFC 7089 — HTTP Framework for Time-Based Access to Resource States (Memento)
  https://www.rfc-editor.org/rfc/rfc7089.html

• SingleFile — Official GitHub Repository
  https://github.com/gildas-lormeau/SingleFile

• ArchiveBox — Official Documentation
  https://docs.archivebox.io/latest/

• Hunchly — Official Site
  https://hunch.ly/

• Hunchly — Evidence Guide
  https://support.hunch.ly/category/50-hunchly-evidence-guide