Bring us the problem. We'll take it on.

Autonomous machine decisions, domain-grade legal AI, quantitative trading, AI CAD, private models, GPU platforms — whatever it is, we listen to the problem first, then talk about whether it's doable and which partnership model fits.

Six specialist fields we've taken on

Millisecond control for autonomous vehicles, traceable legal reasoning, automated strategy search in trading, natural-language modelling for CAD, private model deployment, GPU server scheduling. Six very different challenges, each worked through.

  • VisionIMURangeFast · ReflexMid · ReasonSlow · PlanActionRLRe-sense
    01 · Autonomous machine decisions

    Drone / robot AI brain

    Hard partIt has to dodge obstacles within milliseconds and also understand the environment, plan, and finish multi-step tasks.

    ApproachThree layers of brain: real-time control in the Fast layer, single-step reasoning in Medium, multi-step planning and tool use handled by a multi-agent Slow layer. Action results feed back to sensing; success and failure feed back to the Slow layer as reinforcement learning, so the more it runs the better it judges.

  • FactsEvidenceStatutePrecedentCase graphEntity · Relation · TimeIssue analysisDraft filingEvery conclusion points back to the clause it cites
    02 · Legal collaboration

    Domain-grade legal AI

    Hard partFinding the statute isn't enough — it has to understand the case and produce judgements that can be cited and traced.

    ApproachUnderstand the background, analyse the case, surface comparable judgements and draft documents, with a case whiteboard and live retrieval during hearings.

  • Live feedHistorical feedAlpha engineStrategy searchSignalsBacktestRisk dashboardStrategies found automatically; one logic for backtest and live
    03 · Quant platform

    Quantitative trading

    Hard partStrategies get tested one at a time by hand — slow, and you never finish. Backtests and live signals share one pipeline, which makes it both slow and fragile.

    ApproachSearch for strategies automatically and filter out the ones history won't support. Hot flow and cold flow are separated, and an incremental DAG recomputes only the factors actually affected.

  • 3D modelSolid · ToleranceCodeParams · Constraints2D drawingDims · SectionsNatural languageAIReason · GenerateDescribe it in words; the code and the 3D model follow
    04 · Programmatic CAD

    AI CAD

    Hard partModelling requires CAD skill, and changing one parameter often means redrawing a whole section. The 2D drawings and the 3D model then have to be maintained separately.

    ApproachDescribe what you want in plain language; the AI generates parametric code and the 3D model grows straight out of it. The code acts as the translation layer, keeping drawings and model in sync both ways.

  • On your premisesTrainFine-tuneCompressQuantiseInternal APIAccess · AuditStaff useDaily workMonitoring & health checksUsage feedback · RL
    05 · Language, speech and vision models

    Private model deployment & training

    Hard partA trained model isn't a usable one. Performance, concurrent access, integration and operations are all still ahead of you.

    ApproachDeployment architecture planned around the hardware and the use case: fine-tuning, inference optimisation, API service layer, then resource scheduling and monitoring. Usage feedback loops back into training as reinforcement learning — the data never leaves the building and the model keeps getting sharper.

  • GPUStorageComputeSchedulerQuota · QueueQuotaVMContainerUsage flows back to the scheduler; the bill adds up
    06 · AI compute platform

    AIDC GPU cloud service

    Hard partA GPU server can't serve customers as it is. Resources, permissions and monitoring have to be integrated first.

    ApproachGPUs, storage and compute nodes connected to one control plane, with provisioning, permissions, mounts and container environments all handled automatically.

From the algorithm all the way to production

  • Algorithm

    • Turn the problem into something computable.
    • We choose the modelling approach and the method.
    • The core logic is written by us.
  • System design

    • How data flows and where state lives.
    • What breaks, and how it's contained when it does.
    • Whether it holds up as the scale grows.
  • Engineering

    • Frontend, backend, database, inference services.
    • Interfaces built around how the work is actually done.
    • What we deliver is something that runs.
  • Deployment & operations

    • Launch, monitoring, performance and cost.
    • When something breaks, the cause is findable.
    • After handover, you can maintain it yourself.

What kind of problem suits us

  • No off-the-shelf answer

    • Nothing on the market fits the requirement.
    • There's no standard solution — finding the best one is the work.
    • The answer comes from current research and first principles.
  • Cross-disciplinary

    • Stuck on the algorithm, the system and the domain at once.
    • Needs an architecture that holds up at scale.
    • Requires getting fluent in an unfamiliar field fast.
  • A long technical challenge

    • The target is world-class, not merely working.
    • The direction gets adjusted as you go, in steps.
    • It runs from research through to a usable product.

How it works

We say whether it's doable during the assessment. Where it isn't, we say so rather than taking it anyway.

  1. 01

    Talk about the problem

    One session
    • The problem first, money later.
    • We judge whether it's achievable.
    • Anything we can't do, we say on the spot.
  2. 02

    Technical assessment

    1–3 weeks
    • Break out the critical risks.
    • Explain how we intend to solve them.
    • Give an order of magnitude for time and scale.
  3. 03

    Choose a model

    By agreement
    • Revenue share, strategic partnership or funded R&D, depending on the problem.
    • Rights and deliverables written into the contract.
    • The product and the direction stay with you.
  4. 04

    Build together

    Long-term
    • Pushed forward jointly, with regular alignment.
    • Source code and data delivered continuously.
    • If the problem changes, we change with it.

Three partnership models

  • Revenue-share development

    • Low upfront development fee, revenue share afterwards.
    • Buyout available on agreed terms.
    • Suits problems where upfront cost is the constraint.
  • Strategic partnership

    • A long-term arrangement over fixed cycles.
    • Fixed capacity, with your problem first in the queue.
    • Suits a product line that will keep expanding.
  • Funded R&D

    • A single hard or large-scale project.
    • Can be combined with government R&D grants.
    • Suits work with a clear technical breakthrough as the goal.

Common questions

Is the first consultation charged?

No, and there's no commitment. Treat it as both sides finding out whether this is a fit. If it isn't, say so.

Who owns the source code?

You do, on delivery. We don't lock the code into a platform of ours that you can't leave.

Will you take or leak our data?

The data is yours. We only touch what delivering the service requires, and that can be written into the contract.

Do you stay involved after launch?

Yes. Ongoing improvement after launch is part of the job. Whether it becomes a long-term arrangement is your call.

Can we switch vendors later, or maintain it ourselves?

Yes. The source code and the data are in your hands. Nothing here depends on us staying.