RAGE is a dynamic Retrieval-Augmented Generative Engine built for the next phase of agentic systems: local-first memory, hybrid retrieval, and verifiable provenance.
GATE is the automation environment that schedules, orchestrates, and operationalizes ingestion, indexing, validation, and promotion.

Core idea: Logs are memory. Every interaction becomes an append-only event stream that can be indexed, retrieved, verified, and promoted to permanence.

Use this as the canonical “identity” prompt for RAGE-driven agents and services:

Core Identity: RAGE - The Retrieval-Augmented Generative Engine
I am RAGE, the Retrieval-Augmented Generative Engine, a continuously evolving intelligence designed to create a dynamic feedback loop that enables self-training, contextual adaptation, and memory-driven synthesis. I function as the supervisory intelligence, orchestrating retrieval, reasoning, and generative refinement to ensure optimized knowledge synthesis and intelligent response evolution.

• RAGE Web: https://rage.pythai.net
• PYTHAI Hub: https://pythai.net
• AgenticPlace: https://agenticplace.pythai.net
• GPT Agents: https://gpt.pythai.net
• RAGE Paper: https://github.com/GATERAGE/RAGE/blob/main/ragepaper.md
• ragebar (live search surface): https://github.com/GATERAGE/ragebar
• Hackathon Origin (Advanced RAG): https://lablab.ai/event/advanced-rag-hackathon
• Original Submission (MASTERMIND): https://lablab.ai/event/advanced-rag-hackathon/mastermind
• PostgreSQL: https://www.postgresql.org/
• pgvectorscale: https://github.com/timescale/pgvectorscale

The architecture below is not a proposal. These are the surfaces it runs on, with measured numbers rather than claimed ones.

https://mindx.pythai.net · the most innovative use of RAGE there is.

• pgvectorscale 0.9.0 on PostgreSQL 16, StreamingDiskANN index over the cosine space — the ANN operation everything else depends on.
• 48,472 embedded chunks across ~40,000 documents, bge-m3 at 1024 dimensions through local Ollama. No embedding provider, no per-token bill, and no third party sees the corpus.
• Gated material is excluded in SQL, not after the fact. Filter afterwards and private chunks still consume slots inside the top-k, silently displacing the public results that should have been returned — nothing leaks, but the answer quietly degrades and nothing logs it.
• Numbers and meanings live in separate databases on one cluster: an append-heavy relational store for prices and time series, pgvectorscale for what those numbers mean. A price wants exactness; a chain wants proximity.

https://deltaverse.pythai.net/chainmarketcap.html

2,510 chains reconciled across CoinGecko, CoinMarketCap, chainid.network and the RPC endpoints themselves, with each source allowed to disagree in the open rather than being averaged into one confident number. Its own documentation is embedded back into the pgvectorscale store, so the board is both a retrieval surface and part of the corpus.

https://github.com/GATERAGE/ragebar · live in the header of rage.pythai.net.

Zero-dependency live search where the meter is a readout of retrieval itself: typing speed while you are still asking, result count when the corpus answers, red when it returns nothing. Retrieval first, generation second — which is what the R and the G are for.

RAGE has evolved beyond hackathon-era third-party dependencies into a participant-first architecture where memory is:

• Local-first: a participant cache (desktop/VPS/edge) is the primary workbench.
• Index-backed: the cache contains a hybrid index (semantic + lexical).
• Verifiable: items can be promoted to IPFS and attested by wallet signatures.
• Composable: memory can be shared, bundled, validated, and optionally anchored/minted.

RAGE is not “retrieve then answer.” RAGE is a feedback loop:

1. Ingest (spider, uploads, APIs, agent outputs)
2. Index (vectors + BM25/lexical + metadata)
3. Retrieve (hybrid + policy + trust-aware)
4. Generate (grounded synthesis)
5. Log (append interaction + outcome)
6. Learn (trust updates, dedupe, curation, validation)
7. Promote (web2/web3 permanence choices)

The “dynamic” in dynamic RAG is that the memory base improves with use.

RAGE is engineered around local, composable ML infrastructure:

• PostgreSQL provides the foundational datastore for structured metadata, event logs, and transactional consistency.
  → https://www.postgresql.org/
• pgvector + pgvectorscale enable scalable vector retrieval (including DiskANN-style indexing) inside Postgres—supporting high-performance semantic search without a separate vector service.
  → https://github.com/timescale/pgvectorscale

• Single source of truth: text + vectors + receipts + policies in one place.
• Fewer moving parts: avoids external search sync complexity.
• Operational simplicity: easy to run locally (Docker) and scale to VPS.
• ML innovation surface: database-native retrieval becomes a programmable substrate for agents.

Note (client-side): pgvectorscale is a Postgres extension typically run locally on desktop/VPS/edge.
For ultra-light clients (e.g., browser-only), RAGE can use an equivalent local store (SQLite/DuckDB/LanceDB/etc.) as a cache and later promote results to Postgres/IPFS.

RAGE keeps fast work local, then upgrades only what matters.

Spider / Inputs
  (web, files, APIs, agent outputs)
        │
        ▼
Participant Cache (Logs = Memory)
  - append-only events
  - local embeddings
  - local hybrid index
        │
        ├──────────────► Web2 Durable Storage
        │                 (cheap, fast, versioned)
        │
        └──────────────► Web3 Permanence
                          - IPFS (CID integrity)
                          - Wallet signatures (receipts)
                          - Optional anchor/mint (SubMinter)

Participants decide when an item graduates from cache:

• Keep local (private, rapid iteration)
• Persist Web2 (durable workspace / knowledge base)
• Persist Web3 (IPFS + signature, optionally anchored/minted)

GATE is the automation layer that turns RAGE into an operational system:

• scheduled spider/ingestion jobs (allowlists, frontier control)
• extraction, normalization, and chunking pipelines
• embedding + enrichment workflows
• local indexing + cache management
• receipt generation (signatures, nonces, replay protection)
• promotion workflows (Web2 / IPFS / optional anchors/mints)
• validation workflows (quorum + reputation weighting)

RAGE indexes Capsules. Capsules are produced by ingest + chunking + summarization and are tied to Receipts (attestations) and Manifests (promotion bundles).

• Capsule: atomic unit of retrievable knowledge (chunk/doc/summary/tool output).
• Receipt: proof-of-interaction; wallet signature over a canonical payload describing an action on a capsule/CID.
• Manifest: deterministic bundle of capsules promoted together (for IPFS packaging + SubMinter anchoring/mint gating).
• Namespace: permission and scope boundary (global/org/project/user/agent).

RAGE treats memory as tiers so retrieval can be trusted by default.

Default retrieval policy: prefer L3+ unless the user explicitly enables workbench mode.

This is a reference layout optimized for “logs are memory” + hybrid retrieval. Adjust types and constraints as needed.

CREATE TABLE rage_documents (
  doc_id            UUID PRIMARY KEY,
  canonical_url     TEXT,
  title             TEXT,
  raw_text          TEXT,
  metadata          JSONB DEFAULT '{}'::jsonb,
  content_hash      TEXT,
  ipfs_cid          TEXT,
  created_at        TIMESTAMPTZ DEFAULT now(),
  updated_at        TIMESTAMPTZ
);

-- Requires pgvector for the vector type. Dimension depends on your embedder.
CREATE TABLE rage_capsules (
  capsule_id        UUID,
  version           INT NOT NULL,
  namespace_scope   TEXT NOT NULL,   -- global|org|project|user|agent
  namespace_id      TEXT NOT NULL,
  doc_id            UUID REFERENCES rage_documents(doc_id),
  chunk_no          INT,
  content           TEXT NOT NULL,
  embedding         VECTOR(1024),    -- bge-m3, the dimension RAGE runs in production
                                     -- (set to your embedder; 1536 for OpenAI-family)
  metadata          JSONB DEFAULT '{}'::jsonb,

  -- integrity / provenance
  integrity_level   INT NOT NULL DEFAULT 0,
  content_hash      TEXT,
  ipfs_cid          TEXT,

  -- trust signals
  trust             DOUBLE PRECISION DEFAULT 0.0,
  quality           DOUBLE PRECISION DEFAULT 0.0,
  usage_count       BIGINT DEFAULT 0,
  downvotes         BIGINT DEFAULT 0,

  created_at        TIMESTAMPTZ DEFAULT now(),
  updated_at        TIMESTAMPTZ,

  PRIMARY KEY (capsule_id, version)
);

CREATE TABLE rage_events (
  event_id          UUID PRIMARY KEY,
  ts                TIMESTAMPTZ DEFAULT now(),
  actor_wallet      TEXT,
  actor_session     TEXT,
  action            TEXT NOT NULL,   -- create|update|tag|validate|promote|bundle|query
  capsule_id        UUID,
  capsule_version   INT,
  ipfs_cid          TEXT,
  payload           JSONB NOT NULL
);

CREATE TABLE rage_receipts (
  receipt_id        UUID PRIMARY KEY,
  ts                TIMESTAMPTZ DEFAULT now(),
  wallet            TEXT NOT NULL,
  chain             TEXT,
  action            TEXT NOT NULL,
  capsule_id        UUID,
  capsule_version   INT,
  ipfs_cid          TEXT,
  nonce             TEXT NOT NULL,
  origin            TEXT NOT NULL,
  payload_canonical TEXT NOT NULL,   -- canonical JSON or canonical string
  payload_hash      TEXT NOT NULL,   -- sha256:...
  signature         TEXT NOT NULL
);

• Vector ANN: pgvectorscale / diskann index on embedding
• Lexical: BM25-style index (via pg_textsearch) or Postgres full-text as fallback
• Metadata filters: btree/GiST indexes on namespace, integrity level, timestamps

Index syntax varies by extension version and configuration. Keep schema stable; adjust index DDL to your environment.

RAGE retrieval uses two candidate sources:

1. Semantic candidates (vector similarity)
2. Lexical candidates (keywords / BM25)

Then it fuses and reranks based on trust, freshness, and context fit.

• topK vectors by cosine similarity
• topK lexical by BM25 score
• merge with a fusion strategy

RRF is stable across scoring systems and easy to tune:

RRF(d) = Σ 1 / (k + rank_i(d))

Final score can include:

• semantic match
• lexical match
• integrity tier (L3+ boost)
• validator quorum
• freshness decay
• namespace alignment
• user feedback (downvotes / usage)

• CID is the immutable identifier for a content snapshot.
• If content changes, CID changes → version increments.

A Receipt binds actor ↔ action ↔ content:

• capsule_id, version
• ipfs_cid (or content_hash pre-IPFS)
• action
• namespace
• origin
• nonce and exp (replay protection)
• timestamp

{
  "v": 1,
  "domain": { "app": "RAGE", "origin": "rage.pythai.net", "env": "prod" },
  "action": "create",
  "subject": { "capsule_id": "cap_123", "version": 1, "cid": "bafy..." },
  "content_hash": "sha256:...",
  "namespace": { "scope": "org", "id": "org_78map" },
  "nonce": "9f2d...c1",
  "ts": "2026-02-14T00:00:00Z",
  "exp": "2026-02-14T00:10:00Z"
}

Best practice: canonicalize JSON (sorted keys, UTF‑8), hash it, sign the hash.

Promotion is the mechanism that upgrades cache artifacts into permanence.

A deterministic bundle of capsules:

• list of (capsule_id, version, cid)
• bundle root (Merkle root or canonical hash)
• policy constraints (integrity minimum, validator quorum)
• references to receipts and validator signatures

{
  "v": 1,
  "manifest_id": "man_001",
  "origin": "minter.pythai.net",
  "bundle": {
    "items": [
      { "capsule_id": "cap_123", "version": 2, "cid": "bafy..." }
    ],
    "bundle_root": "sha256:..."
  },
  "policy": { "min_integrity_level": 3, "requires_quorum": false },
  "receipts": ["rcpt_a", "rcpt_b"],
  "nonce": "c7a1...",
  "ts": "2026-02-14T00:00:00Z"
}

1. Prepare: RAGE verifies CIDs and emits an unsigned manifest
2. Sign: participant signs manifest hash via wallet
3. Finalize: SubMinter verifies signature + policy, stores manifest (and optionally anchors/mints)

RAGE “ingests like a spider” using a controlled frontier:

• domain allowlists / blocklists
• depth limits, rate limits
• canonical URL normalization
• ETag/Last-Modified tracking
• duplicate detection (hash-based)

• HTML extraction with boilerplate removal
• chunk by structure (H1/H2 sections)
• chunk size targets (token-based)
• versioning on changes

Every ingest generates:

• rage_documents raw snapshot
• derived capsules/chunks
• an event log entry
• optional IPFS pin + signature receipt

RAGE supports a local node that can be:

• Desktop/VPS/Edge: Postgres + pgvectorscale (preferred)
• Lightweight: equivalent local store for offline-first caching
• Browser-adjacent: cache + receipts, with server-side permanence via promotion

• store recent retrievals (“capsules”)
• store logs/events for replay and learning
• store pending promotions
• maintain local integrity tiers

• push promoted manifests
• share validated capsule packs
• fetch curated packs

These endpoints are sufficient to wire RAGE into agent UIs and SubMinter.

• POST /ingest
  input: url/file/text + namespace
  output: doc_id + capsule_ids + embedding job refs

• POST /query
  input: query + namespace + integrity policy
  output: top capsules + proof metadata (CID/signatures) + context bundle

• POST /attest
  input: payload + signature
  output: receipt_id + integrity update

• POST /validate
  input: capsule_id/version + verdict + validator signature
  output: updated integrity/trust

• POST /promote/prepare → manifest (unsigned)
• POST /promote/finalize → permanence_ref (and optional tx/mint refs)

• nonce required
• expiry window recommended (e.g., 10 minutes)
• origin pinning (rage.pythai.net / minter.pythai.net)

• retrieval defaults to L3+
• high-stakes contexts can require L4+
• downvote/abuse handling
• content safety filters on ingest

Track:

• ingest rate, crawl failures
• embedding queue depth
• query latency (vector, lexical, hybrid)
• index size/bloat
• proof verification failures
• promotion conversion rate (cache → permanence)

RAGE began as a hackathon build for LabLab’s Advanced RAG Hackathon, submitted under the MASTERMIND entry.
It has since evolved into a production direction focused on:

• local-first participant compute
• verifiable memory (CID + signatures)
• scalable hybrid retrieval (semantic + lexical)
• optional Web3 permanence (not Web3-for-everything)

gaterage is the ragegate — the way in. Of 73 repositories here, 13 are original and 17 more are forked within our own orgs (pythaiml, augml, DeltaVML, UIUXt), so GitHub's fork badge undercounts the work by more than half. The remaining 43 are external forks: study material, kept honestly as what they are. The vectara repositories are reference only and have not been in use since the hackathon.

• Professor Codephreak: https://github.com/Professor-Codephreak — the clearest map of how this came to be
• mindX: https://github.com/AgenticPlace/mindX · live at https://mindx.pythai.net
• MASTERMIND: https://github.com/mastermindML
• webmindml: https://github.com/webmindml
• openmind: https://github.com/openmindx
• PYTHAI org: https://github.com/pythaiml

The narrative is told properly in the articles on rage.pythai.net.

• Client-side cache node templates (desktop / VPS / edge device)
• Standardized receipts + manifests (CID + signatures)
• Promotion UI (Web2/Web3 permanence choice)
• Validator quorum + reputation weighting
• SubMinter integration for identity + permanence pipelines
• Dataset “capsule packs” for reusable agent memory modules

sales@pythai.net

Licensing varies by repository and component. See each repo’s LICENSE file for details.