Choosing Between Manual, Semi-Automated and Automated OSINT Workflows

Automation is attractive because it promises speed.

In OSINT, speed is only useful when the workflow still preserves:

• relevance;
• provenance;
• context;
• review;
• stop conditions.

A larger result set is not automatically a better investigation.

A graph with hundreds of nodes can contain less usable intelligence than five carefully verified observations.

The right question is therefore not:

Should I automate this investigation?

It is:

Which parts of this workflow are stable enough to automate without losing analytical control?

That distinction matters.

A good automation strategy does not replace human judgment.

It moves repetitive, well-understood work away from the analyst so that more attention can be spent on:

• interpretation;
• corroboration;
• ambiguity;
• source quality;
• evidence handling.

---

Think in workflow stages, not tool categories

Most OSINT workflows contain several stages:

1. define the research question;
2. identify relevant sources;
3. collect observations;
4. normalize data;
5. deduplicate;
6. pivot to related entities;
7. corroborate important findings;
8. preserve evidence;
9. interpret results;
10. report conclusions.

Different stages tolerate different levels of automation.

For example:

• data normalization can often be automated safely;
• broad collection may be partly automated;
• entity resolution may need review;
• final attribution should rarely be fully delegated.

This means a single investigation can contain:

manual + semi-automated + automated stages

at the same time.

That is usually healthier than choosing one ideology for the entire case.

---

Manual workflows: best when understanding is still forming

A manual workflow means the analyst deliberately chooses and performs each meaningful step.

That does not mean:

• no scripts;
• no browser extensions;
• no APIs.

It means the sequence and interpretation remain directly controlled by the analyst.

Manual workflows are strongest when:

• the research question is narrow;
• the target or topic is sensitive;
• ambiguity is high;
• source context matters;
• the analyst does not yet understand the domain;
• evidence quality matters more than coverage;
• the process is likely to change after each observation.

Example

Question:

Did this company change the legal entity named in its Terms page?

A strong manual workflow might be:

1. inspect the current Terms page;
2. preserve it;
3. identify the current legal entity;
4. inspect historical captures;
5. verify both entities in official registers;
6. narrow the transition period;
7. write the finding.

A broad automated company-enrichment system could collect hundreds of unrelated records.

That would not improve the answer.

Manual strength: context stays visible

When you move one step at a time, you can notice:

• naming inconsistencies;
• time differences;
• contradictory sources;
• changes in terminology;
• unusual redirects;
• subtle qualifications.

Automation can preserve these signals only if the workflow designer anticipated them.

When the investigation is exploratory, that assumption is often false.

---

Manual weakness: repetition

Manual workflows become inefficient when the same deterministic step appears repeatedly.

Examples:

• querying the same API for 200 known domains;
• normalizing hundreds of timestamps;
• hashing every captured artifact manually;
• checking the same DNS record types one host at a time;
• converting identical data formats;
• deduplicating repeated records.

At that point, automation is not replacing analysis.

It is removing clerical work.

That is usually a good candidate.

---

Semi-automated workflows: the practical default

Semi-automation is often the most useful operating model for professional OSINT.

The machine handles predictable steps.

The analyst controls:

• target selection;
• branching;
• review;
• interpretation;
• evidence escalation;
• stopping.

A semi-automated workflow might look like:

analyst selects entity
↓
tool queries 5 structured sources
↓
results normalized
↓
analyst reviews candidates
↓
selected match becomes next pivot
↓
evidence preserved
↓
analyst writes judgment

This is different from:

enter target
↓
collect everything
↓
trust graph

The first model keeps the decision boundary visible.

---

What should usually be automated first?

Good candidates share several properties.

1. The input is well defined

Example:

domain
IP address
company registration number
URL
file hash

Ambiguous inputs are harder to automate safely.

A company name such as:

Global Trading

can produce many possible entities.

A company number is much stronger.

2. The output is structured

Examples:

• JSON;
• DNS records;
• API objects;
• known table schemas.

Structured outputs are easier to validate than free-text interpretation.

3. Failure modes are known

You understand what can happen when:

• API unavailable;
• quota exceeded;
• no result;
• malformed response;
• ambiguous match;
• timeout;
• source changed.

If you have not defined failure behavior, your automation is not mature.

4. The action is repeatable

The same operation must genuinely repeat.

Do not automate a step you perform twice a year simply because it is technically possible.

5. Human review still has a clear place

Automation should make the review queue better.

It should not make the review step disappear.

---

Do not automate a method you cannot explain manually

This is one of the strongest rules in OSINT workflow design.

Before automating a research step, you should be able to explain:

• why the source is relevant;
• what the input means;
• what the source returns;
• how freshness works;
• what missing data means;
• what ambiguous data means;
• what constitutes a false positive;
• what deserves preservation;
• which result triggers the next step.

If you cannot explain those points, automation increases hidden assumptions.

It does not increase maturity.

---

Automation creates scale — including scale of error

Imagine a manual process has a 5% entity-matching false-positive rate.

You apply it to 10 entities.

You may detect and correct the error during review.

Now automate the same logic across 100,000 entities.

The error becomes:

5,000 false matches

The automation did exactly what you asked.

The problem was the method.

This is why workflow maturity should be measured before volume.

---

Precision, recall and review burden

Automation often creates a tradeoff between:

• precision;
• recall;
• analyst workload.

A broad discovery workflow may intentionally accept lower precision to avoid missing candidates.

That can be reasonable if:

• the output is clearly labelled as candidates;
• review capacity exists;
• high-impact conclusions are not automated.

A screening workflow that returns:

candidate match

should not silently become:

confirmed match

during downstream automation.

State transitions matter.

---

Automate labels carefully

A mature pipeline distinguishes states such as:

observed
candidate
matched
verified
rejected
unresolved

These labels are more important than they look.

Without them, automation gradually converts uncertainty into fact.

Example:

OpenSanctions candidate
↓
CSV export
↓
dashboard
↓
"sanctioned companies"

The conclusion changed without an analyst decision.

Good systems prevent that.

---

SpiderFoot: automation-heavy collection

SpiderFoot is explicitly designed to automate OSINT collection.

Its official project describes support for many target types, including:

• IP addresses;
• domains;
• hostnames;
• subnets;
• ASNs;
• email addresses;
• phone numbers;
• usernames;
• person names;
• cryptocurrency addresses.

Its module architecture allows data produced by one module to feed other modules.

That is powerful because one observation can trigger additional collection automatically.

Why this model is useful

SpiderFoot works well when:

• the target type is clearly defined;
• broad collection is useful;
• many sources need to be queried;
• you want repeatability;
• you expect to review a large normalized result set.

Examples include:

• exposure mapping;
• infrastructure discovery;
• broad threat-intelligence enrichment;
• repeatable recon against assets you are authorized to assess.

The automation cost

SpiderFoot's own correlation documentation describes a problem created by successful automation:

large amounts of collected data can become difficult for users to interpret.

Its correlation system exists partly to help surface observations that may deserve more attention.

This is the automation paradox:

the better the collector becomes at producing data, the more important prioritization becomes.

Do not measure success by result count.

---

SpiderFoot scan type is a methodological choice

A broad automated tool can support different collection postures.

The relevant question is not:

Can SpiderFoot find this?

It is:

Which modules and scan behavior are appropriate for this research question and authorization context?

Some SpiderFoot modules can be more interaction-heavy than ordinary passive OSINT.

The official project includes capabilities such as:

• web scraping;
• port scanning;
• banner grabbing;
• zone-transfer checking;
• bucket discovery;
• dark-web searches;
• threat-intelligence lookups.

That means module selection matters.

Do not treat:

run SpiderFoot

as one uniform research action.

The workflow must still define what collection is appropriate.

---

Maltego: guided pivots and graph reasoning

Maltego approaches workflow differently.

Its Graph environment represents entities and relationships visually.

Transforms operate on entities to retrieve or derive related data.

This can support a more analyst-guided style:

entity
↓
run selected Transform
↓
review returned entities
↓
choose meaningful pivot
↓
run next Transform

The graph helps preserve the relationship structure.

That does not automatically make every edge correct.

The analyst still needs to understand:

• transform source;
• relationship semantics;
• time;
• identity resolution.

---

Maltego Machines: automation inside a graph workflow

Maltego Machines automate sequences of Transforms.

Official Maltego documentation describes Machines as macros that can run multiple Transforms in a defined sequence and populate a graph automatically.

This creates an important hybrid model.

The tool can operate:

• manually, one Transform at a time;
• semi-automatically, through analyst-selected pivots;
• more automatically, through Machines.

That shows why the manual/automated distinction should not be assigned permanently to a product.

The same environment can support several workflow styles.

---

Maltego strength: relationship structure stays visible

When used carefully, graph-based work can help analysts reason about:

• entities;
• pivots;
• paths;
• clusters;
• relationships.

This is valuable when the research question is:

How are these entities connected?

rather than:

What can I collect about this domain?

The graph becomes a thinking surface.

But graph density can also create false authority.

A line between two nodes still needs:

• provenance;
• relation type;
• date;
• interpretation.

Visual structure is not evidence by itself.

---

Censys and urlscan: focused services inside larger workflows

Not every automation tool needs to be an all-in-one platform.

Censys and urlscan.io are good examples of services that can become modules in a larger workflow.

Censys

Censys APIs allow programmatic retrieval and search of internet-facing asset observations.

That makes it useful for:

• repeatable host lookups;
• service enrichment;
• certificate context;
• broader infrastructure research.

Use automation when the query pattern is stable.

Do not assume the source's observations represent every moment in time or every possible service.

urlscan.io

urlscan APIs can:

• submit URLs for scanning;
• retrieve scan results;
• search historical scans.

Results can include:

• requests;
• responses;
• page metadata;
• domains;
• IP addresses;
• cookies;
• redirects;
• derived statistics.

This can be integrated into semi-automated or automated URL-analysis workflows.

But scan visibility and privacy require attention.

The API supports visibility settings such as:

• public;
• unlisted;
• private.

Do not submit sensitive investigation URLs to a public scan service without understanding the visibility implications.

Automation can create operational exposure as quickly as it creates analytical value.

---

Manual, semi-automated and automated are not maturity levels

Do not assume:

manual = beginner
semi-automated = intermediate
automated = expert

That model is wrong.

An expert may deliberately choose a manual workflow because:

• the target is sensitive;
• the question is narrow;
• source interpretation is difficult;
• automation would create unnecessary exposure.

A beginner may run a highly automated tool without understanding the output.

Technical automation level is not analyst maturity.

Maturity is the ability to choose the appropriate method.

---

A decision framework

Before automating a workflow, score the following dimensions.

Question stability

Is the research question likely to remain unchanged?

Low stability

Use manual exploration.

High stability

Automation becomes more viable.

Input quality

Is the target uniquely identified?

Ambiguous input

Manual or semi-automated resolution first.

Strong identifier

Automation is safer.

Source stability

Are APIs and formats consistent?

Unstable source

Expect maintenance and human review.

Structured stable source

Better automation candidate.

Interpretation complexity

Does the result require context?

High context

Keep analyst review close.

Low context

More automation is possible.

Error cost

What happens if the result is wrong?

High-impact error

Require human verification.

Low-impact enrichment

Automated processing may be acceptable.

Volume

How many items must be processed?

Low volume

Manual may be faster overall.

High volume

Automation may be justified.

Repetition

Will the same process run repeatedly?

One-off

Do not overengineer.

Recurring

Investing in automation can pay off.

Operational risk

Does automated collection create:

• target interaction;
• account exposure;
• rate-limit issues;
• sensitive third-party submission;
• legal or policy concerns?

The higher the risk, the more deliberate the workflow should be.

---

A simple matrix

The matrix is not absolute.

It is a decision aid.

---

Worked example 1 — infrastructure discovery

Question:

Which public infrastructure signals are associated with the 500 domains owned by our organization?

Manual

For each domain:

• DNS;
• certificate history;
• selected services.

Result:

high control, poor scalability.

Semi-automated

Script:

• validates domain list;
• queries Censys and certificate data;
• normalizes observations;
• produces a review table.

Analyst:

• reviews unusual findings;
• resolves ambiguous assets;
• preserves high-value evidence.

This is often the strongest design.

Fully automated

Schedule collection daily.

Create change alerts.

Good if:

• ownership list is trusted;
• API behavior is known;
• false positives are understood;
• alerts are reviewed.

Bad if:

• every new hostname automatically becomes a confirmed corporate asset.

Automation must not collapse discovery into attribution.

---

Worked example 2 — sanctions screening

Question:

Do any of these 5,000 suppliers match entities in a sanctions dataset?

This requires scale.

Pure manual screening is inefficient.

A strong workflow is:

1. normalize supplier identities;
2. preserve company numbers and jurisdictions;
3. automated candidate matching;
4. score candidate results;
5. human review above threshold;
6. inspect underlying source;
7. mark confirmed/rejected/unresolved;
8. preserve review decision.

The important automation boundary is:

machine generates candidate
human confirms identity

Do not automate:

candidate → sanctioned

without a defensible matching standard and review model.

---

Worked example 3 — image verification

Question:

Is this viral image being reused from an older event?

A manual workflow may be superior:

1. inspect image;
2. reverse-image search;
3. identify earliest relevant results;
4. inspect contextual differences;
5. verify source dates;
6. preserve evidence.

Writing automation around a single image would add complexity without useful scale.

If you instead operate a newsroom monitoring thousands of incoming images, automation may help with:

• perceptual hashing;
• duplicate detection;
• metadata extraction;
• triage.

The final context verification still needs human judgment.

Same method family, different scale.

---

Worked example 4 — recurring web monitoring

Question:

Tell me when these 200 official pages materially change.

This is a strong automation candidate.

A pipeline could:

1. fetch allowed public pages on schedule;
2. hash normalized content;
3. detect changes;
4. store previous version;
5. generate diff;
6. alert analyst.

Human review determines whether the change is meaningful.

Do not alert on every:

• timestamp;
• analytics token;
• randomized ID.

Automation becomes valuable only after normalization and noise handling are stable.

---

The automation readiness test

Before moving a workflow from manual to semi-automated, ask:

Can I write the steps down?

If not, the method is not stable.

Can I define the input schema?

If not, automation will ingest ambiguity.

Can I define a useful output schema?

If not, automation will generate unstructured noise.

Can I define error states?

At minimum:

success
no_result
ambiguous
rate_limited
source_error
invalid_input

Can I define the review rule?

Which result needs human attention?

Can I define the stop condition?

When does the workflow stop expanding?

If any answer is no, keep the workflow closer to manual.

---

The full-automation readiness test

Before scheduling or scaling automation, add more requirements.

You should know:

• source quotas;
• source terms;
• rate limits;
• retry policy;
• deduplication rules;
• data retention;
• logging;
• privacy impact;
• alert thresholds;
• monitoring;
• failure notification;
• maintenance owner.

Automation that silently fails is worse than a manual workflow you know did not run.

---

Human-in-the-loop should mean a real decision

"Human in the loop" is often used vaguely.

A meaningful review step must change the state of the investigation.

Example:

candidate match
↓
human review
↓
confirmed / rejected / unresolved

A weak human-in-the-loop design is:

machine says confirmed
↓
human sees dashboard

The machine already made the consequential judgment.

Define which decisions remain human.

---

Preserve provenance through automation

Automated workflows create an additional evidence challenge.

Each result should retain:

• source;
• query/input;
• retrieval time;
• transformation history;
• tool or workflow version;
• confidence/state;
• related raw record where appropriate.

Without provenance, large automation outputs become difficult to audit.

The Berkeley Protocol emphasizes planning, documentation, preservation, verification and analysis as separate components of professional digital open-source work.

Automation should preserve those separations, not erase them.

---

Workflow versioning matters

Imagine you run the same automated research job in January and August.

Between those dates:

• matching threshold changed;
• one source was removed;
• another API changed;
• normalization rules changed.

The outputs are not directly comparable unless you know which workflow version produced them.

Record:

workflow_name
workflow_version
run_time
source_versions where available
configuration

This becomes especially important for recurring monitoring.

---

Automate deterministic transformations aggressively

Some stages are excellent automation candidates.

Examples:

• lowercase/normalize domains;
• canonicalize timestamps;
• parse structured API output;
• calculate hashes;
• deduplicate exact records;
• validate UUIDs;
• group identical indicators;
• detect known schema errors.

These transformations are explainable.

They reduce analyst workload without replacing interpretation.

This is where automation usually delivers the cleanest value.

---

Automate entity inference conservatively

Entity inference is different.

Examples:

• "same company";
• "same person";
• "same domain owner";
• "same organization";
• "malicious";
• "sanctioned";
• "controlled by".

These are consequential judgments.

Use automation to:

• generate candidates;
• calculate similarity;
• surface conflicts;
• prioritize review.

Do not silently turn inference into fact.

---

Stop graph explosion

Graph tools and recursive automation can expand indefinitely.

One discovered:

domain

leads to:

certificates
subdomains
IPs
ASNs
organizations
email addresses
people
more domains

The technical graph may continue growing.

The research question may already be answered.

Set expansion limits such as:

• maximum pivot depth;
• allowed entity types;
• approved source classes;
• time budget;
• relevance threshold.

Graph size is not a KPI.

---

Tool orchestration is not analytical synthesis

A sophisticated automation can combine:

• SpiderFoot;
• Censys;
• urlscan;
• DNS APIs;
• company databases;
• threat feeds.

That is orchestration.

It is not automatically intelligence analysis.

Synthesis requires asking:

• which observations agree?
• which are stale?
• which sources are independent?
• which contradictions matter?
• what hypothesis is best supported?
• what remains unknown?

The final analytical layer should remain explicit.

---

Common mistakes

Mistake 1 — Automating before understanding

The workflow scales hidden assumptions.

Mistake 2 — Measuring success by result count

More output can mean more noise.

Mistake 3 — Treating candidate states as confirmed states

Uncertainty disappears silently.

Mistake 4 — Using broad automation for a narrow question

Scope expands without analytical value.

Mistake 5 — Ignoring source visibility

Submitting sensitive URLs to a public scanning service can expose research activity.

Mistake 6 — Forgetting rate limits and quotas

A workflow that works once may fail at scale.

Mistake 7 — No workflow version

Historical outputs become hard to compare.

Mistake 8 — No provenance

You cannot audit where findings came from.

Mistake 9 — Automating final attribution

High-impact judgments need review.

Mistake 10 — Believing visual graphs are inherently analytical

Every node and edge still needs meaning.

Mistake 11 — Using "human in the loop" as a cosmetic label

The human must control a consequential state transition.

Mistake 12 — Never stopping

Recursive collection becomes its own objective.

---

A practical maturity path

Most good workflows can evolve through four stages.

Stage 1 — Manual discovery

Goal:

understand the research problem.

Document:

• source choices;
• useful fields;
• failure modes;
• interpretation rules.

Stage 2 — Assisted workflow

Automate:

• formatting;
• repetitive lookups;
• simple parsing;
• evidence IDs;
• note templates.

Keep pivots manual.

Stage 3 — Semi-automated pipeline

Automate:

• structured collection;
• normalization;
• deduplication;
• candidate generation;
• prioritization.

Human reviews consequential findings.

Stage 4 — Scheduled automation

Only after the workflow is stable:

• recurring collection;
• change detection;
• alerts;
• monitoring;
• maintenance.

Do not skip directly from Stage 1 to Stage 4 because the API exists.

---

Related OSINT.dev tools

SpiderFoot

Best understood as an automation-heavy OSINT collection environment.

Useful for broad, repeatable discovery when:

• target types are known;
• modules are selected deliberately;
• output review is planned.

Maltego

Best understood as a graph-based investigation environment where:

• entities;
• relationships;
• Transforms;
• Machines

can support both guided pivots and automated sequences.

Useful when relationship reasoning is central.

Censys

A focused internet-data source that can become a structured enrichment module inside a larger workflow.

Useful when host, service and certificate observations are relevant.

urlscan.io

A focused web-scan service with APIs for submission, result retrieval and historical search.

Useful in URL and web-behavior workflows.

Review visibility settings before submitting sensitive URLs.

---

Choosing the right level

Use manual when:

• the question is new;
• the evidence is ambiguous;
• the volume is low;
• context dominates;
• operational sensitivity is high.

Use semi-automated when:

• repetitive work has appeared;
• inputs are reasonably structured;
• human review still changes decisions;
• you want scale without losing control.

Use automated when:

• the workflow is mature;
• the data model is stable;
• errors are understood;
• provenance is preserved;
• monitoring exists;
• review and escalation rules are explicit.

---

The core principle

Automation should begin where judgment becomes repetitive.

It should stop where repetition becomes judgment.

Use this sequence:

understand manually → formalize the method → automate deterministic steps → generate candidates → preserve provenance → review consequential findings → scale only when failure is understood

That is the difference between workflow automation and tool-driven drift.

The mature analyst is not the person who automates the most.

It is the person who knows which part of the investigation should remain deliberately human.

---

References

Official and primary references used in this guide:

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

• Maltego Documentation — Introduction to Machines
  https://docs.maltego.com/en/support/solutions/articles/15000047415-introduction-to-maltego-machines

• Maltego Documentation — Running Transforms
  https://docs.maltego.com/en/support/solutions/articles/15000009613-running-transforms

• SpiderFoot — Official Open Source Repository
  https://github.com/smicallef/spiderfoot

• SpiderFoot — Correlations Documentation
  https://github.com/smicallef/spiderfoot/blob/master/correlations/README.md

• Censys Documentation — Get Started with Censys APIs
  https://docs.censys.com/reference/get-started

• Censys Documentation — Platform API Transition Guide
  https://docs.censys.com/docs/platform-api-transition-guide

• urlscan.io Documentation — API Introduction
  https://docs.urlscan.io/pages/api-intro

• urlscan.io Documentation — Result API
  https://docs.urlscan.io/pages/result-api-reference