Vidatta is a security-operations learning platform. Its purpose is to help people practise a complete decision, not merely find an alert on a screen. A useful SOC result explains what was observed, how reliable the evidence is, what remains unknown, who may decide the next step, and whether an approved action actually worked.
The platform brings together investigation, detection engineering, vulnerability analysis, configuration management and governed AI exercises. These are separate learning paths with different permissions. A recorded exercise is evidence of that exercise, not a claim that every product integration is installed or that a learner is qualified for an entire job.
Start with a bounded question
An analyst begins with an issued assignment: the permitted identity and site, the exact case or source version, the question to answer and the allowed actions. The alert is a lead. It is not proof of compromise. Before drawing a conclusion, the analyst checks the event window, source coverage and freshness, asset context and any relevant change record.
For example, a synthetic vendor-access scenario can show a login followed by remote access and a scheduled task outside the one supplied maintenance window. That pattern deserves investigation. It does not, by itself, prove malicious intent: the supplied records may be incomplete, the task content may be benign, or another approval may exist. The analyst records those alternatives and asks for the missing evidence.
Build an evidence chain
Every important sentence should be traceable to an observation. The working record separates:
- Observed: what a retained source actually records, with time, scope and provenance.
- Inferred: an interpretation consistent with those observations, including alternatives.
- Proposed: a search, preservation step or response that has not yet happened.
- Verified outcome: an independent observation after an authorised action.
A healthy connector or a recent heartbeat does not prove that the underlying events are fresh. An empty search is not proof that nothing happened if the source was absent, delayed or outside the search window. A response request is not an executed response, and a successful API response is not necessarily the required real-world effect. Vidatta's training stresses these distinctions because they are where attractive dashboards can mislead.
Move the decision to the right role
Level 2 produces a reproducible investigation and a handover. Level 3 challenges the handover, coordinates the incident, weighs service impact and obtains the right authority. Detection experts test an exact rule change against positive and benign examples, then distinguish a promising comparison from deployed effectiveness. Consultants translate the evidence and uncertainty into choices a client can own. Architects and platform engineers make the service, controls and recovery measurable enough that those decisions can be trusted.
The platform's protected exercises use scoped identities and versioned work. Learner submissions, reviewer decisions, engineering repairs and operator changes are different records. One role does not silently substitute for another. If a write returns an uncertain result, the next step is to reconcile the exact request and retained receipt, not repeat it blindly.
Test changes, then test restoration
A detection or configuration proposal states the objective, exact candidate, comparison population, expected positive and benign outcomes, authority, window, stop criteria and reversal plan. The team checks what changed and what did not. A reduced alert count is not automatically an improvement: a rule can remove noise while also missing a true positive.
Where an exercise includes a controlled trial, the record should distinguish proposal, approval, execution, observation, reversal and restored observation. A diagram of that sequence is useful teaching material, but it is not proof those steps ran. The same standard applies to recovery: a backup exists only as a candidate recovery point until an appropriate restore and readback have been demonstrated.
What a learner can take away
The strongest output is a concise, evidence-led decision product: a bounded timeline, source and coverage notes, plausible alternatives, the proposed owner, an action request and a verification plan. A reviewer should be able to reproduce the claim or see it clearly labelled as uncertain. The learner then revises the work against feedback rather than treating a score or a single successful search as the entire story.
The training material includes disclosed synthetic examples and private, separately issued practicals. The examples teach the method; they are not unseen assessment data, customer telemetry or an instruction to act on a live environment. Product-specific experience still requires the relevant licensed service, authorised environment and independent evidence. The goal is not to make a simulated SOC look complete. It is to make the boundary between practice, installed capability and demonstrated competence visible.