One investigation tick: TcsfKernel as the research runtime

· runtime ·

Scanners dump tool output. Nexus runs reasoning. TCSF wraps both in a single investigation tick — code in tcsf/kernel/research_loop.py, not a slide deck.

The tick

pipeline → findings_batch → EvidenceStore
       → reflect → experiment → learn → evaluate
       → graph projection

TcsfKernel.run_investigation loads a mode profile (nexus_url / nexus_network), runs the Nexus pipeline, normalises findings into evidence, then executes optional post_run capabilities: cap.cognitive.reflection and cap.cognitive.experiment.

What reflection actually does

  • Heuristics always run — empty findings → should_replan; active hypotheses with zero confirmed evidence → experiments recommended
  • LLM via MAL when available — critique is typed, not free-form chat
  • Confirmed / refuted experiments mutate hypothesis status and re-enter the evidence plane

Invariant

Nexus remains the reasoning kernel. TCSF owns the loop, the event bus (tcsf/events/), evaluation, and learning signals. Engines never import provider SDKs — they request completions through MAL by task_type.

Why this matters

Autonomous security research only earns trust when the runtime can refuse to overclaim. This note documents a shipped invariant in Nexus / TCSF — the kind of detail practitioners and search engines both need to evaluate the system honestly.

FAQ

Is TCSF a scanner?

No. Scanners are observation capabilities. TcsfKernel owns the research tick around Nexus: evidence → reflect → experiment → learn → evaluate.

Do engines talk to OpenAI/Anthropic SDKs directly?

No. Engines request completions through the Model Abstraction Layer (MAL) by task_type only.

Further reading