Declare producers
Each adapter declares the evidence types and statuses it can emit. Internal platforms, test systems, scanners, and runtime tools all speak through the same vocabulary.
Ingest evidence
Raw outputs become native Veridion evidence. Translators can be first-party or owned by your platform team in whatever language fits the source system.
Decide consistently
Validated evidence flows into policy and produces GO, CONDITIONAL GO, or NO GO with required approvals, next steps, and a machine-readable decision contract.
Every company has different gates.
Veridion gives them consistent meaning.
Existing systems say
The test failed. The check is pending. The scanner found a CVE. The incident is active. The approval is stale.
Veridion asks
Does this evidence block, condition, or allow this specific release under the organization’s policy?
The acceleration
- Every service has different tests, checks, owners, and runtime gates
- Internal platforms produce custom validation signals
- Security, CI, SRE, and compliance tools disagree on language
- Release velocity is outpacing manual decision coordination
The control problem
- Which signals are required for this release?
- Which producer emitted the evidence?
- Is the evidence valid, fresh, and tied to this commit?
- Does policy require a block, review, or approval?
-
Catalog signal meaning
Canonical statuses and evidence types keep every adapter aligned. Failed, missing, degraded, stale, and unsatisfied mean the same thing across producers.
-
Declare producer capability
Producer manifests describe who emits a signal, which evidence types are possible, which statuses can appear, and which subject identifiers attach to the release.
-
Ingest and conform
Raw outputs from JUnit, GitHub checks, scanners, runtime systems, and custom tools are translated, validated, and checked against the producer manifest.
-
Emit a decision contract
Policy evaluates the normalized evidence and emits a stable contract for PR comments, deployment gates, approval routing, audit, and downstream automation.
GO
94
Docs-only change
No introduced findings. Low-friction approval path. High-confidence release decision.
CONDITIONAL GO
74
Required load test missing
The producer declared the load test as required, but no fresh evidence was emitted for this commit. Release requires review.
NO GO
38
Critical dependency + failed e2e
Introduced dependency risk and required validation failure both block release until remediation or approved exception.
CONDITIONAL GO
81
Accepted-risk suppression
Known risk accepted temporarily with reason and expiry. Visibility stays intact and the release posture remains cautious.
Introduced dependency risk
The first install path stays focused: Syft, Grype, Trivy, baseline comparison, accepted-risk metadata, and deterministic release decisioning for PRs.
Evidence gateway
Native evidence JSON, producer manifests, catalog validation, conformance checks, and local translators let teams bring their own release signals without custom product work.
Machine-readable decisions
Every run emits `veridion-decision.json`, a stable contract for workflow gates, approval routing, accepted-risk review, audit, and internal platform automation.
Signals should have consistent meaning
Adapter authors should be able to declare a producer, ingest raw output, validate native evidence, and prove conformance before the decision engine sees it.
Output should feel like a decision memo
Dependency risk, test evidence, baseline quality, accepted risk, approvals, confidence, and next steps should be scannable without opening raw tool logs.
Start with dependency risk.
Bring the rest of your signals next.
Use the quickstart for the first PR gate. Use the Evidence Gateway when your platform team is ready to connect tests, checks, runtime metrics, approvals, and internal validation systems.
veridion-bootstrap --preset dependency-risk-v1