Public operating doctrine
GoSentrix is release-evidence verification software for consequential software delivery. These are the rules our product enforces on evidence and the rules we enforce on ourselves. A verification layer that cannot be checked against its own standard is not a verification layer; it is a vendor with a thesis.
Modern software delivery does not have a detection problem. It has an evidence problem.
AI agents, scanners, test systems, workflow tools, and policy engines now generate more security claims than teams can govern. The important question is no longer what a tool said. It is whether the evidence behind a software decision is strong enough to support that decision — and whether the basis for the decision can be reproduced and explained later.
A category that calls itself verification needs to be checkable. So we wrote down what we will and will not do, and we apply the rules to ourselves first.
GoSentrix qualifies evidence from existing security, engineering and workflow systems.
It evaluates that evidence against versioned customer-defined policy.
It produces explicit outcomes: proceed, stop, escalate, or require authorization.
It preserves the basis for every explicit release decision.
It does not set the organization’s risk appetite. It verifies whether the available evidence is strong enough to support the requested action.
These are not preferences. They are applied to our own marketing the same way they are applied to a scanner finding. Each one exists because the opposite behavior is how verification claims silently collapse into vendor opinion.
1.
Every claim about our capability, coverage, or maturity is tied to evidence. If we cannot show it, we do not say it.
2.
The evidence, policy version, and reasoning behind each decision are preserved so the decision can be reviewed and defended later.
3.
These are independent dimensions. Collapsing them produces a number that looks like authority but cannot be defended.
4.
If required evidence is insufficient, we escalate. The escalation is recorded.
5.
Dismissing a finding is not the same as proving it does not apply. Disproval requires evidence that the finding is invalid in context. We make the distinction structurally.
6.
AI judgment, scanner confidence, and severity scores can enter the evidence ladder. They cannot terminate it.
7.
"Battle-tested," "production-proven," and "deployed at scale" are claims about authority earned in real customer conditions. We use them only when a specific customer field event evidences them.
8.
Scanners, AI agents, runtime systems, and workflow tools are the sources we work from. They produce signals. We determine what those signals are allowed to become. The distinction is structural, not adversarial.
Every signal that enters GoSentrix begins as an unverified claim. It does not become authoritative by being severe, by being detected with high confidence, or by being asserted by an AI agent. It becomes authoritative by being qualified through governed evidence states, on the strength of corroboration from independent sources.
States cannot be skipped unless the source is explicitly trusted to support the target evidence level. Qualification strength is a function of source diversity, not signal count.
Suppression is not disproval. Disproval requires evidence that the finding is invalid in context.
Operator actions on findings are recorded as evidence inputs to the next verification round. They are not terminal closures.
AI-provenance signals are capped at the DETECTED evidence level unless independently promoted by non-probabilistic evidence.
Every consequential decision GoSentrix produces is designed to be reviewable against the evidence and policy version active at the time the decision was made. Later policy changes do not retroactively change a past decision's authority.
The evidence and policy active at the time are preserved with the decision.
Decisions are bound to the policy version active at the time. Policy updates do not retroactively re-grade history.
Proceed, stop, escalate, or require authorization — each with recorded reasoning.
Cryptographic attestation, content-addressing, and deterministic bundle identifiers are architecture targets, not field-proven claims.
The doctrine is not a marketing narrative. It is expressed in product behavior: governed evidence states, policy-version binding, explicit escalation, and decision-history preservation.
Governed evidence states prevent a signal from being promoted beyond what its source can support. A scanner detection cannot become a validated fix without corroboration. An AI-generated claim cannot terminate verification without independent non-probabilistic evidence. Human attestation can strengthen evidence, but it is also recorded and can itself be challenged.
Policy-version binding means every decision record includes the policy version that applied. If a customer changes their policy, new decisions are evaluated under the new version; historical decisions remain judged by their original standard. This is essential for auditability and for honest post-incident review.
Explicit escalation means that insufficient evidence does not silently become approval. The system returns escalate or require authorization, records the missing evidence, and notifies the right owner. The default is not "trust the process"; it is "show the evidence."
Decision-history preservation means the evidence bundle, policy snapshot, reasoning, and outcome are stored together. A decision can be revisited months later without relying on memory, chat logs, or the continued employment of the person who approved it.
Consider a regulated team shipping a change to a payment-processing service. The change includes an AI-generated fix for a secret-exposure finding. The developer closes the ticket after the secret is removed from the repository.
Under the doctrine, this sequence is not enough. GoSentrix asks: was the secret rotated? Is there evidence that the exposed credential no longer grants access? Was the AI-generated change reviewed by a human, and is that review bound to the release candidate? Does the active policy version require runtime observation or a second independent check?
If the evidence satisfies policy, the decision is proceed with a preserved record. If not, the outcome is escalate. The team cannot claim the risk was retired simply because the ticket was closed.
Every claim GoSentrix makes about itself is assigned an evidence status. A claim cannot appear on a surface that demands more evidence than it has earned. The pilot below describes what we have verified in controlled conditions and what we do not claim.
Controlled pilot
A controlled pilot with anonymized participants tested whether release-evidence verification could replace manual review assertion with qualified, policy-bound evidence.
Release reviews relied on manual assertion: developers marked tickets closed, reviewers scanned checklists, and approvers relied on verbal assurance. Evidence was scattered across scanners, CI logs, ticketing systems, and chat threads.
Whether the evidence behind each release decision satisfied the customer’s versioned policy. We qualified scanner output, reviewer attestations, and AI-generated change records; flagged approvals unsupported by evidence; and preserved the reasoning for each verdict.
Policy-bound decision records, qualified evidence bundles, and explicit escalation notices for insufficient proof. Each record links the release candidate to the evidence evaluated and the policy version active at the time.
Reviewers spent less time reconstructing what had been checked. Instead of chasing evidence across systems, they reviewed a single, qualified evidence summary and the policy evaluation that followed.
Proceed, stop, escalate, or require authorization — with a recorded basis. Teams could release with confidence when evidence satisfied policy, and escalate transparently when it did not.
The preserved decision record supports audit requests, post-incident review, and regulated-release documentation. It shows what was known, what policy applied, and why the outcome followed.
Read the full doctrine on what we will and will not claim.
A verification layer that cannot be checked against its own standard is not a verification layer; it is a vendor with a thesis. Publishing the doctrine makes our claims contestable and our product behavior predictable.
Dismissing a finding is not the same as proving it does not apply in context. Disproval requires evidence that the finding is invalid for the specific artifact. Suppression without disproval evidence is not a terminal state.
The doctrine is implemented through governed evidence states, policy-version binding, explicit escalation for insufficient evidence, and decision-history preservation. Marketing claims are also assigned evidence statuses.
Yes, but exceptions must be explicit, authorized, and recorded. An exception is itself a decision with a preserved basis: what policy was waived, why, by whom, and under what evidence conditions.
Yes. Customers define their own policy. GoSentrix evaluates evidence against the customer-defined policy version active at the time of the decision. Policy changes do not retroactively rewrite past decisions.
The definition and mechanics of release-evidence verification.
Definitions for policy-version binding, proof artifacts, and more.
How to make release decisions that can be defended later.
Move from ticket closure to verified remediation evidence.
Definitions for policy-version binding, proof artifacts, defensible release decisions, and more.
Evidence can be uncertain. Policy evaluation must be reproducible, and insufficient evidence must be escalated.
We do not claim authority we cannot evidence.
