@precepts/standards 0.1.0

package/standards/integration/standards/resilience/retry-policy.md

@@ -0,0 +1,268 @@
+---
+identifier: "INTG-STD-034"
+name: "Retry Policy"
+version: "1.0.0"
+status: "MANDATORY"
+
+domain: "INTEGRATION"
+documentType: "standard"
+category: "reliability"
+appliesTo: ["api", "events", "a2a", "mcp", "webhooks", "grpc", "graphql", "batch"]
+
+lastUpdated: "2026-03-28"
+owner: "Integration Architecture Board"
+
+standardsCompliance:
+  iso: []
+  rfc: ["RFC-9110", "RFC-6585"]
+  w3c: []
+  other: ["AWS-Builders-Library", "Google-Cloud-Retry-Strategy"]
+
+taxonomy:
+  capability: "reliability"
+  subCapability: "retry-policy"
+  layer: "infrastructure"
+
+enforcement:
+  method: "hybrid"
+  validationRules:
+    algorithm: "exponential-backoff-with-jitter"
+    maxRetries: 5
+    maxRetryDuration: "30s"
+  rejectionCriteria:
+    - "Fixed-interval retry without backoff"
+    - "Retry on 4xx client errors (except 429 and 408)"
+    - "Retry without idempotency guarantee on non-idempotent operations"
+    - "Missing Retry-After header respect"
+
+dependsOn: ["INTG-STD-029", "INTG-STD-035"]
+supersedes: ""
+---
+
+# Retry Policy
+
+## Purpose
+
+Uncontrolled retries are a leading cause of cascading failures. When clients retry simultaneously with correlated timing, the resulting "thundering herd" overwhelms recovering services. This standard mandates exponential backoff with jitter, retry budgets, and idempotency requirements across all integration boundaries.
+
+Companion standards: INTG-STD-033 (Resilience), INTG-STD-035 (Timeout).
+
+> Normative language follows RFC 2119 semantics.
+
+## Rules
+
+### R-1: Exponential Backoff with Full Jitter
+
+All retry implementations **MUST** use exponential backoff with full jitter as the default algorithm:
+
+```
+sleep = random_between(0, min(cap, base * 2 ^ attempt))
+```
+
+- `base` **MUST** default to 1 second
+- `cap` **MUST** default to 30 seconds
+- Decorrelated jitter **MAY** be used as an alternative
+- Equal jitter and fixed-interval retry **MUST NOT** be used
+
+### R-2: Maximum Retry Count
+
+All retry implementations **MUST** enforce a maximum retry count.
+
+| Context | Default | Allowed Range |
+|---------|---------|---------------|
+| Synchronous API calls | 3 | 1-5 |
+| Async event processing | 5 | 1-10 |
+| Webhook delivery | 5 | 3-8 |
+| Batch job items | 3 | 1-5 |
+| gRPC unary calls | 3 | 1-5 |
+
+Exceeding the upper bound requires Integration Architecture Board approval.
+
+### R-3: Total Retry Duration
+
+All retry loops **MUST** enforce a total duration cap regardless of retry count:
+
+- Synchronous API calls: **MUST NOT** exceed 30 seconds
+- Async events / webhooks: **MUST NOT** exceed 24 hours
+
+Webhook retry schedule **SHOULD** use increasing intervals:
+
+| Attempt | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
+|---------|---|---|---|---|---|---|---|---|
+| Delay | 0s | 1s | 5s | 30s | 2m | 15m | 1h | 4h |
+
+After the final attempt, the message **MUST** be routed to a DLQ and an alert **MUST** fire.
+
+### R-4: Retryable vs Non-Retryable Classification
+
+Implementations **MUST** classify failures before deciding whether to retry.
+
+Retryable (**MUST** retry with backoff):
+
+| HTTP | gRPC | Network |
+|------|------|---------|
+| 408 Request Timeout | UNAVAILABLE (14) | Connection refused |
+| 429 Too Many Requests | DEADLINE_EXCEEDED (4) | Connection reset |
+| 500 Internal Server Error | RESOURCE_EXHAUSTED (8) | Socket timeout |
+| 502 Bad Gateway | ABORTED (10) | DNS failure (max 2 attempts) |
+| 503 Service Unavailable | | TLS handshake timeout |
+| 504 Gateway Timeout | | |
+
+Non-retryable (**MUST NOT** retry):
+
+| HTTP | gRPC | Other |
+|------|------|-------|
+| 400 Bad Request | INVALID_ARGUMENT (3) | TLS certificate error |
+| 401 Unauthorized | NOT_FOUND (5) | Serialization error |
+| 403 Forbidden | PERMISSION_DENIED (7) | Invalid configuration |
+| 404 Not Found | UNAUTHENTICATED (16) | Token permanently revoked |
+| 409 Conflict | UNIMPLEMENTED (12) | |
+| 422 Unprocessable Entity | | |
+
+### R-5: Retry-After Compliance
+
+When a response includes a `Retry-After` header (RFC 9110 Section 10.2.3):
+
+1. The client **MUST** wait at least the specified duration
+2. `Retry-After` **MUST** take precedence over calculated backoff when greater
+3. If `Retry-After` exceeds remaining retry budget, the client **MUST** fail immediately
+
+### R-6: Idempotency Requirements
+
+Retries **MUST** be safe. A retry is safe only when the operation is idempotent or protected by an idempotency mechanism.
+
+Safe to retry without additional measures: GET, HEAD, OPTIONS, PUT, DELETE.
+
+**MUST** use `Idempotency-Key` header for retries: POST, PATCH.
+
+Idempotency key rules:
+- Client **MUST** generate a UUID v4 per logical operation
+- Same key **MUST** be reused across all retry attempts
+- Servers **MUST** store keys for minimum 24 hours and return cached responses for duplicates
+- Keys **MUST** be at most 64 characters
+
+Event consumers **MUST** implement idempotent processing using a deduplication store keyed on event ID (minimum 7-day window).
+
+### R-7: Retry Budget
+
+All services **MUST** enforce a retry budget to prevent amplification:
+
+- Maximum **20%** of total requests **MAY** be retries over a rolling 30-second window
+- When budget is exhausted, retries **MUST** be suppressed and original error returned
+- Budget **MUST** be tracked per downstream dependency
+- Budget exhaustion **SHOULD** trigger circuit breaker open (INTG-STD-033)
+
+### R-8: Dead-Letter Queue Routing
+
+For async integrations (events, webhooks, queues):
+
+1. After retry exhaustion, messages **MUST** be routed to a DLQ
+2. DLQ messages **MUST** retain original payload, headers, and retry metadata
+3. DLQ messages **MUST** trigger an alert
+4. Messages **MUST NOT** be silently dropped
+
+### R-9: Security
+
+Retry logic **MUST NOT** introduce security vulnerabilities:
+
+1. Retries **MUST** use the original auth context (refresh token if expired, never degrade)
+2. Retry logs **MUST NOT** include request bodies, tokens, or PII
+3. TLS certificate errors **MUST NOT** be retried (potential MITM)
+4. Retry budget (R-7) is mandatory to prevent DDoS amplification
+
+### R-10: Observability
+
+Every retry attempt **MUST** be logged with: `correlation_id`, `dependency`, `attempt`, `max_attempts`, `backoff_ms`, `error_type`, `idempotency_key`.
+
+Required metrics:
+
+| Metric | Type |
+|--------|------|
+| `retry_attempts_total` | Counter (by service, dependency, attempt_number) |
+| `retry_exhausted_total` | Counter (by service, dependency) |
+| `retry_backoff_duration_seconds` | Histogram |
+| `retry_budget_utilization_ratio` | Gauge |
+| `dlq_messages_total` | Counter (by queue) |
+
+## Examples
+
+### Retry with full jitter
+
+```
+function retry(operation, max_retries=3, base=1.0, cap=30.0, budget):
+    deadline = now() + max_duration
+
+    for attempt in 0..max_retries:
+        result = operation()
+        if result.success:
+            return result
+
+        if not is_retryable(result.error):
+            fail(result.error)
+
+        remaining = deadline - now()
+        if attempt == max_retries or remaining <= 0:
+            fail("retries exhausted", attempts=attempt+1)
+        if not budget.may_retry():
+            fail("retry budget exhausted")
+
+        delay = min(random(0, min(cap, base * 2^attempt)), remaining)
+        log(attempt=attempt+1, backoff_ms=delay*1000, error=result.error)
+        wait(delay)
+```
+
+### Idempotent retry on a non-idempotent operation
+
+First attempt:
+
+```
+POST /v1/payments
+Idempotency-Key: 7c4a8d09-ca95-4c6d-8f3b-91a7e6e0b9d2
+
+{"amount": 100.00, "currency": "USD"}
+```
+
+Retry (same key - server returns cached response, no duplicate side effect):
+
+```
+POST /v1/payments
+Idempotency-Key: 7c4a8d09-ca95-4c6d-8f3b-91a7e6e0b9d2
+
+{"amount": 100.00, "currency": "USD"}
+```
+
+## Enforcement Rules
+
+| Rule | Gate | Action |
+|------|------|--------|
+| Fixed-interval retry detected | CI lint | Block merge |
+| POST/PATCH retry without idempotency key | CI lint | Block merge |
+| Retry on non-retryable status code | CI lint | Block merge |
+| Missing retry budget | Production readiness | Block deploy |
+| Max retries exceeds allowed range | Architecture review | IAB approval |
+| DLQ not configured for async consumers | Production readiness | Block deploy |
+
+## References
+
+- [RFC 9110 Section 10.2.3 - Retry-After](https://www.rfc-editor.org/rfc/rfc9110#section-10.2.3)
+- [RFC 6585 - 429 Too Many Requests](https://www.rfc-editor.org/rfc/rfc6585)
+- [AWS Builders' Library - Timeouts, retries, and backoff with jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+- [AWS Architecture Blog - Exponential Backoff and Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)
+- [Google Cloud - Retry Strategy](https://cloud.google.com/storage/docs/retry-strategy)
+- [Stripe - Idempotent Requests](https://docs.stripe.com/api/idempotent_requests)
+
+## Rationale
+
+**Full jitter over alternatives:** AWS research shows full jitter produces the least total work across competing clients. Equal jitter's guaranteed minimum floor creates clustering that partially defeats the purpose of jitter.
+
+**20% retry budget:** Google's gRPC default. Without a budget, a service at 1,000 req/s with 50% failure and 3 retries amplifies to 2,500 req/s. At 20%, it stays at 1,200 req/s - manageable headroom for recovery.
+
+**Idempotency keys:** Stripe's pattern makes retries safe at the protocol level without requiring retry logic to understand business semantics.
+
+**DLQ over infinite retry:** Infinite retry causes unbounded queue growth, head-of-line blocking, and masks bugs. DLQ cleanly separates transient failures from problems needing human attention.
+
+## Version History
+
+| Version | Date       | Change             |
+| ------- | ---------- | ------------------ |
+| 1.0.0   | 2026-03-28 | Initial definition |

package/standards/integration/standards/resilience/timeout.md

@@ -0,0 +1,269 @@
+---
+identifier: "INTG-STD-035"
+name: "Timeout Standard"
+version: "1.0.0"
+status: "MANDATORY"
+
+domain: "INTEGRATION"
+documentType: "standard"
+category: "reliability"
+appliesTo: ["api", "events", "a2a", "mcp", "webhooks", "grpc", "graphql", "batch"]
+
+lastUpdated: "2026-03-28"
+owner: "Integration Architecture Board"
+
+standardsCompliance:
+  iso: []
+  rfc: ["RFC-9110"]
+  w3c: []
+  other: ["Zalando-Engineering-Timeouts", "AWS-Builders-Library", "gRPC-Deadlines"]
+
+taxonomy:
+  capability: "reliability"
+  subCapability: "timeout-management"
+  layer: "infrastructure"
+
+enforcement:
+  method: "hybrid"
+  validationRules:
+    connectionTimeout: "2s"
+    readTimeout: "5s"
+    totalTimeout: "30s"
+  rejectionCriteria:
+    - "Missing timeout configuration on any external call"
+    - "Infinite or unset timeouts"
+    - "Timeout longer than upstream caller's deadline"
+
+dependsOn: ["INTG-STD-029"]
+supersedes: ""
+---
+
+# Timeout
+
+## Purpose
+
+Every external call - whether to an API, database, message broker, or file system - **MUST** have an explicit timeout. Unbounded waits are the single most common cause of cascading failures in distributed systems. This standard defines mandatory timeout categories, default values by integration type, deadline propagation rules, and observability requirements. It complements INTG-STD-033 (Resilience) and INTG-STD-034 (Retry).
+
+## Rules
+
+### R-1: Explicit Timeout on Every External Call
+
+Every outbound call to an external dependency **MUST** have an explicit timeout configured. This includes HTTP/REST, gRPC, database queries, message broker operations, file/object storage, DNS lookups, cache reads/writes, and any third-party SDK call performing network I/O. Relying on language or library default timeouts is **NOT** acceptable - many libraries default to infinite timeouts.
+
+### R-2: Separate Connection and Read Timeouts
+
+Services **MUST** configure connection timeout and read timeout as independent values. Connection timeout governs TCP handshake completion; read timeout governs time waiting for the server response after the connection is established.
+
+Connection timeout **SHOULD** follow: `connection_timeout = round_trip_time * 3`. For most intra-region calls, 2 seconds provides ample headroom. Read timeout **MUST** be based on measured downstream latency percentiles (p99.9 recommended), not guesswork.
+
+### R-3: Default Timeout Values by Integration Type
+
+The following defaults **MUST** be used unless a documented exception exists with architectural approval:
+
+| Integration Type       | Connection | Read  | Total  | Rationale                                     |
+| ---------------------- | ---------- | ----- | ------ | --------------------------------------------- |
+| REST/HTTP API          | 2s         | 5s    | 10s    | Most API calls complete within 1-2s at p99    |
+| gRPC (unary)           | 2s         | 5s    | 10s    | Comparable to REST for request-response       |
+| gRPC (streaming)       | 2s         | 30s   | 300s   | Streams require longer read windows           |
+| Database query         | 2s         | 3s    | 5s     | Queries beyond 3s indicate missing indexes    |
+| Database transaction   | 2s         | 3s    | 10s    | Multi-statement transactions need headroom    |
+| Message publish        | 2s         | 5s    | 10s    | Broker acknowledgment should be fast          |
+| Message consume        | 2s         | 30s   | 60s    | Long-poll patterns require extended waits     |
+| Cache (Redis/Memcache) | 1s         | 1s    | 2s     | Cache misses should fail fast                 |
+| File/Object storage    | 5s         | 60s   | 120s   | Large transfers need proportional budgets     |
+| SMTP/Email             | 5s         | 30s   | 60s    | Mail servers vary widely in response time     |
+| DNS resolution         | 2s         | N/A   | 2s     | DNS should resolve from local cache           |
+| MCP tool invocation    | 2s         | 10s   | 15s    | AI tool calls may involve upstream LLM calls  |
+| Webhook delivery       | 2s         | 5s    | 10s    | Receiver should acknowledge quickly           |
+
+Exceptions **MUST** be documented in the service's integration manifest with the dependency name, overridden value, justification, architecture team approval, and a review date no longer than 6 months out.
+
+### R-4: Deadline Propagation
+
+Services that receive inbound requests with a deadline **MUST** propagate a reduced deadline to downstream calls:
+
+```
+downstream_deadline = incoming_deadline - elapsed_time - safety_margin
+```
+
+A safety margin of 100-500ms is **RECOMMENDED**. Protocol-specific mechanisms:
+
+| Protocol | Mechanism                                         | Notes                                       |
+| -------- | ------------------------------------------------- | ------------------------------------------- |
+| gRPC     | `grpc-timeout` header (automatic)                 | Framework propagates via context             |
+| HTTP     | `X-Request-Deadline` header (epoch millis)        | Application layer must read and propagate    |
+| Kafka    | Message header `x-deadline` or record timestamp + TTL | Consumer checks before processing        |
+| GraphQL  | `extensions.deadline` field                       | Resolver checks remaining budget per field   |
+
+For gRPC, services **MUST NOT** create new contexts that discard the incoming deadline. For HTTP, services **SHOULD** include and honor the `X-Request-Deadline` header.
+
+### R-5: Deadline Budget Enforcement
+
+A service **MUST NOT** initiate a downstream call if the remaining deadline budget is less than the minimum time required to complete it. Instead, the service **MUST** return immediately with a timeout error, log the budget exhaustion event, and increment the `timeout.budget_exhausted` metric.
+
+```
+function call_downstream(incoming_deadline, safety_margin, downstream_min):
+    remaining = incoming_deadline - now() - safety_margin
+    if remaining < downstream_min:
+        log_warn("Deadline budget exhausted",
+            remaining_ms=remaining, required_ms=downstream_min)
+        emit_metric("timeout.budget_exhausted_total")
+        return TIMEOUT_ERROR
+
+    downstream_deadline = now() + remaining
+    return call(downstream, deadline=downstream_deadline)
+```
+
+### R-6: Protocol-Specific Timeout Rules
+
+Services **MUST** apply the following protocol-specific rules:
+
+| Protocol        | Rule                                                                                   | Severity |
+| --------------- | -------------------------------------------------------------------------------------- | -------- |
+| HTTP/REST       | Return `408` when server terminates a slow client; `504` when gateway times out upstream | ERROR    |
+| HTTP/REST       | TLS handshake timeout **MUST** be included in total timeout budget                      | ERROR    |
+| gRPC            | Every RPC **MUST** have a deadline set; calls without deadlines are unbounded            | ERROR    |
+| gRPC            | Servers **MUST** check context cancellation and abort work on expired deadlines          | ERROR    |
+| Kafka           | `request.timeout.ms` on producer and `max.poll.interval.ms` on consumer **MUST** be set | ERROR    |
+| RabbitMQ        | Consumer ack timeout **MUST** be configured; message TTL **SHOULD** be set               | ERROR    |
+| SQS             | `VisibilityTimeout` **MUST** be at least 6x expected processing time                    | ERROR    |
+| Database        | `statement_timeout` and `idle_in_transaction_session_timeout` **MUST** be configured     | ERROR    |
+| File/Object     | Per-part upload timeout and stalled transfer detection (30s recommended) **MUST** be set | ERROR    |
+
+### R-7: Client-Side and Server-Side Timeouts
+
+Both client and server **MUST** configure timeouts independently. Client-side timeouts protect against slow servers; server-side timeouts protect against slow or malicious clients.
+
+The client-side timeout **MUST** be at most the server-side timeout for the same operation. If the client times out first, the server wastes resources processing a request whose result will be discarded.
+
+### R-8: Timeout and Circuit Breaker Interaction
+
+Timeouts and circuit breakers (INTG-STD-033) **MUST** work together:
+
+1. Each timeout event **MUST** increment the circuit breaker's failure counter. When the threshold is reached, the circuit **MUST** open.
+2. When the circuit is open, requests **MUST** fail immediately without waiting for a timeout.
+3. Half-open probe requests **SHOULD** use 50% of the normal timeout for faster degradation detection.
+
+### R-9: Security - Timeouts as Defense
+
+Timeouts **MUST** defend against resource exhaustion attacks:
+
+- **Slowloris prevention:** Server read-header timeout **MUST** be 5s or less.
+- **Slow POST prevention:** Server **MUST** enforce a minimum data rate; terminate connections below 500 bytes/second for more than 10 seconds.
+- **Connection pool exhaustion:** Idle connections beyond 120s **SHOULD** be closed.
+- **Query of death:** Database statement timeouts **MUST** prevent single queries from monopolizing resources.
+
+Services **MUST NOT** extend timeouts under load. Longer timeouts during overload consume more resources and accelerate cascading failures. The correct response is to shed load via circuit breakers or rate limiting.
+
+### R-10: Timeout Metrics
+
+Services **MUST** emit the following metrics for every timed external call:
+
+| Metric                                | Type      | Labels                                    |
+| ------------------------------------- | --------- | ----------------------------------------- |
+| `external_call.duration_ms`           | Histogram | `dependency`, `operation`, `result`       |
+| `external_call.timeout_total`         | Counter   | `dependency`, `operation`, `timeout_type` |
+| `external_call.deadline_remaining_ms` | Histogram | `dependency`, `operation`                 |
+| `timeout.budget_exhausted_total`      | Counter   | `dependency`, `operation`                 |
+
+Where `timeout_type` is one of: `connection`, `read`, `write`, `total`, `deadline_exceeded`. `result` is one of: `success`, `timeout`, `error`.
+
+### R-11: Timeout Logging
+
+Every timeout event **MUST** be logged with at minimum: `dependency`, `operation`, `timeout_type`, `configured_timeout_ms`, and `elapsed_ms`. Additional **RECOMMENDED** fields: `trace_id`, `span_id`, `deadline_remaining_ms`, `retry_attempt`, `circuit_breaker_state`.
+
+### R-12: Timeout Alerting
+
+Services **MUST** configure alerts for:
+
+| Condition                                  | Severity | Action                                         |
+| ------------------------------------------ | -------- | ---------------------------------------------- |
+| Timeout rate above 5% for a dependency     | WARNING  | Investigate dependency health                  |
+| Timeout rate above 20% for a dependency    | CRITICAL | Trigger incident; circuit breaker should open  |
+| Budget exhaustion rate above 1%            | WARNING  | Review timeout budgets and call chain          |
+| p99 latency above 80% of configured timeout | WARNING  | Timeout too tight or dependency is degrading   |
+
+## Enforcement Rules
+
+The following **MUST** be enforced via static analysis, configuration scanning, or integration tests:
+
+| Rule    | Check                                                             | Severity |
+| ------- | ----------------------------------------------------------------- | -------- |
+| TMO-001 | Every HTTP client has explicit connection timeout                 | ERROR    |
+| TMO-002 | Every HTTP client has explicit read timeout                       | ERROR    |
+| TMO-003 | Connection timeout is at most 5s                                  | ERROR    |
+| TMO-004 | Read timeout is at most 30s (exceptions require approval)         | WARNING  |
+| TMO-005 | Total timeout is at most 120s (exceptions require approval)       | WARNING  |
+| TMO-006 | Database `statement_timeout` is configured                        | ERROR    |
+| TMO-007 | Kafka `max.poll.interval.ms` is at most 300s                      | WARNING  |
+| TMO-008 | No infinite or zero timeout values in config                      | ERROR    |
+| TMO-009 | Server read-header timeout is at most 5s                          | ERROR    |
+| TMO-010 | gRPC calls have deadline set                                      | ERROR    |
+
+Additional enforcement:
+
+- **Gateway:** API gateways **MUST** enforce a maximum total timeout; requests exceeding it receive `504`.
+- **Code review:** PRs introducing new external calls **MUST** include timeout configuration.
+- **Runtime:** Services **SHOULD** log a warning when any call exceeds 80% of its configured timeout.
+
+## Examples
+
+### Deadline Propagation
+
+The following pseudocode illustrates how a service receives an upstream deadline and propagates a reduced deadline to each downstream call:
+
+```
+function handle_request(request):
+    deadline = parse_deadline_header(request)
+    if deadline is null:
+        deadline = now() + DEFAULT_TIMEOUT
+
+    # Local processing
+    result_a = fetch_from_service_a(request, deadline)
+
+    # Recalculate remaining budget before next call
+    remaining = deadline - now() - SAFETY_MARGIN
+    if remaining < MIN_DOWNSTREAM_TIMEOUT:
+        return error(408, "Deadline budget exhausted")
+
+    result_b = fetch_from_service_b(request, deadline)
+    return combine(result_a, result_b)
+
+function fetch_from_service_a(request, upstream_deadline):
+    remaining = upstream_deadline - now() - SAFETY_MARGIN
+    if remaining < MIN_DOWNSTREAM_TIMEOUT:
+        raise TimeoutError("Budget exhausted before calling Service A")
+
+    return http_call(
+        url = SERVICE_A_URL,
+        timeout = remaining,
+        headers = {"X-Request-Deadline": upstream_deadline}
+    )
+```
+
+## Rationale
+
+**Why separate connection and read timeouts?** They measure different failure modes. Connection timeout detects network unreachability (host down); read timeout measures server processing speed. Conflating them either slows failure detection or sets unrealistic response expectations.
+
+**Why mandate deadline propagation?** Without it, a 5-service chain with 10s timeouts per hop can block the originator for 50s - long after the client has disconnected - while downstream services continue wasted work.
+
+**Why aggressive defaults?** Short timeouts force architectural discipline. A 3s database timeout surfaces missing indexes during development, not production incidents. Services needing longer timeouts can request documented exceptions.
+
+**Why not just circuit breakers?** Timeouts bound a single call's duration; circuit breakers prevent repeated calls to failing dependencies. Without timeouts, circuit breakers have no signal for slow failures. Both are required; neither is sufficient alone.
+
+**Why never extend timeouts under load?** Longer timeouts during overload mean more in-flight requests, more consumed resources, and faster cascading failure. The correct response is load shedding, not longer waits.
+
+## References
+
+- [**RFC 9110**](https://httpwg.org/specs/rfc9110.html) - HTTP Semantics (408 Request Timeout, 504 Gateway Timeout)
+- [**Zalando Engineering - Timeouts**](https://engineering.zalando.com/posts/2023/07/all-you-need-to-know-about-timeouts.html) - Connection timeout formula, latency percentile baselines
+- [**AWS Builders' Library - Timeouts, Retries, and Backoff**](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) - False-timeout rate, retry multiplication risks
+- [**gRPC Deadlines**](https://grpc.io/docs/guides/deadlines/) - Automatic deadline propagation, DEADLINE_EXCEEDED
+- **INTG-STD-033** - Resilience Standard (circuit breakers, bulkheads, fallbacks)
+- **INTG-STD-034** - Retry Standard (retry policies, backoff, idempotency)
+
+## Version History
+
+| Version | Date       | Change             |
+| ------- | ---------- | ------------------ |
+| 1.0.0   | 2026-03-28 | Initial definition |

package/standards/integration/standards/versioning/_category_.json

@@ -0,0 +1 @@
+{"label": "Versioning", "position": 7}