Torq Retrospect: Your SOC’s Past Shouldn’t Be the Price of Switching

Noam Cohen is Head of Artificial Intelligence at Torq, where he leads the AI research and engineering work that powers the platform’s agentic SOC capabilities. Noam work at Torq spans the core AI systems behind autonomous threat investigation, SOC memory, confidence-based decision thresholds, and the guardrails that make agentic AI trustworthy enough to act in production security environments.

The new platform is approved. The pilot went well, the budget is signed, and the team is ready to move. Then someone in the kickoff asks the question nobody planned for: what happens to our history?

Three years of closed cases. Every alert someone already proved benign. Every host that turned out to be the red team’s box. Every incident write-up that explains why a particular 2am login pattern is fine for that one service account. That history is where most of a SOC’s hard-won knowledge lives, and it sits in a schema the new platform has never seen.

The usual approaches are both bad. Spend a month building a migration pipeline, or go live with an AI that knows nothing about you and let your analysts re-teach it from scratch. Plenty of teams pick a third option: they don’t switch.

We built Torq Retrospect so that the question has a short answer. Retrospect takes your case history from whatever system holds it today and rapidly makes it usable in Torq, already validated, indexed, and recency-weighted.

Every SOC Switch Starts With Amnesia

Think about the last time you set up a new phone. Ten years ago, that meant losing half your contacts and emailing yourself photos. Now you put the two phones next to each other, and twenty minutes later, your apps, messages, and photos are just there. Nobody would buy a phone that made them start over.

SOC platforms are still in the ten-years-ago era. Switching tools, whether from a legacy SOAR, a ticketing system, another AI SOC, or an MDR’s case portal, usually means your new system starts with an empty case history.

That matters more for an AI SOC than it did for older tools. A playbook engine doesn’t care what happened last year. An AI that triages alerts does. When it sees a suspicious PowerShell execution on a finance workstation, the most useful thing it can know is that your team saw the same pattern forty times last quarter, and every one of them was a patching script. Without that precedent, the AI reasons from first principles every time (and first principles are exactly what produces the false positives your analysts are tired of closing).

Traditional Migrations Move Data and Lose the Meaning

So teams migrate. Someone exports the old cases. Then the bespoke pipeline work starts: cleaning malformed records, matching the old fields to the new ones, deduplicating cases that were merged or reopened, and converting formats that never quite line up. Teams we’ve talked to say this takes anywhere from weeks to a month, and that’s when it goes well.

Time isn’t the only problem. A traditional migration has three ways to fail quietly:

1. Loss in conversion. A field that doesn’t map cleanly gets dropped, flattened into a free-text blob, or truncated. Nobody notices until an investigation needs it.
2. No proof it worked. Ensuring nothing is lost means building a validation process alongside the pipeline. Most teams spot-check a few cases and hope for the best.
3. Imported isn’t usable. Even if every record arrives intact, the new system still has to find the right one at the right moment. Dump three years of cases into an index with equal weight, and the 2023 incident tied to a decommissioned server competes with last week’s case on the same alert type. The history is all there, and it’s mostly noise.

In 2026, there’s an obvious shortcut: Point an LLM at the old cases and have it rewrite each one in the new format. It sounds efficient. It also means a probabilistic model is regenerating thousands of records you may one day need in an audit or a post-incident review. One invented hostname or one “summarized” timeline, and your history is no longer your history.

We wanted neither.

Torq Doesn’t Recreate Your Data. We Learn How to Copy-Paste It.

The hard part of a migration was never moving bytes. It’s translation: working out that a field called src in one system, Attacker Address in another, and Origin IP in a third all mean the same thing in Torq’s data model. Field names across security tools agree only loosely. Some are obvious synonyms. Some mean the same thing only in context. Some look alike and mean different things.

That kind of loose-similarity matching is exactly what LLMs have become good at. So Retrospect uses the model where it’s strong, on the schema, and keeps it away from the records.

Retrospect works in four steps:

1. The LLM reads both schemas. It sees your source system’s fields and Torq’s case data model.
2. It proposes a mapping. Each source field has a destination in Torq’s model, including cases where the names are only mildly similar.
3. The mapping becomes deterministic. Once validated (more on that below), it’s a fixed translation. Every record goes through the same rules.
4. The records are copied, not regenerated. The value in your old system is the same as the value in Torq. The model wrote the instructions for the move. It didn’t touch the cargo.

The LLM’s work happens once per source schema, not once per case. That’s why the job takes minutes instead of weeks. It also means the thing you have to get right is the mapping, and you check it once instead of auditing every record.

Nothing Falls Through Without Someone Seeing It

A deterministic copy still raises the obvious question: what about the fields that don’t map?

Retrospect measures them. Every field the mapping doesn’t cover is counted as unmapped data, so coverage is a number you can read, not something you find out about three months later. If a source field has no home in Torq’s model, it shows up on that list. It doesn’t vanish quietly.

Then a human looks. Before the migration is called done, someone checks a representative sample of migrated cases against the source. The person checking reviews the translation on cases they recognize. They aren’t auditing a black box.

Silent drops and flattened fields, the things that make traditional migrations risky, show up before go-live instead of in the middle of an investigation.

Imported Isn’t Ready Until It’s Indexed

Getting the records across solves the first problem. Retrospect’s definition of done is stricter: the history has to be usable in triage and investigations the moment the migration finishes.

Migrated cases land in Torq’s case management already indexed, and the index knows when each case was created. Recent cases are more relevant than older ones. When Torq Recall looks for precedent on a new alert, last month’s resolution of the same pattern outweighs a two-year-old case from before your environment changed.

That keeps old data from turning into noise. You don’t need to curate your history before migrating it or decide which years are still trustworthy. Bring all of it. Recency weighting means the old cases are there when nothing newer matches, and stay out of the way when something newer does.

Two Thousand Cases, Under an Hour

One customer brought over 2,000 cases from the past year. With Retrospect, those cases went from export to imported, indexed, and ready for alert triage and investigations in under an hour. Compare that to the traditional, legacy path we described above — bespoke pipelines, cleaning, matching, and dedupe — which takes weeks to a month.

That’s just one customer’s migration. A messier source schema or many more years of history will take longer. The expensive part — translating the schema — still happens once, so more cases don’t mean more translation work.

Next, Your History Becomes Judgment

Torq Recall uses your history as memory: when a new alert comes in, it finds the precedent. That’s the first payoff, and it’s live from the hour the migration finishes.

The second payoff is Torq Reflex, which trains a model on your analysts’ past decisions, so that the AI actually learns your team’s judgment, instead of matching cases one at a time. It picks up the “we always escalate this one” instinct that no prompt captures.

A model like that needs decisions to learn from. Retrospect brings them across, each case with its analyst’s verdict attached. Your migrated history is the material Reflex learns your team’s judgment from, so it doesn’t have to start from zero after a switch.

What Torq Retrospect Means for Your Team

• Switch without starting over. Your closed cases and their verdicts come with you, in Torq’s data model, from day one.
• Minutes, not a migration project. No bespoke pipeline, no month of cleaning and matching. In the customer case above, it took under an hour.
• Your records stay your records. The LLM translates the schema once. Your data is copied, never regenerated.
• Coverage you can see. Unmapped fields are counted, and a human checks a sample, so gaps surface before go-live.
• History without noise. Recency-weighted indexing puts recent precedent first, so you can bring everything without curating it.
• The foundation for learning. The same history powers Recall today and gives Reflex the decisions it learns from.

Bring Your SOC’s Past With You

The reason teams stay on tools they’ve outgrown is rarely the tool itself. It’s everything they’ve built inside it. Every SOC that has switched platforms knows the cost: weeks of migration work, or a new system that has to be taught everything again.

The cost of adopting better technology is a thing of the past. With Retrospect, it doesn’t have to be.

Torq Retrospect is part of our series on Context, Memory, and Learning in the AI SOC, alongside Recall, Reflex, and the Torq Context Graph.