Update tech_docs/networking/network_iac_framework.md

tech_docs/networking/network_iac_framework.md

@@ -1,3 +1,174 @@
+Here’s the **focused documentation** for θ-Meta, crystallizing its core value proposition as a **market-making protocol for verifiable compute** while deliberately avoiding Turing-completeness in the spec layer:
+
+---
+
+# **θ-Meta Protocol Specification**  
+**Version 1.0**  
+*A minimal canonical format for priced, bounded, and verifiable computation.*
+
+## **1. Core Principles**
+### **1.1 Theta’s Iron Triangle**
+```mermaid
+graph TD
+    A[Verifiability] --> B[Predictable Cost]
+    B --> C[Deterministic Bounds]
+    C --> A
+```
+- **No Turing-completeness**: Bounds (`b:`) are pure CEL (no loops/recursion).  
+- **No ambiguity**: Every task has 1:1:1 correspondence between `f`, `b`, and `v`.  
+- **No runtime dependency**: The spec defines *what*, not *how*.
+
+### **1.2 Why Not Turing-Complete?**
+|                      | Turing-Complete Spec | θ-Meta’s Approach          |
+|-----------------------|-----------------------|----------------------------|
+| **Proof Generation**  | Unbounded time        | O(1) (always terminates)   |
+| **Pricing**           | Unpredictable         | Bound → fixed cost         |
+| **Composability**     | Deadlocks possible    | DAG workflows only         |
+
+## **2. Specification**
+### **2.1 Canonical Task Definition (`#Θ`)**
+```cue
+package theta
+
+#Θ: {
+    // What to compute
+    f: string | bytes  // Computation ID or bytecode
+    
+    // How much is allowed (CEL expression)
+    b: string  // e.g., "k <= 11", "input.size() < 1MB"
+    
+    // Proof of correct execution
+    v: #Proof
+    
+    // Price (unitless, scaled by runtime)
+    p: number
+    
+    // Phi-encoded payload (optional)
+    φ?: string
+}
+
+#Proof: {
+    scheme:  "none" | "sha256" | "ed25519" | "groth16"
+    bytes?:  string  // Proof payload
+    ok:      bool    // Validation result
+}
+```
+
+### **2.2 Execution Guarantees**
+For any task `T` where `T.v.ok == true`, the runtime must ensure:  
+1. **Bounds honored**: `T.b` evaluated to `true` during execution.  
+2. **Payment sufficient**: `T.p` was escrowed before proof generation.  
+3. **Proof valid**: `T.v.bytes` cryptographically matches `T.f` and output.
+
+## **3. Workflow Examples**
+### **3.1 Fibonacci Task**
+```cue
+#fibExample: #Θ & {
+    f: "fib"
+    b: "k <= 11"  // CEL constraint
+    v: {
+        scheme: "ed25519",
+        bytes: "a1b2...",
+        ok:    true
+    }
+    p: 0.001
+    φ: "fib|11"  // Phi-encoded input
+}
+```
+
+### **3.2 ML Inference Task**
+```cue
+#mlExample: #Θ & {
+    f: "infer"
+    b: "model == 'resnet50' && batch_size <= 8"
+    v: {
+        scheme: "groth16",
+        bytes: "x128...",
+        ok:    true
+    }
+    p: 0.1
+}
+```
+
+## **4. Runtime Requirements**
+### **4.1 Mandatory Checks**
+Before executing any task `T`:  
+1. **Validate schema**: `cue vet` against `#Θ`.  
+2. **Check bounds**: Ensure `T.b` is syntactically valid CEL.  
+3. **Verify payment**: Confirm `T.p` is escrowed.  
+
+### **4.2 Proof Schemes**
+| Scheme    | Use Case              | O(1) Check |
+|-----------|-----------------------|------------|
+| `sha256`  | Free tasks (RFC)      | ✅         |
+| `ed25519` | Paid tasks (K11)      | ✅         |
+| `groth16` | ZK-verified compute   | ❌ (SNARK) |
+
+## **5. Composability Rules**
+### **5.1 Valid Workflow Patterns**
+```mermaid
+graph LR
+    A[Task 1] --> B[Task 2]
+    B --> C[Task 3]
+```
+- **Acyclic**: No loops in task dependencies.  
+- **Bounded**: Each task’s `b:` must be evaluable before execution.  
+
+### **5.2 Invalid Patterns**
+```mermaid
+graph LR
+    A[Task 1] --> A  // Loops forbidden
+```
+
+## **6. FAQ**
+### **Q: Why not allow loops in bounds?**  
+**A**: To preserve:  
+- **Predictable pricing**: `T.p` can be derived from `T.b`.  
+- **Instant verification**: Proofs don’t require re-execution.  
+
+### **Q: How to handle complex computations?**  
+**A**: Push complexity into `f:` (WASM/ASM), not the spec. Example:  
+```cue
+#Θ & {
+    f: """
+        // Complex logic in WASM
+        fn run() { ... }
+        """
+    b: "input.len() < 1KB"  // Simple bound
+}
+```
+
+## **7. Compliance Tests**
+Run to validate your implementation:  
+```bash
+cue vet theta.cue -c '#testSuite'
+```
+
+---
+
+# **Appendix: Design Alternatives Considered**
+### **A1. Turing-Complete Bounds**
+- **Rejected**: Breaks 1:1:1 task→proof→price model.  
+
+### **A2. Dynamic Pricing**
+- **Rejected**: `p` must be calculable from `b` alone.  
+
+### **A3. Recursive Proofs**
+- **Pending**: May be added in v2 if SNARK recursion improves.  
+
+---
+
+This document intentionally **excludes**:  
+- Runtime implementation details.  
+- Payment layer specifics.  
+- Hardware requirements.  
+
+The θ-Meta spec is **only** about defining tasks in a way that creates a **verifiable compute market**. Turing-completeness lives *above* this layer, not within it.  
+
+Want to **formalize the state machine** or **add a test suite** next?
+
+---
+
 Here’s the distilled meta-framework for designing a configuration management system that balances pragmatism with pride-of-ownership:
 
 ### **The Pillars of Sustainable Network Configuration Design**