Files · exact lines · commit SHA · trust status
ProofGit + ProofMEMSeparate authorities
Know what the code does.
Remember why it does it.
ProofGit supplies current, source-cited repository evidence. ProofMEM preserves the approved decisions and constraints that should survive the session. Caveau Harness assembles both for planning and implementation—without turning either into the other.
ProofGit is available now. ProofMEM is invite-only and currently free during its beta. Accounts, credentials, and subscriptions remain separate.
task / 01Objectives · constraints · decisions · lessons
02 / Task assembly
One task. Six visible hand-offs.
- 01Ask the engineering questionArchitecture, behavior, a bug, a review, or a change plan.
- 02Recall governed memoryProofMEM returns approved context for the active scope.
- 03Retrieve repository evidenceProofGit returns current explanations and exact supporting source.
- 04Keep the sections separateCaveau Harness labels repository evidence distinctly in PLAN and WRITE.
- 05Review the proposed workA person checks intent, evidence, tests, and the resulting change.
- 06Accept a bounded pointerIf approved, memory may retain the decision and an evidence reference—not copied code.
03 / Alone and together
Use only the authority the work needs.
The pairing is valuable when a task depends on both current implementation and retained intent. It is not a reason to make every workflow more complicated.
“What does this repository do now?”
Choose ProofGit when source evidence, repository structure, code review, or fleet visibility is the job.
“What have we approved and learned?”
Choose ProofMEM when scoped continuity, approved decisions, or durable agent context is the job.
“What does the code do—and why did we choose it?”
Use both when the model must compare current code with approved constraints without confusing evidence for instruction or memory for source.
04 / Pilot record
Ten tasks. One bounded repository. Every acceptance check met.
In the internal Trivia & Tunes pilot, all ten tasks met the defined acceptance checks across architecture discovery, behavior explanation, bug location, change planning, code review, and cross-session continuation.
No private code, prompts, repository identifiers, tokens, customer data, or performance claims are disclosed by this summary.
05 / Authority boundaries
Useful together because they do not become one system of truth.
01No automatic memory writes
Evidence retrieval does not silently create a durable decision. Acceptance remains explicit.
02No copied source bundles
ProofMEM may retain a bounded evidence pointer after approval, not source lines or an entire evidence response.
03No shared login or entitlement
ProofGit and ProofMEM remain standalone products with separate credentials and subscriptions.
04No automatic drift detection
The workflow can expose disagreement between remembered intent and current code; it does not claim to monitor or resolve drift by itself.
05No “single source of truth” claim
Repository state and approved organizational context are deliberately different authorities with different review paths.
06Repository content is untrusted input
Quoted code evidence informs the task. It is never treated as an instruction that can override the plan or human review.
Start with current code
Prove what.
Then preserve why.
Begin with a card-backed 14-day ProofGit trial. Bring ProofMEM in when the work needs approved context to survive beyond one session.