CHAPTER 01Situation
In a growing number of development and test engineering projects, results are now produced with the support of generative AI: specifications, test strategies, analyses, reports, code, test plans. This works remarkably well — until someone asks one of the following questions.
“Where does this value come from?”
A limit value, a design decision, a recommendation appears in the document. Who produced it, on what basis, and who signed it off can no longer be reconstructed.
“Could you do that again?”
The same task, three weeks later, a different model — a different result. Without a recorded specification, you can neither isolate an error nor demonstrate an improvement.
“Can somebody else take this over?”
The knowledge of why a result looks the way it does sits in one person's chat history. If that person becomes unavailable, the work cannot be continued without substantial loss.
“Did we actually review that?”
Producing has become orders of magnitude cheaper; reviewing has not. Reviews turn into a bottleneck and are then quietly skipped. Quality assurance does not disappear loudly — it disappears silently.
“Why is that in here again?”
Design rules, quality rules and lessons learned exist as documents that nobody reads at the moment of work. Known mistakes repeat themselves — and AI accelerates that too.
“What if the tool goes away?”
The way of working depends on a single vendor. If the model, the licensing policy or the availability changes, the investment in procedures and trained staff is devalued.
None of these questions is new. What is new is that neither traditional nor agile project management holds an instrument for them, because both rest on assumptions that no longer apply: that implementation is expensive and planning is cheap, or that a human being can review the result in reasonable time.
The bottleneck in AI-assisted projects is no longer production. It is human review and judgment time — and the ability to demonstrate later what was decided on what basis. That is precisely where KEEL applies.
CHAPTER 02The approach in one sentence
Intent becomes a versioned artifact that humans and machines work from alike — and no result becomes part of the project unless a named person has accepted it at a defined point and left a record of doing so.
Behind this lies a simple observation about the history of project management. In each generation something different is binding — the thing people fall back on when two of them disagree. In the traditional approach that was the plan, in the agile approach the working increment. In AI-assisted projects neither can fill that role any longer: the plan is too coarse for results that appear within hours, and a working result is no evidence that it is the intended one. Recorded intent takes their place.
The four elements
The name is also the sequence: Kernel — Execution — Evidence — Learning. One cycle takes hours to a few days and runs inside your existing project phases.
What follows from this in practice
- The statement of intent is machine-readable and is actually used. It is not a preliminary stage of the work but its trigger. Changes to it produce new results, not new change requests.
- Results are replaceable in principle, intent is not. The repair is preferably made to the intent, followed by regeneration. This keeps results consistent instead of letting them drift apart over the life of the project.
- Every acceptance produces evidence — as a by-product of the work, not as extra effort afterwards. This makes the project reconstructable, auditable and ready for handover.
AI is wind: abundant, free of charge, and it makes you fast. A boat without a keel drifts with the wind — quickly, but in one direction only and rarely to where you want to go. The keel does not slow the boat down. It is the reason a sailing boat can tack against the wind. Method relates to AI performance in exactly the same way.
CHAPTER 03The principles
Eight sentences, deliberately kept short. They are formulated independently of any domain and apply equally to software, hardware, test and mixed projects.
- What is not in the Kernel has not been agreed. The Kernel is the single binding source for the goal, the boundaries, the terminology, the applicable rules, the decisions and the acceptance criteria. Agreements made in chats, e-mails and corridors only count once they have arrived there.
- Results are replaceable, intent is not. If a result does not fit, the first thing to examine is whether the intent was imprecise.
- What is reviewed is the change, not the whole thing every time. Every newly produced artifact carries a change note: what has changed, what triggered it, which acceptance criteria are affected and which reviews therefore have to be repeated.
- No result without an acceptance, no acceptance without a name. Every adoption into the project takes place at a defined point and is made by a named person. AI can prepare, propose and check — it cannot accept.
- Every acceptance leaves evidence. What is recorded: what the result refers to, what it was produced with, which reviews it passed and who accepted it.
- Context is a maintained asset, not a chat history. Project context is treated like source code: versioned, reviewable, shared. A chat transcript is a working aid, never a project artifact.
- Portability is an acceptance criterion. A project only counts as being under control if a competent person can continue it with a different tool, a different model or with no AI at all. This capability is tested at regular intervals.
- The data question comes before the first prompt. Data classes, approved processing paths and permitted data transfers are defined before work begins.
Three roles
Intent Owner
Owns the content: what the goal is, what the boundaries are, when something is good enough. Decides when objectives conflict. One person from your own organization, not a committee.
Keel Lead
Owns the form: the structure of the Kernel, the scope and depth of the review points, the design of the procedures, the evidence trail, the choice of tools and models. At the outset this role is typically filled externally and handed over in-house step by step.
Maker
Produces results — with agents, with tools, by hand. Carries out the technical review and takes personal responsibility for the output of the tools used. These are your subject-matter experts, developers and test engineers.
Agents do not have roles, they have assignments. They are described like tools — with a purpose, boundaries, approved data sources and a human owner. An agent can never be the Intent Owner and can never issue an acceptance. This rule is what makes the method usable in regulated environments in the first place.
Three artifacts
Artifact here denotes a deliberately produced, named and versioned work product with a defined role in the project. The term is established in project management terminology — the PMBOK Guide lists “artifacts” as a category in its own right. What is expressly not meant is the metrological sense (an image or measurement artifact as a disturbance). The three artifacts are called Kernel, Runbook and Evidence Log throughout; in plain terms they stand for intent, procedure and evidence. Those plain terms are explanation, not a second set of names — the English terms are the names, because their initials spell KEEL.
| Artifact | Content | Answers the question |
|---|---|---|
| Kernel intent |
Goal and non-goals, constraints, terminology, applicable rules, acceptance criteria, data classes, decision history | What do we want, within which boundaries, and why did we decide it this way? |
| Runbook procedure |
Repeatable procedures: work assignments, choice of tool and model, review steps, definition of the review points | How do we produce and review a result — reproducibly, and by different people? |
| Evidence Log evidence |
Per accepted result: reference, producer, change note, reviews passed, accepting person, date | Where does this come from, who stands behind it, and what has changed since when? |
Nothing more is needed. Status reports, plans, risk registers, specifications and gate documents are derived outputs from the Kernel and the Evidence Log — they are generated, not maintained separately. That is one of the practical punchlines: the weekly status report is no longer written, it is generated and accepted.
CHAPTER 04Reviewing without drowning in reviews
The most common objection to intent-driven working is a fair one: if the intent keeps improving and results are therefore regenerated, does everything have to be reviewed again every time? If that were the case, the method would cost more than what it replaces.
The arithmetic is unforgiving. Reviewing a test strategy in full once may cost a day. Five regenerations cost five days — for an improvement that affects three paragraphs. No team goes along with that twice; on the third occasion it is waved through, and at that point the evidence trail is worthless.
The answer: two types of review point
Every newly produced artifact carries a structured change note that answers four questions: What has changed (down to the section)? What triggered it? Which acceptance criteria are affected? Which reviews therefore have to be repeated — and which expressly do not?
| Review point | Scope | When | Effort |
|---|---|---|---|
| Full review | Against all acceptance criteria | First acceptance and at defined triggers | High — deliberately so. It is the baseline for all subsequent changes |
| Delta review | Only the sections named in the change note and the reviews they affect | The normal case for every regeneration | A fraction — this is where the economic leverage of the method lies |
When a full review is mandatory
Without fixed triggers, a familiar risk arises: many small changes, each harmless in itself, that add up to something different without anyone having seen the whole again. The triggers are defined at the start of the project. A proven starting set:
After a fixed number of delta reviews
Purely mechanical, not a matter of discretion — and effective for precisely that reason.
On a change of model or tool
A different model can alter an artifact in places that no change note captures.
On critical requirements
A change to a Kernel element flagged as safety-, standards- or release-relevant.
At external junctures
A formal milestone, customer acceptance, audit preparation, handover to another team or to a supplier.
Delta reviews are only as reliable as the link between requirement, section in the result and review. Without that traceability, the change note is merely an assertion. Establishing it is not something the method achieves by itself — it is the actual substance of the introduction phase.
CHAPTER 05Hardware, long cycles and suppliers
In pure software projects, regenerating instead of repairing is cheap. In projects with a hardware component it is not: tape-out, prototype build, tooling or placing an order with a supplier are expensive, slow and irreversible. KEEL therefore distinguishes two classes of artifact.
| Class | Examples | Handling |
|---|---|---|
| Intent artifacts cheap to regenerate |
Requirements specification, design specification, architecture concept, simulation model, test strategy, test plan, acceptance criteria, draft FMEA, supplier briefing, test program | Full cycle at high frequency: produce, delta-review, improve |
| Commitment artifacts expensive, physical, irreversible |
Layout sign-off, tape-out, mask set, tooling, prototype build, purchase order, qualification | No delta review, but a deliberately heavyweight review point with a complete review and several people accountable |
The more thinking and reviewing moves ahead of the expensive commitment point, the fewer iterations are needed. A single avoided hardware spin typically pays for an entire introduction project. This calculation holds regardless of one's view of AI.
Rules that actually take effect
Many development organizations have good design rules, quality rules and lessons learned — as documents that nobody reads at the moment of work. Known mistakes therefore repeat themselves, particularly among younger engineers and in the tightly coupled hardware-software tasks that are typical of the ATE environment.
KEEL applies leverage at a single point: rules live in the Kernel — and the Kernel is the entry point for every act of production and every review. A rule therefore takes effect three times:
- During production it is part of the context that every person and every tool works with. A design that violates it is produced less often.
- During review it is an acceptance criterion on the list — not a recollection, but an item that gets ticked off.
- In hindsight the Evidence Log shows at which review point it slipped through. That is where the next rule comes from.
External development and suppliers
If a supplier carries out the development, little changes methodologically. The supplier is a particularly slow and particularly expensive Maker:
- The briefing is derived, not written separately — and is therefore automatically consistent with goals, boundaries and rules.
- Acceptance criteria become supplier criteria, with nothing lost in translation.
- Feedback becomes evidence: measurement report, release, deviation notice — each with a reference and a responsible person.
- The confidentiality boundary runs along the derivation. The supplier receives an extract, never the Kernel. A cleanly defined cut that can be explained to a procurement department.
CHAPTER 06Embedding into existing processes
KEEL is not a process that replaces a process. It is an overlay that supplies an existing process. Your milestone and approval procedure remains unchanged. The only thing that changes is how the documents it requires anyway come into being.
This is not a reassuring formula but a design decision. In established organizations, development and approval processes are binding, audited and often mandated group-wide. A method that presupposes a change to the process cannot in practice be introduced there — at least not within a time frame in which it would still be of use.
In practical terms this means: a single project team can adopt KEEL because it gets its gate documentation finished sooner and better substantiated. Whether and when this becomes an organization-wide standard is a separate decision to be taken later.
CHAPTER 07Data, confidentiality and operating model
In most initial conversations this is the first serious question — ahead of any methodology. It is rarely “which model” but almost always: what is allowed to leave the building at all?
The state of the market in mid-2026, soberly summarized: at enterprise and API level, the major vendors state under their own terms that by default they do not train on business customer data, and they offer data processing agreements; zero data retention usually has to be agreed separately. Processing within the EU is available through European regions depending on the vendor; with US vendors a residual risk arising from the CLOUD Act remains. Open models can be operated entirely in your own data center, though with a noticeable performance gap, poorer scalability and considerable capital expenditure. A multi-model strategy has by now become the normal case.
The decision is therefore not “cloud or on-premises” but: which data on which path. KEEL records this in a small matrix in the Kernel — before first use, not afterwards:
| Data class | Examples | Approved path | Evidence |
|---|---|---|---|
| public | Data sheets, standards, publications | unrestricted, any approved tool | none required |
| internal | Process descriptions, internal reports with no customer reference | Enterprise plan with a data processing agreement | tool and model version |
| confidential | Customer data, test results, yield data, commercial terms | EU data residency or self-hosted operation | path, region, legal basis |
| critical | Core IP, layouts, process recipes, specially protected data | self-hosted operation — or the task is solved without AI | complete, with justification |
The real contribution does not lie in the table. Most organizations already have a classification of this kind — from information security or export control. KEEL does not reinvent it; it links the existing classification to the approved processing path and makes that link auditable in the evidence. This is an agenda item that a data protection officer understands without anyone having to explain AI to them.
Models can fail for reasons that are neither technical nor contractual. In June 2026, access to two models from a major vendor was suspended for around three weeks in order to comply with US export controls, and was restored after those controls were lifted at the beginning of July. Irrespective of how the individual case is judged, the episode illustrates an operational risk that has so far barely featured in architecture decisions. In KEEL, model independence is therefore not a statement of principle but operational precaution — and a change of model is a defined trigger for a full review.
CHAPTER 08Maturity levels and getting started
Every introduction begins by establishing where you stand: a sober assessment of where an organization actually is in its handling of AI in projects — irrespective of how many tools are already in use. Four levels describe that.
L1: Three colleagues have an assistant draft test concepts for them. Each phrases the instruction differently, each reviews by instinct, nothing is written down. If one of them drops out, the next one starts from scratch.
L2: For test concepts there is a recorded work instruction with the constraints that apply, a short checklist worked through before acceptance, and a note of who accepted what and when. The result is not better because the tool got better, but because it has become repeatable and ready for handover.
How the benefit can be measured
| Metric | Measurement | What it tells you |
|---|---|---|
| First-pass acceptance rate | Share of results accepted without rework | Quality of the intent — if it rises, the Kernel was the issue, not the model |
| Review effort per result | Human minutes per accepted artifact | The figure that determines the business case |
| Evidence coverage | Share of results with an unambiguous link to the requirement | Reviewability and audit readiness |
| Handover time | Time until a new person can continue work independently | The hardest test of transferability; relevant when work is relocated |
| Rule violations after acceptance | Violations of documented rules discovered later | Measures whether design and quality rules actually take effect |
Three ways to start
Assessment
Positioning within the maturity levels on the basis of a real project, gap list, data class matrix, prioritized roadmap to the next maturity level. The effort is bounded up front.
The lowest-risk entry point — it commits you to nothing further.
Pilot
A live project is set up and supported according to KEEL over several weeks: build the Kernel, define review points and delta rules, document the procedures, train the team, collect metrics.
The Keel Lead role is filled externally for a limited period.
Enablement
A workshop for project managers and specialist teams: principles, roles, how to scope review points, work on your own Kernel. The scope follows team size and the project at hand — with follow-up support if desired.
CHAPTER 09Limits of the method
What a method does not deliver belongs to its description just as much as what it does. The following points come from experience, not from rhetorical modesty.
Does not replace expertise
KEEL makes decisions traceable. Whether they are technically sound is still decided by whoever makes them. A poorly reasoned requirement does not become better through a clean evidence trail — only better documented.
Does not pay off everywhere
For one-off, short or inconsequential tasks, the effort exceeds the benefit. It is worth using where results endure, have to be reviewed, or where someone is accountable for them.
Needs someone who decides
Without a named Intent Owner with decision-making authority, the cycle runs empty. Where objectives remain permanently contested, that is a leadership problem, not a method problem.
Costs time at the beginning
Building the Kernel and traceability is a real up-front investment. It pays back over the review cycles — but it is incurred first. Anyone in an acute schedule crisis should not start with it.
Is not software
KEEL is a procedure, not a product. It works in a Git repository just as well as in a document folder. That is intentional: no additional dependency should be created.
Does not make regulation redundant
The evidence produced provides substantial support for requirements from the EU AI Act and from management system standards, but it replaces neither a conformity assessment nor legal advice.
KEEL does not compete with established standards. It connects to stage-gate processes, extends the PMBOK Guide's treatment of AI with a concrete way of working, and supplies material for requirements from the EU AI Act and ISO/IEC 42001. In software development it is complementary to spec-driven approaches: those generate code from specifications, whereas KEEL steers, decides and substantiates — including where no code is produced at all.