How I built Everbind: keeping project commitments alive across schedule revisions with Gemini and Google Cloud

Mi — Mon, 31 Aug 2026 22:13:00 +0000

This article was created as part of Everbind’s submission to the All Things Agentic Hackathon.

The activity changed. The commitment didn’t.

A routine schedule revision can retire Activity A and replace it with Activities B and C. A schedule comparison can show that A was retired and B and C were added, but it does not by itself establish which new work inherits A’s existing commitment.

That leaves a dangerous gap: the work may remain visible in the revised schedule while the obligation is left without a verified successor.

Everbind treats that moment as a governed project transaction—not as an “AI approved” answer.

The transaction

The demo begins with Revision 17 as the Current Accepted Schedule and Revision 18 as an incoming contractor submission.

In Revision 17, Activity A is the verified carrier of Commitment C-17: Pier 68 cofferdam in-water completion by January 23. Revision 18 retires A and divides the work into an enabling-access activity and an in-water completion activity.

Gemini, orchestrated through Google ADK, proposes possible lineage using a closed schema tied to retained evidence and known activity IDs. Its proposal is advisory.

When the submitted package does not prove which replacement activity inherits Commitment C-17, Everbind abstains. It pauses acceptance and prepares a clarification request instead of inventing continuity.

After the contractor supplies clarification, the reviewer records the evidence-backed lineage basis. The reviewer is not redesigning the contractor’s means and methods; they are recording what the submitted evidence says the replacement work represents.

Only then does deterministic CPM recompute the revision.

Revision 18 places the inherited in-water completion activity on January 27—four days after the January 23 commitment, with zero float. Everbind therefore prepares schedule-review comments and leaves Revision 17 unchanged as the Current Accepted Schedule.

Revision 19 corrects the sequence and finishes three days early. Even then, a favorable calculation cannot apply itself. An authorized reviewer—represented by a named synthetic authority in this fixture—must accept the exact reviewed bytes.

The accepted schedule record changes once. A separate Python process then reconstructs the transaction from retained bytes and emits a replayable receipt.

Why the model is bounded

Gemini is useful where the problem is semantic:

identifying possible continuity between old and new activities;
classifying the submitted event;
proposing bindings to known project objects;
identifying the evidence that is still missing.

But model output is not accepted as authoritative schedule dates, authorization, contractual entitlement, or permission to mutate the accepted schedule record.

Those decisions remain outside the model:

evidence binding and known-ID validation;
commitment effectivity and lineage state;
deterministic schedule-network evaluation;
authority validation;
eligibility and mutation rules;
one authorized accepted-state transition;
independent reconstruction from retained bytes.

This separation lets the model help resolve open-world ambiguity without turning model confidence into project authority.

Google Cloud architecture

Everbind deliberately separates the recorded Judge transaction from the retained authenticated evidence path.

Recorded Judge transaction

During the recorded transaction, Cloud Run executes:

lineage and abstention state transitions;
clarification and evidence-recording steps;
deterministic CPM recomputation;
eligibility and human-authority gates;
one accepted-schedule transition;
independent cold replay.

The transaction uses fixed, reproducible synthetic schedule fixtures.

Authenticated retained evidence path

A separate authenticated proof bundle demonstrates:

Vertex AI and Google ADK producing a closed-schema Gemini proposal;
Cloud Storage retaining create-only evidence bytes with a pinned generation;
Firestore retaining a create-only manifest that binds source hashes, semantic output, deterministic analysis, and before/after state;
a read-only Cloud Run verifier checking the retained bundle.

The Gemini/ADK proposal and the Cloud Storage and Firestore proof are retained artifacts rather than freshly generated during the recorded Judge transaction.

Multimodal bonus path

After acceptance, Everbind can generate a receipt-bound, non-binding visual change brief using Gemini Image and Veo, with Vision QA and retained Gemma execution evidence.

These assets are presentation support only. They do not participate in commitment lineage, schedule evaluation, authorization, or accepted-state mutation.

What I learned

The difficult part was not generating a persuasive explanation. It was preserving the boundaries between proposal, evidence, calculation, authority, mutation, and proof.

Three lessons mattered most:

Abstention needs an executable next step.

“Not enough evidence” is useful only when it creates a controlled path for obtaining the evidence that changes the decision.
A passing calculation is not permission to mutate accepted state.

Eligibility and authority are separate questions.
Verification should reconstruct the decision from retained bytes.

It should not trust the browser state—or the runtime—that displayed the result.

Everbind

Repository: https://github.com/miemiemi2/everbind

Everbind is a bounded synthetic owner-side fixture. This release does not claim native P6/XER ingestion, production-grade identity, live contractor or CDE integration, legal or contractual effect, practitioner validation, or fresh model generation during the recorded Judge transaction.

DEV Community: Mi