How are you representing uncertain or stale tool data in Gemini function responses?

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.