AssureOps Agent

Gemini proposes the proof plan; humans authorize bounded actions; verified, version-bound evidence—not the model—decides release readiness.

Comment

Inspiration

What it does

Strengthened autonomy boundary

AssureOps now makes its autonomy boundary visible end to end. A breaking API change is intercepted automatically, mapped through a quality ontology into four impacted assets and four proof obligations, and checked against existing evidence. Stale evidence is rejected before Gemini proposes a bounded recovery action through Google ADK. A reviewer authorizes only the exact external execution digest; evidence ingestion and release readiness remain automatic and deterministic. The strengthened candidate collects 128 automated tests across 30 adversarial trust scenarios (60 deterministic evaluation runs). Agents propose. Humans authorize. Evidence decides.

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for AssureOps Agent

Inspiration

CI can tell a team that something failed, and coding agents can suggest a fix, but neither gives an accountable answer to four release questions: what is impacted, what must be proven, who authorized the action, and whether the returned evidence proves this exact revision.

AssureOps Agent was built to close that trust gap. The goal is not to let an LLM declare production readiness. The goal is to let Gemini help reason about the next bounded proof step while people and deterministic controls retain authority.

What it does

The demo follows one synthetic but realistic incident: NimbusCart introduces a breaking delivery-quote API change.

AssureOps:

  1. parses the candidate OpenAPI change;
  2. derives four impacted systems from a bounded context graph;
  3. creates version-bound proof obligations;
  4. rejects stale evidence from a previous revision;
  5. asks Gemini 3.5 Flash, through Google ADK, for a typed proposal;
  6. requires a human to approve the exact plan digest and target revision;
  7. executes only an allow-listed synthetic compatibility suite;
  8. verifies the returned JUnit artifact, identity, digest, and bindings; and
  9. lets deterministic policy—not the model—derive the final release decision.

Approval changes authorization, not truth. A successful execution also does not imply readiness. Only fresh, correctly bound evidence can satisfy a proof obligation.

How we built it

AssureOps is a small full-stack product slice deployed as an authenticated Google Cloud Run service.

  • Gemini 3.5 Flash on Vertex AI produces proposal-only reasoning.
  • Google ADK hosts the Agent adapter and typed proposal path.
  • FastAPI and Pydantic expose the application contract.
  • React and TypeScript provide the operations workbench.
  • SQLite provides a transactional journal for this single-instance competition deployment.
  • An immutable content-addressed artifact store retains synthetic evidence.
  • Docker supplies a reproducible one-command local build.

The domain core is deliberately deterministic. Commands use optimistic concurrency and idempotency keys. Audit events are append-only and hash chained. Human approval binds to the exact target revision and plan digest. The executor rejects actions outside a fixed allowlist. Evidence connectors accept only bounded OpenAPI and JUnit inputs and verify their provenance before policy consumes them.

Built with Google

The live proposal path calls Gemini 3.5 Flash through Vertex AI using Google ADK. The UI and API run together on Google Cloud Run. The health contract exposes only safe deployment facts—model ID, framework, backend, service, and revision—so judges can verify that the visible demo is backed by Google Cloud without exposing credentials.

The hosted service stays authenticated. The Devpost and Google judging groups have Cloud Run Invoker access, and the private GitHub repository has read-only judge invitations. The README also contains a complete local Docker quickstart.

Challenges

The hardest challenge was preserving useful Agent reasoning without turning model output into operational truth. We solved that by ending the Agent boundary at a typed proposal and moving authorization, execution, evidence verification, and release policy into explicit contracts.

A second challenge was creating an honest competition slice. Cloud Run currently runs one instance because the demo uses local transactional adapters. The architecture documents the scale boundary and the ports for future managed storage, outbox publication, and distributed workers instead of claiming production scale we have not implemented.

The final challenge was making the trust model visible in a short demo. The workbench therefore shows the target revision, plan digest, proposal source, policy state, immutable evidence, and audit chain as first-class product concepts.

Accomplishments

  • A live end-to-end path from API change to verified release evidence.
  • Gemini and Google ADK used where probabilistic reasoning helps, with proposal-only authority.
  • Exact-plan human authorization and fail-closed execution.
  • Version-bound evidence that rejects stale or wrong-scope CI results.
  • A deterministic release policy with append-only, hash-chained auditability.
  • Adversarial tests covering stale evidence, approval mismatch, replay, and tampering.
  • A reproducible local build plus an authenticated Cloud Run deployment.

What we learned

The most important design lesson is that Agentic does not have to mean autonomous authority. In high-risk operations, the strongest pattern is: the model proposes, the human authorizes, verified evidence decides.

We also learned that provenance must be part of the product model, not a log added later. When evidence identity, revision binding, approval digest, and audit ancestry are explicit, the system can explain not just its conclusion but why that conclusion is valid for this exact change.

What's next

Next steps are replacing demo-local adapters with managed Google Cloud persistence and outbox workers, adding signed CI callbacks, expanding the evidence connector SDK, and supporting product-specific onboarding profiles without weakening the core trust boundary.

Eligibility and prior work disclosure

This repository is a clean-room, synthetic competition implementation created after the hackathon began. It contains no production credentials, customer data, proprietary product documentation, or copied source from the earlier internal ontology-platform work. That earlier work informed the problem framing; the competition code, synthetic scenario, UI, Agent contract, tests, and deployment package were newly implemented for this entry.

Built With

Share this project:

Updates