How one expert’s method became a production process across dozens of assessments, with AI performing the work and people retaining decision authority.
The AI reasons. Deterministic code enforces what can be checked. Your methodology and authorities determine what is acceptable.
When a required check fails, automatic execution stops. Work must be corrected within defined limits or escalated to an accountable person.
Layer2C is a research and advisory practice that evaluates enterprise AI platforms. It became the first production application of the ideas behind Knerd AI.
The starting point was one expert with a repeatable method for making difficult assessments. The outcome was a production process that could apply that method across dozens of assessments and reuse approved findings in multiple applications.
The important change was where the expert’s time went. AI could perform repeatable work. The expert retained the methodology and the standard for accepting a result.
Evaluating an enterprise AI platform involves more than collecting product facts. Someone has to decide which evidence matters, whether a vendor’s claims are supported, which decisions remain with the customer, and where the customer has accepted a vendor’s authority.
Layer2C already had a method for making those judgments. But applying it required the expert to work through the source material, interpret claims, resolve exceptions, and determine whether each finding was supported.
Every new assessment brought those decisions back to the same person. More documentation did not remove the bottleneck. Another writer could produce more text without necessarily applying the same judgment.
The constraint was the expert’s capacity to execute the method personally. To scale, Layer2C had to make that method explicit enough for AI to perform the repeatable work without taking ownership of the decisions.
Codification meant turning the expert’s way of working into rules that could be applied, checked, and revised independently of the AI model.
Five parts had to become explicit.
Each assessment needed a defined set of sources. The process had to distinguish supported findings from vendor claims, identify where stronger evidence was required, and make missing or conflicting evidence visible.
The published methodology makes one rule concrete: a vendor briefing can direct the research, but changing an assessment requires public evidence that can be cited.
Giving AI more information was not sufficient. The rules had to define what information it was allowed to rely on and what support a conclusion needed.
The assessment categories and the criteria for interpreting evidence had to mean the same thing from one company to the next. Layer2C applies eight common assessment layers to every vendor, including areas where that vendor offers nothing. The method existed independently of the model performing the work.
That separation mattered when the model or the methodology changed. Replacing the AI did not automatically replace Layer2C’s judgment about what made an assessment sound.
Layer2C defined which decisions stayed with people and which work could be delegated. AI could apply established procedures; it did not get to rewrite those procedures simply because it was executing them.
The Decision Authority Placement Model (DAPM) describes the choices: retain judgment, delegate work within defined boundaries, or intentionally accept another system’s authority.
The method had to account for situations that did not fit neatly: insufficient evidence, conflicting sources, and claims that could not support a confident finding.
Those conditions needed an explicit path to review. They could not be resolved by letting AI fill a gap with a plausible answer.
Producing a draft did not mean the assessment was done. Evidence checks, defined controls, and human judgment determined whether a finding was acceptable.
An approved conclusion could then be reused without each downstream application independently reinventing the assessment.
The goal was to make the expert’s method of judgment executable. The evidence, method, exceptions, and acceptance criteria were part of that method, not incidental instructions attached to a prompt.
A language model can produce different recommendations from the same context. Asking it to judge its own answer adds another probabilistic decision. It does not establish that the work is complete or safe to act on.
Deterministic Code in the Loop (DCITL) puts executable checks between the model’s proposed output and the next action. The expert defines the criteria. Code enforces the checks. The authority rules determine what can happen after those checks pass.
The sequence has three parts:
The model remains probabilistic. The acceptance checks and the routing decisions are governed by code and explicit policy. A passing check establishes that the encoded conditions were met; it does not establish every possible claim as true.
This distinction is visible in Layer2C’s evidence-authority lab: a code-based claim resolver checked the test output, and a validator checked the evidence set. The control sat outside the model doing the work.
The same pattern applies to a business recommendation. AI can draft a purchasing decision. Code can check required evidence and spending limits. A result within those bounds still goes to a person if the authority policy requires approval.
The division of work was explicit:
| Work delegated to AI | Authority retained outside the model |
|---|---|
| Gather and organize evidence for an assessment. | Define which sources were admissible and which claims required stronger support. |
| Apply established assessment procedures and draft findings. | Own the methodology and decide when it needed to change. |
| Surface gaps, conflicting evidence, and exceptions for review. | Resolve consequential exceptions and determine whether the evidence justified a conclusion. |
| Perform repeatable work needed to prepare results for reuse. | Set acceptance criteria and approve the conclusions other applications could rely on. |
AI did not determine truth on its own. A fluent answer was not evidence that the work was correct, and the model did not have unilateral authority to approve its own output.
The same distinction mattered when someone other than the expert ran the process.
Lab 015: evidence authority tested two vendor workrooms using an instrument built from public methodology, rather than the proprietary production instrument. Kamiwaza sponsored the lab and supplied the deployment.
Across 51 cross-vendor searches, retrieval returned 241 results, with none coming from the other workroom. The audit grounded 42 of 42 claims in the requesting room’s evidence and found no invented capability claims across 75 assessment cells.
The test also found a limitation: the role that could run an assessment could alter its evidence. Layer2C therefore identified a separate control: check the actual evidence against the approved set before scoring begins.
You can delegate execution without delegating authority over the conditions of execution.
These results cover one deployment and a synthetic test instrument. They demonstrate the tested boundary and its limitation, not production performance with dozens of analysts. Read the measurements and disclosure.
As of September 6, 2026, Layer2C’s public comparison page lists 38 fully assessed vendors. Each is evaluated across the same eight layers. That is an inspectable production output, not a proposed workflow.
Layer2C moved from individual research projects toward a repeatable process. Readers can open an individual assessment, such as Dell’s, and then see that vendor alongside the others in the comparison.
The change can be examined in four dimensions:
| Dimension | What changed |
|---|---|
| Throughput | Repeatable evidence handling, procedure execution, and drafting could be delegated instead of requiring the expert to perform every stage personally. The same method could run across dozens of assessments. |
| Consistency | Assessments used shared categories, evidence rules, and acceptance criteria rather than a new interpretation of the method for each company. |
| Reuse | One approved assessment could support the website, structured data for other software, and comparison tools. Those surfaces could consume the same judgment instead of creating competing versions. |
| Repeatability | The method remained distinct from the person or AI executing the work. Its rules and boundaries could be checked when the work was run again. |
The assessment count demonstrates production coverage. It does not measure hours saved per assessment. The shared criteria demonstrate a consistent method; they do not imply error-free outputs.
Before a result could be reused, it had to be accepted. Once approved, the assessment became a common source for different outputs:
That last boundary matters. A new application can consume the assessment without acquiring permission to revise its judgment. The system map shows how assessment, lab validation, and composition have distinct responsibilities.
Layer2C demonstrated that judgment-heavy expertise can be separated into an explicit method, bounded execution, and an acceptance process. The expert does not have to perform every step personally to remain responsible for the judgment.
For procurement, the method might define which supplier claims need scrutiny, what commercial risks are acceptable, and when legal or security must step in.
For sales, it might capture how the best sellers recognize buying signals, interpret objections, and decide when a specialist should join the conversation.
Those are different kinds of work. The question is the same: what must be explicit before someone else, or AI, can execute the process without quietly changing how the decision gets made?
Explore the business examples.
Layer2C is the first production application of the ideas behind Knerd AI. The same team built both. Common Knerd and Layer2C are separate companies, currently operated by the same people.
The experience at Layer2C informs Knerd AI. Research is the first application of the approach, not the limit of its intended use.
Knerd AI is being built in public. If your organization has a process where a few people consistently make better decisions than everyone else, we want to understand where the methodology is explicit, where it isn’t, and how AI is changing who actually decides.
Tell us about the process you can’t scale.