Deep Dive rewrite: align every page to the current architecture

[haimbj1]

Rewrites the whole Deep Dive tab to match the deployed system. One commit per page, so pages stay cherry-pickable.

Every technical claim is verified against source: cofhe-contracts, the cofhe services, zee-k-verifier, and the published @cofhe/sdk@0.7.1 package.

Pages

New

• compute-pipeline — the four offchain components that carry a task from onchain event to committed result: slim listener, FheOS, FHE Engine, blockchain poster. Replaces the old FheOS Server and Slim Listener pages.
• teecryptor — the current decryption architecture, replacing the Threshold Network page.
• key-management — how the FHE key is born, split, and released to attested enclaves.

Retired, with redirects
threshold-network, result-processor, ct-registry, slim-listener, fheos-server, off-chain-decryption-flow, and fhe-engine. All seven resolve to their successors. 24 redirects total, none chained.

Rewritten
overview, task-manager, acl, plaintext-storage, commitment-registry, zk-verifier, the three data flows (the two decryption pages merged into one), future-plans, and research-in-fhenix.

What changed in the content

• Teecryptor is the current decryption path. The Threshold Network appears only as a plan. Both TEE components, Teecryptor and the ZK Verifier, move to multi-party computation together, with each partner verifying inputs on its own side.
• ACP replaces permit in all Deep Dive prose, per the team decision. Code identifiers keep their real spelling: isAllowedWithPermission is a live ACL function.
• Two broken code samples fixed..withPermit() was renamed to .withACP() in 0.7, so the decryption flow samples did not work against the pinned version.
• ACP upgrade folded in: externalEuint inputs with a batch proof, setConsumingContract, batchVerifyInputs, ACP on the wire, and the batch digest format.
• Trust points corrected on the future plans page: the ZK Verifier TEE is listed as a trust point, external verification names its AVS again, and centralized input storage now says there is no current plan rather than promising a decentralized DA.

Diagrams

Every stale SVG is replaced with in-page Mermaid, styled by a shared theme (scripts/mermaid-theme.json plus a sync script). Eight diagrams total. The overview shows big blocks only and hides the pipeline internals; the detail lives on the Compute Pipeline page. All eight render clean and are queued for a design pass in DOC-59.

Style guide

STYLE.md gains canonical names for the compute pipeline and its four components, drops the retired FheOS Server entry, and states that the ZK Verifier runs in its own TEE. "Component" replaces "service" across the tab.

Checks

Lint, Vale, the compatibility version check, and broken-links all pass. Zero errors and zero warnings across all 14 pages.

Follow-ups

• DOC-64 — sweep permit to ACP across the rest of the site, and fix 12 stale .withPermit() samples outside this tab.
• DOC-65 — add a worked verification example once zee-k-verifier is public.
• DOC-59 — design pass on the eight diagrams.
• DOC-63 — what-is-cofhe still calls the Threshold Network the current decryptor.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
fhenix	🟢 Ready	View Preview	Aug 20, 2026, 1:49 PM

[roeezolantz]

It also archives the inputs and their proofs in Google Cloud Storage for independent auditing.

I'd change it to ->>>>>>>

It also archives the inputs and their proofs in a public and immutable Google Cloud Storage bucket for independent auditing.

Do you think it worth having an example how to verify us? cuz I built one here - https://github.com/FhenixProtocol/zee-k-verifier/blob/main/zk-verifier/scripts/verify_stored_ct.rs

[haimbj1]

Half applied. "public" is in, so the line now says a public Google Cloud Storage bucket.

I left "immutable" out. I could not find anything that enforces it in zee-k-verifier: no object versioning, no object lock, no retention policy. Immutability is a security guarantee, and our style rule says to describe a control as active only if it is enforced. Point me at the bucket policy and I will add the word.

On the verification example, yes, it is the right idea. It makes "independent auditing" something a reader can actually do. We cannot link it yet, because zee-k-verifier is a private repo, and an external reader would get a 404. Haim wants to wait until that repo is public, then add it.