The verification act at pull request
Has the evidence earned the right to merge?
At every pull request, scanners, AI review agents, and policy engines produce a set of claims. GoSentrix treats each as unverified. It promotes evidence under doctrine, evaluates it against the active policy version, and produces a merge readiness decision that can be replayed and defended later.
What enters
A pull request typically arrives with a mix of signals:
- SAST, DAST, SCA, and container scanner findings — each in its own format, each with its own confidence model
- AI review-agent claims, often with high stated confidence and no corroborating source
- Open findings from prior runs of the same scanners, in varying evidence states
- AI-provenance hooks on the commits themselves — which code was AI-generated, which was human-authored, which was edited after AI generation
- Threat model context for the service the PR touches
All of these are claims. None are evidence until promoted.
How GoSentrix verifies
Step 1
Normalize.
Pioneer takes each scanner output and AI-agent claim as an unverified input and produces a normalized claim ready for promotion.
Step 2
Promote.
Findings move through governed evidence states — detected, observed, corroborated, validated. Promotion happens only on independent corroboration. Promotion strength is a function of source diversity, not signal count. Two findings from the same scanner do not double the confidence.
Step 3
Evaluate.
Cassini evaluates the promoted evidence against the policy version active at the time of the pull request. The policy version is bound at evaluation time; it will not change underneath this decision later.
Step 4
Decide.
The gate emits one of four states:
- PASS — cleared to merge
- WARN — advisory, noted on record
- SOFT_BLOCK — requires authorization
- HARD_BLOCK — stops unsafe merge; cannot be issued on severity or AI confidence alone
Step 5
Downgrade if proof is missing.
If the decision requests HARD_BLOCK without the required evidence to support it, GoSentrix downgrades the decision automatically and records the downgrade reason. The operator cannot reverse the downgrade without supplying the missing evidence.
What is produced
Which claims this proof supports
What this does not do
Merge readiness verification does not establish runtime enforcement. It does not establish cross-organization policy distribution. It does not prevent every class of risk — only those for which sufficient evidence is available to produce a defensible decision under the active policy version.
Where field-proven authority is not yet established, this page reflects that. GoSentrix has merge-readiness verification architecture implemented. Field-proven authority across customer environments is not yet established.