Frequently Asked Questions

Common questions about MemoryGate's trust signals, integration, and architecture.

Why use MemoryGate instead of building our own trust gate?

You can build one—but then you own correctness over time.

A trust gate isn't just a score. It's a lifecycle: handling corrections, conflicts, decay, authority, auditability, and replaying why a memory had a given trust level at a specific point in time.

MemoryGate externalizes that responsibility. We manage the trust lifecycle so you don't have to maintain it forever.

Why can't we just assign trust scores when documents are ingested?

You can—but ingestion-time trust is static.

Trust only changes after ingestion, when facts are corrected, superseded, or contradicted by other memories.

That's why trust has to be evaluated at retrieval time, when memories compete in context. If trust changes over time, someone has to own a gate. MemoryGate is that gate.

Why not just delete old documents?

MemoryGate returns trust signals for all retrieved memories. Keep all your documents for compliance—MemoryGate provides trust scores that help downstream systems make decisions. Old documents stay in your vector database, and MemoryGate returns low trust scores for them. Downstream systems decide how to use those signals based on their own policies.

How does the AI know which document to trust?

MemoryGate returns trust scores (0.0-1.0) for each retrieved memory. Downstream systems receive relevance, trust, and confidence scores. Confidence = relevance × trust. Systems apply their own policies—MemoryGate provides signals, not decisions.

Why not just use the newest document by timestamp?

Timestamps are unreliable in enterprise environments. A newer document might be a draft that was rolled back. An older correction from legal/HR is more authoritative than a newer draft. MemoryGate uses trust scores based on corrections and conflicts, not document upload dates.

Can I restore old information if a correction was wrong?

Yes. Since MemoryGate doesn't delete content, you can restore trust on old memories if needed. Full reversibility. All memories remain in your system, trust scores can be adjusted.

How fast are corrections applied?

Corrections are applied quickly. Cache updates are immediate; full persistence (file + database) follows. This is orders of magnitude faster than re-indexing your entire vector database.

How simple is the integration?

One API call to plug in. No data retention. Disconnection is just another click away. Call /v1/query for search, /v1/monitor for corrections. No complex setup, no infrastructure changes, no changes to your system in any way. Works with your existing vector DB.

Does MemoryGate store our content?

No. With Privacy Mode enabled (SVTD_PRIVACY_MODE=true), MemoryGate operates on a "Ghost Protocol."

We process content transiently to compute initial trust signals and then immediately discard it. We retain only:

  • Trust Scores (0.0 - 1.0)
  • Vector Embeddings (Mathematical representations)
  • Metadata (e.g., source, timestamp)

Your raw text content is stored as NULL in our database. You can't leak what you don't store.

What about role-based authority?

Admin corrections apply immediately. User corrections are queued for review. This prevents poisoning because only admin-level corrections trigger trust decay.

Is this SOC2 / HIPAA / GDPR compliant?

Yes, by design.

  • HIPAA: We never store PHI. We only see a random UUID.
  • GDPR: The svtd_id is not PII; it is a random number linked to data only you control.
  • SOC2: We provide a full audit log of score changes for every ID.

How does this integrate with Pinecone/Weaviate?

MemoryGate acts as a lightweight "Sidecar" to your retrieval:

  1. You retrieve chunks from your Vector DB as usual.
  2. You send the IDs to MemoryGate's API.
  3. We return Trust Scores (e.g., [0.99, 0.10, 0.95]) for you to filter before sending to the LLM.
  4. You filter out the low-trust results before sending to the LLM.

Can we use our existing database IDs?

No. We require a strict UUIDv4 format for the svtd_id.

Standard database integers (like 1045) cause collisions in a multi-tenant environment. UUIDs allow you to move, re-index, or re-embed your data without losing its Trust Score history.

How do you prevent malicious users from "poisoning" the trust scores?

We use Role-Based Trust Authority:

  • Admin: Authoritative corrections trigger immediate trust decay.
  • User: Suggestions are queued or apply localized decay only.

Furthermore, because IDs are random UUIDs, it is mathematically impossible for a user to "guess" the ID of a memory to maliciously downrank it.

What happens if I stop using MemoryGate?

You own the content. You own the ID mapping. We only own the Trust Score.

If you leave, your data remains intact in your system. You simply lose the "intelligence layer" that filters out hallucinations. There is no vendor lock-in on your actual data.