---
id: ADR-PFM-TNL-003
title: Request-Specific Availability
product_area: platform
module: tenant-lifecycle
revision: 1
status: proposed
design_intent: confirmed
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
  services-crm: a8d1364f1dd44b723bb5f9acba12f983e9ec8d69
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
  services-committees: 36129c24daeaadcdb339218c38cdeaff9861359d
  services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893
  services-submissions: 64236c19be89579ef5897aad7de3925ed3ce03bf
  services-websites: 5fc6823c69d5e6f208c21dba8c0eb3132f8bdc4c
  services-marketing: d071a159fe9782bb71ff246d5c67d5bbfe07fbfa
decision: Compute request availability from workspace lifecycle, business standing and caller-route context, using
  directly read facts with a thirty-second process cache.
constrains:
- DOM-PFM-TNL-001
- SVC-PFM-TNL-tenants
- SVC-PFM-TNL-crm-tenant-lifecycle
- SVC-PFM-TNL-commerce-tenant-lifecycle
- SVC-PFM-TNL-committees-tenant-lifecycle
- SVC-PFM-TNL-membership-tenant-lifecycle
- SVC-PFM-TNL-submissions-tenant-lifecycle
- SVC-PFM-TNL-websites-tenant-lifecycle
- SVC-PFM-TNL-marketing-tenant-lifecycle
- SCR-PFM-TNL-004
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.6 The access gate (approved 2026-10-09); Andrew
  2026-10-08 (every macroservice may read any table directly)
alternatives:
- option: Publish lifecycle changes as events for each service to apply
  why_not: Event delivery would introduce another source of delay and ordering uncertainty.
- option: Call Platform on every request
  why_not: A synchronous service call would add a network dependency to every request.
- option: Store availability as a field
  why_not: One stored availability value cannot express the caller and route exceptions.
consequences:
- Lifecycle paths clear the changing process’s cache; other processes refresh after expiry.
- Separate application implementations can drift.
- The caller gets a uniform refusal while the deciding service logs the reason.
supersedes: []
evidence:
- 'services-platform at ad3f6a65: modules/tenants/services/access/tenant-availability.ts.'
- 'services-crm, services-commerce, services-submissions, services-websites: modules/tenant-lifecycle/services/lifecycle/tenant-availability.ts.'
---

# Request-Specific Availability

## Context

A workspace can be closed to its customers while authorized staff still inspect it. Loading adds a route exception, so availability depends on more than a stored boolean.

## Decision

Compute request availability from workspace lifecycle, business standing and caller-route context, using directly read facts with a thirty-second process cache.

## Alternatives Considered

Publish lifecycle changes as events for each service to apply: Event delivery would introduce another source of delay and ordering uncertainty. Call Platform on every request: A synchronous service call would add a network dependency to every request. Store availability as a field: One stored availability value cannot express the caller and route exceptions.

## Consequences

Lifecycle paths clear the changing process’s cache; other processes refresh after expiry. Separate application implementations can drift. The caller gets a uniform refusal while the deciding service logs the reason.