Architecture

Think in workflows, policies, entities, and reporting layers

Silinosic-X combines classic scanner behavior with a more layered runtime model. The repo's own docs describe a policy-driven orchestrator, scope-aware extensions, entity normalization, and fused reporting. This page condenses that into a simpler operator view.

Mental model

Four ways into the framework

Profile

Scan usernames and public identity surfaces across the supported platform set, then enrich with plugins, filters, and profile-focused analysis helpers.

Surface

Inspect domain exposure using CT, RDAP, subdomain classification, transport posture, disclosure clues, and domain-specific plugins.

Fusion

Run profile and surface together so evidence from usernames, domains, and contact artifacts can be compared and scored in one output.

Orchestrate

Use the layered orchestration pipeline to let execution policy decide capabilities, filters, engine selection, fusion, and reporting flow.

Source-study layer

The frameworks and surface-kit commands expose local source-study references and translate some of that intent into native Silinosic-X workflows.

Hybrid runtime

The hybrid architecture docs describe console dispatch, registry-session behavior, event flow, and fusion graph ideas as first-class Silinosic-X concepts.

Pipeline

The layered execution path in practice

Guarantees called out in the docs

Policy firstcore.execution_policy.load_execution_policy() decides enabled capabilities, filters, engine, timeout, and worker limits.
Entities over raw dictionariesThe orchestrator and fusion layers are meant to reason over normalized entities from core/domain/entities.py.
Presentation comes lastThe reporting layer exists to render fused results, not to define intelligence logic itself.

Runtime consequences

Engine health mattersThe runtime tracks structured execution results including success, failed, timeout, and execution time.
Correlation is explicitFusion is a named stage, not an accidental side effect buried in collectors.
History is availableOutputs and inventory snapshots make the framework inspectable after the run finishes.

Extension system

Plugins, filters, modules, and source-intel are separate layers

Plugins

20 core plugins plus 3 cryptography plugins are currently discoverable. They enrich scans with identity fusion, contact mapping, media intel, header hardening, takeover risk, signal fusion, threat scoring, and related capabilities.

Filters

17 filters refine outputs by reducing noise, ranking risk, classifying PII, assessing disclosure posture, and prioritizing subdomains, takeover candidates, or triage order.

Module catalog

The module catalog lives separately under modules/ and the runtime inventory currently reports 567 cataloged modules. That makes the project capable of reasoning about a broader source universe than just directly loaded plugins.

Scope-aware behavior

Plugins and filters are not blind global addons. They declare supported scopes such as profile, surface, and fusion, and the runtime inventory tracks coverage counts for those scopes.

plugins: profile 13 plugins: surface 12 plugins: fusion 18 filters: profile 14 filters: surface 9 filters: fusion 17

Naming note

The project is publicly named Silinosic-X, but some internal paths, comments, and generated artifacts still use silinosic_x spellings. The website keeps the public project name while acknowledging that internal naming is still converging.