-
-
Google ADK orchestrates Handover Truth, with Gemini on Vertex AI for reasoning and deterministic rules for evidence-backed outcomes.
Inspiration
Buying a new home is one of the largest financial commitments most people make, yet the final handover is often reduced to a visual inspection.
That creates a fundamental gap: a home can look finished while still failing what the buyer was actually promised.
A fixture can function perfectly and still be wrong if the contract specified another brand or model. A material may look similar while differing from the agreed specification. And when something is disputed, buyers are left manually connecting contracts, walkthrough evidence, conversations, fixes, and re-inspections.
We built Handover Truth to answer a more precise question:
What exactly did the builder promise, what evidence would prove delivery, and which cited obligation is still unmet?
What it does
Handover Truth is an autonomous buyer-side contract-to-reality agent for new-home handover.
Its workflow is:
Documents → Promise Ledger → Targeted Walkthrough → Evidence Gate → VERIFIED / MISMATCH / NOT_VERIFIABLE → Rectification → Fresh Re-verification → Proof Receipt
The buyer supplies the contract.
From there, the Google ADK agent takes ownership of the case. It inspects persistent state, uses Gemini to extract concrete contract promises with clause and page grounding, determines what evidence is needed for each promise, creates a targeted walkthrough mission, and stops only when a genuine physical-world dependency requires the user.
When evidence arrives, the agent resumes the workflow automatically.
Gemini interprets the evidence, while deterministic application policy checks whether the evidence is actually sufficient to support the proposed conclusion.
The system can return:
- VERIFIED — supplied evidence supports the contractual promise.
- MISMATCH — supplied evidence directly contradicts the promise.
- NOT_VERIFIABLE — the evidence does not justify either conclusion.
That third state is critical. Handover Truth is intentionally designed to refuse unsupported certainty.
A readable brand label can support a brand comparison. A complete visual sweep may support a count. An exact dimension requires a visible calibrated measurement. Evidence that cannot prove something is not silently converted into a positive claim.
When a genuine mismatch is found, the agent opens a clause-linked rectification case.
The builder cannot close that case simply by declaring that the problem was fixed. Handover Truth requires fresh evidence captured after the mismatch case was opened, re-verifies that evidence against the original contractual promise, and closes the case only after the new evidence passes the verification gate.
Finally, the system produces a Proof Receipt containing the original promise, contract citation, evidence, hashes, verdict history, rectification history, audit events, final state, and canonical receipt hash.
Why it is agentic
Handover Truth is not a chatbot wrapped around a form.
The Google ADK agent owns the workflow.
It:
- Inspects the current case state.
- Determines the next valid action.
- Extracts grounded contractual promises.
- Creates the evidence mission.
- Stops when the physical world is genuinely required.
- Resumes when new evidence becomes available.
- Chooses the appropriate verification tool.
- Opens rectification only when evidence supports a mismatch.
- Distinguishes initial verification from rectification re-verification.
- Requires fresh post-case evidence before closure.
- Produces the final auditable outcome.
The user supplies real-world inputs; the agent manages the lifecycle.
Architecture
The core production flow is:
Buyer / Judge UI → Google ADK Orchestrator → Gemini reasoning and multimodal interpretation → Deterministic Evidence Policy → Firestore + Cloud Storage → Rectification lifecycle → Proof Receipt
The agent runtime is deliberately separated from deterministic proof policy.
Gemini handles interpretation and reasoning.
Application code enforces minimum proof requirements and lifecycle invariants.
Persistent case state lives in Firestore, while source documents and evidence are stored in Cloud Storage.
The application runs on Google Cloud Run.
Google technologies used
- Gemini 3.6 Flash
- Vertex AI / Google Gen AI SDK
- Google Agent Development Kit (ADK)
- Google Cloud Run
- Google Firestore
- Google Cloud Storage
- Google Cloud IAM / service-account identity
- Structured JSON model outputs
- SHA-256 content-addressed evidence integrity
Evidence integrity
Source documents and evidence are SHA-256 hashed.
A changed source invalidates stale downstream conclusions rather than allowing an old result to remain attached to different bytes.
The resulting Proof Receipt provides a traceable connection between:
contract source → promise → evidence → verdict → rectification → final state
Hashes identify the exact bytes evaluated; they are not presented as proof of who captured a file, where it was captured, or when it was created.
Reproducible judge experience
Judges do not need access to a real apartment to test the complete lifecycle.
The hosted judge interface includes a clearly disclosed fictional handover scenario.
One synthetic test input visibly contains a JAQUAR fitting label against a contractual GROHE promise.
The evidence does not contain a hidden verdict.
Gemini must interpret the evidence, the deterministic evidence gate must accept or reject the proposed conclusion, and the ADK agent must decide which workflow tool to invoke.
A second explicitly disclosed fresh rectification input contains the expected GROHE label.
The agent then routes the open case through fresh-evidence re-verification and may close it only if the original promise becomes VERIFIED.
This gives judges a reproducible full lifecycle while clearly separating synthetic test inputs from real property evidence.
Challenges we ran into
The hardest problem was not detecting differences.
It was deciding when the system had enough evidence to responsibly make a claim.
A generic multimodal model can easily produce plausible conclusions from incomplete images. For a contract-verification system, that behavior is dangerous.
We therefore separated model interpretation from proof policy.
Another challenge was rectification integrity. A normal workflow could allow old evidence to be reused after somebody marks an issue as fixed. We designed the lifecycle so rectification requires evidence newer than the mismatch case and independent re-verification against the original promise.
We also needed the judge experience to be reproducible without pretending synthetic evidence came from a real home. The final judge lifecycle explicitly labels fictional inputs while keeping Gemini inference, ADK routing, state transitions, and evidence gates live.
Accomplishments we're proud of
We built an agent that can move a handover case from an unstructured contract to a clause-grounded Promise Ledger, create its own verification mission, distinguish insufficient evidence from real mismatches, initiate rectification, require fresh proof, independently re-verify the fix, and produce an auditable receipt.
We are particularly proud that the system is designed not only to find problems, but also to know when the evidence cannot support a claim.
That restraint is a feature.
What we learned
Reliable agents need more than better prompts.
High-value autonomous systems need explicit state, deterministic invariants, provenance, failure boundaries, and clear separation between probabilistic interpretation and actions that affect workflow state.
We also learned that stopping can be an intelligent agent action.
If the contract is missing or a physical observation is required, the correct autonomous decision is not to invent an answer—it is to identify the dependency, preserve state, and resume when the missing evidence arrives.
What's next for Handover Truth
The same contract-to-reality architecture can extend beyond residential handover into commercial fit-outs, equipment acceptance, procurement verification, lease-condition checks, insurance restoration, and other workflows where promised specifications must eventually be reconciled with physical evidence.
The larger vision is simple:
important promises should not disappear into documents after they are signed.
They should remain machine-trackable until there is sufficient evidence that they were actually fulfilled.
Log in or sign up for Devpost to join the conversation.