I am working through the contract for a Gemini tool that retrieves changing public information.
The difficult case is not a complete failure. It is a technically successful result that may be stale, incomplete, or from an unexpected regional variant.
Instead of returning only the extracted text, I am considering a structured response like:
{
"status": "partial",
"content": "...",
"source_url": "...",
"retrieved_at": "2026-09-04T08:00:00Z",
"cache_age_seconds": 7200,
"requested_region": "DE",
"observed_language": "de",
"validation_errors": ["currency_missing"],
"safe_to_answer": false
}
The orchestration layer would make the final decision instead of expecting Gemini to infer reliability from a paragraph of tool output.
I am considering four states:
- `accepted`: current and validated;
- `partial`: useful fields exist, but validation is incomplete;
- `stale`: cached content exceeds its freshness target;
- `unavailable`: no acceptable evidence.
For production Gemini applications, do you expose this reliability metadata directly to the model, or keep it in deterministic application logic and only pass accepted content?
I am also curious whether anyone has found a clean pattern for telling the model that stale context may be quoted with a warning but must not be presented as current fact.