The /transparency Page Pattern: A Public Receipts Surface

Most consultancies have a "Trust" page that is a marketing essay. Ours is a file you can read end to end and check against the work. That is the whole point.

What the /transparency page is

/transparency is a single public page on this site that links to the receipts a prospective or current client would otherwise have to ask for in private. It is not a brochure. It is a surface — a directory of artifacts, each one published with a stable URL, a last-updated timestamp, and a note about what evidence class the artifact carries (Class C — this is how the page is built and how the link list is generated).

Concretely, the page exposes:

• The current Trust Receipts Standard, in plain language.
• The redacted engagement-ledger excerpt format we use on live engagements.
• The exit-condition template that every engagement opens with.
• The override-rate and latency notes we keep on AI-shaped projects.
• A public changelog of when we changed our own posture, and why.

If a claim appears on the marketing site without a corresponding artifact on /transparency, that is a bug we want pointed out.

What we publish, what we redact, what we never hide

The page lives by three rules and we say them out loud, because a rule you will not state in public is a rule you will not keep in private.

Publish by default. Posture documents, templates, standards, and the shape of our engagement artifacts are public. If a future client would benefit from seeing it before they sign, it goes on /transparency. We do not gate this content behind a form, because gating receipts is the opposite of having any.

Redact client-identifying detail. Live engagement excerpts are real, but names, dollar figures, vendor identities, and any data that could be re-identified by a competitor are removed. The structure stays. The timestamps stay. The decisions stay. The identities do not. We mark every redaction so a reader can see that something was removed even if they cannot see what (Class C — redactions are explicit, not silent).

Never hide the unflattering. The changelog includes the times we got something wrong and corrected it. A receipts page that only ever moves in one direction — toward looking better — is not a receipts page. It is a press release with a clock on it.

Why a stable URL matters more than the content

The architectural decision that makes /transparency work is boring and load-bearing: every artifact has a stable, public URL that does not move.

If the engagement-ledger explainer lives at /ledger-as-single-source-of-truth today, it lives there next quarter too. If we revise the explainer, the old URL still resolves and the page carries a "this was substantively revised on …" note at the top with a link to the diff. We treat our own URLs the way a serious API team treats endpoints: breaking them silently is not an option (Class E — stable-URL discipline is a long-standing web architecture principle; see Tim Berners-Lee, Cool URIs don't change, 1998, and the W3C TAG findings that followed).

The reason is symmetric to the ledger reason. A client, a journalist, or a future employee should be able to bookmark a claim we made and check it later. If our URLs drift, our receipts drift with them, and the page becomes another marketing essay — exactly the failure mode it exists to prevent.

What this gets you before you sign

If you are evaluating SolutionWright, the /transparency page is meant to be the part of the website you read most carefully. It is the part where the work is doing the talking, not the copy.

You should be able to do four things on it without speaking to anyone at SWU:

1. Read the standard we hold ourselves to.
2. See, in redacted form, what an engagement actually produces.
3. See where we have changed our minds in public, and when.
4. Find the URL of any specific receipt we have referenced anywhere else on the site, and confirm it still resolves.

If any of those four things fails on a given day, the page is broken and we want to know.

For the surrounding pattern, the relevant pieces are here:

• Transparency Architecture Overview — how /transparency fits with the ledger, the standard, and the engagement artifacts behind it.
• The Six Receipts — the specific artifacts the page links out to, and what each one is for.
• /transparency — the live page itself. Read it the way you would read a contract, not the way you would read a homepage.
• Book a workshop — the first place your own receipts start accumulating.