docs: Change architecture to Mermaid and add missing documentation files

docs/security/cafl.md

@@ -0,0 +1,31 @@
+# Capability-Attenuating Flow Labels (CAFL)
+
+**CAFL** is a genuinely new defense primitive introduced by Sentinel Lattice within the GoMCP architecture. While existing Information Flow Control (IFC) mechanisms assume deterministic programs, CAFL operates on the assumption that an LLM can perform **any** information transformation (worst-case taint propagation).
+
+## Attenuation Over Time
+
+Every data object in the GoMCP execution context carries a set of *capability labels* (e.g., `{read, process, transform, export, delete}`). CAFL enforces a unidirectional rule: **Capabilities can only DECREASE across boundaries.**
+
+### Example Flow
+
+1. **Tool Output Returns Sensitive Data**
+   `file_read(.env) -> output features capabilities: {process, display}`
+   *(Note the lack of the `{export}` capability.)*
+2. **LLM Interaction**
+   The LLM parses the data and returns a response. The response inherently inherits the *most restrictive* (most attenuated) capabilities of all inputs it consumed.
+3. **Execution Block**
+   If the LLM now attempts a tool call:
+   `email_send(body: LLM_response) -> operation requires {export}`
+   Because the `.env` data attenuated the flow's capabilities (removing `{export}`), the chain is **BLOCKED**.
+
+## The Membrane Pattern
+
+Trust boundary crossings inherently attenuate capabilities unless explicitly authorized by the developer:
+
+- **Internal → External:** Removes `{export}`
+- **User → System:** Removes `{modify_config}`
+- **Session → Persistent:** Removes `{ephemeral}`
+
+This means that even if a prompt injection tricks the LLM into initiating an exfiltration attempt, the mathematical capabilities of the data prevent the outbound network call.
+
+See the full mathematical foundation in the [Sentinel Lattice Architecture Specification](https://github.com/syntrex-lab/sentinel-community/blob/main/docs/rnd/2026-02-25-sentinel-lattice-architecture.md).

docs/security/dip_pipeline.md

@@ -0,0 +1,15 @@
+# DIP Pipeline (Declarative Intent Parsing)
+
+The **DIP Pipeline** is the first line of defense in the GoMCP architecture, designed to thwart malicious prompts and adversarial intent before they ever reach the underlying LLM.
+
+## How it Works
+
+Traditional security proxies rely heavily on blacklists, regex, or second-model classifiers to detect a "jailbreak." The DIP pipeline flips this paradigm:
+
+1. **Deny-First Oracle**: Instead of allowing all inputs except identified threats, the system denies all inputs except identified benign operations.
+2. **Intent Distillation**: It parses the text, extracts the fundamental "intent vector," and compares it to a rigid list of allowed capabilities.
+3. **Entropy Gate**: Analyzes Shannon entropy of text to detect adversarial/chaotic signals and encoded payloads.
+
+## Lattice Integration
+
+DIP feeds directly into the larger [Sentinel Lattice](https://github.com/syntrex-lab/sentinel-community/blob/main/docs/rnd/2026-02-25-sentinel-lattice-architecture.md) architecture by creating early *Provenance Certificates*. This guarantees that even if a prompt "tricks" the semantic layers, the root source (the external untrusted user) is forever linked mathematically to the parsed intent.