RECONCILE

The problem

An agent can ask Cloud Run to stage a revision, have the provider accept it, and lose the acknowledgement. The timeout proves neither failure nor success. A blind retry can create a duplicate revision; a blind abort can strand an accepted revision before promotion and recording finish.

RECONCILE treats that as an evidence problem. It is built for engineers and operators whose agents invoke consequential tools and must decide what may happen next without guessing what already happened.

What RECONCILE does

Before provider contact, RolloutAgent binds a predeclared release chain with exact semantic identities, preconditions, and expected effects: stage one revision, promote its traffic, then create one Firestore release record.

After an ambiguous acknowledgement, RecoveryAgent gathers bounded, allowlisted provider observations. Deterministic adapters turn those observations into effect-level assertions, and deterministic rules verify source authority, correlation, freshness, scope, and provider coherence.

Sufficient proof yields a VerifiedCertificate bound by canonical SHA-256 digests to the chain, node, envelope, report, target, proof, and supporting evidence. Insufficient or conflicting evidence yields an ambiguity witness with competing evidence-compatible histories and the observations that could distinguish them.

A certificate can mint only an expiring permit for the next exact semantic action. Every permit has max_uses=1, and Firestore compare-and-swap arbitrates its durable claim before provider contact. Replaying consumed authority is rejected before another provider call can leave the process.

Fresh accepted Google Cloud run

The final candidate executed the real lost-acknowledgement path on Google Cloud:

The first classification was UNKNOWN. Both continuation and retry were denied, and no permit existed. After authoritative provider settlement, the same investigation reached COMMITTED. Exactly two continuation permits were issued and consumed, each with max_uses=1. The chain completed with one revision, one traffic promotion, and one Firestore release record. Replaying consumed authority was rejected before provider contact, with contact delta zero. Gemini 3.5 Flash performed one bounded planning generation and produced one evidence-bound hypothesis.

The ephemeral deployment used five authenticated Cloud Run services, Firestore durable state and CAS, Cloud Storage for sealed operator artifacts, and Vertex AI. It was torn down after evidence capture.

How Gemini is used

RECONCILE uses Gemini 3.5 Flash through Vertex AI, Google ADK, and the Google GenAI SDK for one bounded advisory task: form an evidence-cited hypothesis and propose useful allowlisted read-only probes.

The model receives a bounded execution envelope, capability catalog, and sanitized evidence summaries. It cannot call provider tools directly, admit evidence, classify commitment, create certificates, issue or spend permits, mutate a target, or override the action gate. Deterministic code independently validates every proposal and observation. Model or provider failure cannot widen authority.

Architecture

Cloud Run hosts the authenticated API, controller, fault proxy, evidence sandbox, and canary mutation target. Firestore stores recovery state, provider ledgers, permit lifecycle, and the final release record. Vertex AI runs the bounded Gemini planner. IAM and application-level audience checks separate read authority from mutation authority.

The authority flow is:

predeclared intent -> guarded dispatch -> ambiguous acknowledgement -> advisory hypothesis and bounded probes -> admitted provider evidence -> deterministic certificate or ambiguity witness -> exact single-use permit -> guarded provider contact

Reproduce the accepted proof

Public repository: https://github.com/OCHOLA-EDDYPHIL/reconcile-proof-to-permit

Corrected immutable proof package: https://github.com/OCHOLA-EDDYPHIL/reconcile-proof-to-permit/releases/tag/v0.1.1

From a clean checkout with Python 3.12.13 and uv 0.12.3:

git clone https://github.com/OCHOLA-EDDYPHIL/reconcile-proof-to-permit.git cd reconcile-proof-to-permit uv sync --locked --all-groups uv run --no-sync python scripts/replay_gate_g5r.py uv run --no-sync python scripts/check_release_candidate.py

These commands validate the sanitized checked-in proof without cloud credentials or a public endpoint. Release v0.1.1 corrects the public proof package and validation path; it does not change the accepted v0.1.0 runtime or claim a new hosted run. The accepted runtime source remains 4d626bb67739ca51c7569124724ea5d7ac8f5c0e.

Differentiation

Atomix focuses on transactional settlement across tool calls, Cordon on semantic transactions, lineage, staged effects, and recovery, and ACRFence on replay after agent restore. RECONCILE's narrower distinction is the authority transition after an ambiguous side effect: effect-level provider evidence becomes either a hash-bound certificate and exact one-use next-action permit, or an ambiguity witness that keeps mutation closed.

Limitations

The accepted target is deliberately narrow: one Cloud Run stage-to-promote-to-record chain. New providers and actions require explicit effects, probes, and verifier rules. VerifiedCertificate uses canonical SHA-256 bindings; it is not a digital signature or KMS attestation. Firestore CAS enforces one durable claim of a permit, not a general exactly-once guarantee for arbitrary external systems.

Built With

• cloud-run
• cloud-storage
• fastapi
• firestore
• gemini-3.5-flash
• google-agent-development-kit-(adk)
• google-genai-sdk
• python
• terraform
• uv
• vertex-ai