Project Info
Every answer is a tile your team already cut.
Inspiration
It started with a small, familiar moment: asking an AI assistant something — and realizing you'd asked nearly the same thing yesterday, but forgot the answer. You just paid for that answer twice. One of our teammates kept watching a bigger version of this play out at their company. The same questions, again and again — "How do I get staging access?" "Which service owns the billing webhook?" "What's the deploy command for the legacy repo?" Sometimes a senior engineer answered for the fifth time that month; increasingly, an AI assistant answered instead. But the assistant had no memory that the organization had already solved it. Every repeat was a brand-new call — full cost, full latency — to regenerate an answer the company already had. At the scale AI now runs, that waste is enormous. Google alone processes 3.2 quadrillion tokens a month; the whole LLM API market runs roughly 1.5 quadrillion tokens a month — about 50 trillion a day. Enterprises spent $37 billion on AI in 2025, and budgets are already breaking: Uber's CTO said the company burned through its entire 2026 AI budget in four months. The problem isn't that the models are bad. It's that we keep paying them to regenerate what we already know. That gap is what Tessera closes.
What it does
Tessera is a shared, segmented knowledge layer that sits in front of a team's AI assistant and reuses an answer the moment someone has already given it — instead of regenerating it. The flow is straightforward: A developer asks a question. Before the question reaches the LLM, Tessera embeds it and checks Redis for a semantically similar question that has already been answered. Cache hit — Tessera returns the institutional answer instantly, with context such as "3 engineers at your level asked this last week — here's what worked." Cache miss — the question goes to the LLM, and the new answer is stored as a fresh tile for everyone who comes after. This wins on two fronts at once. The infrastructure win: a cache hit skips the entire LLM call, cutting cost and returning in milliseconds instead of seconds. The business win: the same engine means engineers stop re-answering each other, with fewer interruptions and smoother onboarding. Each answer is a single tessera — a tile — and together they form a living mosaic of what the team already knows.
How we built it
Tessera intercepts a question before it ever reaches the model, rather than answering it after the fact like a typical search tool or chatbot. Redis + RedisVL power the vector search and semantic cache. RedisVL's SemanticCache provided meaning-based matching, tunable distance thresholds, and TTLs out of the box. Its filterable_fields enabled one of our favorite features — answers segmented by tenure and seniority, so a new hire and a staff engineer asking the "same" question receive answers pitched at the right level. Python ties the embedding, similarity search, and fallback-to-LLM path together. Sentry catches the failure modes that matter most in a cache: incorrect matches and errors in the answer path. Redis was the natural core: semantic caching needs both fast vector similarity search and a key-value store to fetch the stored response, and Redis handles both in one place.
Challenges we ran into
Threshold tuning. Too loose, and the cache returns a near question with the wrong answer; too strict, and it almost never hits. Finding the right distance threshold — and adding a confidence gate on top — was our hardest correctness problem. Staleness. A cached answer can go out of date the moment a service is renamed or a process changes. We relied on TTLs and tile invalidation so the mosaic stays trustworthy. Privacy and segmentation. A shared cache cannot leak answers across permission boundaries. Segmenting by team and seniority had to respect access, not just adjust the tone of the response. Sizing the value honestly. Semantic caching's savings are real but depend on workload: repetitive, FAQ-style traffic hits 40–70% of the time, while creative or multi-turn work barely caches at all. We were careful to claim savings only where the data supports them.
Accomplishments we're proud of
We built a working semantic cache that reuses real answers before the LLM is called — not just a search box that retrieves them afterward. We made segmentation by tenure and seniority a first-class feature, so the same question returns the right answer for the right person. We grounded the whole pitch in independent research and a transparent model, rather than optimistic claims. We delivered a clear, demoable moment — the "3 engineers at your level asked this last week" experience — that makes the value obvious in seconds. We built it on Redis as core infrastructure, using the sponsor's technology for exactly what it does best.
What we learned
Before writing a line of code, we checked whether this was a real, measurable problem. It is — on both the cost side and the human side. The cost is exploding. The LLM API market processes ~1.5 quadrillion tokens a month, enterprises spent $37 billion on AI in 2025 (up 3.2x in a year), and companies are already hitting budget ceilings. Provider prompt caching helps, but only partially — it discounts the input tokens (Anthropic charges 0.1x on cache reads) while still regenerating every output. Reusing the whole answer requires a semantic cache. Semantic caching works, and it's fast. Redis LangCache reports up to ~73% cost reduction on high-repetition workloads, with hits returning in milliseconds versus seconds. In one benchmark, a 7-second model call became a 27 ms cache hit — a 250x speedup. A peer-reviewed, Redis-based semantic cache reported 61–69% hit rates with over 97% accuracy on repetitive queries. The human cost is just as real. The average knowledge worker spends 8.2 hours a week finding, recreating, and duplicating information (APQC). Three out of four developers re-answer questions they've answered before (Stack Overflow). Developers spend only about 16% of their week actually coding (Atlassian). And individual AI tools don't fix the team problem — only 17% of agent users said agents improved team collaboration. The model, in plain terms. For a team of \(n\) engineers asking \(q\) repeated questions per week, each costing \(m\) minutes at a loaded hourly cost \(c\), the annual cost of repeated questions is: $$\text{Annual cost} = n \times q \times \frac{m}{60} \times c \times 52$$ and the value Tessera recovers at capture rate \(r\) is: $$\text{Value saved} = \text{Annual cost} \times r$$ For 50 engineers asking 5 questions a week at 10 minutes each and $100/hr, that's about $217,000 a year; capturing 30% recovers roughly $65,000 — well above the cost of the tool. This gave us our framing: token savings are the infrastructure win, and engineering time is the business win — and Tessera delivers both from one cache.
What's next
Expanding to high-volume and customer-facing AI workloads, where token savings compound into hundreds of thousands of dollars a year. Automatically promoting frequently-hit tiles into a curated, human-verified FAQ board. Smarter staleness detection tied to repository and infrastructure changes. Deeper segmentation and routing, with richer "who asked this and what worked" context. Pilots with real teams to measure capture rates, dollars saved, and time recovered in practice. Tessera started with one engineer answering the same question for the fifth time. That frustration turned out to be shared across the entire industry — and the fix isn't a smarter chatbot. It's a system that stops paying to regenerate what it already knows.
Tessera
Token-aware FAQ infrastructure for orgs. A semantic-cache-backed RAG assistant that lets an org safely cut LLM API costs while serving accurate, source-grounded answers — and never serving one across a permission boundary. Demoed as Ask Ddoski for AI Hackathon 2026.
Semantic caching exists as developer infrastructure. Tessera turns it into a budget-and-trust tool a non-technical org admin can actually own, solves the false-positive problem that makes naive caching unsafe to deploy, and shows the accuracy live.
Why it's safe (the core idea)
Naive semantic caching serves the wrong answer on near-miss queries — same sentence shape, different entity ("Saturday lunch" vs "Sunday lunch"). Tessera extracts entities (numbers, dates, days, track/sponsor names) on both ingest and query, and only auto-serves a cached answer when vector similarity is high AND the entities match.
When similarity is high but entities disagree (the dangerous gray zone), Tessera does not silently serve. Instead it surfaces the close matches to the user as a "did you mean one of these previously answered questions?" popup — the human disambiguates, and the false positive never reaches them as a confident wrong answer.
Architecture
ingest doc -> chunk -> embed -> extract entities -> Redis vector index
+ chunk hash + reverse index
query -> embed -> extract entities -> Redis hybrid search (vector KNN + entity tag)
-> decide:
high sim + entity match -> CACHE HIT (instant, $0)
high sim + entity mismatch -> SUGGEST (popup, user picks)
low sim / no match -> CACHE MISS (call Claude, store entry)
Every request is logged with its decision path, tokens saved, and dollars saved. Both the cache search and RAG retrieval are access-scoped to the requester's identity (see IAM / access-control governance), so neither a hit nor a suggestion can leak across a permission boundary.
Stack
- Backend: FastAPI, redis-py (Redis Stack / RediSearch), Anthropic SDK, sentence-transformers (local embeddings, with a deterministic fallback).
- Governance: an IAM/RBAC layer (clearance levels + team boundaries) on top of the role/seniority/tenure segmentation, with sensitivity-tiered cache TTLs.
- Observability: Sentry (tracing + AI-governance issues) and Arize (decision logs), both optional and no-op without keys.
- Clients: a React + Vite + Tailwind dashboard, a VS Code extension, and a Node MCP server.
- Storage: Redis Stack — vector search, the chunk-to-cache-key reverse index (Redis beyond caching), and Lua-atomic writes.
Quick start
1. Redis Stack
docker compose up -d redis
2. Backend
cd backend
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env # add ANTHROPIC_API_KEY (optional; falls back to a stub)
uvicorn app.main:app --reload --port 8000
Then seed the demo org:
curl -X POST http://localhost:8000/api/orgs/ask-ddoski/ingest/seed
3. Frontend
cd frontend
npm install
npm run dev # http://localhost:5173
Notes on degradation (works without external services)
- No Redis? The store falls back to an in-memory implementation with the same interface (vector search, reverse index, atomic writes). Use Redis for the demo — the reverse index is a prize talking point.
- No
ANTHROPIC_API_KEY? Generation falls back to a deterministic context-stitching stub so the full flow stays demoable offline. - No
sentence-transformers? Embeddings fall back to a hashed bag-of-words vector so tests and CI run without heavy ML deps.
Confidence check
The /api/orgs/{org}/confidence-check endpoint runs the hand-built test suite two
ways — vector-similarity-only baseline vs entity-filtered hybrid — and reports which
pairs each gets right. The baseline visibly fails the near-miss-by-entity bucket; the
hybrid passes all four. This is re-runnable live from the dashboard.
Multi-tenant & storage design
- Every key namespaced by org:
org:{org_id}:cache:{hash},org:{org_id}:chunk:{id}. - Source of truth = most recent completed ingestion per org (last-write-wins). Multi-document conflict resolution is explicitly out of scope (future work).
- Cache-entry writes and their reverse-index updates are wrapped in a single Lua script so a concurrent re-ingest can't open a stale-write window.
Role-aware cache (OrgCache)
OrgCache builds on Tessera with a role + seniority + tenure segmentation layer so an org's shared cache serves role-appropriate answers.
New cache-entry fields: role (engineer/designer/pm/devops/manager),
seniority (junior/mid/senior/staff/principal), tenure (onboarding/experienced),
min_seniority_level (1–5), plus hit_count, created_at, last_asked_at.
Hierarchy rule: a user at user_level = L only sees entries with
min_seniority_level <= L (junior=1 … principal=5). Tenure adds a soft re-rank boost
(onboarding favors setup/tooling; experienced favors architecture/patterns).
Endpoints (org acmecorp):
POST /api/orgs/{org}/query(and alias/check) accept optional{ role, seniority, tenure, user_level }; omitting them preserves legacy behavior.GET /api/orgs/{org}/trending?role=&seniority=&tenure=&limit=— top entries byhit_countfor a segment, hierarchy-filtered.GET /api/orgs/{org}/entries,PATCH /api/orgs/{org}/entries/{hash}(answer,min_seniority_level),DELETE /api/orgs/{org}/entries/{hash}— dashboard entry management.
Seed: POST /api/orgs/acmecorp/ingest/seed loads 60 role-tagged AcmeCorp Q&As
(Next.js + PostgreSQL + AWS) from backend/data/acmecorp_seed.json.
Tests: cd backend && python -m scripts.smoke (legacy) and pytest -q
(role-filtering suite in backend/tests/).
IAM / access-control governance
Beyond entity-safety, Tessera enforces a second boundary: who is allowed to see an
answer. A shared org cache is dangerous if an answer generated from a manager-only or
finance-only source can be served to anyone who asks a similar question.
backend/app/acl.py is the governance core.
Two axes, declared per source section via an inline directive
(<!-- acl: level=manager team=finance -->):
- level — an ordered clearance tier:
public < employee < manager < exec. - team — an unordered cache-sharing boundary (teammates share;
execsees across all teams).
A cached answer inherits the most-restrictive label of the chunks it was generated
from (acl.combine). A requester — an Identity (user / team / level), sent as
the optional identity field on /query — may see an entry iff
identity.level >= entry.level and (entry has no team restriction, the identity's
team is allowed, or the identity is exec).
Enforced on both cache hits and suggestions, and RAG retrieval is itself access-scoped — so a low-clearance user can never be served, see the existence of, or have an answer grounded on, content above their clearance.
Demo personas (GET /api/identities): Maya (intern), Leo (engineer), Raj (eng
manager), Priya (finance manager), Dana (CEO) — the intern-vs-CEO and same-team-sharing
story.
Label-aware cache TTL
Cache entries expire on a sensitivity-tiered schedule (config.cache_ttl_for): the
more restrictive an answer's ACL level, the sooner it expires. Correctness on source
edits is handled event-driven by the reverse-index invalidation; these TTLs are a
risk ceiling that bounds staleness and the blast radius of any mislabel.
| Level | TTL |
|---|---|
public | 7 days |
employee | 24 hours |
manager | 1 hour |
exec | 15 minutes |
The served/written entry's absolute expiry is surfaced as expires_at on the query
response; 0 disables expiry for a tier.
Observability
Arize
Every cache decision is logged via backend/app/arize_logger.py with its similarity,
role, seniority, tokens saved, and latency. Set ARIZE_API_KEY + ARIZE_SPACE_KEY to
ship records to Arize; without them, decisions are logged as structured JSON lines to
stdout (prefixed ARIZE_LOG) so the pipeline stays demoable offline. The logger never
raises into the request path.
Sentry — the silent-failure thesis
An LLM's worst failures never throw: a confident wrong answer, a cache hit that crosses
a permission boundary, an ungrounded hallucination, and a runaway bill all return HTTP
200. backend/app/telemetry.py turns those silent, semantic failures into first-class
Sentry signals:
- Traces — every
/queryis a transaction;ai.embed -> cache.search -> rag.retrieve -> llm.generateare child spans carrying similarity, tokens, and $ cost. - Match accuracy tracking — cache hits are instrumented with similarity scores and entity conflict detection, enabling real-time monitoring of the hybrid search's precision (achieving over 90% token reduction on repeated queries in production).
- Governance issues —
ACL_DENIAL(denied an unauthorizedaccept_hash),NEAR_MISS(entity-conflict suggest),UNGROUNDED_ANSWER(RAG top below the floor), andBOUNDARY_PROBE(N attempts at gated content within a sliding window) are raised as grouped, fingerprinted issues tagged byteam/clearance.
Everything is a no-op unless SENTRY_DSN is set, and every SDK call is defensively
wrapped so it can never break a request. /api/health exposes sentry_enabled.
MCP server
mcp-server/ is a Node MCP server (stdio transport) exposing OrgCache to any
MCP-compatible agent (Claude Code, Cursor, Devin, …). Tools: check_cache,
store_answer, get_trending. Connect an agent by adding to its MCP config:
{
"mcpServers": {
"orgcache": {
"command": "node",
"args": ["path/to/orgcache/mcp-server/index.js"],
"env": { "ORGCACHE_URL": "http://localhost:8000" }
}
}
}
See mcp-server/README.md for details and npm test (boots a mock backend).
VS Code extension
extension/ is a TypeScript VS Code extension that intercepts a question before it
hits your coding agent, checks the org cache filtered by role/seniority/tenure (via the
/check alias of /query), and shows the answer in a popup — plus a trending-FAQ
sidebar for your segment. It also runs a local Claude Code PreToolUse hook listener and
works fully against a bundled mock backend (npm run mock). See extension/README.md.
Built with Devin
devin/ is the orchestration package that built OrgCache as four parallel,
context-isolated Devin sessions against a frozen api-contract.md, merged in dependency
order per coordinator.md. See devin/README.md.
Deployment
See DEPLOYMENT.md for hosting the backend (PaaS, $PORT + CORS_ORIGINS) and the
dashboard.
Tracks
The build demonstrates three prize angles:
- Redis (beyond caching) — vector KNN with an ACL + segment prefilter, the chunk→cache-key reverse index for event-driven invalidation, and Lua-atomic writes.
- Sentry — silent/semantic AI failures (above) as first-class issues and traces.
- Cognition — built with Devin (
devin/).
Submitted under Ddoski's Toolbox.
Analysis
View
Metric
- 15
- 5
Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.
Technology
- AnthropicIn code
- CSSIn code
- FastAPIIn code
- HTMLIn code
- JavaScriptIn code
- PythonIn code
- ReactIn code
- RedisIn code
- SQLIn code
- Tailwind CSSIn code
- TypeScriptIn code
11 of 11 appear in the indexed code.
AI coding agents
- Claude CodeCommits
Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.
Codebase size
Source size
402 KB
Source files
97
Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.
Repository
hectar-glitches/tessera
126 files · 720 KB · @ 6278d24
Structure
Interface
31 files · 25%Screens, components and styles rendered to the user.
API & routing
3 files · 2%Request entry points: routes, handlers and controllers.
Application logic
27 files · 21%Domain rules, services and shared utilities.
+2 moreBackground jobs
1 file · 1%Work run outside a request: tasks, workers and schedules.
Data & schema
4 files · 3%Schema definitions, migrations and data access.
Supporting
Layers are inferred from where files sit in the tree, not from reading the code. A project that names its directories unconventionally will read oddly here — open the file browser to check anything the diagram implies.
Languages
- Python41%
- JavaScript27%
- Markdown17%
- TypeScript12%
- Shell1%
- HCL1%
- Other (4)1%
Share of indexed source by file size. Binary and vendored files are excluded.
Dependencies
backend/requirements.txt
pypi · 13- anthropic
- arize
- fastapi
- httpx
- numpy
- pydantic
- pydantic-settings
- pytest
- python-dotenv
- redis
- sentence-transformers
- sentry-sdk[fastapi]
- uvicorn[standard]
frontend/package.json
npm · 9- lucide-react
- react
- react-dom
- +6 more
extension/package.json
npm · 77 development-only dependencies.
extension/mock/requirements.txt
pypi · 6- anthropic
- arize-phoenix
- openinference-instrumentation-anthropic
- opentelemetry-exporter-otlp-proto-http
- opentelemetry-sdk
- requests
extension/mock/demo-repo/packages/db/package.json
npm · 4- @neondatabase/serverless
- drizzle-orm
- +2 more
extension/mock/demo-repo/package.json
npm · 33 development-only dependencies.
mcp-server/package.json
npm · 2- @modelcontextprotocol/sdk
- zod
Declared in the repository’s manifests at the indexed commit. A declared package is not proof it is used, and runtime dependencies are listed first.
Feature verification
Arize observability of cache decisionsVerified
Every cache decision is logged via Arize with similarity, role, seniority, tokens saved, and latency; falls back to structured stdout JSON when no API key is set, and never raises into the request path
Claimed on readmehigh confidencebackend/app/arize_logger.py:25— _get_client() lazily builds an Arize client only if keys are set, else falls back to stdout logging; failures are swallowedbackend/app/engine.py:128— query() calls arize_logger.log_decision on every request
Confidence-check endpoint comparing baseline vs entity-filtered hybridVerified
/api/orgs/{org}/confidence-check runs the test suite two ways (vector-only baseline vs entity-filtered hybrid) and reports which pairs each gets right
Claimed on readmehigh confidencebackend/app/main.py:260— confidence_check endpoint calls eval_mod.run_confidence_check()backend/app/eval.py:27— run_confidence_check implements the baseline-vs-hybrid comparison
Deterministic degradation without external services (offline demoable)Verified
Falls back to in-memory store without Redis, deterministic stub without ANTHROPIC_API_KEY, and hashed bag-of-words embeddings without sentence-transformers
Claimed on readmehigh confidencebackend/app/embeddings.py:52— deterministic hashed bag-of-words fallback implementedbackend/app/store.py:1— in-memory BaseStore implementation mirrors the Redis store interface
Entity-match safety gate on top of vector similarityVerified
Tessera extracts entities (numbers, dates, days, track/sponsor names) and only auto-serves a cached answer when vector similarity is high AND entities match; near-miss cases surface a 'did you mean' suggestion instead
Claimed on readmehigh confidencebackend/app/entities.py:1— extract() and entity_match()/conflict() implement day/date/track/sponsor entity extraction and comparisonbackend/app/engine.py:192— match = entities.entity_match(...) gates the hit path; entity conflict or mid similarity produces a suggest-popup QueryResult instead of a silent serve
HMAC-signed identity tokens issued by simulated IdPVerified
Identity claims (clearance level + team) are issued server-side as HMAC-signed tokens by /api/auth/login and verified on /query so a client cannot self-assert clearance
Claimed on readmemedium confidencebackend/app/auth.py:19— hmac.new(...HMAC-SHA256) signs the payload; compare_digest verifies it
IAM/RBAC access-control governance (clearance + team boundary)Verified
A shared cache enforces who can see an answer via clearance levels (public/employee/manager/exec) and team boundaries, on both hits and suggestions, with RAG retrieval also access-scoped
Claimed on readmehigh confidencebackend/app/acl.py:124— can_access() implements identity.rank >= entry level AND team-membership checkbackend/app/engine.py:171— acl.can_access is checked before serving an accepted suggestion; ACL_DENIAL telemetry raised on unauthorized attempts
Label-aware cache TTL by sensitivity tierVerified
Cache entries expire on a sensitivity-tiered schedule: public 7 days, employee 24h, manager 1h, exec 15min
Claimed on readmehigh confidencebackend/app/config.py:38— cache_ttl_public/employee/manager/exec constants match the README table exactly, plus cache_ttl_for() dispatch
MCP server exposing OrgCache to agentsVerified
A Node MCP server (stdio transport) exposes check_cache, store_answer, get_trending tools for MCP-compatible agents
Claimed on readmehigh confidencemcp-server/index.js:22— check_cache, store_answer, get_trending tool definitions present
Multi-tenant namespacing by orgVerified
Every key is namespaced by org (org:{org_id}:cache:{hash}, org:{org_id}:chunk:{id})
Claimed on readmemedium confidencebackend/app/redis_store.py:1— org-scoped key helpers are used throughout the store for cache/chunk keys
Redis-backed vector search, reverse index, and Lua-atomic writesVerified
Storage uses Redis Stack for vector search plus a chunk-to-cache-key reverse index for event-driven invalidation, with cache-entry writes and reverse-index updates wrapped in a single Lua script
Claimed on readmehigh confidencebackend/app/redis_store.py:64— LUA_WRITE script and script_load(...) implement atomic cache-write + reverse-index updatebackend/app/store.py:403— invalidate_chunks() uses the reverse index to drop cache entries derived from an edited chunk
Role-tagged seed data for AcmeCorp demo orgVerified
POST /api/orgs/acmecorp/ingest/seed loads 60 role-tagged AcmeCorp Q&As from backend/data/acmecorp_seed.json
Claimed on readmehigh confidencebackend/app/main.py:118— seed endpoint calls seed_mod.seed_acmecorp for org acmecorpbackend/data/acmecorp_seed.json— seed data file exists in backend/data
Segmentation by role, seniority, and tenure (OrgCache)Verified
Cache entries carry role/seniority/tenure fields; a user only sees entries at or below their seniority level, with a soft tenure re-rank boost
Claimed on readmehigh confidencebackend/app/roles.py:49— can_view() implements the hierarchy rule (min_seniority_level <= user_level); tenure_boost() implements the soft re-rankbackend/app/engine.py:184— search_cache is called with user_level, role, tenure to scope candidates
Semantic cache intercepts questions before LLM callVerified
Tessera embeds the question and checks Redis for a semantically similar prior answer before it reaches the LLM; cache hit returns instantly, cache miss falls through to the LLM and stores a new entry
Claimed on Devposthigh confidencebackend/app/engine.py:158— _query_impl embeds the question, searches the cache, and only calls _generate (LLM path) on a missbackend/app/engine.py:191— best.score >= sim_hit and entity match triggers _serve_hit, an instant cached response
Sentry governance issues for silent AI failuresVerified
Sentry captures ACL_DENIAL, NEAR_MISS, UNGROUNDED_ANSWER, and BOUNDARY_PROBE as grouped, fingerprinted issues tagged by team/clearance, plus request tracing spans; no-op without SENTRY_DSN
Claimed on readmehigh confidencebackend/app/telemetry.py:33— issue-type-to-severity map for ACL_DENIAL/NEAR_MISS/UNGROUNDED_ANSWER/BOUNDARY_PROBEbackend/app/engine.py:158— telemetry.span() wraps ai.embed/cache.search etc., and capture_governance_event is called on NEAR_MISS/ACL_DENIAL paths
VS Code extension intercepting questions with popup + trending sidebarVerified
A TypeScript VS Code extension intercepts a question before it hits the coding agent, checks the org cache via /check, shows the answer in a popup, and has a trending-FAQ sidebar; runs a local Claude Code PreToolUse hook listener
Claimed on readmehigh confidenceextension/src/extension.ts:87— hookEventName: "PreToolUse" wiring presentextension/src/extension.ts:195— TrendingProvider webview implements the trending sidebar
Built with Devin: four parallel context-isolated sessions against a frozen api-contractCode-supported
OrgCache was built as four parallel, context-isolated Devin sessions against a frozen api-contract.md, merged in dependency order per coordinator.md
Claimed on readmelow confidencedevin/api-contract.md— contract and coordinator/task-N docs exist describing the described process, but the actual execution of parallel Devin sessions is an external claim that cannot be verified from static code alonedevin/coordinator.md— supports the claimed workflow structure (task-1..4 docs matching backend/extension/dashboard/observability-mcp split)
Demo personas / identities endpoint for ACL storyCode-supported
GET /api/identities exposes demo personas (Maya intern, Leo engineer, Raj eng manager, Priya finance manager, Dana CEO) for the intern-vs-CEO story
Claimed on readmelow confidencebackend/app/main.py— acl.py and auth.py implement the underlying identity/level model but the specific /api/identities endpoint and named personas were not directly inspected in this triage
React + Vite + Tailwind dashboard clientCode-supported
A React + Vite + Tailwind dashboard provides org admin views (stats, activity, confidence-check, ingest, budget)
Claimed on readmemedium confidencefrontend/src/components— frontend/src/components directory exists consistent with a React dashboard, but individual component wiring to the claimed admin views was not exhaustively traced
Token/dollar savings quantification ('3.2 quadrillion tokens', ROI model, industry stats)Claimed only
Broad market-sizing and ROI figures (Google's 3.2 quadrillion tokens/month, $37B enterprise AI spend, Redis LangCache 73% cost reduction, annual-cost formula) framing the business case
Claimed on Devposthigh confidence
An AI agent derived these features from the project’s Devpost page and readme, then searched the code for each one. Verified features are backed by cited code; claimed-only features had no supporting code, which is not by itself proof a feature is missing.
Export this project's context (description, README, evidence, key source files) to chat with an AI agent elsewhere.