Neighbor probe: ProofPR → CounterProof → Fowlcon as a reviewer evidence chain?

[hippoley]

This is a collaboration probe, not a proposal that any project should absorb another one.

Verified neighbors:

• ProofPR: https://github.com/linsk-labs/proof-pr
• Fowlcon: https://github.com/mpawliszyn/fowlcon

The useful question is whether one small claim/evidence artifact can move between these review stages without any tool taking authority it does not own.

1. ProofPR — PR intake / evidence presence

ProofPR is a deterministic PR triage gate. It already has first-class:

• EvidenceContract
• EvidenceRequirement
• EvidenceScore
• ReviewDecision (ready / review-carefully / needs-evidence / block-merge)
• JSON output

Important correction to the earlier wording: ProofPR does not currently have a generic external CounterProof-receipt ingestion path. Its evidence contracts currently infer signals such as verification, reproduction, screenshot, changelog, and permission-rationale from PR text/diff/test signals.

So the real interoperability question is narrower:

when ProofPR requires verification, can an auditable external executable receipt strengthen or satisfy that requirement without turning ProofPR into an execution engine?

2. CounterProof — what does the executable evidence actually establish?

CounterProof keeps evidence scope explicit:

claim                         evidence                 status
original regression           BASE fail / HEAD pass   WITNESSED (submitted judge)
atomic write durability       no exercising test      UNPROVEN
product oracle disagrees      product probe           CONTRADICTED

It carries candidate SHAs, exact tests/probes, provenance, digest, and scope limits. It does not decide whether a PR is ready for review or whether the PR should merge.

3. Fowlcon — reviewer comprehension

Fowlcon organizes a PR into concepts and keeps human reviewer states separate (pending / reviewed / accepted). Its Description Verification section already has Claim | Status | Evidence.

The possible chain is therefore:

ProofPR
  "is enough review evidence present to spend maintainer time?"
        ↓
CounterProof
  "what does this executable evidence actually prove?"
        ↓
Fowlcon
  "present the claims and code in a human review walkthrough"
        ↓
human judgment

What not to build yet

• no shared runtime
• no integration SDK
• no aggregate cross-tool score
• no automatic approve/reject
• no new Fowlcon status vocabulary

Smallest Reality Probes

ProofPR

Take one existing Evidence Contract requiring verification. Compare:

1. PR prose merely says tested;
2. PR carries a CounterProof receipt bound to exact HEAD, exact test, BASE/HEAD result, digest, and scope limit.

Ask whether case 2 should change ProofPR's intake decision or evidence explanation.

Fowlcon

On one real PR, attach one CounterProof receipt to one existing description claim/concept. Measure whether the reviewer avoids repeating an evidence check without confusing executable evidence with reviewed / accepted.

If either experiment produces no real review benefit, we should stop rather than build adapters.

[mpawliszyn]

Note that I don't consider Fowlcon to be in a usable state right now. I'm back to trad-coding with friends right now. (So much fun!) I fully intend to get back to it at some point right now.

Fowlcon's status is meant to be the review status rather than specific functionality claims although those could be related, I suspect that they probably are different fields on a concept claim. That or they might be different projections on the same PR? They could feed each other for sure.

I assume you had some AI help with the above which is fine but I'm more curious what the humans think more directly on the topic.

Would a small, tool-neutral claim/evidence receipt be useful at either boundary, or is this composition cleaner on paper than in an actual reviewer workflow? I don't know how we will find out without trying it out? It seems reasonable to try though. At worst there might need to be some kind of adapter. Fowlcon is intended to be built in a way that devs can adapt it to whatever situations they need to address which would include your case. I have no idea how successful that would be in practice without trying it.

What are you hoping to achieve wrt this probe beyond "collaboration"? Or is this meant to get similar projects talking?

[hippoley]

@mpawliszyn — yes, the point is more specific than “get similar projects talking.”

What I want to learn is whether a reviewer can avoid re-doing evidence work when the same PR moves between tools.

The concrete hypothesis is:

if one tool already established “this exact claim is red on BASE / green on HEAD, with these limits,” a downstream review tool should be able to carry that fact forward without turning it into an overall approval.

So the success condition is not “we integrated Fowlcon.” It is something much smaller: on one real PR, does attaching a CounterProof claim/evidence receipt to a concept/claim save a human reviewer from re-running or re-reading the same proof, while still keeping Fowlcon’s own review status separate?

Your note that Fowlcon is not in a usable state right now is useful — I don’t want to push an adapter against an inactive surface. I’ll treat this as a boundary hypothesis, not an integration task.

When you get back to Fowlcon, the smallest experiment I’d want is one existing PR + one concept claim + one external receipt URL/digest. If that does not reduce any human review work, we should kill the idea rather than build glue around it.

And yes, AI helped me organize the earlier mapping. The part I care about validating is the human workflow outcome above, not whether the architecture diagram looks neat.

[hippoley]

@linsk27 @mpawliszyn — I re-checked both projects and tightened this probe to their actual current contracts.

For ProofPR, the interesting gap is now concrete: EvidenceContract can require verification, but current satisfaction is inferred from PR text/diff/test signals. CounterProof can instead carry a candidate-bound executable receipt (head_sha, exact test/probe, BASE/HEAD, digest, scope limit).

So the ProofPR question is simply: should that kind of receipt count as stronger intake evidence than prose that merely says “tested”, or is executable-proof provenance intentionally outside ProofPR's boundary?

For Fowlcon, I am keeping the experiment dormant until the project is active again: one existing concept/description claim + one external receipt, then measure whether a human reviewer actually avoids repeating the evidence check.

No adapter code is being proposed until one of those workflow effects is confirmed.