AI/ML Engineer: SIGINT & ELINT
Auric AI Labs
Location
🇮🇳 Bengaluru, India
Type
full_time
Salary
Undisclosed
Posted
2w ago
Job Description
About the Role
Auric AI Labs is developing the world's most advanced AI-powered vision intelligence platform for defense applications. We are building an AI-native intelligence system from scratch. No legacy DSP pipeline, no AI-as-classifier-stage, no hybrid compromises. We need an engineer to build the deep learning models that detect, classify, geolocate, and fingerprint radar and communications emitters directly from raw IQ data. Why this role exists Most “AI in SIGINT” today is AI bolted onto a 1990s DSP pipeline as a final classification stage. Filter, threshold, extract feature, then hand the leftovers to a small neural network. Each stage before the network throws away information the network could have used. Each hand-crafted feature is a prior the model is forced to inherit. We are not doing that. We are betting that an AI-native architecture, where deep learning operates on raw IQ data with minimal pre-processing, learns its own features, and replaces the deterministic stack rather than supplementing it, delivers a 5-10x improvement on every metric that matters: detection in low SNR, classification of unknown waveforms, specific emitter ID, real-time anomaly detection, cognitive EW. This is not an “AI feature” inside a conventional product. The model is the product. The actual problems • The signals are designed to defeat you: A modern LPI radar deliberately spreads its energy below the noise floor. A frequency-agile emitter changes frequency every pulse. Your job is to find structure that has been deliberately hidden. • You will not have real training data: Zero, for the signals that matter most. Before you can train a model, you have to answer a harder question: what does it mean for a model trained entirely in simulation to be trustworthy in the real world? You will design the synthetic data pipeline, the channel models, the validation methodology, and the test for knowing when your simulator is wrong. • Every emitter is unique: Two radars of the same model number have hardware differences (oscillator drift, amplifier non-linearities, timing jitter) that fingerprint them individually. The problem is not “which class of radar,” it is “have I seen this specific transmitter before, even in a different mode, even years ago.” Open-set, fine-grained, unlabelled. • The DSP world will tell you it cannot be done: Some of their reasons are right. You will need to engage with them honestly, then figure out which ones are wrong and why. Who we are looking for Not a list of traits, those describe nothing. Specific, observable things we will recognise when we see them: • AI-native instinct: Your first instinct on a new problem is not “what filter, transform, or heuristic applies here” but “what should a learned function take in, what should it output, and what is the right inductive bias.” You think in terms of data, loss, and architecture the way a DSP engineer thinks in filter coefficients. You see hand-engineered features as priors to be questioned, not assumed. • You reason about whether a model fits its data: Not just whether it trains. You can look at a problem and argue, before writing code, why a particular architecture is or is not suited to the structure of the data it will see. You know that complex-valued signals, long-range temporal dependencies, and small distribution shifts each break specific assumptions, and you can name which. • You design experiments that can fail: Most ML work tunes until the loss goes down. Yours starts with the question: what result would prove I am wrong. You build the falsifying test before you build the model. With synthetic data and no real ground truth, this discipline is the entire difference between research that works and research that only seems to. • You read papers to find what the authors did not say: You reproduce a paper and notice the seed dependence the authors quietly omitted, the dataset preprocessing buried in the appendix, the hyperparameter that does most of the work. This habit is rare and it is what separates engineers who absorb a field from engineers who collect summaries of it. • The best work on your CV is work nobody assigned: A paper you reproduced because the result seemed too clean. A side project that became four months. An idea you kept thinking about after the class or job that introduced it had ended. The single hardest thing to fake. • You can turn a vague objective into a defensible ML problem: “Detect this radar” is not a specification. You can take an objective in plain English, decide what the inputs are, what the outputs should be, what the right loss is, and what evaluation would actually mean the system works in the field. This translation is most of the job.