I’ve been building a program that started as “I need to stop wasting time on tool output chaos” and turned into something that feels… different.

This is not a scanner. It’s not a SIEM. It’s not “AI security.”

It’s an engine that runs security investigations.

Most security workflows still look like this:

Run tool → stare at output → manually connect dots → rerun different tool → forget what you already tested → repeat

This program tries to turn that into:

Run tool → interpret signals → decide what matters → pick the next action → keep escalating until the lead is either proven or dead

So instead of “here are 900 findings,” the output is closer to: • what was tested • why it was tested • what changed the investigation’s direction • what got confirmed vs ruled out • what the next step would be if you kept going

The part that makes this unusual

I hit the wall where security automation always becomes a dumpster fire: scripts calling scripts calling scripts, YAML pipelines that grow teeth, glue code everywhere, no real structure, no replayability.

So I did something that sounds insane:

I built a purpose-built programming language inside it.

Not because I wanted “my own language,” but because security workflows need a way to be expressed as real programs: repeatable, constrained, auditable, and not dependent on a human remembering the next step.

The language exists for one reason: security automation should not collapse into spaghetti.

What I need help with

I’m not posting the full repo publicly yet, but I do want real critique from people who’ve built: • orchestration engines • DSLs / interpreters • security automation frameworks • pipelines with state, decision-making, and evidence trails

Please let me know if you’re interested in reviewing.