Transparency without consent is just leaking. The Redaction Rule is how we publish engagement receipts in the open without putting a single client at risk.
The problem the rule solves
We publish six receipts for every engagement: the falsifier, the cost-per-task line, the ledger snippet, the artifact list, the failure log, and the runbook excerpt. Public, dated, with the engagement number — the practice described in /the-receipts-page-pattern.
Receipts have to be specific enough to be useful to the next prospective client (otherwise they are marketing slop, not evidence) and yet never identify the client, their customers, their staff, or anything reconstructable into a competitive intelligence brief. The Redaction Rule is the explicit, written compromise.
The rule, in five lines
- The client's identity is redacted by default. Industry, region, and rough company size are publishable; legal name, brand, domain, and product names are not.
- Any number that could be back-solved to revenue, headcount, or customer counts is rounded or bucketed. "Reduced manual triage time from 18 hours per week to 2" is publishable; "$184,000 saved across the 47-person team" is not.
- No screenshots of internal UI, no field names from internal schemas, no customer-facing copy. Code snippets are paraphrased into a runnable shape that does not include the client's variable names, table names, or domain language.
- Anything the client flagged as confidential in intake stays out forever, even after the engagement ends. The flag is binding; we do not litigate it later (Class C — the flag is captured in the signed scope and the ledger entry references it).
- The client signs off on every receipt before it is published. Sign-off is on the redacted draft itself, not on a description of it. If the client says no, the receipt does not run. There is no appeal and no "but it would be useful for marketing."
That is the entire rule. It fits on one page on purpose — a rule that takes ten pages to describe is one nobody enforces consistently.
The format, so you can see what publishable looks like
A redacted receipt has six fields, in order, and nothing else:
- Engagement number (internal, e.g. ENG-2026-014). Lets us cross-reference internally without naming the client.
- Sector + region + size bucket (e.g. "regional logistics, US Midwest, 25–75 employees").
- The problem in one paraphrased sentence, with no domain-specific nouns from the client's vocabulary.
- The falsifier that was set up-front (Class C — the falsifier is in the signed scope, the receipt quotes it verbatim from the ledger).
- What actually happened — pass, fail, or partial — with the date, and one specific metric rounded per rule (2).
- The artifact handed off, described generically ("a 340-line Python ingestion script with a 12-row eval set" rather than "the FooCorp invoice parser").
Same shape every time. Boring on purpose — boring formats are harder to game.
The consent flow
The consent flow runs in three steps and is logged in the ledger.
At intake. We tell the prospective client, in writing, that we publish redacted receipts and we show them three prior published receipts as examples. If they want a non-publication clause, we honor it — the engagement just runs without contributing to the public corpus. Roughly one in five clients chooses this. The choice is in the signed scope.
Mid-engagement, before each receipt is drafted. The redacted text is written by us, then sent to the client's designated reviewer with a one-week window. Silence is not consent; we need an explicit reply. The reply is pasted into the ledger entry for that receipt.
Permanent. Once a receipt is published, it stays published as written. We do not silently edit live receipts. If the client later asks for an additional redaction we missed, we add a dated correction note on the same page rather than rewrite history — mutating receipts after the fact defeats their purpose.
What the rule is not
The Redaction Rule is not a non-disclosure agreement and it is not legal advice. The client's NDA still governs everything the rule does not (Class E — clients should treat their own counsel as the authority on disclosability on their side; we are the authority on what we publish on ours). The rule is the floor on our publication discipline, not a ceiling on the client's confidentiality requirements.
It is also not a substitute for the engagement being good. A redacted receipt that says "the falsifier fired in week three and we ended the engagement" is more honest and harder to fake than a glossy testimonial. If you cannot publish honest receipts about your own work, the problem is not the rule.
Where this lives in the architecture
The Redaction Rule sits inside the broader transparency stack described on /transparency-architecture-overview — receipts, falsifiers, the running ledger, exit-ready artifacts, partnership clauses. The receipts page itself is documented at /the-receipts-page-pattern. The consent flow starts in the intake call linked from every page on this site.