Structured extraction
Invoices and forms are turned into validated JSON. Re-processing the same document returns the validated result without another model call.
AI and LLMLLM operationsPerformance and Scale plans
Guardrail and Moderation Caching
Replay answers that already passed your validators, and refuse repeat offenders without calling moderation or the model again.
- caches, good and bad
- 2
- re-validation on a hit
- 0
- TTLs for refusals
- Short
Step 1 of 5
Generate and validate
The namespaces were made once with GUARD.CREATE and NCACHE.CREATE. The model produces JSON, and your validator checks it against the schema before anything is stored.
Example sessionplaying
# Generate and validate
hotkv> GUARD.SET validated "Summarize ticket 812 as JSON" "{\"summary\":\"Login fails on Safari\"}"
OK
An animated walkthrough with real HotKV commands and example replies. Click any step to jump to it.
The problem
Structured output and safety checks are slow and cost money. There is a model call, a JSON schema validation, and maybe a second model to judge the answer. Repeated requests pay all of it again. And the same abusive prompt, sent a thousand times by a script, goes to moderation a thousand times.
How HotKV handles it
The guard cache stores only responses that have already passed your schema validation or guardrail checks, so a hit is known to be safe to replay as is. The negative cache remembers refusals such as "refused by moderation" with a short TTL, so repeated bad requests are turned away before they reach the moderation service or the model.
Step by step
What happens, command by command
- 01
Generate and validate
The namespaces were made once with GUARD.CREATE and NCACHE.CREATE. The model produces JSON, and your validator checks it against the schema before anything is stored.
GUARD.SET validated "Summarize ticket 812 as JSON" "{\"summary\":\"Login fails on Safari\"}" - 02
Replay without re-checking
The same request again. The stored answer already passed validation, so it is returned as is.
GUARD.GET validated "Summarize ticket 812 as JSON" - 03
Moderation refuses a prompt
A harmful prompt is refused. The refusal is remembered for five minutes.
NCACHE.SET refused "prompt:9f31c2" "refused_by_moderation" TTL 300 - 04
The script tries again
The same prompt a moment later is turned away from the cache. Moderation and the model are not called.
NCACHE.GET refused "prompt:9f31c2" - 05
Measure both caches
Each namespace reports hits, misses, evictions and memory.
GUARD.STATS validated
Where it fits
Real-world scenarios
Consumer chat apps
Abuse scripts that hammer the same prompt are refused from the negative cache, keeping moderation costs flat.
Lookups that fail
"User not found" and other negative answers are cached briefly, so retries do not hit the backend.
Built in
What you get
Guard cache
Only responses that passed your checks are stored, so a hit is safe to replay.
GUARD.SETGUARD.GETNegative cache
Remember refusals and not-found results for a short time.
NCACHE.SETNCACHE.GETTTLs and limits
Default TTLs and entry limits per namespace, with eviction when full.
GUARD.CREATENCACHE.CREATEStatistics
Hits, misses, evictions, memory and savings per namespace.
GUARD.STATSNCACHE.STATSCommon questions
Does HotKV validate the output itself?
No. Your validator or guardrail decides. HotKV stores only what you put in the guard cache after it passed.
How long should refusals be cached?
Usually briefly, minutes rather than days, so a policy change or a false positive does not stick. Set the TTL per namespace or per entry.
Which plans include it?
The guard cache and negative cache are part of the Performance and Scale plans.
Related use cases
Try it on your own workload
HotKV speaks the Redis protocol, so you can point an existing client at it and run these same commands.