• 

• 

Everbind

The activity changed. The commitment didn’t.

Construction schedules are rewritten throughout a project. An activity may be retired and replaced by several new activities. Schedule comparison can show what was deleted and added, but it does not by itself establish which replacement work inherits an existing project commitment.

That gap matters. If commitment continuity is unresolved, accepting the new schedule can allow a real project requirement to silently fall out of the review process.

Everbind is an owner-side schedule-revision review agent that prevents that from happening.

The problem

In the demo, Revision 17 is the Current Accepted Schedule. Activity A is the verified carrier of Commitment C-17: Pier 68 cofferdam in-water completion by January 23.

The contractor then submits Revision 18. Activity A is retired and the work is divided into two new activities: enabling access and in-water completion.

The structural change is visible, but the submitted package does not prove which replacement activity inherits the January 23 commitment.

A language model could guess. Everbind refuses to.

What Everbind does

Gemini 3.5, orchestrated through Google ADK, proposes possible lineage using a closed schema tied to retained evidence and known project activity IDs. The proposal is advisory rather than authoritative.

Because the evidence is ambiguous, Everbind pauses acceptance and prepares a targeted schedule clarification request. It asks for the one missing fact that changes the decision: which replacement activity now carries Commitment C-17?

After a controlled contractor clarification is loaded, 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 the deterministic schedule engine recompute Revision 18.

The inherited in-water completion activity finishes 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 must accept the exact reviewed bytes before Revision 19 can become the unique accepted successor.

A separate cold-replay process then reconstructs the transaction from retained source, schedule, lineage, authorization, and state bytes.

Why this is more than document search

The hard part is not finding a sentence in a document.

The hard part is preserving a project commitment when the schedule objects carrying it change across revisions:

• Is the commitment still effective?
• Has it been superseded?
• Which new activities inherit it?
• Is the submitted evidence sufficient to establish that lineage?
• Who has authority to record or accept the result?
• Does the revised network actually satisfy the commitment?
• Did the rejected candidate leave the accepted schedule untouched?
• Can another process reconstruct the same result from retained bytes?

Everbind turns those questions into a governed state transaction rather than an “AI approved” answer.

How I built it

Everbind separates five responsibilities:

1. Gemini and Google ADK propose semantic lineage.
   The model identifies possible continuity and missing evidence, but its output cannot directly change accepted project state.

2. Governed commitment continuity preserves the obligation.
   Source, scope, effectivity, authority, supersession, and lineage remain explicit across schedule revisions.

3. Deterministic rules evaluate the revision.
   Schedule dates, float, commitment compliance, eligibility, and protected drift come from deterministic code—not model confidence.

4. Human authority changes accepted state.
   An eligible revision remains ineffective until an authorized reviewer accepts the exact reviewed package.

5. A separate process proves the result.
   Cold replay reconstructs the transaction from retained bytes rather than trusting the browser or the runtime that displayed the verdict.

The Google Cloud evidence path uses Vertex AI and Google ADK for closed-schema Gemini triage, Cloud Storage for create-only evidence bytes, Firestore for a binding manifest, and Cloud Run for the recorded transaction and read-only verification path.

The recorded demo uses fixed, reproducible synthetic schedule revisions. The governed transaction, deterministic recomputation, authority gate, accepted-state transition, and cold replay execute during the recorded flow. The Gemini/ADK semantic proposal and authenticated Cloud Storage and Firestore evidence bundle are retained artifacts rather than freshly generated during the recording.

Challenges I faced

The first challenge was avoiding false confidence. A plausible model mapping is not evidence, so ambiguity had to produce abstention and a controlled clarification path rather than an automatic binding.

The second challenge was preventing a passing calculation from becoming permission. Eligibility and authority had to remain separate.

The third challenge was preventing rejected candidates from contaminating accepted state. Revision 18 remains available in review history, but it produces zero accepted-schedule mutations.

The final challenge was verification. The proof path could not merely trust the same UI or runtime that claimed success; it had to reconstruct the transaction from retained bytes.

What I learned

1. 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.

2. A passing calculation is not permission to mutate accepted state.
   Eligibility and authority are different questions.

3. Verification should reconstruct rather than trust.
   A receipt is meaningful only when another process can reproduce it from retained inputs.

What’s next

The current release is a bounded owner-side fixture. Future work would add native P6/XER ingestion, production identity and authorization, live contractor or common-data-environment integration, broader activity lineage, and practitioner validation.

Everbind does not claim legal, contractual, permit, entitlement, payment, or production effect.

Schedules get rewritten. Project commitments should not disappear with them.

Built With

• docker
• fastapi
• firestore
• javascript
• pydantic
• pytest
• python
• uvicorn