Meniva
Book a Free Consultation
<- MENIVA.NET
MENIVA / SYSTEMS / DOSSIER3 CASE STUDIES / 3 LABSEVIDENCE BOUNDARIES INCLUDED

Systems
you can
inspect.

Selected AI and data builds with clear boundaries: what the system does, what the demo uses, and which signals have been reproduced.

3
Case studies
3
Labs
100%
Claims classified
Case studies & demos
ENTRY NO. 01Restaurant review intelligenceDemo availableAWS Bedrock / OpenSearch / source-linked answersRAG POC / DEMO AVAILABLE

TasteTrend Analytics

Identity · Client-demo RAG proof of concept

AI RAG over restaurant reviews. Ask a question, inspect the evidence, open the demo.

Problem

Heterogeneous review files need one queryable, source-linked interface without hiding the underlying evidence.

System Flow
5 stages · Review inputs -> Answer · AWS Bedrock / OpenSearch / source-linked answers
->
->
->
->
Click any stage to inspect
Signature Module · Client-demo RAG proof of concept

Inspect the PoC flow

AWS Bedrock / OpenSearch / source-linked answers

Follow review inputs through normalisation, Titan embeddings, OpenSearch retrieval, and a source-linked answer.

TasteTrend · documented PoC flowinspectable
INPUTfour heterogeneous review files
ETLnormalise · validate · record warnings
EMBEDAmazon Titan Embed Text v2configuration
INDEXOpenSearch KNN · review records
AGENTBedrock Agent invokes search action
OUTPUTanswer + supporting review records

Demonstrated Change

Demo scope
Before

Separate review files with inconsistent schemas and manual inspection.

->
Demonstrated build

One inspectable PoC flow from normalisation to source-linked answers.

The PoC demonstrates a complete path from review ingestion to a source-linked answer in a browser demo.

PoC dataset and run; no production SLA or client outcome claimed.

Proof Signals

Classified evidence
1,660
review records indexed
Repository fact
4
review sources normalised
Repository fact
0
indexing failures
Repository fact

Every signal is classified as a repository fact, recorded test, configuration, or disclosed data boundary.

Why This Is Hard

3 engineering challenges
Challenge · 01

Schema normalisation

source files use different column names, scales, and missing-value patterns.

Challenge · 02

Evidence preservation

generated answers must retain a path to supporting review records.

Challenge · 03

Managed-service boundaries

the browser, API, agent, Lambda functions, and index must share a stable contract.

Engineering Depth

3 topics · click to expand

The active PoC uses Titan embeddings, OpenSearch KNN retrieval, a Bedrock Agent, Lambda functions, and API Gateway.

Key numbers
1,024-dimTitan embedding configuration
12questions defined in the evaluation harness
Built withAWS BedrockOpenSearchLambdaAPI GatewayPythonReact
Open demoInspect repository
ENTRY NO. 02Hackathon market-intelligence workflowHackathon demoStructured analysis / Qdrant evidence / workflow traceDECISION SUPPORT / HACKATHON DEMO

PiacRadar

Identity · Hackathon case study

LLM market-intelligence workflow. One question becomes hypotheses, evidence, and an action plan.

Problem

A strategic market question needs to become an auditable decision workflow rather than a one-shot answer.

System Flow
5 stages · Strategic question -> Decision package · Structured analysis / Qdrant evidence / workflow trace
->
->
->
->
Click any stage to inspect
Signature Module · Hackathon case study

Inspect the decision package

Structured analysis / Qdrant evidence / workflow trace

Follow one strategic question through context assembly, evidence retrieval, hypothesis ranking, actions, and validation tasks.

PiacRadar · decision packageinspectable
INPUTone strategic market question
CONTEXTsynthetic company data + public evidence
RETRIEVEQdrant evidence when configured
REASONrank hypotheses + validation tasks
OUTPUTbrief · actions · sources · workflow trace
BOUNDdecision support · not causal proof

Demonstrated Change

Demo scope
Before

A strategic question spread across disconnected signals and ad-hoc analysis.

->
Demonstrated build

A structured demo package with hypotheses, evidence, actions, and validation tasks.

The hackathon build produces a structured decision package with ranked hypotheses, an executive brief, actions, evidence references, and a workflow trace.

Core company and market data is synthetic/generated; public evidence quality varies. Decision support, not causal proof.

Proof Signals

Classified evidence
8
validated demo artifacts
Repository fact
60
companies in source list
Synthetic data
1
decision package per request
Repository fact

Every signal is classified as a repository fact, recorded test, configuration, or disclosed data boundary.

Why This Is Hard

3 engineering challenges
Challenge · 01

Evidence separation

synthetic business context must not be confused with retrieved public evidence.

Challenge · 02

Structured reasoning

hypotheses, actions, and validation tasks need a stable contract.

Challenge · 03

Demo resilience

cached analysis must remain transparent when live integrations are unavailable.

Engineering Depth

3 topics · click to expand

The analysis orchestrator stages refinement, aggregation, retrieval, hypothesis generation, scoring, executive briefing, and trace assembly.

Key numbers
3request modes defined: demo, enriched, live
8cached artifacts required by validator
Built withReactExpressTypeScriptQdrantLangSmith
Open hackathon demoView repository
ENTRY NO. 03Technical learning product demoDemo availableFastAPI / React / curriculum / RAG configurationLEARNING PLATFORM / DEMO AVAILABLE

Nullfal

Identity · Practice and retrieval system

AI learning product with practice tracks, RAG explanations, progress events, and a live demo.

Problem

Technical practice content, progress events, and reference retrieval need one coherent product workflow.

System Flow
4 stages · Curriculum -> Reference retrieval · FastAPI / React / curriculum / RAG configuration
->
->
->
Click any stage to inspect
Signature Module · Practice and retrieval system

Inspect practice and retrieval

FastAPI / React / curriculum / RAG configuration

See how curriculum content, executable practice, progress events, and configured reference retrieval fit together.

Nullfal · practice and retrievalinspectable
CONTENTtracks · quests · microdrills
PRACTICEattempt · feedback · explanation
EVENTSprogress and learning analytics
RAG768-dim · 1,200-char · top-k 8configuration
BOUNDlearning outcomes not yet validated

Demonstrated Change

Demo scope
Before

Curriculum, practice, progress, and reference material handled as separate concerns.

->
Demonstrated build

One demo product with tested APIs, structured practice content, and a configurable retrieval layer.

The demo brings authentication, tracks, quests, microdrills, analytics, and retrieval-backed reference flows into one product surface.

Learning outcomes and psychometric performance have not been validated at cohort scale.

Proof Signals

Classified evidence
1,061
microdrills in test data
Recorded test
5
tested learning tracks
Recorded test
25/25
API tests passed
Recorded test

Every signal is classified as a repository fact, recorded test, configuration, or disclosed data boundary.

Why This Is Hard

3 engineering challenges
Challenge · 01

Content scale

practice banks and curriculum metadata need consistent schemas and administration.

Challenge · 02

Execution safety

coding exercises require clear sandbox boundaries before broader use.

Challenge · 03

Outcome honesty

product activity must not be presented as validated learning impact.

Engineering Depth

3 topics · click to expand

The repository includes authentication, curriculum administration, tracks, quests, microdrills, analytics endpoints, and a React frontend.

Key numbers
768-dimembedding configuration
1,200-charchunk configuration
Built withFastAPIReactMongoDBQdrantPython
Open learning demoInspect repository
Labs & R&D
ENTRY NO. 04Sales Technology / R&DPrototypeTinyFish / TypeScript / SQLite replayAGENT WORKFLOW / PROTOTYPE

Scoutbound

Identity · Agentic prospecting capability demo

Agentic prospecting workflow. Research leads, keep evidence, score fit, export to CRM.

Problem

Browser-agent output needs explicit execution modes, persisted evidence, and a safe handoff boundary.

System Flow
5 stages · Prospecting brief -> Handoff · TinyFish / TypeScript / SQLite replay
->
->
->
->
Click any stage to inspect
Signature Module · Agentic prospecting capability demo

Replay the workflow boundary

TinyFish / TypeScript / SQLite replay

See how execution mode, evidence, uncertainty, score reasons, persistence, and export remain visible.

Scoutbound · explicit execution modeinspectable
MODElive · mock · degraded
BRIEFmarket · company size · keywords · role
AGENTTinyFish discovery and inspection adapters
TRACEevidence · uncertainty · score reasons
OUTPUTpersisted session · JSON / CSV handoff

Demonstrated Change

Demo scope
Before

Disconnected prospect research and copy-paste handoff.

->
Demonstrated build

A replayable prototype with explicit modes, evidence, scoring, and versioned export.

The prototype demonstrates a reviewable path from prospecting brief to evidence-bearing lead export.

Mock mode is the safe default. Live browser-agent performance and extraction quality are not yet benchmarked publicly.

Proof Signals

Classified evidence
3
run modes
Repository fact
2
export formats
Repository fact
1
CRM handoff contract
Repository fact

Every signal is classified as a repository fact, recorded test, configuration, or disclosed data boundary.

Why This Is Hard

3 engineering challenges
Challenge · 01

Mode honesty

live, mock, and degraded runs must stay visibly distinct.

Challenge · 02

Evidence retention

output must preserve sources and uncertainty.

Challenge · 03

Safe external calls

paid traffic and CRM writes require explicit opt-in.

Engineering Depth

3 topics · click to expand

The canonical repository blocks live calls unless explicitly enabled and keeps mock or degraded output labelled.

Key numbers
Built withTinyFishTypeScriptExpressReactZodSQLite
Open capability demoInspect repository
ENTRY NO. 05Revenue Operations / R&DUnder developmentReact / Express / Prisma / rules + ML scaffoldingREVOPS / UNDER DEVELOPMENT

Revon

Identity · Lead triage and decisioning prototype

ML-ready lead scoring workspace for enrichment, routing, review, and RevOps automation.

Problem

A lead workspace needs explainable decisioning and an evidence path from rules to evaluated ML.

System Flow
5 stages · Ingest lead -> ML extension · React / Express / Prisma / rules + ML scaffolding
->
->
->
->
Click any stage to inspect
Signature Module · Lead triage and decisioning prototype

Inspect current decisioning

React / Express / Prisma / rules + ML scaffolding

Follow a tenant-scoped lead through enrichment hooks, rule scoring, review, workers, and the ML extension boundary.

Revon · current prototype boundaryinspectable
INPUTtenant-scoped lead record
ENRICHcompany and person provider hooks
SCOREconfig-driven rules + inspectable reasons
WORKERSenrichment · scoring · reporting · integration
MLtraining and inference scaffolding
BOUNDno trained result artifact claimed

Demonstrated Change

Demo scope
Before

Lead data and decisions spread across disconnected steps.

->
Demonstrated build

One prototype workspace with rule scoring, workers, reporting, and ML extension points.

The prototype demonstrates the application and worker architecture needed to test that path.

No trained model artifact, calibration report, or production outcome is claimed.

Proof Signals

Classified evidence
3
ML training paths
Repository fact
4
worker roles
Repository fact
1
ML feature contract
Repository fact

Every signal is classified as a repository fact, recorded test, configuration, or disclosed data boundary.

Why This Is Hard

3 engineering challenges
Challenge · 01

Tenant boundaries

application data and workers must preserve organization scope.

Challenge · 02

Explainability

current rule signals need inspectable reasons.

Challenge · 03

ML evidence

training code is not a model result until artifacts and reports exist.

Engineering Depth

3 topics · click to expand

The checked-in scoring engine is config-driven and computes explainable industry, size, seniority, engagement, completeness, and source-quality signals.

Key numbers
Built withReactExpressPrismaPostgreSQLTypeScriptPython
View prototypeInspect repository
ENTRY NO. 06Research Intelligence / R&DLocal R&DFAISS / MiniLM / Qwen / FastAPILOCAL RAG / R&D

AI Research Intelligence

Identity · CPU-first research assistant

Local RAG for AI research. Search papers, rerank evidence, synthesize source-backed answers.

Problem

A local research assistant needs reproducible retrieval, reranking, and source-bearing synthesis on commodity hardware.

System Flow
5 stages · Ingest papers -> Synthesise · FAISS / MiniLM / Qwen / FastAPI
->
->
->
->
Click any stage to inspect
Signature Module · CPU-first research assistant

Inspect local retrieval

FAISS / MiniLM / Qwen / FastAPI

Follow arXiv metadata through topic mapping, MiniLM embeddings, exact FAISS retrieval, reranking, and local synthesis.

Research Intelligence · local R&Dinspectable
INGESTarXiv metadata · deterministic topics
EMBEDMiniLM · 384-dimensional configuration
SEARCHFAISS exact retrieval
RERANKMS MARCO cross-encoder
OUTPUTlocal Qwen synthesis + sources
BOUNDexternal artifacts · no published benchmark

Demonstrated Change

Demo scope
Before

Research search and synthesis depend on disconnected tools or hosted APIs.

->
Demonstrated build

One local-first R&D pipeline with exact retrieval, reranking, and source-bearing output.

The R&D repository demonstrates the architecture and interfaces for that local-first workflow.

Model, corpus, and index are external downloads. Quality evaluation is currently heuristic and no benchmark result is published.

Proof Signals

Classified evidence
12
deterministic research topics
Repository fact
25
defined evaluation cases; results not yet published
Repository fact
0
paid inference APIs required at runtime
Configuration

Every signal is classified as a repository fact, recorded test, configuration, or disclosed data boundary.

Why This Is Hard

3 engineering challenges
Challenge · 01

Local inference

CPU constraints dominate generation latency.

Challenge · 02

Artifact setup

model, corpus, and index must remain version-aligned.

Challenge · 03

Evaluation

a defined test set is not a quality result without an executable saved run.

Engineering Depth

3 topics · click to expand

The active path uses normalized MiniLM embeddings and FAISS IndexFlatIP before cross-encoder reranking.

Key numbers
384-dimMiniLM embedding configuration
2query modes: fast and full
Built withPythonFAISSMiniLMCross-encoderQwenFastAPIStreamlit
Read R&D noteView repository
NEXT ENTRYSTATUS: UNWRITTENYOUR SYSTEM

Your
system,
next.

We take on a small number of engagements per quarter. Bring the problem and the success metric; we will bring the engineering.

Book an AI systems consultation ->Send a system brief ->