# Configuration Boundaries ## Standalone Mode Standalone mode is for local development, tests, prototypes, and small single-service deployments. Expected characteristics: - local configuration file or environment variables; - local database or file-backed persistence during early development; - fixture or local identity claims adapter; - deterministic authorization test adapter; - no password, MFA, or token issuance responsibility inside user-engine. ## Platform Mode Platform mode is for a NetKingdom-aligned shared service deployment. Expected characteristics: - verified IAM Profile claims arrive from an identity layer; - authorization decisions are requested through the authorization check port; - runtime secrets are delivered through a scoped secret provider; - audit records and outbox events are correlated with platform sinks; - tenant and application bindings are explicit. ## Secret Names The code should refer to logical secret names, not platform paths. Concrete secret lookup is owned by the active `SecretProvider` adapter. Initial logical names: - `database.url` - `event.signing_key` - `webhook.shared_secret` ## Production Guardrails - Local issuers must be rejected by production adapters. - Sensitive writes must fail closed when authorization is unavailable. - Claims enrichment must be optional and must not make user-engine a token issuer. ## Portal integration settings The production portal requires its existing database, OIDC, proxy-marker, and identity-provisioning settings. Platform tenant creation is enabled only when both of these settings are present: - `USER_ENGINE_TENANT_MANAGEMENT_URL` — tenant-authority base URL; - `USER_ENGINE_TENANT_MANAGEMENT_TOKEN` — workload-scoped bearer token. The adapter calls `POST /v1/tenants` with correlation and idempotency headers. The token is never returned in errors, audit records, outbox events, or browser responses. When the settings are absent, ordinary portal behavior remains available and platform tenant creation fails closed as unavailable.