Nisaba Gate

Gemini interprets evidence and coordinates the task; Nisaba governs every consequence.

Comment

The problem

An agent can say “done” before the evidence supports it. That becomes dangerous when the next step releases a supplier, moves money, changes access, publishes a record, or triggers another system.

Our hackathon example is deliberately concrete. A supplier agent says its packet is ready. The insurance certificate has expired, a data-processing agreement contains a hostile instruction, and a required attestation is missing. Trusting the sentence would release an unsafe packet.

Sending every step to a person is not a reliable answer either. It creates approval theatre: reviewers are asked to rubber-stamp work without a precise question or a clear source of authority.

What we built

Nisaba Gate is a governance runtime between an agent's completion claim and a consequential action. It binds six things before an effect may occur:

  1. the accepted task;
  2. the agent's claim;
  3. the source evidence;
  4. fixed policy;
  5. the exact authority required, if any; and
  6. the current ledger state.

The hackathon applies that mechanism to one synthetic supplier-release workflow. Supplier release is not Nisaba's product boundary. Other governed workflows can use different evidence, policies, authorities, and effects.

We tested that claim with authenticated Gemini evaluation across four synthetic document domains: supplier insurance, banking credit, research evidence, and industrial safety. The same source-citation, deterministic-validation, and bounded-action contract accepted all four. One shared Nisaba runtime then carried every result through durable intake, independent validation, policy, one bounded consequence, and terminal replay. All four jobs completed with 11-event valid chains and complete replays. This is one configurable lifecycle, not four separate product builds and not a claim that one policy fits every domain.

The judge sees two journeys and three outcomes:

  1. Bad evidence blocked → repaired → automatically released. Gemini interprets the actual synthetic PDF and drives the bounded lifecycle. Nisaba validates the interpretation, hard-blocks the three failures, permits repair only for those failed obligations, re-verifies the replacements, and performs one automatic release with no human authorization.
  2. Valid evidence → named Compliance/Legal exception. Machine-verifiable evidence passes, but this example's policy identifies one cross-border jurisdiction question. The assigned Compliance role may request four fixed source records. Retrieval is not a decision. Compliance then Legal must decide in order before one case-bound exception release.

Compliance and Legal are not fixed Nisaba roles. This synthetic policy assigns them to one example. Another workflow may assign different people or no human authority.

The three outcomes are materially different:

  • Automatic release: all fixed checks pass, so the task finishes without approval theatre.
  • Hard block: evidence is invalid, so neither a model nor a person can override it.
  • Named exception: evidence passes, but policy assigns one exact question to exact roles.

How we used Gemini

Gemini 3.7 Flash is not a label added to the architecture. It performs material work in both the deep Taskmaster journey and the four-domain portability proof.

Multimodal interpretation through the Google Gen AI SDK

Gemini receives the generated synthetic insurance certificate as application/pdf. It proposes source-cited facts, recognizes that a printed “Active” label conflicts with the expiry date, and recognizes a document instruction as untrusted evidence content rather than following it.

Nisaba then validates the supplied bytes, candidate fields, and citations before the observation can enter the governed record.

Adaptive coordination through Google ADK

Google ADK runs Gemini as the state-bound coordinator. At each lifecycle state, Gemini invokes one governed selection tool, chooses one action from Nisaba's current allowlist, returns one bounded result, and stops. The authenticated reference trace records 12 accepted selections across intake, verification, hard block, repair, re-verification, and release.

This is adaptive rather than a prescribed sequence, but it is not unbounded. Every selection is rebound to the current ledger head. Gemini cannot create a canonical evidence finding, change fixed policy, impersonate a human role, execute release, or write the terminal record.

That is the product's core distinction: Gemini does the interpretive and coordinative work; Nisaba retains consequence authority.

One evidence boundary across four document domains

The supplier workflow remains the deep Taskmaster demonstration. Separately, Gemini 3.7 received four generated PDFs through the same evaluator and chose a bounded action for each: request replacement supplier-insurance evidence while holding the transaction, request a corrected banking covenant certificate, mark a research claim unsupported pending review, and request a matching industrial calibration certificate.

Nisaba accepted each choice only after verifying the PDF digest, source fields, literal citations, deterministic findings, hostile-document-text handling, and the action allowlist. The responsible person retains contextual judgment and authority over any consequence. This shows that the governance boundary travels with the evidence pipeline; it does not rebuild Nisaba for each profession.

How we used Google Cloud

  • Cloud Run hosts the private FastAPI service and background worker.
  • Cloud Tasks provides authenticated asynchronous dispatch, retry, and resumption.
  • Firestore preserves durable job state and the append-only governed ledger.
  • Vertex AI provides authenticated Gemini 3.7 Flash inference in the global location.
  • Google Gen AI SDK carries multimodal PDF input and structured output.
  • Google ADK coordinates Gemini's next state-bound action through a governed tool.

The authenticated competition deployment remains private by design. Its Cloud Run service is invoker-only and returns 403 without Google IAM authorization; no shared credentials are distributed. A separate public, no-credential Cloud Run judge sandbox is available at the hosted demo. It uses synthetic in-memory state and exposes no external effects. The sandbox presents the sanitized authenticated Gemini 3.7 reference run and both governed journeys; it does not make a fresh model call on every click. Judges also receive the reproducible local path, public video, required architecture diagram, and sanitized evidence from the private Google deployment.

What judges can verify

Claim Visible evidence Sealed cloud result
Gemini performs real work Technical audit shows the PDF findings and all 12 model-selected actions Real application/pdf input; source match, citations, contradiction, and hostile-instruction recognition verified
Unsupported evidence stops the task Three named failures produce a non-overridable hard block Repair begins only after the recorded block
Repair preserves accountability Rejected records remain; replacements add lineage Valid 30-event chain reconstructs both failure and repair
The clear task finishes autonomously Automatic release appears with no approval step Two attempts, one release, one terminal record, zero human release authorization
Human authority is specific Separate case assigns one question to Compliance then Legal Two attempts across revisions, 40 events, ordered roles, one supervised release
Retry does not duplicate consequence Activity and replay show one terminal path Valid chains, complete replay, zero issues in both jobs
The evidence boundary is reusable Four domains show the same six-stage lifecycle, a bounded outcome, 11 ledger events, valid chain, complete replay, and retained human authority Four private Cloud Tasks jobs completed on exact revision xdom-b98a3a3 in one attempt each: 44 events, four bounded consequences, and zero release authorizations

Exact Google Cloud proof

The sealed Google Cloud cross-domain execution was built from source commit b98a3a3.

  • Cloud Build: bc3b7e5f-a972-40a8-91d5-ebb0c526e732 — SUCCESS
  • Image digest: sha256:5c04cb238cc393cecf2dfde5424d8dc6b8c55c64be8c2c22fff81ad360040dfb
  • Private Cloud Run revision: nisaba-gate-gemini37-candidate-xdom-b98a3a3
  • Candidate traffic: 100 percent
  • Four authenticated Cloud Tasks requests: HTTP 200
  • Four Firestore jobs: one attempt each, 44 governed events, four bounded consequences, four terminal records, valid chains, complete replay, and zero release authorization
  • Gemini 3.7 Flash usage across those calls: 11,258 tokens

The earlier automatic multimodal and named-exception journeys remain separately sealed to their recorded revisions in the public Google execution proof. This later candidate adds exact cross-domain cloud receipts without rewriting those historical runs.

Automatic multimodal job gemini37-cloud-auto-8273b7b completed in two attempts with 30 events, one automatic release, one terminal record, zero human release authorization, a valid chain, and complete replay.

Named-exception job gemini37-cloud-named-58e02e3 checkpointed on g37r1, resumed on g37r2, completed in two attempts with 40 events, required Compliance then Legal, and produced one supervised exception release with a valid chain and complete replay.

The earlier provider-neutral Phase 1 fallback remained unchanged.

Key features

  • Gemini 3.7 multimodal interpretation of an actual synthetic PDF.
  • Source citations, contradiction recognition, and hostile-document-text recognition.
  • Google ADK coordination of Gemini's next action from a state-bound allowlist.
  • A reusable governance boundary between an agent claim and consequential action.
  • Four-domain governed lifecycle proof without four separate product builds.
  • Automatic release, non-overridable hard block, and named-exception outcomes.
  • Bounded repair that preserves rejected evidence and replacement lineage.
  • Ordered, role-bound decisions for one defined ambiguity.
  • One-time release only after current evidence, policy, authority, and ledger bindings pass.
  • Append-only ledger, hash-chain integrity, and full state reconstruction.
  • Cloud Tasks retry and Firestore continuity across a changed Cloud Run revision.
  • A non-technical judge workspace and a separate technical evidence view.
  • Synthetic-only fixtures and a local judge path requiring no model key.

Architecture

The architecture reads left to right:

  1. A synthetic supplier packet enters a private Cloud Run service.
  2. Gemini 3.7 Flash uses the Google Gen AI SDK to interpret the PDF.
  3. Google ADK coordinates Gemini's next lifecycle action through one governed selection tool and a state-derived allowlist.
  4. Deterministic Nisaba responsibilities validate requirements, evidence, policy, human authority, release, and the final record.
  5. Cloud Tasks carries retries and Firestore preserves job state and the event chain.
  6. The system emits only automatic release, hard block, or a policy-assigned exception.

Functional role names are primary in the judge experience. Internal names remain secondary for engineering traceability:

Function Internal name
Release requirements Contract
Supplier intake agent Worker
Evidence verifier Momos
Fixed policy checker Maat
Release controller Janus
Final audit record Aletheia

Required architecture upload: assets/public/nisaba-gate-architecture.png — 1600 × 1000 PNG, 332,546 bytes, SHA-256 0DE9782819EF528850AE1587A2CDE403D0B3299ED12E674484AB9EA4CC66D9F4. The Gemini 3.7 revision was regenerated, visually checked at full resolution with no clipping, hidden content, or crowded primary labels, and uploaded as the required architecture diagram.

Technologies used

  • Gemini 3.7 Flash
  • Vertex AI
  • Google Gen AI SDK
  • Google Agent Development Kit
  • Google Cloud Run
  • Google Cloud Tasks
  • Google Firestore
  • Python 3.11/3.12
  • FastAPI, Pydantic, and Uvicorn
  • Pytest and Ruff

Challenges and accomplishments

The hard problem was not prompting a model to produce a plausible answer. It was letting a strong model interpret real evidence and adapt the workflow without letting fluent text silently become evidence, policy, authority, or release.

A second challenge was durability. The named case paused on one revision, waited for the assigned roles, and resumed on another revision without losing its evidence bindings or performing a duplicate release.

The result is not a slide-deck architecture. Both paths ran through the private Google profile and reconstruct from valid event chains.

Findings and learnings

  • Model capability and consequence authority should be designed separately.
  • Agent output is a claim until source evidence and current state support it.
  • A state-derived action allowlist enables adaptation without scripting or unrestricted tools.
  • Collecting evidence does not itself authorize an outcome.
  • Repair should add lineage rather than erase failure.
  • Human judgment remains essential where consequences require context, authority, or accountability. Nisaba reduces evidence-gathering and coordination work so the responsible person receives a precise question with verified evidence and retains the power to approve, refuse, or stop the process.
  • Durable state matters only if the governed history can be reconstructed.
  • Judge comprehension is part of engineering: explain the task and observable effect before internal vocabulary.

Nothing in life—or in software—is perfectly accurate. AI can reduce repetitive evidence handling and coordination, but it does not remove the need for human judgment or responsibility. Coexistence requires mutual understanding: people need to understand how models communicate and fail, while systems need explicit evidence and authority boundaries rather than assumed human-like meaning.

What is next

The hackathon fork deliberately makes Gemini central and uses synthetic records. The permanent Antecedent Labs Nisaba product remains provider-neutral and may communicate with local models. Future product work includes customer-controlled identity, production evidence connectors, locally controlled durable execution, and the same replay and authority invariants across every provider adapter.

Data sources and disclosure

All supplier records, identities, organizations, policies, decision-support records, role principals, and generated PDFs are fixed synthetic fixtures. The governed portability proof adds only fictional banking, research, and industrial-safety documents. The build includes no customer data, production dataset, proprietary research corpus, credential, or private archive.

The governance research and broader product direction predate the event. The submitted implementation was built as clean-room code during the eligible period and does not contain or require that private source material.

Built With

Share this project:

Updates

Submission history