Give KESDONE the context. It does the engineering.

KESDONE reads what you write and the document you attach, flags what contradicts what, and asks only the questions a machine cannot settle: at what grain, over what window, what counts as churn, where the result is delivered. It also answers yours: what already exists on these sources, whether the product will be fresh before your Monday job.

It connects to the sources you authorize, reads their schemas and your existing models, and proposes a business meaning and an owner for every field. Each one is labelled observed, inferred, confirmed or governed, so a deduction never passes for a fact. You correct a meaning in place, and it moves from inferred to confirmed.

It shows how it intends to proceed, step by step, and what the result will look like on a real sample. The estimate is on the right: sources read, tables built, features, checks, time. Approving this plan is the first of the two decisions that stay with you.

An isolated workspace opens for the job: machine, repository, read-only access to the sources, secrets in a vault. It provisions what it needs in your cloud, writes the pipelines, computes the features and runs the tests, on a sample rather than on all your data. The workspace is destroyed when the build ends.

Every promise from the approved brief is checked and scored: one row per customer and per date, no information from after the scoring date, amounts reconciled to the cent, no field carrying personal data. Compliance and the full audit trail sit beside it. Approving before production is the second and last decision that stays with you.

Freshness, source schema, feature drift, row volume, run cost and access rights are watched at every run. Twelve days later a source is renamed upstream: it finds the cause in three minutes, prepares the fix, verifies it on a sample, then waits for you, because you set autonomy at level 2. Incident closed in 29 minutes, and no wrong data served in between.

Definitions, decisions with their reason, relationships and fixes are kept. They are versioned in a context repository, on your own branch, and shared to the main branch only after the owners of each domain have reviewed them. Your code repositories do not change: pipelines and fixes are versioned there, as always. This is the context, versioned separately, and it is what the next request reads.