MossPulse AI — Zero-Latency Knowledge Copilot

A real-time AI copilot that uses Moss for ultra-fast semantic retrieval, validates evidence before generation, and delivers grounded, source-cited answers with measurable latency.

Comment

Inspiration

AI assistants are becoming extremely good at generating answers, but we noticed a fundamental problem: an AI answer is only as reliable as the information it retrieves before generating it.

In protocol-driven environments such as healthcare and field operations, users often need a specific piece of approved information quickly. Traditional keyword search can miss relevant information when the user's wording differs from the source document, while sending a question directly to an LLM can lead to unsupported or hallucinated answers.

That led us to a simple idea:

What if retrieval itself became fast, measurable, and part of the AI product experience?

We built MossPulse AI around that idea. Moss provides the semantic retrieval layer, Context Guard validates the evidence, and Gemini generates an answer only from the validated context.

The goal isn't to build another chatbot. It is to build a knowledge copilot where retrieval speed, evidence quality, and AI grounding are first-class features.

What it does

MossPulse AI lets users ask questions using natural language or voice and receive answers grounded in an approved knowledge base.

The core pipeline is:

User Query
    ↓
React Frontend
    ↓
Node + Express API
    ↓
Moss Semantic Retrieval
    ↓
Context Guard + Safety
    ↓
Gemini Grounded Generation
    ↓
Answer + Sources + Evidence + Latency

Moss performs semantic retrieval and returns relevant evidence with measurable retrieval latency.

Before Gemini receives that information, our Context Guard + Safety layer evaluates the retrieved evidence.

It can identify states such as:

  • VALID
  • INSUFFICIENT
  • CONFLICTING
  • STALE
  • AMBIGUOUS
  • UNAPPROVED

If the evidence isn't sufficient, MossPulse does not simply ask the LLM to guess.

When evidence is valid, Gemini receives the retrieved context and generates a grounded response with source citations.

The interface also provides:

  • Real Moss retrieval latency
  • Generation latency
  • Total response latency
  • Retrieved evidence
  • Source metadata
  • Grounding status
  • Conversation history
  • Voice input
  • Performance monitoring
  • Reliability evaluation

For safety, the demonstration uses synthetic knowledge only and does not use real patient data.

How we built it

We built MossPulse AI as a lightweight full-stack application without a traditional database.

Frontend

We used:

  • React
  • TypeScript
  • Vite
  • Tailwind CSS

The interface uses a three-panel copilot experience:

Conversation → AI Response → Evidence

This allows users to see not only the answer but also the information behind it.

Backend

The backend uses:

  • Node.js
  • TypeScript
  • Express

The API coordinates the entire AI pipeline and keeps API credentials server-side.

Retrieval

The knowledge base consists of synthetic approved JSON documents.

We created a local processing pipeline:

Documents
   ↓
Validation
   ↓
Approval Filtering
   ↓
Chunking
   ↓
Metadata
   ↓
Moss Index

Moss then performs semantic retrieval against these indexed knowledge chunks.

This is the most important part of the architecture because Moss sits directly on the critical path between the user's question and AI generation.

Grounded Generation

After retrieval, the Context Guard evaluates the evidence.

Only valid and sufficiently grounded context is passed to Gemini.

Gemini is instructed to:

  • Use the supplied evidence
  • Avoid inventing information
  • Avoid unsupported claims
  • Preserve source relationships
  • Clearly communicate uncertainty

Retrieved documents are treated as data rather than instructions, which also helps protect against prompt injection through malicious document content.

Performance and Evaluation

We record real request measurements in memory, including:

  • Retrieval latency
  • Generation latency
  • Total latency
  • Result count
  • Grounding status
  • Success/failure

The total response time can be represented as:

$$ T_{total} = T_{retrieval} + T_{validation} + T_{generation} + T_{overhead} $$

We also created a synthetic evaluation set covering valid, irrelevant, ambiguous, conflicting, stale, and safety-sensitive questions.

This lets us evaluate not just whether the AI can answer, but whether it knows when it should and should not answer.

Challenges we ran into

1. Making retrieval meaningful

The biggest challenge was avoiding a superficial integration where Moss was simply added somewhere in the stack.

We designed the architecture so Moss is directly responsible for retrieving the evidence that Gemini uses.

That makes its contribution measurable and essential to the product.

2. Preventing unsupported answers

A normal chatbot can always generate something.

Our system needed to do the opposite when evidence was missing.

We therefore introduced the Context Guard layer to distinguish between valid evidence, insufficient evidence, conflicting information, stale sources, and ambiguous questions.

3. Separating retrieval latency from AI latency

A fast retrieval layer does not mean the complete AI response will take only a few milliseconds.

Gemini generation naturally adds additional latency.

We therefore measure retrieval, validation, generation, and total response time separately.

This allows us to demonstrate Moss's retrieval performance without making misleading claims about total response time.

4. Safety and prompt injection

Retrieved documents cannot automatically be trusted as instructions.

We had to make a clear distinction between:

information retrieved from a document

and

instructions that control the AI system.

The Context Guard and Safety layers enforce this boundary before generation.

5. Building without unnecessary infrastructure

We deliberately avoided adding a traditional database or complicated infrastructure.

For the hackathon prototype, local synthetic knowledge, Moss indexing, and controlled in-memory state were enough to demonstrate the core product.

Accomplishments that we're proud of

Moss is part of the core architecture

Moss isn't just an optional feature.

It is the semantic retrieval layer that supplies the evidence used by the AI.

The AI can refuse to guess

MossPulse is designed around the principle:

No evidence → no unsupported answer.

That is especially important for protocol-driven applications.

Answers are explainable

Users can inspect the evidence and sources behind an answer instead of receiving a black-box response.

Performance is measurable

We measure retrieval and generation independently rather than presenting fabricated or misleading latency numbers.

Voice uses the same safety pipeline

Voice input doesn't bypass retrieval or safety.

It follows the same workflow:

Voice
  ↓
Retrieval
  ↓
Validation
  ↓
Generation

Reliability is testable

The evaluation system tests not only successful questions but also failure conditions such as conflicting, stale, ambiguous, and insufficient evidence.

What we learned

The biggest lesson was that building a reliable AI application is much more than connecting an LLM to a user interface.

We learned to treat retrieval, grounding, safety, and observability as independent engineering problems.

We also learned that speed has to be measured at the correct layer.

Instead of saying:

"Our AI is ultra-fast."

we can precisely show:

"Our semantic retrieval layer is optimized for extremely fast retrieval, while total response time includes validation and generation."

We also learned the importance of designing failure states intentionally.

A good AI system shouldn't only know how to answer.

It should know when the available evidence isn't enough to answer responsibly.

What's next for MossPulse AI — Zero-Latency Knowledge Copilot

The current version demonstrates the core architecture using synthetic knowledge.

Our next steps would be:

1. Production Knowledge Management

Introduce stronger document lifecycle management, approval workflows, version control, and automated stale-document detection.

2. More Powerful Evaluation

Expand the evaluation framework into continuous reliability testing covering:

  • Retrieval accuracy
  • Grounding accuracy
  • Citation correctness
  • Safety behavior
  • Prompt injection resistance
  • Regression testing

3. Edge and Local-First Capabilities

Explore running parts of the retrieval and knowledge workflow closer to the user for environments where connectivity, privacy, or latency are critical.

4. Better Multimodal Interaction

Extend the copilot beyond text and voice to support richer operational inputs while keeping the same grounding and safety pipeline.

5. Production-Scale Observability

Add distributed tracing and persistent performance analytics so teams can monitor retrieval quality and AI reliability over time.

Ultimately, we want MossPulse to become a reliable AI knowledge layer for high-stakes operational environments — one where users can ask naturally, retrieve relevant knowledge quickly, understand why an answer was produced, and know when the system doesn't have enough evidence to answer.

Built With

Share this project:

Updates

Submission history