Production configuration should fail fast

What the public implementation shows

ProductionConfigurationValidator checks database, descriptor secret strength, Keycloak, HTTPS metadata, disabled fallback auth, OpenBao, durable data protection, and callback network policy.

Environment-specific safety rules run at startup outside development and test contexts. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleReadiness begins by refusing to start with a configuration the institution would not accept.

The decision behind the mechanism

The validator converts institutional deployment assumptions into executable invariants.

A default secret, ephemeral key directory, or permissive callback setting can pass compilation and surface only after data or traffic makes the weakness material. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Reject known default and weak secrets.
• Require strict identity settings in production.
• Require durable data-protection storage.
• Test every guardrail with an unsafe configuration.

How the control should be operated

Every invariant should have an owner, remediation message, test, and documented exception policy for isolated non-production environments.

Configuration drift becomes a deployment failure rather than a hidden runtime condition. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.