Scoped, documented, and handed over.

• Research engagement

  A defined question about a market, an instrument or a strategy, answered with a dataset, a stated method and a written conclusion, including when the conclusion is negative. The deliverable is the evidence and the reasoning, not a recommendation: what was tested, how, what would have counted as a negative result, and what the data actually supports.

  Typical shape: a hypothesis agreed in writing, a data audit before any modelling, a documented evaluation scheme fixed before results are seen, and a written report with the code that produced every figure in it.

• Build

  A specified system delivered end to end: research, backtest, execution and monitoring, with documentation and handover to the people who will run it. Scope is fixed before work starts, and changes are re-scoped explicitly rather than absorbed silently, because silent absorption is how a build becomes undeliverable.

  Typical shape: data and connectivity first, because everything downstream depends on them; then the research and evaluation layer; then execution against a paper or test environment; then production with risk controls, reconciliation and monitoring in place before any capital is at risk.

• Review & rescue

  An independent look at an existing stack (methodology, code and risk controls) with findings, priorities and a realistic path to production. Often the fastest way to establish what a system is actually doing as opposed to what it was intended to do, and the two are rarely identical in a system nobody has audited.

  Typical shape: reproduce the existing result first, which is frequently where the engagement ends and the finding is delivered; then separate defects from design decisions; then a prioritised list distinguishing what is wrong from what is merely unfamiliar.

Scoping is a short conversation about what exists now, what it needs to do, and whether this is the right fit. It is not a sales call, and it can end with a recommendation to go elsewhere. That is a real outcome rather than a courtesy: taking on work outside where the method is strong means learning on a client's budget, which is a bad trade for both sides.

Three things get established before a proposal exists. What question is actually being asked, which is often different from the question first stated. What data exists and in what condition, because a project's timeline is usually decided by data rather than by modelling. And what would count as success, stated precisely enough that both sides would recognise failure.

Method stated up front

What will be tested, how it will be evaluated, and what would count as a negative result. All agreed before the work rather than after the numbers are in, because an evaluation scheme chosen once results are visible is not an evaluation scheme.

Costs before conclusions

Spread, slippage, commission, financing, borrow and assignment are priced in before anything is described as an edge. Gross performance is treated as an intermediate number, never a finding.

Data audited before it is modelled

Coverage, gaps, revisions, survivorship, corporate actions and timestamp discipline are checked first. Most results that fail to reproduce fail here rather than in the model, and finding it early is the difference between a short engagement and a wasted one.

Fixed scope, explicit changes

Engagements are typically fixed-scope and quoted after scoping. Where the work reveals that the original scope was wrong, that is raised as a decision rather than absorbed, with the cost and the alternatives stated.

The test of a delivered system is whether the client's team can operate, modify and debug it without its author. That is a design constraint from the first commit rather than a documentation exercise afterwards, and it is why the code is written to be read.

Code and research

The client owns both. Source, with history, in the client's own repository. Research is delivered so that every figure and number can be regenerated from the code and data supplied, not just described.

Documentation that matches

What the system does, what it assumes, how it fails, and what to do when it does. Runbooks for the operational paths that matter: start, stop, reconcile, recover from a disconnect, and what to check before capital is committed on any given day.

The assumptions, written down

Every system encodes decisions that are invisible once it runs: fill assumptions, timestamp conventions, holiday handling, what happens on a partial fill or a halted venue. These are stated explicitly, because they are what a future maintainer will need and what a silent failure will exploit.

A walkthrough

Live, with the people who will run it, working through the code and the failure paths rather than the happy case. Followed by a defined period of support while the system runs under the client's operation.

Engagements fail in a small number of recognisable ways, and naming them up front is cheaper than discovering them at the halfway point.

The data was not what it was believed to be

The most common cause by a wide margin. History that is not point-in-time, a feed that differs from the production feed, timestamps that mean something other than what was assumed. This is why data is audited before modelling, and why an engagement occasionally converts into a data engagement.

The question kept moving

A scope that expands without being re-scoped produces a system that does several things adequately and nothing well. Changes are welcome; absorbing them silently is not.

The answer was unwelcome

Research that concludes a strategy does not work has delivered its result. Where a client needs a specific conclusion rather than an answer, that is a mismatch worth identifying during scoping rather than at delivery.

Nobody was going to operate it

A system delivered to a team with no capacity to run it will stop working, and the reason will not be technical. Where that is the situation, the honest options are a smaller system or an ongoing arrangement, and both are better than a handover into a vacuum.

Work begins with that short scoping conversation. If it is not the right fit, you will be told so.