fde-framework · bring an engagement

Should you actually build this AI system?

You have one workflow where everyone says AI should help and nobody has a defensible answer for what to build, whether it would beat the people doing it now, or whether to build it at all. In two weeks, with your real examples and a measured baseline, you get that answer in writing.

build itchange the designdon't build it

Five founding engagements, no fee

The framework behind this has run four complete engagements in public and none for a client yet. The first five that run to its written protocol are the measurement; that is why they are free. Your data stays in your environment. A stop is a legitimate outcome, and it costs you less than a system that should not have been built.

Bring a workflow What each side gives and gets

How it goes

  1. You bring one workflow, described the way you would to a colleague, and the person who owns it.
  2. You bring real examples: inputs with the answers your people gave, a few hundred if you have them, forty at the least. They become the exam, and a holdout the build never sees.
  3. The baseline is measured: volume, time per item, hours, error and exception rates. Stated figures are accepted and marked as stated.
  4. Someone on your side signs the outcome contract: which number this exists to move, from what to what, measured how, by when. Nothing is built without it, or without a written reason it cannot be set yet.
  5. The architecture is decided on the evidence, with what was rejected and why. Plain code where plain code is enough; a model only where the evidence earns one.
  6. It is built only if the evidence says so, scored on cases nobody chose, and handed over with the runbook, the risks and the record. Or it stops, and the record says why.

Three shapes, one first

A decision, two weeks

Should this be built? Baseline, architecture with alternatives, the exam, a prototype where the evidence supports one, and the written answer. The first five engagements are this shape.

A delivery, four to six weeks

Everything above, plus a deployable system for your environment, the runbook, and handover to your team. Agreed separately, after the decision.

Production, eight weeks and up

Deployed, watched for drift, incidents on the record, adoption and the contracted metric measured in the field. Not offered until a delivery has run.

What it has run on

Four complete engagements on real data, every refusal preserved: 626 scanned receipts, 2,034 consumer complaints, 58 technical standards, and 13,083 bank support messages across 77 queues, where the router stopped itself once on its own stop condition and the card now says it routes better than the bank's people and routes less of it. Production-proven it is not, yet; the pages say so themselves.

Who this is for

A company of fifty to five hundred people with a workflow that five to fifty of them touch every day, historical examples of it, and one person who owns its number. Support triage, document processing, claims, compliance review, invoice handling, internal routing. It is also for a company whose AI pilot did not work: the answer may be to fix it, redesign it, or stop it, and the record will say which.

Who this is not for

Anyone who cannot yet bring the examples, a baseline and an owner. That is not a rejection; it is the order of work. The framework refuses to build until those exist, and it would refuse for you too.

Bring a workflow   or write on LinkedIn with the workflow in three sentences.

The framework: github.com/atulkapoor/fde-framework · Apache-2.0 · built by Atul Kapoor