Trust by Design: Turning CI/CD from ‘used’ to ‘believed in’
Uptime keeps your system running; legitimacy keeps it believed in.
Engineers often conflate reliability with trust, but they are not the same. Reliability is a technical property measured in nines. Trust is a social one, measured in adoption and advocacy. A platform’s true resilience depends not just on its uptime, but on its perceived legitimacy.
This is the practice of trust choreography—building consistency, explainability, and reciprocity into the fabric of a system.
Legitimacy (definition): the shared belief that a system’s rules are fair, its operators are accountable, and its outcomes are explainable.
Pull-quote: Uptime is a promise kept—legitimacy is a promise believed.
This framework applies broadly, but it’s clearest at the heart of the modern software factory: the CI/CD platform.
The three layers of platform trust
Consider the CI/CD platform your company relies on. Its trust model can be decomposed into three layers:
| Layer | Question | Failure symptom | Repair tactic |
|---|---|---|---|
| Mechanical | “Does it work?” | Flaky builds, silent errors | SLOs, reproducible runners |
| Social | “Is the process fair?” | Shadow pipelines, Slack escalations | RFCs, changelogs, incident PM |
| Moral | “Whose interests win?” | Opaque policy, tool rebellions | Transparent policy, user veto windows |
A system can be mechanically perfect yet fail at the social and moral layers, breeding resentment and workarounds. True legitimacy appears when all three converge.
Designing for legitimacy
Make trust an architectural property.
- Observability as consent. Expose reason codes for queues, throttles, and denials. Decisions without explanations feel like punishments; with explanations, they become policies.
- Releases as controlled conversations. Predictable cadences are good; decoupled releases are better. Use feature flags to turn deployment into an opt-in conversation. Create a beta cohort, respect workflow stability, and let users adopt at their pace. Agency builds moral trust.
Anti-pattern: Security by surprise. When a new policy silently blocks deploys, users route around the tool. Fix: publish a policy RFC with a 7-day veto window and run in dry-run before enforcement.
Grounded in prior art
This framework builds on established findings in DevOps and MLOps:
- Measuring human friction. Teams are shifting focus from raw build times to intervention rate—how often a human must fix an automated process. Lower interventions correlate with higher perceived legitimacy. (See: Continue.dev’s “Intervention rates are the new build times”).
- Explainable policy. Policy-as-Code makes governance auditable and versioned. If a policy can block, it must also explain. (See: OPA/Rego patterns).
- Transparent telemetry. Privacy-respecting dashboards like Chip Huyen’s Sniffly show you can surface usage/error patterns without invasive telemetry—an “observability as consent” example.
- The demand for “why?”. User threads across Azure DevOps, Travis CI, and Codemagic repeat the same ask: Why am I queued? Some vendors publish their queue algorithms, proving scheduling can be explainable. (e.g., JetBrains TeamCity queueing write-ups).
Design goal: an open, participatory pipeline
The design philosophy behind Relay applies these principles directly: make the observability pipeline open and participatory. Users don’t just consume logs; they can contribute to the infrastructure that monitors the system. That drives trust across all three layers: mechanical reliability, social transparency, and moral alignment with the community.
From reliability to legitimacy
Technical choices like “do no harm” licensing (e.g., CCxL), open audit logs, and verifiable builds aren’t edge features. They’re the bedrock of a platform that is not just used, but believed in.
So look at the system you’re building—pipeline, API, or agent—and ask: what one change can I ship this week to move beyond mechanical reliability and build social or moral trust?
Start here:
- Add “Why am I queued?” reasoning to your dashboard.
- Use feature flags to create an opt-in beta for your next major change.
- Introduce a 7-day policy veto window with dry-run metrics.
References & prior art (short list)
- Continue.dev — “Intervention rates are the new build times.”
- Chip Huyen — Sniffly (privacy-respecting usage/error dashboards).
- JetBrains TeamCity — Queueing algorithm & bottleneck posts.
- OPA/Rego — Policy-as-Code for explainable enforcement.
- DORA & SRE literature — DORA, Google SRE.