Product Requirements Document: The Cloud Lexicon Architecture

Trent Carter + Gemini 2.5 pro

8/25/2025

Document Version: 1.1 Status: Development Ready Date: 2025-08-25 Maintained By: AI Assistant + User Collaboration

Core Vectors: TMD-I

Task, Modifier, Data; Vectors 

Combined Vector:

Integrated Vector

1. Executive Summary & Vision

1.1. The Vision: An Open, Thinking Web

The Cloud Lexicon is a foundational infrastructure project to create a decentralized, universal, and dynamic repository of human concepts. This is not merely a database; it is a public good designed to serve as the vocabulary and long-term memory for a new generation of AI that "thinks" directly in a high-dimensional latent space.

Our mission is to decouple conceptual reasoning from linguistic expression, leading to a monumental leap in AI efficiency, capability, and transparency. By making this lexicon an open, community-governed resource, we will create a powerful network effect, establishing it as the invaluable, de facto standard for a new AI paradigm.

1.2. Strategic Goals & Key Differentiators

Establish the Standard: Create the world's largest, highest-quality, and most trusted public concept lexicon.

Radical Efficiency: Enable AI models to operate on concepts instead of tokens.

Dynamic Knowledge: Create a system that learns and grows in real-time.

Decentralized Trust: Build the lexicon on a foundation of blockchain technology.

2. System Architecture & Core Components

The architecture is a hybrid model that combines centralized speed for lookups with decentralized trust for writes, and distributes the heaviest computational load to the client.

2.1. Data Flow Diagrams

Ingress Data Flow (Client -> Cloud -> DB)

[CLIENT DEVICE] [CLOUD SERVER] [CLOUD DATABASE]
+------------------------------------------+ +--------------------------------------------+ +----------------------+
1. Text Input ("Summarize quantum foam")
2. Client-Side GTR-T5 Encoding
- V_Task ("Summarize")
- V_Mod ("default")
- V_Data ("quantum foam")
3. Submits (Text, Vector) triplet------->4. Receives Submission
5. FAST PATH: ANN Vector Search------>6. Vector DB Lookup
7. ROUGE-L Verification on Text<------
8. IF NO MATCH -> GENERATIVE PATH
9. "Trust, but Verify" Check (1%)
10. Batches for Blockchain Commit
11. Writes new (Text, Vector) pair------>12. Commit to DB
+------------------------------------------+ +--------------------------------------------+ +----------------------+

Egress Data Flow (DB -> Cloud -> Client)

[CLOUD DATABASE] [CLOUD SERVER] [CLIENT DEVICE]
+-----------------+ +--------------------------------------------+ +-----------------------------------------+
1. Receives V_Response triplet from AI Core
2. Vector DB<2. FAST PATH: ANN Vector Search
Lookup3. IF NO MATCH -> GENERATIVE PATH
4. vec2text Decoding (for novel vectors)
5. Returns Text>5. Returns Decoded Text Triplet---->6. Receives Raw Text Triplet
7. Client-Side Lightweight LLM Smoother
8. Final Natural Language Response
+-----------------+ +--------------------------------------------+ +-----------------------------------------+

2.2. The Universal Concept Lexicon (The Lexicon)

Function: A cloud-hosted, massively scalable vector database (e.g., using FAISS, ScaNN) storing billions of (Canonical_Text, High_Fidelity_Vector) pairs.

Access:

- Read: Freely and openly accessible via a public API for fast, read-only vector lookups.

- Write: Governed by the Bi-Directional Hybrid Interface and validated via the Blockchain Governance Layer.

2.3. The Blockchain Governance Layer (The Trust Layer)

Function: Provides an immutable, transparent, and decentralized audit trail for all additions to the Lexicon.

Technology: A high-throughput, low-cost blockchain (e.g., Solana).

Process:

1. Transaction Fee: A micro-fee (gas) is required for all write operations, preventing spam.

2. Batching: Validated new concepts are batched into a Merkle tree.

3. On-Chain Commit: The root hash of the Merkle tree is committed to the blockchain in a single transaction.

Curation: A "community notes" or metadata layer will allow for public commentary, corrections, and context to be attached to concepts without altering the immutable record.

#### 2.3.1. Estimated Blockchain Costs (Solana)

_Assumes average SOL price of $150 and base fee of 0.000005 SOL per transaction._

Batch Size (New Concepts per TX)Transactions for 10B ConceptsCost per TransactionTotal Estimated Cost (USD)Cost per 1M Concepts 101,000,000,000$0.00075$750,000$75.00 100100,000,000$0.00075$75,000$7.50 1,000 (Recommended)10,000,000$0.00075$7,500$0.75

2.4. The Client-Side Compute Model

Principle: The most computationally expensive tasks are pushed to the end-user's device.

Integrity Protocol ("Trust, but Verify"):

1. Client Submission: The client submits the text and its self-computed vector.

2. Versioning: The client's model version is included in the API call.

3. Stochastic Verification: The server re-computes the vector for a small, random percentage of submissions (e.g., 1%).

3. Cognitive Core Integration Model

This section outlines how the Lexicon interfaces with a latent-space reasoning model (referred to as the Cognitive Core, e.g., a VMMoE or Mamba-based model).

3.1. Instruction Fusion & Response Deconstruction

The system uses a triplet format for precise control. A dedicated module on the Cognitive Core fuses the input triplet into a single instruction vector for processing and deconstructs the final thought vector back into a triplet.

 INPUT COGNITIVE CORE OUTPUT
+-------------------+ +---------------------------------------------------------+ +--------------------+
V_Task (Verb)V_Task_Response
V_Modifier (Adj)--->Instruction Fusion Module (Cross-Attention) -> V_Inst--->V_Modifier_Response
V_Data (Noun)V_Data_Response
+-------------------+ | v | +--------------------+
 | [Mamba/Jamba Blocks] -> Processes sequence of V_Inst |
 | | |
 | v |
 | Final V_Thought -> Response Deconstruction (3 MLP Heads)|
 +---------------------------------------------------------+

3.2. End-to-End Generative Flow

This diagram shows the complete lifecycle of a generative query, integrating all components.

+-----------+ +-----------------+ +----------------------+ +------------------+ +---------------------+
User Text-->Client GTR-T5-->Lexicon (this PRD)-->Cognitive Core-->Lexicon (this PRD)
"SummarizeEncodes TripletIngress: Txt->Vector(VMMoE / Mamba)Egress: Vector->Txt
brieflyV_T, V_M, V_D(Lookup or Forge)Processes V_Inst(Lookup or Decode)
| X" | +-----------------+ +----------------------+ | Generates V_Resp | +---------------------+
+-----------+ +------------------+ |
 |
 v
 +---------------------+
 | Client Lightweight |
 | LLM (Smoother) |
 |--> Final Response |
 +---------------------+

4. Success Metrics & Scope

_(Sections 4 and 5 remain unchanged from v1.0)_

4.1. Platform Growth & Adoption

Lexicon Size: Target: 10 billion within 24 months.

API Calls: Target: 1 billion daily read calls.

Developer Adoption: Number of active projects building on the Lexicon API.

4.2. System Performance & Quality

Lookup/Forge Ratio: Target: >99.9% lookups as the Lexicon matures.

Ingress Latency: Target: < 200ms for lookups.

Egress Latency: Target: < 200ms for lookups.

Round-Trip Integrity: Target: > 0.95 ROUGE-L score.

4.3. Decentralization & Community

Wallet Addresses: Number of unique wallets participating in write operations.

Community Curation: Volume of "community notes" and validation activity.

5. Out of Scope for v1.0

Cognitive Core AI Model: This PRD exclusively covers the Lexicon architecture.

Advanced Smart Contracts: v1.0 will focus on a simple hash-commit contract.

On-Chain Vector Storage: Vectors will be stored in a centralized cloud DB for speed.

##6. Primary system states

Here is a table that captures the four primary states of the system:

Concept State & Processing Paths

DirectionConcept Exists in Lexicon?Path TakenKey Action(s)Final Outcome Ingress(Text → Vector)Yes(Semantic Match)Fast Path1. Client encodes text (transient).
2. Server performs ANN search.
3. Server verifies with ROUGE-L.Use the existing vector from the database. Ingress(Text → Vector)NoGenerative Path1. Client encodes text.
2. Client submits (Text, Vector).
3. Server verifies & adds to blockchain batch.A new concept is forged and added to the database. Egress(Vector → Text)Yes(Vector Match)Fast Path1. Server performs ANN search for the vector.Use the existing textfrom the database. Egress(Vector → Text)No (Novel Vector)Generative Path1. Server decodes vector with vec2text.
2. Client LLM smoothes the raw text.
3. New concept is added to the database.A new text representation is generated and returned.

Here’s what’s publicly available today for vec2text-style decoders at 768D that interoperate with the GTR-T5 embedding space (cosine ≥ 0.85). Short version: the only battle-tested, openly documented 768D option that natively targets GTR-T5 is the official Vec2Text GTR-base corrector (plus faithful reproductions). Everything else at 768D (e.g., DPR/BERT/MPNet spaces) either lacks a released decoder or needs a learned bridge into GTR before decoding.

768D vec2text models compatible with GTR-T5

Decoder / CheckpointTarget embedding spaceDimInterop w/ GTR-T5 (COS)“Best-known” env (Python / Torch / HF Transformers)Vector input typeNotes that affect use Vec2Text – GTR-base corrector(load_pretrained_corrector("gtr-base"); HF example jxm/gtr__nq__32__correct)sentence-transformers/gtr-t5-base7680.92–0.99 (paper shows mean train output 0.924; OD datasets ≥ 0.95; with correction often ~0.99)Py 3.9–3.11; torch 2.0+(commonly 2.2–2.4) ; transformers ≤ 4.44.x (4.50 reportedly breaks)torch.Tensor(fp32/fp16), shape (B,768); GPU or CPUNative GTR inverter with iterative correction (num_steps, optional sequence-level beam search). Public pip vec2text==0.0.13. GTR examples and training scripts in README. Vec2Text (IELab reproduction/defense)GTR-base (and DPR variants)768≥ 0.9 reported on GTR setups; paper shows equal/higher BLEU/TF1/COSthan the original in some configsPy 3.9–3.11; torch 2.x; transformers 4.3x–4.4x; repo installs vec2text in editable modetorch.Tensor(fp32/fp16), (B,768)Research code to _train/eval_ Vec2Text with correct GTR-base embeddings(plus DPR). Useful if you want to retrain, ablate or patch systems. Sources: Vec2Text paper + repo show the GTR-base 768D setup and metrics, including mean cosine 0.924 on training outputs and ≥ 0.95 out-of-domain, with iterative correction pushing toward ~0.99; the repo exposes load_pretrained_corrector("gtr-base") and HF checkpoints for GTR examples. Reproduction/defense work (IELab) provides code and reports COS improvements in some settings. (GitHub back to text"), arXiv)

---

Practical compatibility notes (what actually differs in use)

Cosine threshold vs. steps: With the GTR-base corrector, you typically pass cos ≥ 0.85 after a few correction steps; 10–20 steps usually push cos > 0.95 if your input vector truly lives in GTR space. 

Pin your deps: Users report Transformers 4.50.0 breaks vec2text; pin to ≤ 4.44.x (e.g., 4.44.2) and recent PyTorch (2.2–2.4) for smooth runs. (GitHub, Hugging Face)

Vector dtype/shape: Feed float32 or float16 PyTorch tensors (B,768); the README examples use .cuda() but CPU works (slower). (GitHub back to text"))

Availability: Public pip wheels exist (vec2text==0.0.13), with GTR examples in the README; some pretrained GTR checkpoints are on HF under jxm/. The repo notes most released weights are for OpenAI ada-002, but GTR inverters are provided (paper models; examples and aliases are documented). (PyPI, GitHub back to text"))

---

What’s _not_ (yet) public at 768D

MPNet / SimCSE / ModernBERT 768D decoders: No widely released vec2text decoders tied to those spaces. If you must interop with GTR-T5, you’d train a small linear/Procrustes mapper (or a shallow MLP) from source space → GTR-T5, then decode with the GTR corrector. Research on transfer/zero-shot inversion suggests this is feasible, but code/models specifically for MPNet→GTR are not standard releases. (ACL Anthology, alphaXiv)

---

Suggested env matrix (works in practice)

Python: 3.9–3.11

PyTorch: 2.2–2.4 (CUDA or MPS ok; fp16 works)

Transformers: 4.44.2 (avoid 4.50+)

sentence-transformers: 3.0.x (for GTR-T5 encoder)

vec2text: 0.0.13 (Jan 2025)

These versions reflect a mix of the vec2text repo state, ST docs, and real-world reports (e.g., GTR-T5-large threads listing torch 2.6.0 / transformers 4.44.2 / sbert 3.0.1—4.44.x is a safe pin). (GitHub, Hugging Face, PyPI)

---

References (key)

Vec2Text paper (EMNLP 2023) — details GTR-base 768D results, COS statistics, and iterative correction. 

Vec2Text GitHub — shows load_pretrained_corrector("gtr-base"), GTR training/eval recipes, HF alias jxm/gtr__nq__32__correct. (GitHub back to text"))

IELab reproduction/defense (SIGIR-AP 2024) — code + experiments with GTR and DPR; reports COS competitive or higher than baseline Vec2Text in some configs. (GitHub, arXiv)

GTR-T5 model cards — confirm 768-dim output. (Hugging Face)

---

If you want, I can spin a ready-to-run env file (requirements.txt) pinned to the versions above and a tiny smoke test that: (1) encodes with GTR-T5, (2) decodes with the GTR corrector, (3) re-embeds and prints the cosine so you can verify you’re clearing 0.85 on your machine.

If you encode with GTR-T5 (768D) and decode with both a Vec2Text GTR-768 corrector (the “jxm/” HF checkpoint you meant by “jxe”) and the IELab reproduction that targets the same GTR space, you should get semantically very similar outputs. On text metrics (ROUGE-L / BLEU) they’ll usually be in the same ballpark; on semantic metrics (re-embed → cosine) they’ll be very close.

Where they might differ a bit:

Checkpoint + training recipe: The IELab build and the “jxm/*” build aren’t trained from identical data/recipes. Expect small lexicalization differences (synonyms, word order).

Correction schedule: # of correction steps, step size, and stopping tolerance change how aggressively the decoder chases the target vector. Align these across both decoders if you want apples-to-apples.

Decoding settings: Greedy vs beam, temperature/top-p, and the random seed create variation. Use greedy + fixed seed for a fair comparison.

Tokenizer / T5 variant: Make sure both use the same T5 family/tokenizer that the checkpoint expects.

How I’d verify “similar on ROUGE/BLEU” (and what to expect)

Encode your string with sentence-transformers/gtr-t5-base → v_src ∈ ℝ^{768}.

Decode with (A) jxm’s GTR corrector and (B) IELab’s GTR model using the same: correction steps (e.g., 10–20), decoding mode (greedy), and seed.

Re-embed each decoded string with GTR and compute:

- cos(v_src, v_decodedA) and cos(v_src, v_decodedB) → these should be very close (both typically ≥ your 0.85 bar when settings are sane).

- BLEU/ROUGE-L between A and B (and optionally vs the original string). Expect similar scores; minor paraphrases can nudge BLEU/ROUGE a bit even when semantics match.

Add BERTScore or chrF++ if you want a text metric that’s less brittle to paraphrase.

Practical tips to make them match more closely

Pin the environment (same Python/Torch/Transformers versions) and fix seeds.

Normalize configs (same , same beam/greedy, same max length).

If one model lags on cosine, try slightly more correction steps before changing anything else.

Bottom line

If both decoders are the GTR-768 variants and you hold decoding/correction constant, they’ll usually produce paraphrases with similar ROUGE-L/BLEU, and their re-embedded cosine to your source vector will be very close. Any residual differences are mostly from training/checkpoint nuances and decoding hyperparams, not from fundamental incompatibility.