OSINT cluster research: IntelOwl artifacts, playbooks, pivots, and analysis lifecycle #176

New issue

Open

opened 2026-08-29 10:28:07 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-08-29 10:28:07 +00:00

Owner

Goal

Deeply research IntelOwl for reusable investigation and enrichment architecture. Extract the lifecycle and composition semantics, not its Python/Django implementation or every analyzer.

Architecture rule

Use IntelOwl to inform an Investigation/Analysis domain-server cluster and shared StarLang orchestration. Source-specific enrichment remains owned by the proper domain server.

Feature surface to verify

typed artifacts for files and observables
repeat analysis of the same artifact
jobs / analysis requests
analyzers backed by local tools or external services
connectors for outbound integrations
pivots that trigger chained analyses
playbooks for repeatable compositions
ingestors that turn streams into analysis jobs
visualizers specialized to analyzer/playbook results
shared data models for normalizing heterogeneous results
user events / analyst evaluations
investigations and collaboration
REST/API client integration
plugin configuration and permissions
robot/service users for automation
plugin parameter ownership
analyzer selection by observable type
file/static-analysis pipelines
external service enrichment
connector-driven export
playbook sharing and reuse
scaling/concurrency model
result persistence and historical evaluation

StarIntel target

Research whether StarIntel should standardize these shared semantics across domain servers:

artifact/target identity
analysis job
playbook
pivot
capability selection
result binding
analyst assessment
service identity
result-specific visualization declaration

These should be StarLang/runtime concepts where possible, not IntelOwl compatibility layers.

Implementation preference

StarLang → extend StarLang → Common Lisp → Python only as last resort.

Output gate

Stage findings in roam/internal/OSINT-TOOLS-LEDGER.org and this issue. Do not update ARARD/ARADR conclusions until explicit human instruction to add research.

## Goal Deeply research IntelOwl for reusable investigation and enrichment architecture. Extract the lifecycle and composition semantics, not its Python/Django implementation or every analyzer. ## Architecture rule Use IntelOwl to inform an Investigation/Analysis domain-server cluster and shared StarLang orchestration. Source-specific enrichment remains owned by the proper domain server. ## Feature surface to verify - typed artifacts for files and observables - repeat analysis of the same artifact - jobs / analysis requests - analyzers backed by local tools or external services - connectors for outbound integrations - pivots that trigger chained analyses - playbooks for repeatable compositions - ingestors that turn streams into analysis jobs - visualizers specialized to analyzer/playbook results - shared data models for normalizing heterogeneous results - user events / analyst evaluations - investigations and collaboration - REST/API client integration - plugin configuration and permissions - robot/service users for automation - plugin parameter ownership - analyzer selection by observable type - file/static-analysis pipelines - external service enrichment - connector-driven export - playbook sharing and reuse - scaling/concurrency model - result persistence and historical evaluation ## StarIntel target Research whether StarIntel should standardize these shared semantics across domain servers: - artifact/target identity - analysis job - playbook - pivot - capability selection - result binding - analyst assessment - service identity - result-specific visualization declaration These should be StarLang/runtime concepts where possible, not IntelOwl compatibility layers. ## Implementation preference StarLang → extend StarLang → Common Lisp → Python only as last resort. ## Output gate Stage findings in `roam/internal/OSINT-TOOLS-LEDGER.org` and this issue. Do not update ARARD/ARADR conclusions until explicit human instruction to add research.