# How case studies are published

_Published 2026-08-28._

Engagements are written up under one of three confidentiality levels: **public**, **public anonymized**, or **internal**. The level is decided with the client before any draft exists, and it determines what the published record can show.

A `public` case study names the client and the system. A `public anonymized` case study keeps the technical detail but removes the client name and any identifying context. An `internal` case study stays in the project record and never appears on `/work` at all.

This is why the work index is shorter than the project list. Most engagements are internal. A short public record is not a gap to fill; it is the result of a deliberate filter.

## What counts as evidence

A case study is not a testimonial. It is built from evidence the engagement actually produced: architecture diagrams, request attribution, detection outputs, failure logs, and the current state of the system after launch. If the evidence cannot be shown, the case study cannot be written honestly, so it stays internal.

The `public` and `public anonymized` levels differ only in naming. The technical content is the same. Anonymization removes the client and the identifying context, not the engineering.

## Why some work never appears

Some engagements are confidential by nature — security architecture for systems that are still in production, infrastructure that other parties rely on, or work where the client's own disclosure policy forbids a public writeup. These remain in the internal record and inform later work, but they do not get a public URL.

The studio's record is the project list, not the work index. The work index is the subset that can be shown without lying about what was built or who built it.