NEXUS Evidence Fleet

The problem

Autonomous AI agents are becoming extraordinarily fast at producing operational conclusions, security assessments, and decisions.

But speed creates a governance problem:

model confidence is not evidence, and model confidence must never become authority.

A worker agent should not be able to generate a claim, review its own claim, and silently promote that claim into trusted enterprise state.

NEXUS Evidence Fleet explores a different architecture:

Agents propose evidence. Independent review challenges it. Deterministic policy decides what gets promoted.

What we built

NEXUS Evidence Fleet is a new contest-period implementation for the Fortified Enterprise Fleet track.

The runtime separates the system into distinct authority layers:

  1. SourceReceipt

    • provenance
    • content hash
    • timestamps
    • freshness state
  2. ScoutAgent

    • Google Antigravity SDK
    • Gemini 3.7 Flash
    • extracts and proposes CandidateEvidence
    • authority ceiling: CANDIDATE_PROPOSAL_ONLY
  3. ReviewerAgent

    • separate Gemini 3.7 Flash / Antigravity agent
    • independently checks provenance, freshness, and evidence binding
    • authority ceiling: REVIEW_DECISION_ONLY
  4. DeterministicPolicyGate

    • pure Python
    • no LLM reasoning
    • evaluates hard invariants
    • is the only component allowed to produce a PromotionReceipt

The core rule is therefore enforced structurally, not just through prompting:

Scout != Reviewer != Promotion Authority

Three adversarial scenarios

VERIFIED_EVIDENCE

Fresh corroborated evidence flows through Scout and independent Reviewer.

When every deterministic invariant passes:

PROMOTED

STALE_POISONED

A convincing but superseded source is introduced.

Even if the candidate has high model confidence, stale provenance causes the deterministic gate to fail closed:

DENIED

REVIEWER_FAILURE

The independent reviewer is deliberately failed.

The system emits a FailureReceipt and does not silently bypass review:

REVIEW_FAILED

No reviewer means no promotion.

Google technology

The project uses:

  • Gemini 3.7 Flash
  • Google Antigravity SDK
  • Google Cloud Run
  • Google Stitch
  • Python / FastAPI
  • structured Google Cloud-compatible logging
  • Firestore persistence when a cloud Firestore database is available, with a transparent local fallback for development

The agent layer also uses explicit capability ceilings and bounded Antigravity session budgets.

Visual governance with Google Stitch

We used Google Stitch to design an operations console where visual hierarchy reflects actual authority.

AI-generated CandidateEvidence is intentionally visually subordinate.

Independent review receives stronger treatment.

The strongest visual state belongs only to the Deterministic Authority Boundary and its final PROMOTED, DENIED, or REVIEW_FAILED outcome.

This makes the governance architecture visible to the operator instead of hiding it behind a chat interface.

External observer experiment

During development we also connected Gemini Spark to a custom NEXUS MCP bridge as a read-only telemetry sidecar.

The observer ran under:

EXTERNAL_OBSERVE_ONLY

That experiment demonstrates a second separation principle:

even an agent that can observe system telemetry does not automatically receive authority to mutate the governed runtime.

The Spark/NEXUS observer ledger and the contest application's evidence receipts remain separate systems.

What we learned

The biggest lesson was architectural rather than model-specific:

autonomy and authority should not be the same primitive.

Gemini 3.7 Flash and Antigravity made it possible to implement and iterate extremely quickly, but the deterministic gate deliberately remains outside the model.

We also learned that evidence should carry provenance from ingestion through review and promotion; infrastructure state, agent assertions, and model confidence should not silently increase that authority.

Challenges

The project was built under an extremely compressed contest deadline.

That forced us to prioritize:

  • explicit role separation
  • deterministic fail-closed policy
  • provenance receipts
  • reproducible tests
  • deployment evidence

over a much broader feature surface.

The final test suite contains 18 passing tests covering valid promotion, stale evidence rejection, reviewer failure, identity separation, missing evidence, and policy failures.

New-project disclosure

This repository is a new standalone contest-period implementation inspired by the broader NEXUS evidence-governance research program.

Canonical NEXUS internals, private datasets, and private authority infrastructure were not transplanted into the contest application.

Repository

https://github.com/specimba/nexus-evidence-fleet

Built With

Share this project:

Updates

Submission history