Research Labsconsulting

Eptalights Research Labs is the part of the company that works on hard problems before they are products. We take on research and engineering engagements where the question is not “which tool should we buy” but “how do we make this work, and how do we know that it does”: finding bugs a scanner cannot see, making a compiler produce something safer, hardening a runtime that cannot be rewritten, getting a data platform to stop falling over, or building the deep technology that does not exist yet.

We also build: when no existing tool does the job, we design and ship the technology itself. Our work sits where machine learning meets systems. Most of it is code that has to be correct, on a deadline, in someone else’s codebase.

What we work on

AI research

We build and evaluate models for software and data tasks: code understanding, program repair, retrieval over large codebases, and agents that act on real systems. The focus is on measurement. Every engagement starts with an evaluation harness, a held-out set drawn from your own code or data, and a baseline the new system has to beat. A model that cannot be evaluated is a demo.

• Retrieval and long-context pipelines over monorepos, issue history and documentation
• Agent design with explicit tool contracts, sandboxing and trace-level observability
• Failure analysis: where a model is wrong, why, and what it costs

Model fine-tuning

When a general model is close but not good enough, we adapt it to your domain and prove the gain on your own evaluation set. Most of the work is in the data and the measurement, not the training run.

• Supervised fine-tuning and preference optimization (DPO and related methods) on code, security and structured-output tasks
• Parameter-efficient methods (LoRA, QLoRA) for fast iteration, and full fine-tuning where the gain justifies the cost
• Training-data pipelines: collection, deduplication, decontamination against the test set, and synthetic data with verifiable labels
• Distillation of a large model into a smaller one that is cheap enough to run on every commit or at the edge
• Evaluation and regression testing: capability gains, plus what the model forgot along the way
• Serving: quantization, batching, latency and cost per request, deployed in your environment when the data cannot leave it

Code analysis and review

This is the area we know best, and the one behind EptaKode. We combine classical program analysis with language models: the analysis supplies soundness and structure, the model supplies judgment about what matters.

• Static analysis: AST, control-flow and call-graph construction, SSA and intermediate representations
• Dataflow and taint analysis, including inter-procedural and field-sensitive approaches
• Variant analysis: take one confirmed vulnerability and find every sibling of it across a codebase
• Bug discovery in C, C++, Rust, Go, Python and JavaScript, with proof-of-concept inputs rather than a list of warnings
• Review automation that comments on a pull request only when it can explain the failure path

Compiler tooling

We write the infrastructure that sits inside and around compilers, and we are comfortable reading a compiler we did not write.

• LLVM and MLIR passes, custom IR dialects and lowering pipelines
• Compiler-based instrumentation: sanitizers, coverage, tracing and profiling hooks
• Source-to-source transforms and codemods that preserve semantics at scale
• Language front ends, parsers and language servers for internal DSLs
• Build and toolchain hardening: reproducible builds, hardening flags, symbol and debug-info pipelines

Runtime protections

Not every system can be rewritten in a memory-safe language this year. For the ones that cannot, we add protection at the layer underneath.

• Memory-safety mitigations: allocator hardening, bounds and lifetime checking, control-flow integrity
• Binary analysis and rewriting for code you have no source for
• Sandboxing and privilege reduction: seccomp, namespaces, capability-based designs, WebAssembly isolation
• Runtime detection: anomaly signals from syscalls, eBPF probes and process behavior, tuned to keep false positives low enough that someone still reads the alerts
• Exploit mitigation review: what an attacker still gets after your current defenses

Data engineering

Research output is only useful if the data under it is trustworthy, so we also build the pipelines.

• Batch and streaming pipelines, with idempotent stages and replayable history
• Warehouse and lakehouse design, schema evolution and data contracts
• Embedding, indexing and vector-search infrastructure sized for what you will actually query
• Data quality: lineage, tests on the data itself, and alerts that fire before a dashboard is wrong
• Cost engineering: finding the three queries that account for most of the bill

Building deep tech

Some problems have no off-the-shelf answer, so we build the technology itself. We take an idea from a research question to a working system, and we stay on it until it runs under real load.

• Feasibility studies and technical due diligence: what is possible, what is not, and what it would cost to find out
• Prototypes that test the riskiest assumption first, built to be thrown away or to grow into the product
• Core engines and SDKs in Rust, C++, Go and Python: analysis engines, inference runtimes, query and indexing layers
• Performance engineering: profiling, memory layout, parallelism and GPU work, measured against a budget set at the start
• Research-to-production: turning a result that works in a notebook into a service with tests, monitoring and a release process
• Co-development with your team, so the people who will own the system help build it

How an engagement runs

Stage	What happens	What you get
Scoping	A short call and read-only access to a representative slice of your code or data	A written problem statement
Baseline	We build the evaluation first: ground truth, metrics, and the current state measured honestly	A number to beat
Research	Short cycles, each ending with a result you can inspect, including the ones that failed	Weekly written notes and working code
Hand-off	Documented tooling that your engineers can run, change and own	Source, tests, a runbook and a walkthrough

We work in your repository and your CI where we can. We do not leave behind a model or a tool that only we know how to run.

How we work

Reproducible. Every claim comes with the script that produced it. If a result cannot be rerun, we do not report it.

Honest about negatives. A hypothesis that does not hold is a finding. You will see it in the notes, with the evidence.

Sound where it matters. We use heuristics and models to prioritize, and we use proofs, type systems and exhaustive checks where a wrong answer is expensive.

Your code stays yours. Work happens under NDA, on infrastructure you control where required, and your code and data are never used to train anything outside the engagement.

Where we are a good fit

• A security or platform team with a large codebase and not enough reviewers
• A product company that wants an AI feature measured against real usage before it ships
• An infrastructure team carrying C or C++ it cannot replace, and needing protection now
• A data team whose pipelines are correct on a good day and unknowable on a bad one

Where we are not

We do not do generic AI strategy, penetration testing as a checklist, or staff augmentation. If the work is not a technical problem with a testable answer, we will say so on the first call and point you to someone better suited.

Work with us

Book a call and tell us the problem, with as much of the code or data context as you are able to share. You will get a straight answer on whether it is a fit, what a first phase would involve, and what would count as success.