Transparency
The artifact tells users about its own decisions.
Substrate honesty is the precondition: every value names how it came to be true. Transparency extends substrate honesty outward: every user-affecting decision — your trust score, your escrow tier, a fraud flag, a payout hold, a fee, a tier downgrade — must be inspectable by the affected party. Not by request. By default.
Four rings
- Operator self-transparency. The platform admits to itself, in audits and logs, what decisions it made and why.
- Subject transparency. The user affected by a decision can read the reasoning that produced it.
- External auditor transparency. A third party can read the methodology of a class of decisions.
- Cross-system transparency. When the platform inherits a decision from a sister-system, it names which system.
Where you'll see it: <WhyLink> pills on user-affecting values, methodology pages (this is one) for each decision class, and the <Verifiability> primitive for values claimed to be cryptographically attested.
Where this lives in code. The canonical principle isdocs/principles/transparency.mdin the repo. The companion audit (pnpm audit:transparency) measures compliance. UI primitives<WhyLink>+<Verifiability>live inapps/admin/src/lib/ui/and the corresponding storefront library.
Why this exists
A decision a user cannot inspect is a decision they cannot contest. A decision they cannot contest is a power asymmetry made invisible. The platform's discipline is to make every consequential decision inspectable by the person affected, so the asymmetry stays explicit and therefore correctable.