Some designs carry per-operation values such as tenant or user identity as explicit parameters through the call chain; others keep them in ambient per-thread storage read implicitly by any layer. How would you decide between these approaches for a large service?

## Framing the decision Both approaches solve the same problem — deep code needs a value the entry point knows — and both have real costs. The productive question is not which is cleaner in the abstract but **what happens when the value is absent or belongs to a different operation**, because that is the failure both designs will eventually experience. - Explicit parameter missing → the code does not compile, or the call site visibly passes something. The failure is loud, local, and pre-production. - Ambient value missing → a read returns nothing, or worse, a stale value another task left on that thread. The failure is silent, remote from its cause, intermittent, and scheduler-dependent. That asymmetry drives the whole decision. ## The dividing line: does it change the answer? Classify each value by whether it influences the *result* or *authorization* of the operation. **Result- or security-influencing → explicit.** Tenant (selects the data set), principal and permissions (decide access), deadline (decides whether to proceed at all), and business-meaningful locale/currency (changes computed output). For these, ambient storage is dangerous in a specific way: it fails *open*. A code path that forgets to set the tenant does not throw — it inherits whatever is there, and if that is a real tenant from a previous request, you have cross-tenant data disclosure that passes every functional test because the tests set the context. Making them parameters means the type system and the call site enforce presence, reviewers can see the flow, and a new code path physically cannot forget. **Annotation-only → ambient is a good trade.** Correlation ids, trace spans, structured log tags, sampling hints. These are consumed by infrastructure — loggers, metric collectors, instrumentation — not by business logic, and the transitive call graph that would have to carry them includes every third-party library you call. Threading a correlation id through hundreds of signatures that will never read it is real, permanent API pollution with no compensating safety benefit, because a missing correlation id degrades a log line rather than a result. ## What explicit parameters actually cost Be honest about the downside or the answer sounds naive: - **Signature churn.** Every intermediate function grows a parameter it does not use, and adding a new context field is a wide refactor. - **Reach limits.** You cannot add a parameter to a callback signature a library defines, so at those boundaries you must close over the value or fall back to ambient storage anyway. - **Bundling pressure.** Teams collapse the growing parameter list into one context object, which recovers ergonomics but reintroduces a grab-bag that accumulates unrelated fields. Worth doing, but keep the object small, immutable, and explicitly typed rather than a map of strings. ## What ambient context actually costs - **Hidden dependencies.** A function's behaviour depends on state its signature never mentions. Readers cannot see it; static analysis cannot follow it. - **Testability.** Unit tests must arrange thread state instead of passing arguments, and forgetting to clear it leaks between tests, producing order-dependent failures. - **A permanent propagation obligation.** Every hand-off — pools, continuations, timers, retries, message boundaries, library-internal executors — must be wrapped, forever, including in dependencies you add later. Coverage is never provably complete. - **Fails open by default.** Stale values look legitimate and are attributed to the wrong operation. ## The pragmatic architecture Most large services land on a hybrid with an explicit rule: 1. **A small, immutable, typed context object passed explicitly** at every trust and module boundary, carrying tenant, principal, and deadline. Small, and closed to casual additions. 2. **Ambient storage for diagnostics only** — correlation id, span, log tags — with a documented, short allow-list of keys. 3. **Enforcement in code, not documentation.** An architecture test that fails the build if business or security-relevant keys appear in the ambient mechanism, or if any module outside the propagation layer calls the raw set/get primitives directly. 4. **Fail-closed reads everywhere.** Ambient lookups that come back empty throw rather than defaulting. This kills the "leave the last value around just in case" habit that turns absence into bleed. 5. **One propagation layer, applied at boundaries.** Decorating executors and instrumented clients, so no call site is responsible for remembering. 6. **Scoped bindings where the platform provides them** — a value bound for the dynamic extent of a call and unbound automatically — because that fixes the lifetime problem structurally rather than by discipline. ## Migration strategy for an existing service If a service already carries security context ambiently, do not attempt a big-bang refactor. Stage it: (a) add fail-closed reads and task-id stamping so stale context throws immediately, which converts silent bleed into loud errors and surfaces every unwrapped boundary; (b) introduce the explicit context object at the outermost handlers and thread it inward one module at a time, keeping the ambient copy in place as a fallback with a metric counting how often the fallback is used; (c) once that counter is zero in production for a sustained period, delete the ambient copy for those keys and add the architecture test that keeps them out. The metric is the important part — it turns a judgement call about coverage into evidence. ## The one-line position *Explicit for anything that changes what the system returns or who may see it; ambient for anything that merely describes what happened — and enforce the boundary with a test, because the failure mode of ambient security context is silent cross-tenant disclosure.*