Forward Deployed Engineer - Data

Commotion builds an AI operating system for large enterprises, and at the centre of it is a context graph: a live model of an organisation’s entities, the relationships between them, and the decisions taken across them, assembled from the systems that already run the business.

Most enterprise AI stops at retrieval over documents. We think the layer that matters next is structural — resolved entities, explicit relationships, and a record of every decision and the reasoning behind it. A dashboard tells you what happened. A context graph lets an agent work out what to do about it, and show its working.

We build this inside our clients’ own environments, where the data is real, messy and consequential. We are backed by Tata Communications, and we are early enough that the people joining now shape how this gets built.

This is the engineer who sits between a client’s business problem and their data. You work out what the business is actually trying to decide, model the data so that decision is answerable, and write the logic that makes it true. Then the application layer and the modelling work build on what you produced.

You are not building the ingestion platform — that exists, and other engineers own it. You are the one who understands a specific client’s data deeply enough to drive it correctly, and who automates what would otherwise be done by hand on every engagement.

• Understand the business problem first. Sit with the people who own the outcome, work out what decision is being made, what question has to be answerable, and what data would have to be true for the answer to be trusted.
• Model the domain: the entities that exist, the relationships between them, the attributes that matter, and how the client’s source tables map onto all of it.
• Write the enrichment and derived logic — the objects and properties that do not exist in any source system and have to be computed, along with the backfill and the refresh that keeps them current.
• Encode business logic into data views in SQL and Cypher, so that the application layer and the modelling work consume a correct, reusable definition rather than each rebuilding it.
• Run entity resolution against the configuration our machine learning engineers own: supply the match keys for a client’s data, review what merged and what did not, work the exception queue, and escalate the hard cases rather than tuning the matcher yourself.
• Do the analytical work underneath all of it — profile source data, find what is abandoned or quietly wrong, reconcile against the system of record, and raise what the client needs to know before anything is built on top.
• 
  
• Work out what public or third-party data the use case needs — registries, reference sets, market or geographic data — and bring it in through our existing connectors rather than one-off scripts.
• 
  
• Use LLMs as a tool where rules run out: extraction from unstructured sources, classification, structured output — with an evaluation set, not vibes.
• Automate the per-client work so the second engagement is faster than the first.

• 4 to 7 years as a working engineer. You write code every day and you will keep doing so here.
• Excellent SQL, and a graph query language in production — Cypher preferred, or the ability to demonstrate you will be fluent in weeks.
• Strong Python for profiling, transformation, extraction and analysis.
• Real data analysis depth. Distributions, cohorts, reconciliation, sanity checks. You can find the thing that is wrong in a dataset nobody has looked at properly.
• Data modelling experience in some form — dimensional, semantic layer, MDM, ontology — where you decided the model rather than implemented someone else’s.
• Applied data science fundamentals: clustering, similarity, scoring, statistical validation. Enough to do the analytical parts of this job well, not enough to be a full-time modeller.
• Practical LLM application experience: extraction and classification pipelines, structured output, and how you evaluated whether the output was good.
• You can hold a conversation with a client SME about what a field means and keep asking until you get a real answer.

• We are not asking you to invent a framework from scratch. We are asking you to know what to reach for, where it breaks, and how you found that out. Bring opinions about tools you have run in production, including ones you would never use again.
• Every engineer here works with Claude and agentic coding tools daily, for exploration, transformation code, test data and analysis scaffolding. Our delivery pace assumes it. Be ready to describe how these tools changed your workflow and where you have learned not to trust them.
• This is client-facing work on client sites in India. Expect travel, and expect to sit with the client’s own data owners.

• Graph databases in production, including modelling decisions and query tuning.
• Exposure to entity resolution or record linkage, enough to know what a matching system needs from you.
• Document extraction at volume.
• dbt or an equivalent semantic or transformation layer.
• Having built the automation that replaced your own manual process.