Six stages, and the order is the argument. Measurement comes before implementation, a deployed slice comes before a feature set, and the escalation path gets designed before the happy path. Everything after that is ordinary careful engineering.
engineering / stages
One call with the people who know the problem, then a written brief back to you within two working days: what we understood, what we think the hard part is, what is explicitly out of scope, and which of the four engagements fits. If none of them fits we say that instead of reshaping your problem to match a price list.
Output: A written brief and a named engagement, or an honest noBefore any prompt is written we build a labelled set from your real examples with your domain experts, split by category, with a held back portion. The pass threshold goes in writing, with the consequence of missing it agreed at the same time. This is the week that makes every later argument about quality a number rather than an opinion.
Output: A labelled evaluation set, a harness, and an agreed thresholdOne path through the system, end to end, running in your cloud account, usually inside the second week. Not a prototype on a laptop. Deploying early is how integration risk, credential problems and data access surprises surface while there is still time to change the plan.
Output: A deployed slice on your infrastructure and a working pipelineEvery week ends with a working demonstration against the evaluation set rather than a status document. You see the score, the failures, and what we are doing about them. Anything at risk is raised in the week it becomes at risk, not in the week it becomes a problem.
Output: Shipped increments, a score per week, and a visible risk listGuardrails on the output path, escalation payloads, tracing, cost and latency instrumentation, alerts wired to people who can act, and runbooks for the two or three ways this specific system fails. Where the system can act, it shadow runs against live traffic before it is granted authority.
Output: Guardrails, dashboards, alerts, runbooks and shadow run resultsYour engineers make the last change while we are still there to watch. Repository, infrastructure as code, evaluation suite, documentation and access all sit with you, and none of it depends on an account we control. If you want us to stay, that is an Embedded AI Pod with its own scope, not a dependency we engineered into the build.
Output: Code, IP, docs, evaluation coverage and a team that can run itengineering / the gate
This is the mechanism that turns a disagreement about a prompt into a number that moved. It is also the reason a regression is caught by a machine on a Tuesday rather than by a customer on a Friday.
engineering / standards
E1
No implementation begins against an unmeasured target. If your domain experts cannot spare the time to label a set, that is a real constraint and we plan around it, but we will not substitute a vibe check and call it quality assurance.
E2
Your cloud tenancy, your repository, your credentials, issued by you and revocable by you. Nothing we build depends on infrastructure we control, so the end of an engagement is a handover rather than a migration.
E3
One interface for every model call, prompts versioned as artefacts rather than scattered string literals, provider selection as configuration, and an evaluation suite that can run against more than one provider. Changing provider should cost a configuration change and an evaluation run.
E4
A lookup table, a query or a rule is not a worse answer for being unfashionable. We use a model for the part of the problem that genuinely needs judgement and ordinary code for the rest, which is usually most of it.
E5
We work in your repository, on branches, through your review process. If your team cannot review what we wrote, we have handed you a dependency rather than a system, whatever the demo looked like.
E6
Every engagement scope names what it excludes. Every capability page names where the approach stops working. A buyer who finds the limits on the website is not surprised by them in month three.
engineering / refusals
Published because it is the fastest way for you to find out whether this is a fit, and because a supplier who will build anything will eventually build you something you have to switch off.
R1
Anyone who does is quoting a number measured on somebody else's problem. What we will do is agree how it gets measured, and put the threshold in the contract.
R2
If an action cannot be reversed or held for approval, it stays a recommendation. This is a design position, not a negotiating one.
R3
If the answers live only in three people's heads, the first project is writing them down. Retrieval over a gap returns a confident, fluent, wrong answer.
R4
Some problems are solved by a product you can buy this afternoon. Saying so costs us one engagement and saves the relationship.
R5
A model introduced where a condition would serve adds cost, latency and a failure mode, in exchange for looking modern in a release note.
R6
Documentation, evaluation coverage and knowledge transfer are contractual deliverables. The exit is designed at the start, because a supplier who is hard to leave is a supplier you stop trusting.
engineering / terms
These are terms rather than measured averages. They are what we commit to at signature, and they are the same on all four engagements.
First response
One working day, from a person, not a form autoresponder
Contract to first commit
5 business days
Code ownership
Yours in full, assigned in the contract, from the first commit
Repository
Yours. We work on branches through your review process
Infrastructure
Your cloud account, credentials issued and revocable by you
Overlap
Mornings US eastern, full days for Australia and the Gulf, async handoffs for the rest
Paperwork
NDA, IP assignment and security review before kickoff, not after
Currency
USD
It costs you an hour, and it ends with a document you keep whether or not you continue.