Observed
Relevant production-safety evidence is visible in the reviewed code and pull-request context.
Confirm that the evidence is active, correctly placed, and applicable to the changed path.
Documentation · Reports
Read Qedix evidence without over-trusting it.
A Qedix report organizes production-safety evidence around a pull-request change. It helps maintainers focus review, but it does not replace tests, security assessment, or final engineering judgment.
Recommended review sequence
Review freshness and context before acting on an individual finding.
- 01
Confirm repository and pull request
Make sure the report belongs to the repository and pull request your team intended to review.
- 02
Confirm the analyzed commit
Compare the report commit with the current pull-request head. New commits can make an older result stale.
- 03
Read the recommendation
Use the recommendation as a review summary, not as automatic approval or a deployment decision.
- 04
Inspect evidence and affected code
Review the visible control, missing proof, affected file, and relevant changed context together.
- 05
Perform the suggested verification
Run or review the recommended tests and checks using your application and environment.
- 06
Make the maintainer decision
Combine Qedix evidence with tests, code review, security review, staging, and application knowledge.
Evidence states
Evidence states communicate what was visible in the reviewed pull-request context.
Not proven
Qedix did not find enough visible evidence to establish the expected safety control.
This is not proof that the control is absent. Check wrappers, runtime configuration, external policy, and application context.
Review
The change requires application-specific judgment or verification before a conclusion can be reached.
Review the affected code and perform the recommended validation.
What a report contains
Read each part as supporting context for the recommendation.
Pull-request context
Repository, pull request, commit, status, and analysis timing help establish whether the report is current.
Recommendation
A concise advisory conclusion that summarizes the visible production-safety evidence and review attention.
Affected code
File references and limited changed context help maintainers locate the relevant pull-request path.
Evidence explanation
The visible control, unproven assumption, potential impact, and reason for review are presented together.
Suggested verification
Focused tests, review questions, or operational checks that the team should perform.
Analysis status
Indicates whether analysis is queued, running, completed, or unable to complete successfully.
Interpret recommendations carefully
Recommendation labels prioritize review; they do not make the release decision.
Clean or low-risk result
The reviewed context did not produce evidence requiring a stronger recommendation.
Continue normal tests, review, staging, and deployment controls.
Review recommended
One or more production-sensitive changes require maintainer attention, additional evidence, or focused verification.
Review the evidence before deciding whether the pull request is ready to merge.
Suggested tests are not execution results
Qedix may recommend verification, but the team must perform and evaluate it.
A suggested test describes evidence that would help verify the changed behaviour. It does not mean Qedix ran the application, executed the test suite, reproduced the environment, or confirmed the test outcome.
When a result looks wrong
Use application context to verify whether the evidence is incomplete, stale, or not applicable.
Check report freshness
Confirm that the analyzed commit matches the current pull-request head after force pushes, rebases, or new commits.
Look for external controls
The expected control may exist in infrastructure, middleware, configuration, a wrapper, or another path not visible in the reviewed change.
Review the actual code path
Confirm whether the affected file and changed operation are reachable in the production behaviour your team is evaluating.
Report useful context
When contacting support, provide the repository, pull-request number, commit, evidence title, and why the result appears incorrect. Do not send credentials.