The file C:\Users\NickV\.claude\plans\harmonic-nibbling-pony.md has been updated successfully.

# Plan: Master Verification Spreadsheet — Column Headers

## Context

Nick has a formal verification stack with:
- **CubieMasterStack PDF** (v1.0, 77 pages): 7 deliverables, 163 theorems (146 unique), full Coq + Lean source, SHA-256 hashes per file, patent claim mapping
- **Cubie theorem roadmap** (xlsx): 185 items across 19 clusters (0-18), dependency ordering, types (C/V/R/E/F), proof sketches
- **Theorem Omega 4.0** (tf-OMEGA): separate Lean 4 + Coq proof, Docker verification container
- Patent family: US11956363B2, US12073439B2, US20240195628A1
- Target: TrustFortress BNN gate, Blue Shield kernel-bypass, Cubie Trust Compiler

The master spreadsheet must:
1. One row per theorem/axiom/definition (granular)
2. Group by cluster AND by deliverable
3. Carry the actual Lean4 and Coq source code per theorem
4. Carry SHA-256 hashes for each source file
5. Include Verus code column (future, for Rust formal verification)
6. Include raw Rust implementation code
7. Include human-readable description
8. Support category/cluster filtering and dependency tracing

---

## Recommended Column Headers (37 columns, 7 groups)

### Group 1: Identity & Grouping (10 columns)

| # | Column | Type | Description | Example |
|---|--------|------|-------------|---------|
| A | `ID` | string | Master unique ID | `CUBIE-001` |
| B | `RoadmapID` | int | OriginalID from roadmap backlog | `8` |
| C | `DependencyOrder` | float | Cluster-relative order | `1.1` |
| D | `ClusterNo` | int | Cluster number (0-18) | `1` |
| E | `Cluster` | string | Cluster name | `Cubie primitive geometry` |
| F | `Deliverable` | enum | CubieMasterStack deliverable | `V2.0` |
| G | `Type` | enum | C/V/R/E/F (per roadmap legend) | `C` |
| H | `Action` | string | Create/formalize, Rewrite/spec, etc. | `Create/formalize` |
| I | `Priority` | enum | High / Medium / Future/Research | `High` |
| J | `Dependencies` | string | Comma-separated IDs this builds on | `CUBIE-008, CUBIE-012` |

### Group 2: Human Layer (5 columns)

| # | Column | Type | Description | Example |
|---|--------|------|-------------|---------|
| K | `TheoremName` | string | Formal name in proof system | `omega_4_absolute` |
| L | `Description` | string | One-sentence plain English | `Adversarial payloads are always routed to tarpit and never mutate reality` |
| M | `FormalStatement` | string | Math notation / formula | `∀x, Adversarial x → RoutedToPhotonicTarpit x ∧ ¬MutatesPhysicalReality x` |
| N | `ProofSketch` | string | How validated (from roadmap) | `Unfold ManifoldValid; apply Ashby's limit; derive contradiction` |
| O | `PatentClaim` | string | Mapped patent limitation if any | `US20240195628A1 Claim 3` |

### Group 3: Lean 4 Layer (7 columns)

| # | Column | Type | Description | Example |
|---|--------|------|-------------|---------|
| P | `Lean4_SourceFile` | string | Source filename | `CubieTrustCompilerV2.lean` |
| Q | `Lean4_Code` | text | Full Lean 4 proof code for THIS theorem | `theorem omega_4_absolute...` |
| R | `Lean4_Version` | string | Lean version used | `4.30.0-rc2` |
| S | `Lean4_AxiomProfile` | string | Which axioms used | `axiom-free` or `[propext]` or `[propext, Quot.sound]` |
| T | `Lean4_FileSHA256` | string | SHA-256 of entire .lean file | `0f269cb0...` |
| U | `Lean4_Status` | enum | PASS / PENDING / FAIL | `PASS` |
| V | `Lean4_VerifyDate` | date | Last verification date | `2026-04-30` |

### Group 4: Coq Layer (7 columns)

| # | Column | Type | Description | Example |
|---|--------|------|-------------|---------|
| W | `Coq_SourceFile` | string | Source filename | `RamenCornerConsensusV1192.v` |
| X | `Coq_Code` | text | Full Coq proof code for THIS theorem | `Theorem seam_is_clean_eq_J...` |
| Y | `Coq_Version` | string | Coq version used | `8.18.0` |
| Z | `Coq_AxiomProfile` | string | Axiom status | `closed under global context` |
| AA | `Coq_FileSHA256` | string | SHA-256 of entire .v file | `d564c483...` |
| AB | `Coq_Status` | enum | PASS / PENDING / FAIL | `PASS` |
| AC | `Coq_VerifyDate` | date | Last verification date | `2026-04-30` |

### Group 5: Verus Layer (4 columns)

| # | Column | Type | Description | Example |
|---|--------|------|-------------|---------|
| AD | `Verus_Code` | text | Verus proof code | *(PENDING — future)* |
| AE | `Verus_Version` | string | Verus toolchain version | *(PENDING)* |
| AF | `Verus_Status` | enum | VERIFIED / PENDING / N/A | `PENDING` |
| AG | `Verus_VerifyDate` | date | Verification date | *(PENDING)* |

### Group 6: Rust Implementation (6 columns)

| # | Column | Type | Description | Example |
|---|--------|------|-------------|---------|
| AH | `Rust_Crate` | string | TF crate name | `tf-gauntlet` |
| AI | `Rust_Module` | string | Module path | `manifold::admission` |
| AJ | `Rust_Function` | string | Function/struct/enum name | `evaluate_seam()` |
| AK | `Rust_Code` | text | Raw Rust implementation code | `pub fn evaluate_seam(...) {...}` |
| AL | `Rust_FilePath` | string | Source file relative path | `crates/tf-gauntlet/src/manifold/admission.rs` |
| AM | `Rust_Conformance` | enum | Does Rust match formal spec? | `VERIFIED` / `PENDING` / `DIVERGED` |

### Group 7: Traceability (4 columns)

| # | Column | Type | Description | Example |
|---|--------|------|-------------|---------|
| AN | `DockerDigest` | string | SHA-256 of verification container | `sha256:07600e7b...` |
| AO | `SourceBasis` | string | Where this came from | `Cubie Master Stack / V1.40` |
| AP | `Context` | string | Why this matters (from roadmap) | `Define six-faced 3×3 object...` |
| AQ | `Notes` | string | Caveats, edge cases, open items | `V2.0 subsumes V1.50 version` |

---

## Sheet Structure (multi-sheet workbook)

| Sheet | Purpose |
|-------|---------|
| `Master` | All rows, all columns — the single source of truth |
| `ByCluster` | Pivot/filtered view grouped by ClusterNo (0-18) |
| `ByDeliverable` | Filtered view grouped by Deliverable (V1.19.2 → V2.0-PP + Omega) |
| `SHA_Manifest` | One row per source file: filename, Coq SHA, Lean SHA, Docker digest |
| `Legend` | Column definitions, type enum values, axiom profile explanations |
| `DependencyGraph` | Visual or adjacency-list of which theorems depend on which |
| `PatentMap` | Theorem → patent claim cross-reference (especially V2.0-PP's 54 corollaries) |
| `RoadmapSync` | Import from cubie_theorem_roadmap_full.xlsx for delta tracking |

---

## Deliverable mapping (what populates the rows)

| Deliverable | Theorems | Coq File | Lean File |
|-------------|----------|----------|-----------|
| V1.19.2 Ramen Corner | 53 | `RamenCornerConsensusV1192.v` | `RamenCornerConsensusV1192.lean` |
| V1.30 ToR Admission | 5 | (from CubieMasterStack) | (from CubieMasterStack) |
| V1.31 ToR Corner Spoofing | 2 | (from CubieMasterStack) | (from CubieMasterStack) |
| V1.40 Cubie Bridge | 6 | (from CubieMasterStack) | (from CubieMasterStack) |
| V1.50 Track B | 17 | (from CubieMasterStack) | (from CubieMasterStack) |
| V2.0 Track C (canonical) | 26 | (from CubieMasterStack) | (from CubieMasterStack) |
| V2.0-PP Per-Predicate | 54 | (from CubieMasterStack) | (from CubieMasterStack) |
| Omega 4.0 | 1 | `theoremOmega.v` | `TheoremOmega.lean` |
| **Total existing** | **164** | | |
| Roadmap pending (C items) | ~121 | *(to be created)* | *(to be created)* |

---

## Key design decisions in this layout

1. **One row = one theorem** — axioms, definitions, and lemmas each get their own row too, because the Rust mapping is per-declaration, not per-file
2. **Deliverable + Cluster are independent grouping axes** — a theorem belongs to one Deliverable (V2.0) AND one Cluster (e.g., "Seam strings"), allowing two different filter views
3. **Code columns (Q, X, AD, AK) are text blobs** — Excel handles multiline cells; freeze panes on columns A-O for scanning
4. **SHA-256 is per FILE not per theorem** — many theorems share one source file; the SHA changes when ANY theorem in the file changes
5. **AxiomProfile tracks constructivity** — critical for patent claims ("fully constructive, no classical logic")
6. **Rust_Conformance is the bridge** — this is the field that proves the deployed Rust code matches the formal proof. VERIFIED means Verus or manual audit confirmed it. PENDING means the mapping exists but isn't proven. DIVERGED means a known delta.

---

## Verification

- Load the CubieMasterStack PDF — extract all 163 theorems into rows
- Cross-reference against roadmap's 185 items — every roadmap C/V item should map to a Master row
- R (rewrite) items from the roadmap are documentation tasks, not theorem rows — track separately or tag with Type=R
- Confirm SHA-256 hashes match between PDF manifest and Master sheet SHA columns

# Plan: Intel AI Edge Application Ready Verification -- Cubie Trust Compiler Integration

## Context

The Cubie Trust Compiler is a formally verified AI workload admission gate that compiles to native x86_64 machine code. It already:
- Cross-compiles to 3 bare-metal targets (RISC-V, x86_64, AArch64)
- Has a C-ABI entry point: `extern "C" fn cubie_admit(*const CubieRequest) -> AdmitResult`
- Runs in ~730 ns/call on Intel Core Ultra 9 285HX (~1.37M admits/sec)
- Is proven correct by 754 theorems across Coq 8.18.0, Lean 4.30.0, and Verus
- Has 62 passing integration tests and zero external dependencies
- Is backed by 3 patent families (US11956363B2, US20240195628A1)

Intel's AI Edge Application Ready Verification program (Rev 2.1, Jan 2026) is a 5-step ISV onboarding process. Nick has testbed access. The goal: get Cubie verified as an Intel AI Edge application, which unlocks technical support and co-marketing.

**What Intel needs from us:**
1. Application running on Intel edge hardware
2. Workload performance metrics at light/medium/heavy loads
3. Pipeline block diagram
4. Resource utilization screenshots (CPU/GPU/NPU)
5. Sizing tool report OR Appendix A alternative artifacts

**The gap:** The bare-metal library has no Python bindings, no C header, no container config, and no OpenVINO pipeline integration. We need a bridge from `libcubie_bare_metal.a` to a Python+OpenVINO demo pipeline.

---

## Phase 1: FFI Bridge (Python-callable shared library)

**Why:** Intel's ecosystem is Python+OpenVINO. We need `cubie_admit()` callable from Python.

**Why ctypes over PyO3:** Zero Python build tooling. Load `.so`, define struct, call function. Minimal moving parts for a verification submission.

**Why mock feature:** Non-mock builds use `core::ptr::read_volatile()` on hardware MMIO addresses -- this will segfault in Linux userspace. The `mock` feature replaces MMIO with AtomicU32 cells. The admission logic is identical. The formal proofs hold regardless of MMIO backend.

### Files to create:

- [ ] **`cubie-ffi/Cargo.toml`** -- New workspace member, `crate-type = ["cdylib"]`, depends on `cubie-bare-metal` with `features = ["std", "mock"]`
- [ ] **`cubie-ffi/src/lib.rs`** -- Re-exports `cubie_admit`, adds `cubie_mock_setup()` (configures eFuse key + NVLink + PCIe mock state) and `cubie_create_valid_request()` (returns a CubieRequest with correct HMAC)
- [ ] **`cubie-ffi/include/cubie.h`** -- C header documenting the ABI. Uses `_Bool` (not `bool`). Includes `static_assert(sizeof(CubieRequest) == 40)`
- [ ] **`pipeline/cubie_gate.py`** -- Python ctypes wrapper. `CubieRequest` as `ctypes.Structure`, `CubieGate` class with `admit()`, `benchmark()`, `create_test_request()` methods

### Modify:

- [ ] **`Cargo.toml`** (workspace root) -- Add `"cubie-ffi"` to `members` list

### Build:

```bash
cargo build --release --manifest-path cubie-ffi/Cargo.toml
# Output: target/release/libcubie_ffi.so (Linux) or cubie_ffi.dll (Windows)
```

### Verify:

```bash
cargo test --manifest-path bare-metal-tests/Cargo.toml  # 62 tests still pass
python3 -c "from pipeline.cubie_gate import CubieGate; g = CubieGate(); print(g.benchmark(100000))"
```

### Critical detail -- CubieRequest struct layout:

```
Offset  Field              Type    Size
0       who_pass           bool    1
1       what_pass          bool    1
2       how_pass           bool    1
3       where_pass         bool    1
4       when_pass          bool    1
5       why_pass           bool    1
6       has_valid_lease    bool    1
7       epoch_fresh        bool    1
8       request_hash       u64     8
16      capability_hmac    u64     8
24      key_slot           u8      1
25      peer_id            u8      1
26-31   (padding)                  6
32      adapter_id         u64     8
Total: 40 bytes
```

Source: `bare-metal/src/types.rs:4-25`

---

## Phase 2: OpenVINO Pipeline (Cubie as pre-inference gate)

**Architecture:**

```
Request --> [Cubie Gate ~730ns] --Allow--> [OpenVINO Inference (CPU/GPU/NPU)] --> Result
                |
                +--Deny--> [Blocked -- zero accelerator resources consumed]
```

**Workload type:** Video Processing (preferred) or NLP Text Generation.

### Files to create:

- [ ] **`pipeline/cubie_openvino_demo.py`** -- Main demo. Loads `libcubie_ffi.so` + OpenVINO model. For each request: build CubieRequest -> call `cubie_admit()` -> if Allow, run inference -> log metrics. Supports `--mode light|medium|heavy` and `--workload video|nlp`
- [ ] **`pipeline/load_profiles.py`** -- Load generator. Light: 1 req/s. Medium: 10 req/s, 4 threads. Heavy: max throughput. Each runs configurable duration (default 60s)
- [ ] **`pipeline/resource_monitor.py`** -- Background thread sampling CPU/GPU/NPU utilization at 1s intervals, writes timestamped CSV
- [ ] **`pipeline/requirements.txt`** -- `openvino>=2024.0`, `psutil>=5.9`, `matplotlib>=3.7`, `numpy>=1.24`

### Model options:

- Video: `ssd_mobilenet_v2_coco` (OpenVINO Model Zoo) -- `omz_downloader --name ssd_mobilenet_v2_coco && omz_converter --name ssd_mobilenet_v2_coco`
- NLP: `TinyLlama-1.1B` in OpenVINO format -- `pip install openvino-genai`

---

## Phase 3: Intel Edge Testbed Deployment

**Prereqs:** Testbed access (confirmed), Ubuntu 22.04/24.04, Rust toolchain, Python 3.10+, OpenVINO, Node.js 22+

### Steps:

- [ ] **Clone repo and build FFI** on testbed
- [ ] **Run speedtest** -- `cargo run --release --manifest-path bare-metal-tests/Cargo.toml --bin speedtest` -- captures Intel CPU brand string + TSC-calibrated ns/call for all gate components
- [ ] **Install OpenVINO + download model** on testbed
- [ ] **Run demo pipeline at 3 load levels** -- capture metrics CSVs
- [ ] **Capture resource utilization** -- CPU/GPU/NPU screenshots at each load level

### Intel Edge AI Sizing Tool (primary method):

```bash
git clone https://github.com/intel/edge-ai-sizing-tool
cd edge-ai-sizing-tool && ./install.sh && ./start.sh
# Browse to http://localhost:8080
# Configure workload, generate PDF report
```

### Appendix A fallback (if sizing tool doesn't support custom pipelines):

```bash
sudo dmidecode > artifacts/hardware_info.txt                    # System info
lsof -p $(pgrep -f cubie_openvino_demo) > artifacts/runtime_libs.txt  # Runtime libraries
# Resource utilization captured by resource_monitor.py at each load level
```

---

## Phase 4: Generate Submission Artifacts

### Files to create:

- [ ] **`pipeline/generate_diagrams.py`** -- Produces pipeline block diagram (PNG) + formal verification architecture diagram using matplotlib
- [ ] **`artifacts/capture_system_info.sh`** -- Captures CPU, RAM, GPU, NPU, OS, OpenVINO version, Rust version
- [ ] **`artifacts/pipeline_description.md`** -- Narrative for Intel form: "First formally verified AI workload admission gate for Intel edge hardware. 754 theorems, sub-microsecond decisions, 3 patent families, native x86_64 machine code, FIPS 198-1 HMAC-SHA256."
- [ ] **`artifacts/build_submission_report.py`** -- Compiles system info + metrics CSVs + diagrams into a single PDF

### Required artifacts checklist:

| Artifact | Source | Format |
|----------|--------|--------|
| System info | `capture_system_info.sh` | TXT |
| Pipeline description | `pipeline_description.md` | Text (pasted into form) |
| Block diagram | `generate_diagrams.py` | PNG |
| Sizing tool report | Edge AI Sizing Tool or Appendix A | PDF |
| CPU utilization (light/med/heavy) | `resource_monitor.py` | Screenshots/CSV |
| GPU utilization (light/med/heavy) | `intel_gpu_top` or resource_monitor | Screenshots/CSV |
| System photo | Testbed screenshot | Image |

---

## Phase 5: Submit

- [ ] **Fill Intel form** at `https://app.smartsheet.com/b/form/019a3bfa6a0b7623876994c2950fc14f`
- [ ] **Upload all artifacts** from Phase 4
- [ ] **Application name:** "Cubie Trust Compiler -- Formally Verified AI Admission Gate"

**Narrative for Intel review meeting:**

> The Cubie Trust Compiler is the first formally verified AI workload admission gate. It runs as a sub-microsecond pre-inference filter on Intel edge hardware, making admission decisions in ~730 nanoseconds -- proven correct by 754 independent theorems across three proof assistants (Coq, Lean 4, Verus). Every AI inference request passes through the gate before consuming GPU or NPU compute. Denied requests use zero accelerator resources. The entire stack compiles to native x86_64 machine code with zero external dependencies. Protected by 3 patent families (US11956363B2, US12073439B2, US20240195628A1).

Support: intel.edge.ai.application.qualification@intel.com

---

## File Summary

| Phase | New Files | Modified |
|-------|-----------|----------|
| 1: FFI Bridge | `cubie-ffi/Cargo.toml`, `cubie-ffi/src/lib.rs`, `cubie-ffi/include/cubie.h`, `pipeline/cubie_gate.py` | `Cargo.toml` (workspace) |
| 2: Pipeline | `pipeline/cubie_openvino_demo.py`, `pipeline/load_profiles.py`, `pipeline/resource_monitor.py`, `pipeline/requirements.txt` | -- |
| 3: Deploy | -- (commands only) | -- |
| 4: Artifacts | `pipeline/generate_diagrams.py`, `artifacts/capture_system_info.sh`, `artifacts/pipeline_description.md`, `artifacts/build_submission_report.py` | -- |
| **Total** | **12 new files** | **1 modified** |

**Zero existing files touched** (all bare-metal, Coq, Lean, Verus source preserved).

---

## Critical Source Files (read-only dependencies)

| File | What the plan uses from it |
|------|---------------------------|
| `bare-metal/src/types.rs:4-25` | `CubieRequest` #[repr(C)] layout -- Python ctypes must mirror exactly |
| `bare-metal/src/admit.rs:20-32` | `cubie_admit` C-ABI signature -- FFI crate re-exports this |
| `bare-metal/src/mmio.rs` | Mock setter functions (`mock_set_efuse_key`, etc.) -- exposed through FFI |
| `bare-metal/src/hmac.rs` | `hmac_sha256` -- used by FFI to compute valid test HMACs |
| `bare-metal-tests/src/speedtest.rs` | CPUID + RDTSC benchmarks -- run on testbed for Intel-specific numbers |
| `Cargo.toml` | Workspace members list -- add `cubie-ffi` |

---

## Risks and Mitigations

| Risk | Mitigation |
|------|-----------|
| CubieRequest struct layout mismatch (Rust vs Python) | `static_assert(sizeof == 40)` in C header + round-trip test |
| Sizing tool doesn't support custom pipelines | Use Appendix A alternative (explicitly supported by Intel Rev 2.1) |
| NPU utilization is zero (model not compiled for NPU) | Frame Cubie as CPU-side filter that *reduces* unnecessary NPU load |
| Mock MMIO means "not real hardware" | HMAC-SHA256 computation is identical; formal proofs hold regardless of MMIO source; document clearly |
| Bool representation differs C vs Rust | Use `_Bool` in header (not `bool`); `ctypes.c_bool` maps to `_Bool` correctly |

---

## Verification (how to test end-to-end)

1. `cargo test --manifest-path bare-metal-tests/Cargo.toml` -- 62 tests pass (no regression)
2. `cargo build --release --manifest-path cubie-ffi/Cargo.toml` -- .so builds
3. `python3 -c "from pipeline.cubie_gate import CubieGate; g = CubieGate(); print(g.admit(g.create_test_request()))"` -- prints True
4. `python3 pipeline/cubie_openvino_demo.py --mode light --duration 10` -- runs without error
5. `python3 pipeline/generate_diagrams.py --output artifacts/` -- produces PNGs
6. All artifacts in `artifacts/` directory are non-empty and submission-ready

-# Plan: Master Verification Spreadsheet — Column Headers

+# Plan: Intel AI Edge Application Ready Verification -- Cubie Trust Compiler Integration

-Nick has a formal verification stack with:

-- **CubieMasterStack PDF** (v1.0, 77 pages): 7 deliverables, 163 theorems (146 unique), full Coq + Lean source, SHA-256 hashes per file, patent claim mapping

-- **Cubie theorem roadmap** (xlsx): 185 items across 19 clusters (0-18), dependency ordering, types (C/V/R/E/F), proof sketches

-- **Theorem Omega 4.0** (tf-OMEGA): separate Lean 4 + Coq proof, Docker verification container

-- Target: TrustFortress BNN gate, Blue Shield kernel-bypass, Cubie Trust Compiler

+The Cubie Trust Compiler is a formally verified AI workload admission gate that compiles to native x86_64 machine code. It already:

+- Cross-compiles to 3 bare-metal targets (RISC-V, x86_64, AArch64)

+- Has a C-ABI entry point: `extern "C" fn cubie_admit(*const CubieRequest) -> AdmitResult`

+- Runs in ~730 ns/call on Intel Core Ultra 9 285HX (~1.37M admits/sec)

+- Is proven correct by 754 theorems across Coq 8.18.0, Lean 4.30.0, and Verus

+- Has 62 passing integration tests and zero external dependencies

+- Is backed by 3 patent families (US11956363B2, US20240195628A1)

-1. One row per theorem/axiom/definition (granular)

-3. Carry the actual Lean4 and Coq source code per theorem

-4. Carry SHA-256 hashes for each source file

-5. Include Verus code column (future, for Rust formal verification)

-6. Include raw Rust implementation code

-8. Support category/cluster filtering and dependency tracing

+Intel's AI Edge Application Ready Verification program (Rev 2.1, Jan 2026) is a 5-step ISV onboarding process. Nick has testbed access. The goal: get Cubie verified as an Intel AI Edge application, which unlocks technical support and co-marketing.

+1. Application running on Intel edge hardware

+2. Workload performance metrics at light/medium/heavy loads

+4. Resource utilization screenshots (CPU/GPU/NPU)

+5. Sizing tool report OR Appendix A alternative artifacts

+**The gap:** The bare-metal library has no Python bindings, no C header, no container config, and no OpenVINO pipeline integration. We need a bridge from `libcubie_bare_metal.a` to a Python+OpenVINO demo pipeline.

-## Recommended Column Headers (37 columns, 7 groups)

+## Phase 1: FFI Bridge (Python-callable shared library)

-### Group 1: Identity & Grouping (10 columns)

+**Why:** Intel's ecosystem is Python+OpenVINO. We need `cubie_admit()` callable from Python.

-| # | Column | Type | Description | Example |

-| A | `ID` | string | Master unique ID | `CUBIE-001` |

-| B | `RoadmapID` | int | OriginalID from roadmap backlog | `8` |

-| C | `DependencyOrder` | float | Cluster-relative order | `1.1` |

-| D | `ClusterNo` | int | Cluster number (0-18) | `1` |

-| E | `Cluster` | string | Cluster name | `Cubie primitive geometry` |

-| F | `Deliverable` | enum | CubieMasterStack deliverable | `V2.0` |

-| G | `Type` | enum | C/V/R/E/F (per roadmap legend) | `C` |

-| H | `Action` | string | Create/formalize, Rewrite/spec, etc. | `Create/formalize` |

-| I | `Priority` | enum | High / Medium / Future/Research | `High` |

-| J | `Dependencies` | string | Comma-separated IDs this builds on | `CUBIE-008, CUBIE-012` |

+**Why ctypes over PyO3:** Zero Python build tooling. Load `.so`, define struct, call function. Minimal moving parts for a verification submission.

+**Why mock feature:** Non-mock builds use `core::ptr::read_volatile()` on hardware MMIO addresses -- this will segfault in Linux userspace. The `mock` feature replaces MMIO with AtomicU32 cells. The admission logic is identical. The formal proofs hold regardless of MMIO backend.

-| K | `TheoremName` | string | Formal name in proof system | `omega_4_absolute` |

-| L | `Description` | string | One-sentence plain English | `Adversarial payloads are always routed to tarpit and never mutate reality` |

-| M | `FormalStatement` | string | Math notation / formula | `∀x, Adversarial x → RoutedToPhotonicTarpit x ∧ ¬MutatesPhysicalReality x` |

-| N | `ProofSketch` | string | How validated (from roadmap) | `Unfold ManifoldValid; apply Ashby's limit; derive contradiction` |

-| O | `PatentClaim` | string | Mapped patent limitation if any | `US20240195628A1 Claim 3` |

+- [ ] **`cubie-ffi/Cargo.toml`** -- New workspace member, `crate-type = ["cdylib"]`, depends on `cubie-bare-metal` with `features = ["std", "mock"]`

+- [ ] **`cubie-ffi/src/lib.rs`** -- Re-exports `cubie_admit`, adds `cubie_mock_setup()` (configures eFuse key + NVLink + PCIe mock state) and `cubie_create_valid_request()` (returns a CubieRequest with correct HMAC)

+- [ ] **`cubie-ffi/include/cubie.h`** -- C header documenting the ABI. Uses `_Bool` (not `bool`). Includes `static_assert(sizeof(CubieRequest) == 40)`

+- [ ] **`pipeline/cubie_gate.py`** -- Python ctypes wrapper. `CubieRequest` as `ctypes.Structure`, `CubieGate` class with `admit()`, `benchmark()`, `create_test_request()` methods

-| # | Column | Type | Description | Example |

-| P | `Lean4_SourceFile` | string | Source filename | `CubieTrustCompilerV2.lean` |

-| Q | `Lean4_Code` | text | Full Lean 4 proof code for THIS theorem | `theorem omega_4_absolute...` |

-| R | `Lean4_Version` | string | Lean version used | `4.30.0-rc2` |

-| S | `Lean4_AxiomProfile` | string | Which axioms used | `axiom-free` or `[propext]` or `[propext, Quot.sound]` |

-| T | `Lean4_FileSHA256` | string | SHA-256 of entire .lean file | `0f269cb0...` |

-| U | `Lean4_Status` | enum | PASS / PENDING / FAIL | `PASS` |

-| V | `Lean4_VerifyDate` | date | Last verification date | `2026-04-30` |

+- [ ] **`Cargo.toml`** (workspace root) -- Add `"cubie-ffi"` to `members` list

-| W | `Coq_SourceFile` | string | Source filename | `RamenCornerConsensusV1192.v` |

-| X | `Coq_Code` | text | Full Coq proof code for THIS theorem | `Theorem seam_is_clean_eq_J...` |

-| Y | `Coq_Version` | string | Coq version used | `8.18.0` |

-| Z | `Coq_AxiomProfile` | string | Axiom status | `closed under global context` |

-| AA | `Coq_FileSHA256` | string | SHA-256 of entire .v file | `d564c483...` |

-| AB | `Coq_Status` | enum | PASS / PENDING / FAIL | `PASS` |

-| AC | `Coq_VerifyDate` | date | Last verification date | `2026-04-30` |

+cargo build --release --manifest-path cubie-ffi/Cargo.toml

+# Output: target/release/libcubie_ffi.so (Linux) or cubie_ffi.dll (Windows)

-| # | Column | Type | Description | Example |

-| AD | `Verus_Code` | text | Verus proof code | *(PENDING — future)* |

-| AE | `Verus_Version` | string | Verus toolchain version | *(PENDING)* |

-| AF | `Verus_Status` | enum | VERIFIED / PENDING / N/A | `PENDING` |

-| AG | `Verus_VerifyDate` | date | Verification date | *(PENDING)* |

-### Group 6: Rust Implementation (6 columns)

+cargo test --manifest-path bare-metal-tests/Cargo.toml  # 62 tests still pass

+python3 -c "from pipeline.cubie_gate import CubieGate; g = CubieGate(); print(g.benchmark(100000))"

-| AH | `Rust_Crate` | string | TF crate name | `tf-gauntlet` |

-| AI | `Rust_Module` | string | Module path | `manifold::admission` |

-| AJ | `Rust_Function` | string | Function/struct/enum name | `evaluate_seam()` |

-| AK | `Rust_Code` | text | Raw Rust implementation code | `pub fn evaluate_seam(...) {...}` |

-| AL | `Rust_FilePath` | string | Source file relative path | `crates/tf-gauntlet/src/manifold/admission.rs` |

-| AM | `Rust_Conformance` | enum | Does Rust match formal spec? | `VERIFIED` / `PENDING` / `DIVERGED` |

+### Critical detail -- CubieRequest struct layout:

+Offset  Field              Type    Size

-| AN | `DockerDigest` | string | SHA-256 of verification container | `sha256:07600e7b...` |

-| AO | `SourceBasis` | string | Where this came from | `Cubie Master Stack / V1.40` |

-| AP | `Context` | string | Why this matters (from roadmap) | `Define six-faced 3×3 object...` |

-| AQ | `Notes` | string | Caveats, edge cases, open items | `V2.0 subsumes V1.50 version` |

-## Sheet Structure (multi-sheet workbook)

+## Phase 2: OpenVINO Pipeline (Cubie as pre-inference gate)

-| `Master` | All rows, all columns — the single source of truth |

-| `ByCluster` | Pivot/filtered view grouped by ClusterNo (0-18) |

-| `ByDeliverable` | Filtered view grouped by Deliverable (V1.19.2 → V2.0-PP + Omega) |

-| `SHA_Manifest` | One row per source file: filename, Coq SHA, Lean SHA, Docker digest |

-| `Legend` | Column definitions, type enum values, axiom profile explanations |

-| `DependencyGraph` | Visual or adjacency-list of which theorems depend on which |

-| `PatentMap` | Theorem → patent claim cross-reference (especially V2.0-PP's 54 corollaries) |

-| `RoadmapSync` | Import from cubie_theorem_roadmap_full.xlsx for delta tracking |

+Request --> [Cubie Gate ~730ns] --Allow--> [OpenVINO Inference (CPU/GPU/NPU)] --> Result

+                +--Deny--> [Blocked -- zero accelerator resources consumed]

+**Workload type:** Video Processing (preferred) or NLP Text Generation.

+- [ ] **`pipeline/cubie_openvino_demo.py`** -- Main demo. Loads `libcubie_ffi.so` + OpenVINO model. For each request: build CubieRequest -> call `cubie_admit()` -> if Allow, run inference -> log metrics. Supports `--mode light|medium|heavy` and `--workload video|nlp`

+- [ ] **`pipeline/load_profiles.py`** -- Load generator. Light: 1 req/s. Medium: 10 req/s, 4 threads. Heavy: max throughput. Each runs configurable duration (default 60s)

+- [ ] **`pipeline/resource_monitor.py`** -- Background thread sampling CPU/GPU/NPU utilization at 1s intervals, writes timestamped CSV

+- [ ] **`pipeline/requirements.txt`** -- `openvino>=2024.0`, `psutil>=5.9`, `matplotlib>=3.7`, `numpy>=1.24`

+- Video: `ssd_mobilenet_v2_coco` (OpenVINO Model Zoo) -- `omz_downloader --name ssd_mobilenet_v2_coco && omz_converter --name ssd_mobilenet_v2_coco`

+- NLP: `TinyLlama-1.1B` in OpenVINO format -- `pip install openvino-genai`

-## Deliverable mapping (what populates the rows)

+## Phase 3: Intel Edge Testbed Deployment

-| Deliverable | Theorems | Coq File | Lean File |

-| V1.19.2 Ramen Corner | 53 | `RamenCornerConsensusV1192.v` | `RamenCornerConsensusV1192.lean` |

-| V1.30 ToR Admission | 5 | (from CubieMasterStack) | (from CubieMasterStack) |

-| V1.31 ToR Corner Spoofing | 2 | (from CubieMasterStack) | (from CubieMasterStack) |

-| V1.40 Cubie Bridge | 6 | (from CubieMasterStack) | (from CubieMasterStack) |

-| V1.50 Track B | 17 | (from CubieMasterStack) | (from CubieMasterStack) |

-| V2.0 Track C (canonical) | 26 | (from CubieMasterStack) | (from CubieMasterStack) |

-| V2.0-PP Per-Predicate | 54 | (from CubieMasterStack) | (from CubieMasterStack) |

-| Omega 4.0 | 1 | `theoremOmega.v` | `TheoremOmega.lean` |

-| Roadmap pending (C items) | ~121 | *(to be created)* | *(to be created)* |

+**Prereqs:** Testbed access (confirmed), Ubuntu 22.04/24.04, Rust toolchain, Python 3.10+, OpenVINO, Node.js 22+

+- [ ] **Clone repo and build FFI** on testbed

+- [ ] **Run speedtest** -- `cargo run --release --manifest-path bare-metal-tests/Cargo.toml --bin speedtest` -- captures Intel CPU brand string + TSC-calibrated ns/call for all gate components

+- [ ] **Install OpenVINO + download model** on testbed

+- [ ] **Run demo pipeline at 3 load levels** -- capture metrics CSVs

+- [ ] **Capture resource utilization** -- CPU/GPU/NPU screenshots at each load level

+### Intel Edge AI Sizing Tool (primary method):

+cd edge-ai-sizing-tool && ./install.sh && ./start.sh

+# Configure workload, generate PDF report

+### Appendix A fallback (if sizing tool doesn't support custom pipelines):

+sudo dmidecode > artifacts/hardware_info.txt                    # System info

+lsof -p $(pgrep -f cubie_openvino_demo) > artifacts/runtime_libs.txt  # Runtime libraries

+# Resource utilization captured by resource_monitor.py at each load level

+## Phase 4: Generate Submission Artifacts

-1. **One row = one theorem** — axioms, definitions, and lemmas each get their own row too, because the Rust mapping is per-declaration, not per-file

-2. **Deliverable + Cluster are independent grouping axes** — a theorem belongs to one Deliverable (V2.0) AND one Cluster (e.g., "Seam strings"), allowing two different filter views

-3. **Code columns (Q, X, AD, AK) are text blobs** — Excel handles multiline cells; freeze panes on columns A-O for scanning

-4. **SHA-256 is per FILE not per theorem** — many theorems share one source file; the SHA changes when ANY theorem in the file changes

-5. **AxiomProfile tracks constructivity** — critical for patent claims ("fully constructive, no classical logic")

-6. **Rust_Conformance is the bridge** — this is the field that proves the deployed Rust code matches the formal proof. VERIFIED means Verus or manual audit confirmed it. PENDING means the mapping exists but isn't proven. DIVERGED means a known delta.

+- [ ] **`pipeline/generate_diagrams.py`** -- Produces pipeline block diagram (PNG) + formal verification architecture diagram using matplotlib

+- [ ] **`artifacts/capture_system_info.sh`** -- Captures CPU, RAM, GPU, NPU, OS, OpenVINO version, Rust version

+- [ ] **`artifacts/pipeline_description.md`** -- Narrative for Intel form: "First formally verified AI workload admission gate for Intel edge hardware. 754 theorems, sub-microsecond decisions, 3 patent families, native x86_64 machine code, FIPS 198-1 HMAC-SHA256."

+- [ ] **`artifacts/build_submission_report.py`** -- Compiles system info + metrics CSVs + diagrams into a single PDF

+| System info | `capture_system_info.sh` | TXT |

+| Pipeline description | `pipeline_description.md` | Text (pasted into form) |

+| Block diagram | `generate_diagrams.py` | PNG |

+| Sizing tool report | Edge AI Sizing Tool or Appendix A | PDF |

+| CPU utilization (light/med/heavy) | `resource_monitor.py` | Screenshots/CSV |

+| GPU utilization (light/med/heavy) | `intel_gpu_top` or resource_monitor | Screenshots/CSV |

+| System photo | Testbed screenshot | Image |

-- Load the CubieMasterStack PDF — extract all 163 theorems into rows

-- Cross-reference against roadmap's 185 items — every roadmap C/V item should map to a Master row

-- R (rewrite) items from the roadmap are documentation tasks, not theorem rows — track separately or tag with Type=R

-- Confirm SHA-256 hashes match between PDF manifest and Master sheet SHA columns

+- [ ] **Fill Intel form** at `https://app.smartsheet.com/b/form/019a3bfa6a0b7623876994c2950fc14f`

+- [ ] **Upload all artifacts** from Phase 4

+- [ ] **Application name:** "Cubie Trust Compiler -- Formally Verified AI Admission Gate"

+**Narrative for Intel review meeting:**

+> The Cubie Trust Compiler is the first formally verified AI workload admission gate. It runs as a sub-microsecond pre-inference filter on Intel edge hardware, making admission decisions in ~730 nanoseconds -- proven correct by 754 independent theorems across three proof assistants (Coq, Lean 4, Verus). Every AI inference request passes through the gate before consuming GPU or NPU compute. Denied requests use zero accelerator resources. The entire stack compiles to native x86_64 machine code with zero external dependencies. Protected by 3 patent families (US11956363B2, US12073439B2, US20240195628A1).

+| 1: FFI Bridge | `cubie-ffi/Cargo.toml`, `cubie-ffi/src/lib.rs`, `cubie-ffi/include/cubie.h`, `pipeline/cubie_gate.py` | `Cargo.toml` (workspace) |

+| 2: Pipeline | `pipeline/cubie_openvino_demo.py`, `pipeline/load_profiles.py`, `pipeline/resource_monitor.py`, `pipeline/requirements.txt` | -- |

+| 3: Deploy | -- (commands only) | -- |

+| 4: Artifacts | `pipeline/generate_diagrams.py`, `artifacts/capture_system_info.sh`, `artifacts/pipeline_description.md`, `artifacts/build_submission_report.py` | -- |

+| **Total** | **12 new files** | **1 modified** |

+**Zero existing files touched** (all bare-metal, Coq, Lean, Verus source preserved).

+## Critical Source Files (read-only dependencies)

+| `bare-metal/src/types.rs:4-25` | `CubieRequest` #[repr(C)] layout -- Python ctypes must mirror exactly |

+| `bare-metal/src/admit.rs:20-32` | `cubie_admit` C-ABI signature -- FFI crate re-exports this |

+| `bare-metal/src/mmio.rs` | Mock setter functions (`mock_set_efuse_key`, etc.) -- exposed through FFI |

+| `bare-metal/src/hmac.rs` | `hmac_sha256` -- used by FFI to compute valid test HMACs |

+| `bare-metal-tests/src/speedtest.rs` | CPUID + RDTSC benchmarks -- run on testbed for Intel-specific numbers |

+| `Cargo.toml` | Workspace members list -- add `cubie-ffi` |

+| CubieRequest struct layout mismatch (Rust vs Python) | `static_assert(sizeof == 40)` in C header + round-trip test |

+| Sizing tool doesn't support custom pipelines | Use Appendix A alternative (explicitly supported by Intel Rev 2.1) |

+| NPU utilization is zero (model not compiled for NPU) | Frame Cubie as CPU-side filter that *reduces* unnecessary NPU load |

+| Mock MMIO means "not real hardware" | HMAC-SHA256 computation is identical; formal proofs hold regardless of MMIO source; document clearly |

+| Bool representation differs C vs Rust | Use `_Bool` in header (not `bool`); `ctypes.c_bool` maps to `_Bool` correctly |

+## Verification (how to test end-to-end)

+1. `cargo test --manifest-path bare-metal-tests/Cargo.toml` -- 62 tests pass (no regression)

+2. `cargo build --release --manifest-path cubie-ffi/Cargo.toml` -- .so builds

+3. `python3 -c "from pipeline.cubie_gate import CubieGate; g = CubieGate(); print(g.admit(g.create_test_request()))"` -- prints True

+4. `python3 pipeline/cubie_openvino_demo.py --mode light --duration 10` -- runs without error

+5. `python3 pipeline/generate_diagrams.py --output artifacts/` -- produces PNGs

+6. All artifacts in `artifacts/` directory are non-empty and submission-ready


ToolSearch

Question: select:ExitPlanMode


Question: select:ExitPlanMode


ExitPlanMode

Prompt: build Rust crates with cargo

Prompt: run cargo tests

Prompt: run Python scripts for smoke testing

Prompt: install Python dependencies with pip

Prompt: list directory contents

Prompt: run git commands for staging and committing

# Plan: Intel AI Edge Application Ready Verification -- Cubie Trust Compiler Integration

## Context

The Cubie Trust Compiler is a formally verified AI workload admission gate that compiles to native x86_64 machine code. It already:
- Cross-compiles to 3 bare-metal targets (RISC-V, x86_64, AArch64)
- Has a C-ABI entry point: `extern "C" fn cubie_admit(*const CubieRequest) -> AdmitResult`
- Runs in ~730 ns/call on Intel Core Ultra 9 285HX (~1.37M admits/sec)
- Is proven correct by 754 theorems across Coq 8.18.0, Lean 4.30.0, and Verus
- Has 62 passing integration tests and zero external dependencies
- Is backed by 3 patent families (US11956363B2, US20240195628A1)

Intel's AI Edge Application Ready Verification program (Rev 2.1, Jan 2026) is a 5-step ISV onboarding process. Nick has testbed access. The goal: get Cubie verified as an Intel AI Edge application, which unlocks technical support and co-marketing.

**What Intel needs from us:**
1. Application running on Intel edge hardware
2. Workload performance metrics at light/medium/heavy loads
3. Pipeline block diagram
4. Resource utilization screenshots (CPU/GPU/NPU)
5. Sizing tool report OR Appendix A alternative artifacts

**The gap:** The bare-metal library has no Python bindings, no C header, no container config, and no OpenVINO pipeline integration. We need a bridge from `libcubie_bare_metal.a` to a Python+OpenVINO demo pipeline.

---

## Phase 1: FFI Bridge (Python-callable shared library)

**Why:** Intel's ecosystem is Python+OpenVINO. We need `cubie_admit()` callable from Python.

**Why ctypes over PyO3:** Zero Python build tooling. Load `.so`, define struct, call function. Minimal moving parts for a verification submission.

**Why mock feature:** Non-mock builds use `core::ptr::read_volatile()` on hardware MMIO addresses -- this will segfault in Linux userspace. The `mock` feature replaces MMIO with AtomicU32 cells. The admission logic is identical. The formal proofs hold regardless of MMIO backend.

### Files to create:

- [ ] **`cubie-ffi/Cargo.toml`** -- New workspace member, `crate-type = ["cdylib"]`, depends on `cubie-bare-metal` with `features = ["std", "mock"]`
- [ ] **`cubie-ffi/src/lib.rs`** -- Re-exports `cubie_admit`, adds `cubie_mock_setup()` (configures eFuse key + NVLink + PCIe mock state) and `cubie_create_valid_request()` (returns a CubieRequest with correct HMAC)
- [ ] **`cubie-ffi/include/cubie.h`** -- C header documenting the ABI. Uses `_Bool` (not `bool`). Includes `static_assert(sizeof(CubieRequest) == 40)`
- [ ] **`pipeline/cubie_gate.py`** -- Python ctypes wrapper. `CubieRequest` as `ctypes.Structure`, `CubieGate` class with `admit()`, `benchmark()`, `create_test_request()` methods

### Modify:

- [ ] **`Cargo.toml`** (workspace root) -- Add `"cubie-ffi"` to `members` list

### Build:

```bash
cargo build --release --manifest-path cubie-ffi/Cargo.toml
# Output: target/release/libcubie_ffi.so (Linux) or cubie_ffi.dll (Windows)
```

### Verify:

```bash
cargo test --manifest-path bare-metal-tests/Cargo.toml  # 62 tests still pass
python3 -c "from pipeline.cubie_gate import CubieGate; g = CubieGate(); print(g.benchmark(100000))"
```

### Critical detail -- CubieRequest struct layout:

```
Offset  Field              Type    Size
0       who_pass           bool    1
1       what_pass          bool    1
2       how_pass           bool    1
3       where_pass         bool    1
4       when_pass          bool    1
5       why_pass           bool    1
6       has_valid_lease    bool    1
7       epoch_fresh        bool    1
8       request_hash       u64     8
16      capability_hmac    u64     8
24      key_slot           u8      1
25      peer_id            u8      1
26-31   (padding)                  6
32      adapter_id         u64     8
Total: 40 bytes
```

Source: `bare-metal/src/types.rs:4-25`

---

## Phase 2: OpenVINO Pipeline (Cubie as pre-inference gate)

**Architecture:**

```
Request --> [Cubie Gate ~730ns] --Allow--> [OpenVINO Inference (CPU/GPU/NPU)] --> Result
                |
                +--Deny--> [Blocked -- zero accelerator resources consumed]
```

**Workload type:** Video Processing (preferred) or NLP Text Generation.

### Files to create:

- [ ] **`pipeline/cubie_openvino_demo.py`** -- Main demo. Loads `libcubie_ffi.so` + OpenVINO model. For each request: build CubieRequest -> call `cubie_admit()` -> if Allow, run inference -> log metrics. Supports `--mode light|medium|heavy` and `--workload video|nlp`
- [ ] **`pipeline/load_profiles.py`** -- Load generator. Light: 1 req/s. Medium: 10 req/s, 4 threads. Heavy: max throughput. Each runs configurable duration (default 60s)
- [ ] **`pipeline/resource_monitor.py`** -- Background thread sampling CPU/GPU/NPU utilization at 1s intervals, writes timestamped CSV
- [ ] **`pipeline/requirements.txt`** -- `openvino>=2024.0`, `psutil>=5.9`, `matplotlib>=3.7`, `numpy>=1.24`

### Model options:

- Video: `ssd_mobilenet_v2_coco` (OpenVINO Model Zoo) -- `omz_downloader --name ssd_mobilenet_v2_coco && omz_converter --name ssd_mobilenet_v2_coco`
- NLP: `TinyLlama-1.1B` in OpenVINO format -- `pip install openvino-genai`

---

## Phase 3: Intel Edge Testbed Deployment

**Prereqs:** Testbed access (confirmed), Ubuntu 22.04/24.04, Rust toolchain, Python 3.10+, OpenVINO, Node.js 22+

### Steps:

- [ ] **Clone repo and build FFI** on testbed
- [ ] **Run speedtest** -- `cargo run --release --manifest-path bare-metal-tests/Cargo.toml --bin speedtest` -- captures Intel CPU brand string + TSC-calibrated ns/call for all gate components
- [ ] **Install OpenVINO + download model** on testbed
- [ ] **Run demo pipeline at 3 load levels** -- capture metrics CSVs
- [ ] **Capture resource utilization** -- CPU/GPU/NPU screenshots at each load level

### Intel Edge AI Sizing Tool (primary method):

```bash
git clone https://github.com/intel/edge-ai-sizing-tool
cd edge-ai-sizing-tool && ./install.sh && ./start.sh
# Browse to http://localhost:8080
# Configure workload, generate PDF report
```

### Appendix A fallback (if sizing tool doesn't support custom pipelines):

```bash
sudo dmidecode > artifacts/hardware_info.txt                    # System info
lsof -p $(pgrep -f cubie_openvino_demo) > artifacts/runtime_libs.txt  # Runtime libraries
# Resource utilization captured by resource_monitor.py at each load level
```

---

## Phase 4: Generate Submission Artifacts

### Files to create:

- [ ] **`pipeline/generate_diagrams.py`** -- Produces pipeline block diagram (PNG) + formal verification architecture diagram using matplotlib
- [ ] **`artifacts/capture_system_info.sh`** -- Captures CPU, RAM, GPU, NPU, OS, OpenVINO version, Rust version
- [ ] **`artifacts/pipeline_description.md`** -- Narrative for Intel form: "First formally verified AI workload admission gate for Intel edge hardware. 754 theorems, sub-microsecond decisions, 3 patent families, native x86_64 machine code, FIPS 198-1 HMAC-SHA256."
- [ ] **`artifacts/build_submission_report.py`** -- Compiles system info + metrics CSVs + diagrams into a single PDF

### Required artifacts checklist:

| Artifact | Source | Format |
|----------|--------|--------|
| System info | `capture_system_info.sh` | TXT |
| Pipeline description | `pipeline_description.md` | Text (pasted into form) |
| Block diagram | `generate_diagrams.py` | PNG |
| Sizing tool report | Edge AI Sizing Tool or Appendix A | PDF |
| CPU utilization (light/med/heavy) | `resource_monitor.py` | Screenshots/CSV |
| GPU utilization (light/med/heavy) | `intel_gpu_top` or resource_monitor | Screenshots/CSV |
| System photo | Testbed screenshot | Image |

---

## Phase 5: Submit

- [ ] **Fill Intel form** at `https://app.smartsheet.com/b/form/019a3bfa6a0b7623876994c2950fc14f`
- [ ] **Upload all artifacts** from Phase 4
- [ ] **Application name:** "Cubie Trust Compiler -- Formally Verified AI Admission Gate"

**Narrative for Intel review meeting:**

> The Cubie Trust Compiler is the first formally verified AI workload admission gate. It runs as a sub-microsecond pre-inference filter on Intel edge hardware, making admission decisions in ~730 nanoseconds -- proven correct by 754 independent theorems across three proof assistants (Coq, Lean 4, Verus). Every AI inference request passes through the gate before consuming GPU or NPU compute. Denied requests use zero accelerator resources. The entire stack compiles to native x86_64 machine code with zero external dependencies. Protected by 3 patent families (US11956363B2, US12073439B2, US20240195628A1).

Support: intel.edge.ai.application.qualification@intel.com

---

## File Summary

| Phase | New Files | Modified |
|-------|-----------|----------|
| 1: FFI Bridge | `cubie-ffi/Cargo.toml`, `cubie-ffi/src/lib.rs`, `cubie-ffi/include/cubie.h`, `pipeline/cubie_gate.py` | `Cargo.toml` (workspace) |
| 2: Pipeline | `pipeline/cubie_openvino_demo.py`, `pipeline/load_profiles.py`, `pipeline/resource_monitor.py`, `pipeline/requirements.txt` | -- |
| 3: Deploy | -- (commands only) | -- |
| 4: Artifacts | `pipeline/generate_diagrams.py`, `artifacts/capture_system_info.sh`, `artifacts/pipeline_description.md`, `artifacts/build_submission_report.py` | -- |
| **Total** | **12 new files** | **1 modified** |

**Zero existing files touched** (all bare-metal, Coq, Lean, Verus source preserved).

---

## Critical Source Files (read-only dependencies)

| File | What the plan uses from it |
|------|---------------------------|
| `bare-metal/src/types.rs:4-25` | `CubieRequest` #[repr(C)] layout -- Python ctypes must mirror exactly |
| `bare-metal/src/admit.rs:20-32` | `cubie_admit` C-ABI signature -- FFI crate re-exports this |
| `bare-metal/src/mmio.rs` | Mock setter functions (`mock_set_efuse_key`, etc.) -- exposed through FFI |
| `bare-metal/src/hmac.rs` | `hmac_sha256` -- used by FFI to compute valid test HMACs |
| `bare-metal-tests/src/speedtest.rs` | CPUID + RDTSC benchmarks -- run on testbed for Intel-specific numbers |
| `Cargo.toml` | Workspace members list -- add `cubie-ffi` |

---

## Risks and Mitigations

| Risk | Mitigation |
|------|-----------|
| CubieRequest struct layout mismatch (Rust vs Python) | `static_assert(sizeof == 40)` in C header + round-trip test |
| Sizing tool doesn't support custom pipelines | Use Appendix A alternative (explicitly supported by Intel Rev 2.1) |
| NPU utilization is zero (model not compiled for NPU) | Frame Cubie as CPU-side filter that *reduces* unnecessary NPU load |
| Mock MMIO means "not real hardware" | HMAC-SHA256 computation is identical; formal proofs hold regardless of MMIO source; document clearly |
| Bool representation differs C vs Rust | Use `_Bool` in header (not `bool`); `ctypes.c_bool` maps to `_Bool` correctly |

---

## Verification (how to test end-to-end)

1. `cargo test --manifest-path bare-metal-tests/Cargo.toml` -- 62 tests pass (no regression)
2. `cargo build --release --manifest-path cubie-ffi/Cargo.toml` -- .so builds
3. `python3 -c "from pipeline.cubie_gate import CubieGate; g = CubieGate(); print(g.admit(g.create_test_request()))"` -- prints True
4. `python3 pipeline/cubie_openvino_demo.py --mode light --duration 10` -- runs without error
5. `python3 pipeline/generate_diagrams.py --output artifacts/` -- produces PNGs
6. All artifacts in `artifacts/` directory are non-empty and submission-ready


Error: The user doesn't want to proceed with this tool use. The tool use was rejected (eg. if it was a file edit, the new_string was NOT written to the file). To tell you how to proceed, the user said:
how do you even know what an incomingf workload looks like?

Note: The user's next message may contain a correction or preference. Pay close attention — if they explain what went wrong or how they'd prefer you to work, consider saving that to memory for future sessions.


That's a critical question. I'm designing a gate without understanding what it's gating. Let me research what an actual Intel Edge AI workload looks like.


Agent

Research Intel Edge AI Sizing Tool architecture

Prompt:
Research the Intel Edge AI Sizing Tool at https://github.com/intel/edge-ai-sizing-tool to understand:

1. What is the actual architecture? (Node.js frontend + Python workers?)
2. How are workloads configured and submitted?
3. What does an inference request look like in their pipeline?
4. What is DLStreamer and how does it process video frames?
5. What does the OpenVINO inference API look like for a single request?
6. How does the sizing tool measure resource utilization?

Also research:
- OpenVINO Python API: what does `compiled_model.infer_new_request()` or `core.compile_model()` look like?
- DLStreamer pipeline elements and how they chain together
- What metadata or properties does an AI inference request carry (model name, device target, input tensor shape, priority, etc.)?

The goal is to understand what a REAL incoming AI workload looks like so we can design an admission gate that gates actual workload properties, not made-up fields.


WebFetch

Prompt: Extract the complete README content. What is the architecture of this tool? What are the main components? How are workloads defined? What technologies does it use (Node.js, Python, OpenVINO, DLStreamer)? What does the pipeline configuration look like? What API endpoints exist?


# Edge AI Sizing Tool Architecture Analysis

## Overview
The Edge AI Sizing Tool is designed to "showcase the scalability and performance of AI use cases on intel-based edge devices" with zero-code configuration for selecting inputs, accelerators, performance modes, and AI models.

## Main Components

Based on the README structure, the tool comprises:

1. **Frontend** - Web interface (React-based, port 8080)
2. **Workers** - Background services handling inference (ports 5000-6000)
3. **Custom Models Directory** - Storage for OpenVINO IR format models
4. **Scripts** - Utility and setup automation

## Workload Definition

The tool supports five model input methods:

- **Predefined Models**: Curated set including YOLOv8/11, Mask R-CNN, diffusion models, and LLMs
- **Hugging Face Integration**: Direct model repository access with token authentication
- **ModelScope Integration**: Alternative model hub support
- **ZIP Upload**: Custom OpenVINO IR models packaged with XML/BIN files
- **Custom Directory**: Models placed in `./custom_models/` for auto-detection

## Core Technologies

- **Node.js 22+** for frontend/orchestration
- **Python 3.10+** for inference backends
- **OpenVINO** for model inference optimization
- **Intel GPU/NPU drivers** for hardware acceleration
- **System monitoring**: CPU, GPU, memory, and disk I/O metrics

## Configuration & APIs

The tool uses environment variables (`.env` file) for configuration including `HF_TOKEN`, `HF_ENDPOINT`, and `MODELSCOPE_DOMAIN`. While specific API endpoint details aren't detailed in the provided content, the architecture suggests RESTful communication between frontend and worker services on designated port ranges.


I now have comprehensive data from all the research threads. Here is the full synthesis.

---

## Research Findings: Real AI Workload Anatomy for Admission Gate Design

### 1. Intel Edge AI Sizing Tool Architecture

**Stack**: Next.js 14 frontend (TypeScript, port 8080) + Python worker processes (FastAPI, ports 5000-6000) + MongoDB + local disk storage.

**Worker types** (7 independent Python workers under `workers/`):
- `dlstreamer/` -- video analytics via GStreamer/DLStreamer pipelines
- `instance-segmentation/` -- video segmentation via DLStreamer
- `text-generation/` -- LLM inference via `openvino_genai.LLMPipeline`
- `text-to-image/` -- image generation
- `text-to-speech/` -- audio synthesis
- `automatic-speech-recognition/` -- speech-to-text
- `custom-application-profiling/` -- resource monitoring (CPU/GPU/NPU/memory/disk)

**Orchestration pattern**: The Next.js frontend spawns Python worker processes. Each worker runs its own FastAPI server on a dedicated port. The frontend proxies to workers by port number -- the `/api/infer` route accepts `{ port: number, ...data }`, validates the port, then forwards the entire request body to `http://localhost:{port}/infer`. There is no central job queue or scheduler; workers are standalone processes.

**Resource monitoring**: The `custom-application-profiling` worker (Platform Profiler) collects real metrics:
- CPU: per-PID `psutil` percentages, normalized by core count
- GPU: Intel `xpumcli` JSON output (compute utilization %, memory MB, memory %)
- NPU: sysfs sampling from `/sys/devices/.../npu_busy_time_us` (delta/time calculation)
- Memory: RSS per-process via psutil
- Disk I/O: read/write bytes/sec via `psutil.disk_io_counters()`
- Baseline subtraction: 5-second idle sample before profiling, then delta calculation

### 2. How Workloads Are Configured and Submitted

Each worker accepts CLI arguments at spawn time. Here is what a real workload configuration looks like across the three main worker types:

**Vision/DLStreamer worker** (`workers/dlstreamer/main.py`):
```
--input          # video file path, /dev/videoN, or rtsp:// URL
--model          # model name (e.g., "yolo11n")
--device         # inference device: CPU, GPU, NPU
--decode_device  # decode device: CPU, GPU
--batch_size     # frames per inference batch (default: 1)
--number_of_streams  # parallel video streams
--width_limit    # video width constraint
--height_limit   # video height constraint
--tcp_port       # internal TCP port for frame transport
--port           # FastAPI port for API/metrics
--id             # workload identifier for status updates
```

**Text generation worker** (`workers/text-generation/main.py`):
```
--model-name     # HuggingFace model ID or .zip path
--repo-source    # "huggingface" or "modelscope"
--device         # target hardware: "CPU" (default), "GPU", "NPU"
--port           # FastAPI port (default: 5997)
--id             # workload identifier
```
Runtime inference request body: `{ prompt: string, max_tokens?: number }` (default 100)

**Instance segmentation worker** (`workers/instance-segmentation/main.py`):
```
--input          # video source
--model          # e.g., "mask_rcnn_inception_resnet_v2_atrous_coco"
--device         # CPU/GPU/NPU
--decode_device  # CPU/GPU/NPU
--batch_size     # default: 1
--model_precision  # FP16/FP32
--number_of_streams
--id
```

Workers report status back to the frontend via `PATCH http://127.0.0.1:8080/api/workloads/{id}` with `{ status: "active"|"failed", port: number }`.

### 3. What an Inference Request Looks Like in the Pipeline

There are three distinct layers where "inference request" means different things:

**Layer A -- OpenVINO Python API (direct)**:
```python
import openvino as ov

core = ov.Core()
model = core.read_model("model.xml")              # Load IR model
compiled = core.compile_model(model, "CPU", {      # Compile with config
    ov.properties.hint.performance_mode: ov.properties.hint.PerformanceMode.LATENCY,
    ov.properties.hint.model_priority: ov.properties.hint.Priority.HIGH,
    ov.properties.inference_num_threads: 4,
    ov.properties.hint.num_requests: 2,
    ov.properties.num_streams: 1,
    ov.properties.hint.scheduling_core_type: ov.properties.hint.SchedulingCoreType.PCORE_ONLY,
    ov.properties.affinity: ov.properties.Affinity.CORE,
    ov.properties.cache_dir: "/tmp/ov_cache",
    ov.properties.enable_profiling: True,
})
infer_request = compiled.create_infer_request()
input_tensor = ov.Tensor(np.random.rand(1, 3, 224, 224).astype(np.float32))
infer_request.set_input_tensor(input_tensor)
infer_request.infer()                              # synchronous
# or: infer_request.start_async() + infer_request.wait()
output = infer_request.get_output_tensor()
profiling = infer_request.get_profiling_info()      # per-layer timing
```

**Layer B -- OpenVINO GenAI (high-level, used by text-generation worker)**:
```python
import openvino_genai
pipe = openvino_genai.LLMPipeline(str(model_path), device)
result = pipe.generate(prompt, max_new_tokens=100)
```
This wraps the low-level API entirely.

**Layer C -- OpenVINO Model Server (OVMS) REST/gRPC (KServe V2 Protocol)**:
```
POST /v2/models/{model_name}/versions/{version}/infer
```
```json
{
  "id": "request-42",
  "parameters": { "binary_data_size": 0 },
  "inputs": [
    {
      "name": "input_image",
      "shape": [1, 3, 224, 224],
      "datatype": "FP32",
      "parameters": {},
      "data": [0.12, 0.34, ...]
    }
  ],
  "outputs": [
    { "name": "detection_output" }
  ]
}
```
OVMS model config (`config.json`):
```json
{
  "model_config_list": [
    {
      "config": {
        "name": "yolov8",
        "base_path": "/models/yolov8",
        "target_device": "GPU",
        "batch_size": "auto",
        "shape": "auto",
        "nireq": 32,
        "plugin_config": {
          "PERFORMANCE_HINT": "THROUGHPUT",
          "NUM_STREAMS": "4"
        }
      }
    }
  ]
}
```

### 4. DLStreamer -- How It Processes Video Frames

DLStreamer is a GStreamer-based framework. Pipelines are built as GStreamer command strings.

**Core inference elements**:
| Element | Purpose | Key Properties |
|---------|---------|---------------|
| `gvadetect` | Object detection on full frames | `model`, `model-proc`, `device`, `nireq`, `inference-interval`, `threshold`, `batch-size`, `pre-process-backend`, `ie-config`, `model-instance-id` |
| `gvaclassify` | Classification on detected ROIs | Same as above, operates on `GstVideoRegionOfInterestMeta` |
| `gvainference` | Generic full-frame inference | Same core properties, outputs raw `GstGVATensorMeta` |
| `gvawatermark` | Draw inference overlays on frames | |

**Pipeline chain** (real example from the sizing tool):
```
filesrc location=video.mp4
  ! decodebin
  ! videoconvert
  ! gvadetect model=/models/yolo11n.xml device=GPU
      nireq=4 batch-size=2 inference-interval=1
      pre-process-backend=va-surface-sharing
      model-instance-id=inf1
  ! gvawatermark
  ! jpegenc
  ! tcpserversink host=0.0.0.0 port=5100
```

**Metadata flow**:
- `gvadetect` produces `GstVideoRegionOfInterestMeta` (bounding boxes) attached to each `GstBuffer`
- `gvaclassify` reads those ROIs, runs classification on each, adds `GstStructure` entries to the ROI's `params` list containing: tensor data, dimensions, model name, layer names, label string
- `gvainference` produces `GstGVATensorMeta` (raw tensor output) -- one per model output layer
- Python/C++ API: `GVA::VideoFrame` -> `GVA::RegionOfInterest` -> `GVA::Tensor` (map-like storage: output blob dims, layout, rank, precision, raw data, interpreted labels)

**Key properties on `gvadetect`/`gvaclassify`/`gvainference`**:
- `model` -- path to `.xml` (OpenVINO IR)
- `model-proc` -- JSON file describing pre/post-processing per layer
- `device` -- `CPU`, `GPU`, `NPU`, `MULTI:GPU,CPU`
- `nireq` -- number of parallel inference requests
- `inference-interval` -- run inference every N-th frame (skip frames)
- `batch-size` -- frames batched per inference call
- `threshold` -- detection confidence cutoff
- `pre-process-backend` -- `ie`, `opencv`, `va`, `va-surface-sharing`
- `ie-config` -- pass-through OpenVINO Inference Engine config string
- `model-instance-id` -- for sharing a loaded model across elements

### 5. OpenVINO Inference API -- Single Request Detail

**`ov.Core.compile_model()` config dictionary** -- the complete set of real properties:

| Property | Python Path | Values | Purpose |
|----------|------------|--------|---------|
| Performance mode | `ov.properties.hint.performance_mode` | `LATENCY`, `THROUGHPUT` | High-level scheduling hint |
| Model priority | `ov.properties.hint.model_priority` | `LOW(0)`, `MEDIUM(1)`, `HIGH(2)` | Multi-model resource priority |
| Num requests | `ov.properties.hint.num_requests` | int | Optimal async request count |
| Num streams | `ov.properties.num_streams` | int or `AUTO` | Parallel inference streams |
| Inference threads | `ov.properties.inference_num_threads` | int | CPU thread limit |
| Scheduling core type | `ov.properties.hint.scheduling_core_type` | `ANY_CORE`, `PCORE_ONLY`, `ECORE_ONLY` | P-core vs E-core on hybrid CPUs |
| Affinity | `ov.properties.affinity` | `NONE`, `CORE`, `NUMA`, `HYBRID_AWARE` | Thread pinning strategy |
| Cache directory | `ov.properties.cache_dir` | string path | Model compilation cache |
| Enable profiling | `ov.properties.enable_profiling` | bool | Per-layer timing counters |
| Execution mode | `ov.properties.hint.execution_mode` | `PERFORMANCE`, `ACCURACY` | Precision trade-off |

**`InferRequest` methods**:
- `set_input_tensor(index, tensor)` / `set_tensor(name, tensor)`
- `infer()` -- synchronous, blocking
- `start_async()` -- non-blocking
- `wait()` / `wait_for(timeout_ms)` -- block for async result
- `set_callback(fn)` -- async completion callback
- `get_output_tensor(index)` -- get result
- `get_profiling_info()` -- per-layer execution times

**`AsyncInferQueue`** -- manages a pool of `InferRequest` objects for throughput mode.

**Device targets**: `CPU`, `GPU`, `NPU`, `AUTO`, `MULTI:GPU,CPU`, `HETERO:GPU,CPU`, `BATCH:GPU`

### 6. How the Sizing Tool Measures Resource Utilization

The `custom-application-profiling` worker implements a `ProfilingOrchestrator` with five monitor classes:

1. **CPUMonitor**: `psutil` per-PID CPU%, normalized by logical core count
2. **MemoryMonitor**: RSS (MB) summed across process tree
3. **GPUMonitor**: Intel `xpumcli` JSON -- compute utilization %, memory MB, memory %
4. **NPUMonitor**: sysfs sampling of `npu_busy_time_us` -- `(busy_delta / time_delta) * 100`
5. **DiskIOMonitor**: `psutil.disk_io_counters()` delta -> MB/s

Process: establish 5-second idle baseline, then continuous sampling with delta calculation to isolate workload-specific consumption. Process tree tracking detects child spawns/exits for accurate PID aggregation.

### 7. Synthesis: What a REAL Incoming AI Workload Carries

Based on all the above, here are the actual fields that exist on real AI workloads at different levels:

**Workload-level (what the sizing tool tracks)**:
```
workload_id:         string     # unique identifier
workload_type:       enum       # "dlstreamer" | "text-generation" | "instance-segmentation" | ...
model_name:          string     # "yolo11n", "mask_rcnn_...", HuggingFace ID
model_precision:     enum       # "FP16" | "FP32"
device:              string     # "CPU" | "GPU" | "NPU" | "AUTO" | "MULTI:GPU,CPU"
decode_device:       string     # "CPU" | "GPU" (video workloads only)
batch_size:          int        # frames or tokens per inference
number_of_streams:   int        # parallel video streams (vision) or inference streams
input_source:        string     # file path, RTSP URL, device path, or prompt text
status:              enum       # "active" | "failed" | "pending"
port:                int        # worker's API port
```

**Model compilation config (OpenVINO properties)**:
```
performance_mode:    enum       # LATENCY | THROUGHPUT
model_priority:      enum       # LOW(0) | MEDIUM(1) | HIGH(2)
num_streams:         int        # parallel inference streams on device
inference_num_threads: int      # CPU thread limit
num_requests:        int        # async request pool size (nireq)
scheduling_core_type: enum     # ANY_CORE | PCORE_ONLY | ECORE_ONLY
affinity:            enum       # NONE | CORE | NUMA | HYBRID_AWARE
execution_mode:      enum       # PERFORMANCE | ACCURACY
cache_dir:           string     # model cache path
enable_profiling:    bool       # per-layer timing
```

**Inference request (KServe V2 / OVMS)**:
```
id:                  string     # request correlation ID
model_name:          string     # target model
model_version:       string     # optional version
inputs[]:
  name:              string     # tensor name (e.g., "input_image")
  shape:             int[]      # e.g., [1, 3, 224, 224]
  datatype:          string     # "FP32", "FP16", "UINT8", "INT64", etc.
  data:              any[]      # raw tensor values or binary
  parameters:        dict       # optional per-input params
parameters:          dict       # request-level params (e.g., binary_data_size)
```

**DLStreamer pipeline element properties (per inference stage)**:
```
model:               string     # .xml path
model_proc:          string     # .json pre/post-processing config
device:              string     # CPU | GPU | NPU | MULTI:...
nireq:               int        # parallel inference requests
inference_interval:  int        # process every N-th frame
batch_size:          int        # frames batched per inference
threshold:           float      # detection confidence cutoff
pre_process_backend: enum       # ie | opencv | va | va-surface-sharing
ie_config:           string     # pass-through OpenVINO config
model_instance_id:   string     # shared model handle
```

**Runtime metrics (what the profiler produces)**:
```
cpu_percent:         float      # per-PID, normalized 0-100
memory_rss_mb:       float      # resident set size
gpu_compute_pct:     float      # GPU utilization %
gpu_memory_mb:       float      # GPU memory consumed
gpu_memory_pct:      float      # GPU memory utilization %
npu_utilization_pct: float      # NPU busy time %
disk_read_mbps:      float      # read throughput
disk_write_mbps:     float      # write throughput
fps:                 float      # frames per second (video)
latency_ms:          float      # inference latency
throughput:          float      # tokens/sec or inferences/sec
time_to_first_token: float      # LLM-specific
```

### Key Takeaway for Admission Gate Design

An admission gate should validate properties that actually exist at the point of workload submission, not internal runtime details. The real gating surface is:

1. **model_name** + **model_precision** -- what model, at what precision
2. **device** -- where it wants to run (CPU/GPU/NPU/AUTO/MULTI)
3. **batch_size** -- how much work per inference call
4. **num_streams** / **nireq** -- parallelism demand
5. **performance_mode** -- LATENCY vs THROUGHPUT (determines resource allocation strategy)
6. **model_priority** -- LOW/MEDIUM/HIGH (OpenVINO's own priority system)
7. **input_shape** -- tensor dimensions (determines memory footprint)
8. **workload_type** -- vision/text-generation/segmentation (determines pipeline shape)
9. **inference_interval** -- for video, how many frames are skipped (affects throughput demand)

These are not made-up fields. They are the actual parameters that OpenVINO, DLStreamer, OVMS, and the Intel Edge AI Sizing Tool use in production.

---

Sources:
- [Intel Edge AI Sizing Tool - GitHub](https://github.com/intel/edge-ai-sizing-tool)
- [Open Edge Platform Edge AI Sizing Tool](https://github.com/open-edge-platform/edge-ai-sizing-tool)
- [Intel Solution Hub - Edge AI Sizing Tool](https://builders.intel.com/ecosystem-engagement/solution-hub/applications/edge-ai-sizing-tool)
- [OpenVINO compile_model API](https://docs.openvino.ai/2024/api/ie_python_api/_autosummary/openvino.compile_model.html)
- [OpenVINO Python API Exclusives](https://docs.openvino.ai/2025/openvino-workflow/running-inference/integrate-openvino-with-your-application/python-api-exclusives.html)
- [OpenVINO InferRequest API (2025)](https://docs.openvino.ai/2025/api/ie_python_api/_autosummary/openvino.runtime.InferRequest.html)
- [OpenVINO Inference Request Documentation](https://docs.openvino.ai/2025/openvino-workflow/running-inference/inference-request.html)
- [OpenVINO Running Inference Pipeline (2025)](https://docs.openvino.ai/2025/openvino-workflow/running-inference.html)
- [OpenVINO High-level Performance Hints](https://docs.openvino.ai/2025/openvino-workflow/running-inference/optimize-inference/high-level-performance-hints.html)
- [OpenVINO hint.Priority enum](https://docs.openvino.ai/2025/api/ie_python_api/_autosummary/openvino.properties.hint.Priority.html)
- [OpenVINO Query Device Properties](https://docs.openvino.ai/2025/openvino-workflow/running-inference/inference-devices-and-modes/query-device-properties.html)
- [OpenVINO Model Server Parameters](https://docs.openvino.ai/2025/model-server/ovms_docs_parameters.html)
- [OpenVINO Model Server KServe REST API](https://docs.openvino.ai/2025/model-server/ovms_docs_rest_api_kfs.html)
- [OpenVINO Benchmark Tool](https://docs.openvino.ai/2024/learn-openvino/openvino-samples/benchmark-tool.html)
- [OpenVINO CPU Device Properties](https://docs.openvino.ai/2026/openvino-workflow/running-inference/inference-devices-and-modes/cpu-device.html)
- [OpenVINO CompiledModel API](https://docs.openvino.ai/2024/api/ie_python_api/_autosummary/openvino.runtime.CompiledModel.html)
- [DLStreamer gvadetect element](https://dlstreamer.github.io/elements/gvadetect.html)
- [DLStreamer gvainference element](https://dlstreamer.github.io/elements/gvainference.html)
- [DLStreamer gvaclassify element](https://dlstreamer.github.io/elements/gvaclassify.html)
- [DLStreamer Metadata](https://dlstreamer.github.io/dev_guide/metadata.html)
- [DLStreamer GStreamer Bin Elements](https://dlstreamer.github.io/architecture_2.0/gstreamer_bins)
- [DLStreamer Performance Guide](https://dlstreamer.github.io/dev_guide/performance_guide.html)
- [DLStreamer GitHub Repository](https://github.com/open-edge-platform/dlstreamer)
- [KServe V2 Inference Protocol](https://kserve.github.io/website/docs/concepts/architecture/data-plane/v2-protocol)
- [OpenVINO Model Server GitHub](https://github.com/openvinotoolkit/model_server)

agentId: a0c0e7213a0900211 (use SendMessage with to: 'a0c0e7213a0900211' to continue this agent)
<usage>total_tokens: 57576
tool_uses: 53
duration_ms: 367667</usage>

Prompt:
Research the Intel Edge AI Sizing Tool at https://github.com/intel/edge-ai-sizing-tool to understand:

1. What is the actual architecture? (Node.js frontend + Python workers?)
2. How are workloads configured and submitted?
3. What does an inference request look like in their pipeline?
4. What is DLStreamer and how does it process video frames?
5. What does the OpenVINO inference API look like for a single request?
6. How does the sizing tool measure resource utilization?

Also research:
- OpenVINO Python API: what does `compiled_model.infer_new_request()` or `core.compile_model()` look like?
- DLStreamer pipeline elements and how they chain together
- What metadata or properties does an AI inference request carry (model name, device target, input tensor shape, priority, etc.)?

The goal is to understand what a REAL incoming AI workload looks like so we can design an admission gate that gates actual workload properties, not made-up fields.


Now I understand what a real workload looks like. The key insight: the CubieRequest fields (who/what/how/where/when/why + HMAC) need to map to **actual OpenVINO workload properties**, not abstract booleans. Let me update the plan with this grounded understanding.


1	# Plan: Intel AI Edge Application Ready Verification -- Cubie Trust Compiler Integration
2
3	## Context
4
5	The Cubie Trust Compiler is a formally verified AI workload admission gate that compiles to native x86_64 machine code. It already:
6	- Cross-compiles to 3 bare-metal targets (RISC-V, x86_64, AArch64)
7	- Has a C-ABI entry point: `extern "C" fn cubie_admit(*const CubieRequest) -> AdmitResult`
8	- Runs in ~730 ns/call on Intel Core Ultra 9 285HX (~1.37M admits/sec)
9	- Is proven correct by 754 theorems across Coq 8.18.0, Lean 4.30.0, and Verus
10	- Has 62 passing integration tests and zero external dependencies
11	- Is backed by 3 patent families (US11956363B2, US20240195628A1)
12
13	Intel's AI Edge Application Ready Verification program (Rev 2.1, Jan 2026) is a 5-step ISV onboarding process. Nick has testbed access. The goal: get Cubie verified as an Intel AI Edge application, which unlocks technical support and co-marketing.
14
15	**What Intel needs from us:**
16	1. Application running on Intel edge hardware
17	2. Workload performance metrics at light/medium/heavy loads
18	3. Pipeline block diagram
19	4. Resource utilization screenshots (CPU/GPU/NPU)
20	5. Sizing tool report OR Appendix A alternative artifacts

# Plan: Intel AI Edge Application Ready Verification -- Cubie Trust Compiler Integration

## Context

The Cubie Trust Compiler is a formally verified AI workload admission gate that compiles to native x86_64 machine code. It already:
- Cross-compiles to 3 bare-metal targets (RISC-V, x86_64, AArch64)
- Has a C-ABI entry point: `extern "C" fn cubie_admit(*const CubieRequest) -> AdmitResult`
- Runs in ~730 ns/call on Intel Core Ultra 9 285HX (~1.37M admits/sec)
- Is proven correct by 754 theorems across Coq 8.18.0, Lean 4.30.0, and Verus
- Has 62 passing integration tests and zero external dependencies
- Is backed by 3 patent families (US11956363B2, US20240195628A1)

Intel's AI Edge Application Ready Verification program (Rev 2.1, Jan 2026) is a 5-step ISV onboarding process. Nick has testbed access. The goal: get Cubie verified as an Intel AI Edge application, which unlocks technical support and co-marketing.

**What Intel needs from us:**
1. Application running on Intel edge hardware
2. Workload performance metrics at light/medium/heavy loads
3. Pipeline block diagram
4. Resource utilization screenshots (CPU/GPU/NPU)
5. Sizing tool report OR Appendix A alternative artifacts


Edit

# Plan: Intel AI Edge Application Ready Verification -- Cubie Trust Compiler Integration

## Context

The Cubie Trust Compiler is a formally verified AI workload admission gate that compiles to native x86_64 machine code. It already:
- Cross-compiles to 3 bare-metal targets (RISC-V, x86_64, AArch64)
- Has a C-ABI entry point: `extern "C" fn cubie_admit(*const CubieRequest) -> AdmitResult`
- Runs in ~730 ns/call on Intel Core Ultra 9 285HX (~1.37M admits/sec)
- Is proven correct by 754 theorems across Coq 8.18.0, Lean 4.30.0, and Verus
- Has 62 passing integration tests and zero external dependencies
- Is backed by 3 patent families (US11956363B2, US20240195628A1)

Intel's AI Edge Application Ready Verification program (Rev 2.1, Jan 2026) is a 5-step ISV onboarding process. Nick has testbed access. The goal: get Cubie verified as an Intel AI Edge application, which unlocks technical support and co-marketing.

**What Intel needs from us:**
1. Application running on Intel edge hardware
2. Workload performance metrics at light/medium/heavy loads
3. Pipeline block diagram
4. Resource utilization screenshots (CPU/GPU/NPU)
5. Sizing tool report OR Appendix A alternative artifacts

**The gap:** The bare-metal library has no Python bindings, no C header, no container config, and no OpenVINO pipeline integration. We need a bridge from `libcubie_bare_metal.a` to a Python+OpenVINO demo pipeline.

# Plan: Intel AI Edge Application Ready Verification -- Cubie Trust Compiler Integration

## Context

The Cubie Trust Compiler is a formally verified AI workload admission gate that compiles to native x86_64 machine code. It already:
- Cross-compiles to 3 bare-metal targets (RISC-V, x86_64, AArch64)
- Has a C-ABI entry point: `extern "C" fn cubie_admit(*const CubieRequest) -> AdmitResult`
- Runs in ~730 ns/call on Intel Core Ultra 9 285HX (~1.37M admits/sec)
- Is proven correct by 754 theorems across Coq 8.18.0, Lean 4.30.0, and Verus
- Has 62 passing integration tests and zero external dependencies
- Is backed by 3 patent families (US11956363B2, US20240195628A1)

Intel's AI Edge Application Ready Verification program (Rev 2.1, Jan 2026) is a 5-step ISV onboarding process. Nick has testbed access. The goal: get Cubie verified as an Intel AI Edge application, which unlocks technical support and co-marketing.

**What Intel needs from us:**
1. Application running on Intel edge hardware
2. Workload performance metrics at light/medium/heavy loads
3. Pipeline block diagram
4. Resource utilization screenshots (CPU/GPU/NPU)
5. Sizing tool report OR Appendix A alternative artifacts

**The gap:** The bare-metal library has no Python bindings, no C header, no container config, and no OpenVINO pipeline integration. We need a bridge from `libcubie_bare_metal.a` to a Python+OpenVINO demo pipeline.

---

## What a Real Intel Edge AI Workload Looks Like

The Intel Edge AI Sizing Tool (Node.js frontend + Python FastAPI workers, ports 5000-6000) processes workloads that carry these actual properties:

**Workload-level properties (what gets submitted to a worker):**
```
workload_id:           string    # unique identifier
workload_type:         enum      # "dlstreamer" | "text-generation" | "instance-segmentation" | ...
model_name:            string    # "yolo11n", HuggingFace ID, or custom .xml path
model_precision:       enum      # "FP16" | "FP32"
device:                string    # "CPU" | "GPU" | "NPU" | "AUTO" | "MULTI:GPU,CPU"
batch_size:            int       # frames or tokens per inference call
number_of_streams:     int       # parallel inference streams
input_source:          string    # file path, RTSP URL, /dev/videoN, or prompt text
```

**OpenVINO compile_model config (set at model load time):**
```
performance_mode:      LATENCY | THROUGHPUT
model_priority:        LOW(0) | MEDIUM(1) | HIGH(2)
num_streams:           int
inference_num_threads: int
num_requests (nireq):  int       # async request pool size
scheduling_core_type:  ANY_CORE | PCORE_ONLY | ECORE_ONLY
affinity:              NONE | CORE | NUMA | HYBRID_AWARE
execution_mode:        PERFORMANCE | ACCURACY
```

**DLStreamer pipeline element properties (per-stage in video pipelines):**
```
gvadetect / gvaclassify / gvainference:
  model:               .xml path
  device:              CPU | GPU | NPU
  nireq:               parallel inference requests
  inference_interval:  process every N-th frame
  batch_size:          frames batched per call
  threshold:           detection confidence cutoff
  pre_process_backend: ie | opencv | va | va-surface-sharing
```

**KServe V2 inference request (OVMS REST API):**
```json
{
  "id": "request-42",
  "inputs": [{ "name": "input", "shape": [1,3,224,224], "datatype": "FP32" }],
  "outputs": [{ "name": "detection_output" }]
}
```

### Mapping CubieRequest to Real Workload Properties

The existing `CubieRequest` (40 bytes, `bare-metal/src/types.rs:4-25`) has abstract booleans. Here is how each field maps to real Intel Edge workload properties:

| CubieRequest field | Real-world meaning on Intel Edge | How it gets populated |
|---|---|---|
| `who_pass` | **Identity**: Is the requesting entity (user/service/container) authenticated? | Check API key, JWT, or mTLS cert against allow-list |
| `what_pass` | **Capability**: Is this model+precision allowed on this device? | Validate `model_name` + `model_precision` + `device` against policy |
| `how_pass` | **Method**: Is the execution config (batch_size, nireq, streams) within bounds? | Check `batch_size <= max_batch`, `nireq <= max_nireq`, `num_streams <= max_streams` |
| `where_pass` | **Location**: Is this edge node authorized for this workload type? | Check node ID / testbed system ID against deployment policy |
| `when_pass` | **Lease**: Is the time-bounded execution lease still valid? | Check `lease_expiry > current_time` |
| `why_pass` | **Policy**: Does the workload comply with governance rules? | Check `model_priority`, `performance_mode`, resource quotas |
| `has_valid_lease` | Lease not expired | `lease_expiry_epoch > now()` |
| `epoch_fresh` | Request not stale/replayed | `request_epoch` within freshness window |
| `request_hash` | Hash of (model_name + device + batch_size + input_shape) | SHA-256 of workload config fields, truncated to u64 |
| `capability_hmac` | HMAC-SHA256 of request_hash with eFuse key | Proves the request was authorized by the platform root of trust |
| `key_slot` | Which eFuse key slot (0 = platform root) | Always 0 for single-tenant edge; multi-tenant uses slots 0-7 |
| `peer_id` | NVLink peer to check for deadlock | Maps to GPU device index in multi-GPU edge systems |
| `adapter_id` | PCIe adapter for bandwidth check | Maps to GPU/NPU PCIe device ID |

### The Pipeline Integration Point

The Cubie gate sits at **workload submission time** -- BEFORE `core.compile_model()` or DLStreamer pipeline launch. It does NOT gate individual inference frames. It gates whether the entire workload is allowed to start.

```
Workload Request (model, device, config)
    |
    v
[Policy Evaluator] -- populates CubieRequest bools from workload config
    |
    v
[cubie_admit()] -- ~730ns, HMAC + NVLink + PCIe hardware checks
    |
    +-- Allow --> core.compile_model(model, device, config) --> inference loop
    |
    +-- Deny --> HTTP 403, workload never touches GPU/NPU
```