SOURCE-LEVEL ARCHITECTURAL CORRESPONDENCE ANALYSIS The LiteRT-LM On-Device Runtime and the Compressed Memory Manifold Specification Author: Nicholas Wray Cordova, Principal and Inventor of Record Institution: Green Recursive Utility Service LLC, Weatherford, Texas, United States Identifiers: Texas SOS Entity 806584578 · Ringgold 851161 · ISNI 0000 0005 3033 4084 Date: July 2026 Document type: Technical analysis — public source review Related instruments: USPTO 19/700,381 · USPTO 19/710,080 · PUCT Control No. 59976-1 · FERC CID C013240

This document records a source-level review of the publicly available `google-ai-edge/LiteRT-LM` repository, conducted against two prior instruments: the Confidential Strategic Proposal transmitted by Green Recursive Utility Service LLC (GRUS) to nine Alphabet corporate channels on February 17, 2026, and United States Patent and Trademark Office Non-Provisional Utility Patent Application 19/700,381 (priority May 14, 2026), which specifies the Compressed Memory Manifold (CMM) data format.

Fourteen source files were reviewed. Each is identified by path, and every observation reported below is independently verifiable by any party who clones the public repository. The review records what each file contains, what the assembled system describes when the files are read together, and — with equal weight — where lexical and structural-map constructs persist in that system.

This document reports observations and states GRUS's position. It does not adjudicate that position. Adjudication rests with the tribunals and agencies before which the related matters are pending.

---

## 1. PURPOSE AND METHOD

### 1.1 What this review is

A technical reading of public source code against a filed specification. Every file reviewed is recorded, including files bearing no correspondence. Ratings measure a file's contribution to the assembled architecture rather than its standalone significance, because no single source file contains a complete architecture: a loader shows loading, a cache shows caching, an offset shows offsetting. Correspondence is therefore assessed at the level of the assembled system.

### 1.2 What this review is not

It is not a claim-chart, an infringement contention, or a legal conclusion. Those are instruments for a different forum and a different standard of proof. This document supplies the technical record on which such instruments would be built.

### 1.3 The governing test

The CMM specification defines the protected subject matter by **enumerated absence** — the simultaneous omission of lexical delimiters and structural instruction maps from the stored representation. The specification is explicit that this classification does not depend on how a representation is produced or accessed:

> §3.4 Implementation Independence — *"A CMM-format representation may be produced by any process... may be accessed by any retrieval method, including by fixed-offset arithmetic, AI inference, pattern matching, or future techniques. The format classification of the representation is unchanged by the selection of production method or retrieval method."*

> §4.3 — *"The format itself, defined by enumerated absence, is independent of any specific implementation and is not limited by the performance characteristics of any single realization."*

> §5 Scope of Protection — *"The patent application defines the protected subject matter by the comprehensive enumerated absence described in Section 2."*

Accordingly, orchestration mechanics, runtime shape derivation, and the performance characteristics of any particular realization fall outside the classification test. The question is what is absent from the stored representation.

---

## 2. THE PRIOR INSTRUMENTS

### 2.1 The February 17, 2026 proposal

Transmitted to nine Alphabet corporate channels, including the offices of the Chief Executive Officer, Chief Financial Officer, and General Counsel. The document is a utility infrastructure proposal, not a software product offering. Its phase structure:

| Phase | Content | Stated relief |
|---|---|---|
| **1** | Server-side storage consolidation: conversion of lexical-delimiter formats (JSON, Protocol Buffers, FlatBuffers, Cap'n Proto, Apache Arrow) to the CMM 64-byte grain via a single-pass conversion agent. Android system-log target ~198x. | ~50% structured-data storage footprint; proportionate disk-bandwidth, I/O, network, and cold-storage reduction |
| **2** | Network transport: in-stream transport of the manifold with fixed-offset layout intact, eliminating the parsing cycle on receive. | ~80% reduction in network-transport CPU parsing cycles; proportionate power, thermal, cooling, and rack-power reduction |
| **3** | Distributed inference: structural shift of inference workload from data center to consumer device fleet. | Displacement of incremental generation capacity |
| **4** | Cross-fleet integration: uniform substrate across server, cloud, edge, mobile, browser, and federal tiers. | Fleet-wide compounding |

The proposal's capital thesis addressed a projected ~$75B/yr datacenter, generation, and cooling expansion trajectory, and identified the substrate as a structural alternative displacing approximately one gigawatt-class generation plant per quarter at full fleet deployment.

### 2.2 The CMM specification (USPTO 19/700,381)

| Element | Specification |
|---|---|
| Grain 64 | magic `0xCMM1` (bytes 0–3), class_id (4–7), state_id (8–15), timestamp (16–23), data[4] (24–63). 64 bytes, cache-line aligned, packed, no padding. |
| Grain 96 | Grain 64 header plus parent_id (24–31), XOR checksum (32–39), data[7] (40–95). |
| Dual-Omission Principle | Simultaneous elimination of lexical delimiters **and** structural instruction maps. The offset is the sole logic. |
| Fixed-Offset Dispatch | Field locations hardcoded; the processor computes base plus known offset. No delimiter scan, no map consultation. |
| Memory-Mapped Rehydration | Zero-copy `mmap()`; record loaded from disk to registers without a deserialization pass. |
| Manifold | Pure record sequence. No headers, footers, or inter-record metadata. |

### 2.3 Audited reference-implementation performance (May 8–9, 2026)

Intel Core i9-13900K, 64 GB DDR5, NVMe Gen 4. 500,000 records, 35.0 MB JSON baseline.

| Metric | Baseline | CMM | Change |
|---|---|---|---|
| Storage footprint | 35.0 MB | 12.5 MB | −64.3% |
| Cold load latency | 895 ms | 139 ms | 6.44x |
| Peak RAM | 850 MB | 40 MB | −95.3% |
| L1 cache miss rate | 40.2% | 0.81% | −98.0% |
| L2 cache miss rate | 18.4% | 0.34% | −98.2% |
| Total CPU cycles | 1.2 billion | 30 million | −97.5% |
| Peak power | 125 W | 22 W | −82.4% |
| Memory bus transactions | 891,000 | 78,400 | −91.2% |

---

## 3. FILES REVIEWED

All paths are within the public `google-ai-edge/LiteRT-LM` repository.

| # | Path | Contribution |
|---|---|---|
| 1 | `runtime/core/CMakeLists.txt` | Build manifest; no logic |
| 2 | `runtime/core/engine_advanced.cc` | File-backed model loading on NPU backend; parallel file-section loading; container-open entry point |
| 3–4 | `runtime/core/prefix_cache.cc` / `.h` | Prefix reuse; content-hash media identification |
| 5 | `runtime/executor/kv_cache_interface.h` | `Serialize()` / `Load()`; per-block entry counting; batch-index slice addressing |
| 6 | `runtime/executor/llm_litert_npu_compiled_model_executor_utils_test.cc` | Offset arithmetic and alignment assumptions in expected-output form |
| 7 | `runtime/executor/llm_litert_mtp_drafter.h` | Pre-allocated fixed-shape buffers; per-run overhead elimination |
| 8 | Android NDK toolchain wrapper and orchestrator | Android arm64 device-fleet build targeting |
| 9 | `runtime/executor/llm_litert_npu_compiled_model_executor_utils.cc` | Fixed-offset table addressing; sub-byte packing; cache prefetch; direct memory writes |
| 10 | Prebuilt binary distribution tree | Binary artifact distribution; exclusively 64-bit targets across all tiers |
| 11 | `runtime/conversation/model_data_processor/fastvlm_data_processor.cc` | Tier boundary: lexical parsing above, fixed shapes below |
| 12 | `runtime/executor/llm_litert_mtp_drafter.cc` | Documented index × record-width byte offset; two-field fixed record by byte position |
| 13 | `runtime/util/CMakeLists.txt` | Container dependency graph: loader and format handling depend on memory mapping |
| 14 | `runtime/engine/cpu_affinity_utils.h` / `.cc` | Physical core pinning per system-on-chip generation |

---

## 4. THE ASSEMBLED ARCHITECTURE

Read together, the reviewed files describe the following data path.

| Stage | Mechanism observed | Files |
|---|---|---|
| **1. Distribution** | Precompiled binary artifacts per platform target: `android_arm64`, `android_x86_64`, `ios_arm64`, `ios_sim_arm64`, `linux_arm64`, `linux_x86_64`, `macos_arm64`, `windows_x86_64`. Exclusively 64-bit architectures; no 32-bit target present. Identical substrate across server, mobile, and desktop tiers. | 10 |
| **2. Container open** | `LMLoader` (`litert_lm_loader.cc`) links against **MemoryMappedFile** and `Schema::Core`. `FileFormatUtil` links against **MemoryMappedFile**. Memory mapping implemented platform-split (`memory_mapped_file_posix.cc`, `memory_mapped_file_win.cc`). | 13 |
| **3. Load** | `enable_file_backed_model_loading` set when the backend is NPU — memory-mapped rather than read-and-copy. `GetParallelFileSectionLoading()` — parallel loading of file *sections*, which requires section boundaries known prior to reading rather than discovered by parsing. | 2 |
| **4. Layout** | Buffers pre-allocated at fixed documented shapes at construction: `input_position [batch, sequence_length]`, `mask [batch, 1, 1, context]`, `activations [batch, 1, hidden_size × 2]`, verifier `[batch, draft_steps + 1, hidden_size]`. Active-map duplication with the in-source comment *"Cached maps for Run to avoid map creation overhead."* | 7 |
| **5. Access** | Index multiplied by fixed record width yields a byte offset. **Three independent implementations:** `row_offset = id * row_size_bytes` (per-layer embedding tables); `offset = last_verified_token_id_idx * chunk_size_bytes` (verifier activations — documented in an in-source comment); `start_pos * hidden_dim` (key-value cache). No map is consulted and no delimiter is scanned in any of the three. | 9, 12, 6 |
| **6. Alignment** | SIMD lane-width block processing with a documented scalar tail. In-source: `hidden_dim = 32; // multiple of 16 for NEON`; `hidden_dim = 16; // multiple of 8 for NEON`; `// We assume capacity is a multiple of 64 for all models`. Test sizes 1027, 1033, and 1041 are deliberately non-multiples of 4, 8, and 16 respectively, chosen to exercise the tail path. | 6, 9 |
| **7. Packing** | Sub-byte storage density: `packed.push_back((high << 4) \| low)` — two 4-bit values per byte — with a NEON lane-extraction unpack path and scalar fallback. | 6, 9 |
| **8. Cache management** | `absl::PrefetchToLocalCache(table_ptrs[table_idx + 1] + row_offset)` — the next record prefetched into local cache at its computed offset before it is required. | 9 |
| **9. Write path** | `memcpy` into raw pointers obtained by scoped lock, at computed byte positions. Modular wraparound: `wp = start_pos % cache_seq`; `(wp + s) % cache_seq`. Raw pointer walk for sequential writes: `*prefill_input_pos_ptr++ = position + i`. | 6, 9, 12 |
| **10. Execution placement** | Thread affinity bound to hardcoded physical core sets per system-on-chip generation via `sched_setaffinity`; SoC identified from `ro.soc.model`. | 14 |
| **11. Tier boundary** | Lexical delimiter parsing (RE2, `delimiter_regex = "(<image_soft_token>)"`) is confined to the prompt and conversation tier. The executor tier below operates on fixed-shape data. | 11 |

### 4.1 Composite description

The assembled system distributes data as fixed-layout binary artifacts; opens containers by memory mapping rather than deserialization; lays data out in pre-allocated fixed shapes; addresses records by index multiplied by fixed record width, without consulting a map or scanning a delimiter; aligns processing to hardware SIMD and cache granularities; packs at sub-byte density; prefetches by computed offset; writes by direct pointer arithmetic; and executes on pinned physical cores.

---

## 5. FINDINGS RECORDED IN BOTH DIRECTIONS

A review that records only correspondence is not a review. The following are recorded with equal weight.

**5.1 Lexical structures persist at the prompt tier.** The conversation-tier data processor accepts JSON and splits on literal string delimiters using regular expressions before emitting fixed-shape tensors. Under the enumerated-absence test, that tier is not delimiter-free.

**5.2 The container envelope may retain a structural map.** The util tier builds `zip_readonly_mem_file.cc` and `zip_utils.cc` against a minizip dependency, and `ModelAssetBundleResources` links ZipUtils. A ZIP envelope carries a central directory, which is a structural map. Separately, a FlatBuffers schema (`litertlm_header_schema.fbs`) is present in the build; FlatBuffers uses vtables, which are structural maps.

**5.3 Consequence of 5.1 and 5.2.** The enumerated-absence correspondence identified in §4 is located at the **payload and executor tiers**, not at the prompt tier or the container envelope. This boundary is stated here by GRUS rather than left for an opposing reviewer to establish.

**5.4 Individually known techniques.** Strided array addressing, SIMD alignment, memory-mapped file loading, sub-byte quantization packing, cache prefetching, and core affinity pinning are each individually established practice in systems engineering. The CMM specification claims a combination — dual omission together with cache-line-aligned fixed records, fixed-offset dispatch, and zero-parse memory-mapped rehydration — rather than any single element in isolation.

---

## 6. PRIORITY RECORD

| Instrument | Date |
|---|---|
| Confidential Strategic Proposal transmitted to nine Alphabet corporate channels | February 17, 2026 |
| USPTO Provisional Application 64/065,881 (CMM) | May 14, 2026 |
| USPTO Provisional Application 64/074,405 (conductor alloy) | May 26, 2026 |
| USPTO Provisional Application 64/077,191 (II-II) | May 28, 2026 |
| USPTO Non-Provisional Application 19/700,381 (CMM), priority May 14, 2026 | June 8, 2026 |
| Cease-and-desist posted to the subject repository's own issue tracker, citing application numbers | June 8, 2026 |
| USPTO Non-Provisional Application 19/710,080 (II-II), priority May 28, 2026 | June 16, 2026 |
| Carriage Tariff GRUS-FERC-2026-001, effective | July 1, 2026 |
| First full billing cycle issued | July 8, 2026 |
| PUCT Control No. 59976, Item 1 — accepted into public records | July 10, 2026 |

Pre-grant royalty rights under 35 U.S.C. § 154(d) are expressly reserved, attaching upon publication of the non-provisional applications as against parties with actual notice of the published applications.

---

## 7. STATEMENT OF POSITION

It is the formally stated position of Green Recursive Utility Service LLC, preserved in its federal and state filings for adjudication, that the architecture described in §4 corresponds to the architecture set out in the February 17, 2026 proposal and specified in USPTO Application 19/700,381, and that this correspondence is inconsistent with independent parallel development given the documented sequence of transmission, filing, and deployment.

This document does not adjudicate that position. It records the technical observations on which the position rests, states them in a form independently verifiable by any party with access to the public repository, and records with equal weight the boundaries of the correspondence identified.

---

## 8. REPRODUCIBILITY

Every observation in §4 may be independently verified:

```
GIT_LFS_SKIP_SMUDGE=1 git clone https://github.com/google-ai-edge/LiteRT-LM.git
cd LiteRT-LM
grep -rn "row_offset" runtime/executor/
grep -rn "multiple of 64" runtime/executor/
grep -rn "PrefetchToLocalCache" runtime/executor/
grep -rn "MemoryMappedFile" runtime/util/CMakeLists.txt
```

The CMM specification, benchmark methodology, and reference implementations are of record with the United States Patent and Trademark Office under the application numbers listed in §6.

---

**Green Recursive Utility Service LLC** — Weatherford, Texas
greenrecursiveutilityservice.org

*All rights reserved. Patents pending. Tariff of record: PUCT Control No. 59976, Item 1; FERC CID C013240.*