How a lab works
A lab builds a small, real version of a workload on real hardware or real cloud accounts, and checks one specific claim against what happens. The claim might be a vendor's launch announcement, an architecture pattern, or a cost argument. The lab ends in a ruling an architect can act on, and states exactly what system the ruling was measured on.
Labs are different from the assessments on layer2c.com and cloud.layer2c.com. An assessment reads a vendor's documentation, briefings and public material and scores the whole platform. A lab doesn't score a vendor. It runs one piece of the stack and reports what the running system did, including the parts no document could tell you.
Which framework is a lab measured against?
Two, and a lab can use either or both. Each one has its own layer numbers, and they don't map onto each other, so a lab page always says which one a table belongs to.
The 4+1 Layer AI Infrastructure Model covers AI infrastructure. It splits the stack into eight layers, from Layer 0 (compute and networking) through the data layers (1A to 1C), the operational layers (2A orchestration, 2B runtime, 2C the reasoning plane where agents and placement decisions are governed), up to Layer 3, the applications. Each layer is described in one line on What is Layer 2C.
Fourth Cloud covers the operating model. It asks whether a platform can run an enterprise's whole workload portfolio, virtual machines, containers, databases and AI, through one control plane on-premises the way a hyperscaler does in its own cloud. Its layers run from FC-0 (the physical substrate) to FC-4 (the integration fabric), and it scores each function from 0 to 4 against the public cloud as the benchmark. It's explained on What is Fourth Cloud.
Most labs use the 4+1 model, because most of them test AI infrastructure. A lab uses Fourth Cloud when its question is about operating the whole estate, such as moving an application off a managed cloud onto infrastructure you run yourself.
What does the placement table mean?
Every lab has a table titled "Where each layer belongs." It applies the Decision Authority Placement Model (DAPM), which sorts each layer into one of three placements. That model has two readings, and each table names the one it uses.
Portability: could you leave?
Retained means your configuration, policies and operating knowledge at that layer would survive a vendor change. Delegated means a partner or open tool provides it and you could swap them without rebuilding. Ceded means the vendor's way of doing it is proprietary, and leaving means rebuilding.
Decision authority: who decides while you stay?
Retained means you, or code you control, make the runtime decision. Delegated means the vendor or a model decides and you can see and override it. Ceded means the vendor or a model decides and you can't override it, and often can't see it.
At Layer 0, portability turns on the hardware, not on who owns it or where it sits. Commodity x86 and NVIDIA hardware is Retained, because what runs on it can move to another box. Proprietary networking, storage or orchestration is Ceded. For any other accelerator, the runtime you adopt decides: an open or standard interface is Retained, and a proprietary runtime that ties you to that vendor's hardware is Ceded. Owning a machine doesn't make a layer Retained, and renting one doesn't make it Delegated. In a table read for decision authority, Layer 0 asks something else: who decides what runs on the hardware.
Neither reading is a grade on quality. A Ceded layer can be excellent. Ceded means you are depending on the vendor's approach, and the lab's job is to show whether that dependence holds up. Fourth Cloud tables always use the portability reading, because that is the only one the Fourth Cloud instrument defines.
How does a lab run?
Before anything is built, a written spec names the claim, the decision the result would change, and what would make the lab fail. Most lab pages open with that failure condition in plain words, so you know what the test was before you read the result.
Wherever code can decide whether something passed, code decides. Repairs are scored by each project's own tests. Quotes are checked word for word against the source document. Where a judgment call remains, such as whether a quoted passage actually supports a claim, a person reads it and the page says so. Automated scores have been overruled by a human reading more than once in this series, and the labs report those cases.
A number isn't reported until it has been re-scored on a clean run, the failures behind it are recorded next to it, and the setup that produced it has been checked mechanically before the run starts. A single run is reported as a single run: "reachable at this size, not yet reliable there," never as a floor or a rate. Known weaknesses in the comparison are stated on the page in a sentence rather than held back until the comparison is perfect. The labs aim at direction an enterprise can use, not at academic completeness.
When a lab turns out to be wrong, the correction goes into the lab's record with a note on what changed and why. The earlier claim isn't quietly deleted.
How to read a lab page
The sections appear in this order.
The opening paragraph
What was tested, on what, and what result would have counted as a failure.
The verdict and the Do and Don't calls
The ruling, the limits of the system it was measured on, and what an architect should do or avoid as a result. The independence line under it says who paid and which relationships apply.
The essay
The full argument in prose: how the lab ran, the obvious objection and the answer to it, what it didn't prove, and the question it leaves open.
The numbers
The measured results a reader would cite, each with a note on how it was measured.
Where each layer belongs
The placement table described above, one row per layer the lab touched.
Assessments at the time of the lab
The published assessment grades for the vendors involved, frozen as they stood on the day the lab ran, so later changes to an assessment don't rewrite the lab's context.
Method and disclosure
How the bench was built, what is published, what stays private, and any sponsorship or client relationship. Some labs also offer the raw lab detail as a download.
What a lab claims, and what it doesn't
A lab's claim covers the system it measured: that hardware, that release, that workload. It doesn't declare a winner and it doesn't assess a whole vendor. When a lab bears on one of the frameworks above, the claim is that the lab tested the framework on a workload or supports it there, never that it proves the framework in general. A lab that contradicts a framework has found a limit of where it applies, not disproved it. Every lab states what it did not prove, and a lab isn't a security test unless it says it is.
Who pays, and what does that buy?
Editorial labs are self-funded. Sponsored labs are paid for by a vendor, and the sponsor is named at the top of the page and again in the independence line. A sponsor can propose the use case and supply the deployment and access. A sponsor can review the findings for factual errors before publication. A sponsor doesn't choose the method, doesn't edit the verdict, and can't stop publication. Sponsorship doesn't buy a score on layer2c.com or cloud.layer2c.com. When a lab features a product from a company that is a client of The CTO Advisor, the page says so, whether or not that company paid for the lab. The full policy is on the disclosure page.
What's published, and what isn't
The test harness and the audit tooling are open source under the MIT license at loopcontrolbench, so anyone can rerun the mechanics and build their own assessment on top. Each lab is also published as a structured record for machines, in JSON and Markdown alongside the page, and indexed in llms.txt. What stays private is the calibrated assessment method behind the layer2c.com grades: the grading rules, the reference examples and the thresholds.
Who writes the page?
Keith Townsend writes and rules on the structured record first: the question, the numbers, the verdict, and what the lab did not prove. The essay is then drafted from that record by an AI model working to Keith's written voice specification. A script checks the draft for number accuracy and style, and Keith reads and approves it before it publishes. The record is the source of truth. If the essay and the record ever disagree, the record wins and the essay gets redrafted.