diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index f3f00e7b30..51b115ad21 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -61,6 +61,50 @@ Hermit pins Rust, `just`, Node, pnpm, and other tools to the versions in
 upfront. If you don't use Hermit, ensure your toolchain meets the minimum
 versions in the table above.
 
+#### Native AWS-LC build requirements
+
+The locked non-FIPS dependency graph includes `aws-lc-rs` and `aws-lc-sys`.
+`aws-lc-sys` compiles bundled AWS-LC sources during a clean build, so Rust
+alone is not sufficient. Contributors need a working platform C/C++ compiler,
+linker, and SDK headers:
+
+- macOS: Xcode Command Line Tools (`xcode-select --install`);
+- Debian/Ubuntu: `build-essential` (also included in the desktop package list
+  below); and
+- Windows: Visual Studio Build Tools with the **Desktop development with C++**
+  workload and a Windows SDK. Windows x86 and x86-64 source builds also need
+  NASM unless the resolved crate features explicitly enable and permit the
+  crate-provided prebuilt objects.
+
+For the versions in `Cargo.lock` (`aws-lc-rs` 1.17.0 and `aws-lc-sys`
+0.41.0), the default non-FIPS build does not require CMake, Go, or bindgen.
+The presence of the `cmake` helper crate in the lockfile or a Hermit-pinned
+`cmake` executable does not by itself make CMake an AWS-LC prerequisite. If an
+upgrade, target, or feature change selects a different builder, update this
+section from the newly locked crate's build requirements in the same change.
+
+On macOS or Linux, verify a fresh-clone bootstrap before a long test run:
+
+```bash
+. ./bin/activate-hermit
+cc --version
+c++ --version
+cargo check --locked --workspace --all-targets
+```
+
+On Windows, use a Developer Command Prompt after making the repository's
+pinned toolchain available on `PATH`:
+
+```text
+cl
+nasm -v
+cargo check --locked --workspace --all-targets
+```
+
+If `aws-lc-sys` fails before Rust compilation starts, verify the native tools
+first. Do not switch cryptographic backends, disable locked features, or add
+unreviewed prebuilt objects to work around a missing contributor toolchain.
+
 ### First-Time Setup
 
 ```bash
diff --git a/docs/CORPORATE_IDENTITY.md b/docs/CORPORATE_IDENTITY.md
index 4c418a78d8..d97a788547 100644
--- a/docs/CORPORATE_IDENTITY.md
+++ b/docs/CORPORATE_IDENTITY.md
@@ -6,6 +6,26 @@ Historical corporate identity approaches based on provider-specific middleware,
 
 This documentation revision does not include a NIP-FI runtime adapter, activate identity enforcement, or establish conformance. Do not deploy a legacy identity sidecar or trust an identity header as a temporary substitute. A later exact-head implementation and deployment must pass the [behavioral evidence matrix](nips/NIP-FI-CONFORMANCE.md) before discovery or enforcement is enabled.
 
+### Delegation availability
+
+Corporate-identity delegation is currently unsupported. The public production
+path does not implement complete delegated issuance, owner-bound resolution,
+expiry, invalidation, reconnect, or protected-transport behavior. Operators
+must keep delegation disabled, and discovery must report it as false or omit
+it. A legacy or downstream configuration flag does not add the missing
+authority and must not be used to advertise support.
+
+This documentation-only revision does not change runtime code or configuration
+defaults. Operators must verify the effective setting in their deployment;
+public wording alone is not activation or conformance evidence. See the
+[integration guide's availability boundary](NIP_FI_INTEGRATION.md#delegation-availability)
+for the implementation and evidence requirements.
+
+Direct NIP-FI authorization and future delegation are separate capabilities.
+Delegation can be advertised only after a reviewed delegated-owner
+implementation passes the complete applicable cross-transport lifecycle and
+session evidence.
+
 ## Supported boundary
 
 NIP-FI combines a valid issuer assertion with independent fresh Nostr key proof, current durable binding and lifecycle state, server-owned request context, and final application admission. For the trusted-proxy profile, the stock Buzz contract requires cryptographic HMAC provenance bound to the complete canonical request. Header presence and network location alone are insufficient.
diff --git a/docs/NIP_FI_INTEGRATION.md b/docs/NIP_FI_INTEGRATION.md
index 921abd8335..5e4ca1bb6f 100644
--- a/docs/NIP_FI_INTEGRATION.md
+++ b/docs/NIP_FI_INTEGRATION.md
@@ -8,6 +8,28 @@ This documentation revision does not add a runtime adapter, activate enforcement
 
 Source review, type presence, configuration parsing, route registration, and prose checks are useful review inputs. None proves runtime behavior.
 
+### Delegation availability
+
+NIP-FI delegation is an optional protocol capability, not an implied Buzz
+feature. The current public production path has no reviewed delegated-owner
+implementation and MUST NOT advertise delegation. Discovery reports
+`"delegation": false` or omits the field, and operators keep delegation
+disabled. A downstream or legacy configuration switch cannot create the
+missing issuance, owner-resolution, expiry, invalidation, reconnect, and
+protected-transport behavior.
+
+This documentation-only revision does not change runtime code or configuration
+defaults. Operators must verify the effective setting in their deployment;
+public wording alone is not evidence that the runtime or its defaults satisfy
+this boundary.
+
+The specification, model, sealed types, and conformance vectors may describe
+future delegation work without claiming that a route is live. Support can be
+advertised only after one reviewed implementation supplies the separate
+delegated-owner capability and passes every applicable delegation and session
+trace across every advertised transport. Until then, any partially wired
+delegation-shaped request must fail closed.
+
 ## Integration boundary
 
 NIP-FI is an additional admission authority above NIP-42 or NIP-98 proof of key control. It does not replace Nostr signatures or application authorization. A protected operation proceeds only when all applicable gates agree:
@@ -130,6 +152,10 @@ See [runtime operations](NIP_FI_RUNTIME_OPERATIONS.md) for preconditions, postco
 
 HTTP authorization applies to one request. A WebSocket lease is per key, domain, capability, resource, and exact dependency set. Its deadline is the earliest applicable assertion, key-snapshot, proxy, proof, binding, delegation, policy, and implementation bound.
 
+This section defines the contract for future delegation support; the current
+[delegation availability](#delegation-availability) statement remains
+controlling for Buzz deployments.
+
 Direct lease reuse rechecks current binding and lifecycle versions, the key-snapshot hard deadline, and JWKS generation. Delegated lease reuse rechecks the current exact owner binding and relationship revision. A lease for one key never covers another key on the connection.
 
 Delegation is optional and separate from federated assertion transport. The delegate supplies its own fresh Nostr proof and no assertion or assertion-provenance field. The owner must remain current and eligible at preparation and final admission. Rotation does not transfer delegation to the new owner key.
diff --git a/docs/examples/nip-fi-stock-domain.json.example b/docs/examples/nip-fi-stock-domain.json.example
index 945ac6e1f8..4ddf2d974f 100644
--- a/docs/examples/nip-fi-stock-domain.json.example
+++ b/docs/examples/nip-fi-stock-domain.json.example
@@ -1,6 +1,7 @@
 {
   "schema": "nip-fi-stock-domain-review-v1",
   "document_role": "review-template-not-runtime-schema",
+  "numeric_values_role": "illustrative-review-values-not-production-defaults",
   "domain": {
     "id": "community.example.test",
     "authority": "community.example.test:443",