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 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 s 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.
Gemini is useful where the problem is semantic:
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:
This separation lets the model help resolve open-world ambiguity without turning model confidence into project authority.
Everbind deliberately separates the recorded Judge transaction from the retained authenticated evidence path.
During the recorded transaction, Cloud Run executes:
The transaction uses fixed, reproducible synthetic schedule fixtures.
A separate authenticated proof bundle demonstrates:
The Gemini/ADK proposal and the Cloud Storage and Firestore proof are retained artifacts rather than freshly generated during the recorded Judge transaction.
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.
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.
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.