How Dulvarn works

Know whether a software release is ready for production.

Dulvarn brings together test results, defects, code changes, approvals and operational readiness, then provides an explainable GO, CONDITIONAL GO or NO-GO recommendation.

Your team keeps control of the final decision. Dulvarn makes the available evidence, risks and required actions visible before software goes live.

See a release decisionFollow the process
Human-controlledExplainable recommendationsAuditable decisions
Release decision process
Release evidence
  • Tests
  • Defects
  • Changes
  • Approvals
  • Rollback readiness
Dulvarn evaluation

Evaluates release rules, detects blockers, identifies missing evidence, recommends required actions.

Decision
GO
CONDITIONAL GO
NO-GO

+ reasons, blockers, required actions

Concept

Think of it as a pre-flight check for software releases.

Before an aircraft takes off, the crew does not rely on a single green signal. They review the aircraft condition, weather, route readiness, flight clearance and emergency procedures.

Only after those checks are considered together can the crew make a GO or NO-GO decision. Software releases need the same kind of complete readiness check.

Pre-flight checks
  • Aircraft condition
  • Weather and external conditions
  • Flight clearance
  • Route and crew readiness
  • Emergency procedure
  • Departure decision
Software release checks
  • Test results and system health
  • Operational and customer risk
  • QA and stakeholder approval
  • Deployment and monitoring readiness
  • Rollback procedure
  • GO / CONDITIONAL GO / NO-GO

A single green signal is not enough.

An aircraft does not take off only because the engine started. A software release should not go live only because CI is green.

Mapping

From take-off readiness to release readiness

Before take-off
Before production release
  • Aircraft condition
    Test results and system health
  • Weather and external conditions
    Operational and customer risk
  • Flight clearance
    QA and stakeholder approval
  • Route and crew readiness
    Deployment and monitoring readiness
  • Emergency procedure
    Rollback procedure
  • Final departure decision
    GO / CONDITIONAL GO / NO-GO

Dulvarn performs this combined readiness evaluation for a software release. The analogy explains the principle — it does not imply that aviation certification and software release processes are legally or operationally identical.

Workflow

How Dulvarn works in practice

Step 1 · Release evidence
Test results
Code changes
Open defects
QA approval
Security checks
Monitoring readiness
Rollback readiness
Step 2 · Dulvarn
  • Evaluates release rules
  • Detects blockers
  • Identifies missing evidence
  • Recommends required actions
Step 3 · Decision
GO CONDITIONAL GO NO-GO INSUFFICIENT DATA
Step 4 · Output
Explanation
Blockers
Warnings
Passed checks
Required actions
Decision record
Definitions

What each decision means

GO

The required evidence is complete and no release-blocking condition was detected.

CONDITIONAL GO

The release may proceed only after the listed checks or actions are completed.

NO-GO

A blocking condition must be resolved before the release should proceed.

INSUFFICIENT DATA

There is not enough reliable evidence to make a meaningful recommendation.

All decisions are advisory. Dulvarn does not guarantee a safe release, approve deployments autonomously, or replace human judgement.

Example

A real example: a checkout release before a marketing campaign

An e-commerce company plans to release an update to checkout and payment processing before a marketing campaign. Here is the evidence Dulvarn evaluates.

Release evidenceCI failed
Release

Checkout and payment validation update

Update checkout validation rules and payment event handling. Multiple critical path failures and no verified rollback.

Test results

937 tests passed

  • checkout.e2e.spec.ts
  • payment-webhook.spec.ts
  • checkout-tax.spec.ts
Status
  • Critical checkout failure for guest users
  • QA approval: Missing
  • Rollback: Missing
  • Monitoring: Failed
NO-GO

This release should not be deployed yet.

Blocking reasons
  • CI pipeline failed
  • Failed tests in critical area
  • Significant coverage drop
  • Critical blocking defect
  • Monitoring not ready
  • Rollback plan missing
What the team should do next
  • Resolve the critical blocking defect before release.
  • Verify the security result before release.
  • Fix the failing CI pipeline and re-run the build.
  • Re-run and fix the failed checkout/payment tests.
  • Document the rollback owner and procedure before release.
  • Review the coverage drop in changed areas.
  • Obtain QA approval for the release scope.
  • Confirm production monitoring readiness.
  • Do not reduce validation because of schedule pressure.

This example uses the built-in demo scenario and the deterministic Dulvarn analyzer. No external API or repository connection is used.

Progression

Dulvarn does not only say “no”. It shows what must change.

NO-GOStage 1

Blocking defects and critical test failures remain.

Resolve hard blockers
CONDITIONAL GOStage 2

Hard blockers are resolved, but QA approval, monitoring or another required check remains incomplete.

Complete mandatory checks
GOStage 3

Mandatory evidence is complete and no hard blocker remains.

Try the progression yourself
Comparison

Dulvarn is not another test dashboard.

  • CI tools(Jenkins, GitHub Actions)

    Run builds, checks and automated tests.

  • Issue trackers(Jira)

    Record defects, tasks and delivery work.

  • Source-control tools(GitHub)

    Show code changes, reviews and merge status.

  • Monitoring tools

    Show the health of running systems.

  • Dulvarn

    Combines the relevant evidence in the context of one release and produces an explainable release recommendation.

Other tools show individual signals. Dulvarn provides the release decision layer above them.

What Dulvarn is not
  • Not a replacement for CI/CD
  • Not a test runner
  • Not an issue tracker
  • Not an autonomous deployment authority
  • Not a guarantee that incidents cannot happen
Value by role

Who benefits and how

QA Lead

  • Sees blockers and missing evidence
  • Understands required validation
  • Avoids manually assembling release status

Engineering Manager

  • Receives one consistent release view
  • Sees ownership and required actions
  • Improves release-decision consistency

Release or Platform Manager

  • Tracks readiness
  • Confirms rollback and monitoring preparation
  • Keeps a reviewable decision history

CTO or Head of Engineering

  • Sees release risk and rationale
  • Improves accountability
  • Understands why a release proceeded or stopped
Technical workflow

Technical workflow

For engineering and QA teams, Dulvarn can apply this decision process to repository, CI, testing and release-policy evidence.

  1. 01
    Connect release sources

    Connect your GitHub repository

    Install or connect Dulvarn to the repository you release from. Dulvarn reads PR metadata, changed files and configured repository policy.

    • repository
    • branch
    • PR metadata
    • release policy
  2. 02
    Configure release rules

    Set release guardrails

    Define thresholds and rules that influence GO, CONDITIONAL GO and NO-GO outcomes.

    • risk threshold
    • test integrity threshold
    • status checks enabled
    • ignored files
    • override policy
  3. 03
    Analyze code changes

    Analyze what changed

    Dulvarn evaluates changed files, affected areas and risky hotspots before the release decision is produced.

    • changed files
    • changed areas
    • touched product flows
    • hotspots
  4. 04
    Collect CI and test evidence

    Collect CI and test evidence

    CI can be green while product risk remains unclear. Dulvarn combines CI state with test integrity and impact signals.

    • CI status
    • test results
    • missing impacted tests
    • coverage gaps
  5. 05
    Evaluate impacted product areas

    Choose the right test scope

    Dulvarn recommends Smoke, Partial non-regression testing (NRT) or Full non-regression testing based on risk, impact and policy.

    • Smoke
    • Partial non-regression testing
    • Full non-regression testing
    • manual checks
  6. 06
    Generate a release recommendation

    Generate GO, CONDITIONAL GO or NO-GO

    The result is a decision summary with reasons, risk score, test integrity score and recommended next actions.

    • GO
    • CONDITIONAL GO
    • NO-GO
    • rationale
  7. 07
    Human review and override

    Human decides, Dulvarn records

    QA or release owner reviews the evidence, approves or overrides the decision with a reason. Every decision is stored in the audit trail.

    • reviewer
    • override reason
    • audit event
    • decision history
  8. 08
    Store the decision record

    Decision record stored

    The release decision, evidence snapshot, reviewer identity and any override reason are persisted as a reviewable record.

    • decision record
    • evidence snapshot
    • reviewer
    • timestamp

Test scope recommendations

Non-regression testing (NRT) verifies that existing functionality continues to work after a change. Dulvarn recommends the appropriate scope based on risk, impact and policy.

Smoke testing

Best for low-risk changes where critical flows are not affected and test integrity is healthy.

Partial non-regression testing

Best for medium-risk changes that affect specific product areas such as checkout, auth or payments.

Full non-regression testing

Best for broad, high-risk releases, failing CI, low test integrity or changes across critical flows.

Integration depth depends on beta setup. Not all integrations are currently production-ready.

Human control

The recommendation is explainable. The final decision remains human.

  • Dulvarn shows the evidence used.
  • Dulvarn shows which rules passed, warned or failed.
  • The team can review the recommendation.
  • An override should include an explicit reason.
  • Decisions and overrides can form a reviewable history.

The public sandbox demonstrates the recommendation and progression logic. Full audit-trail persistence is a platform capability — the public demo does not store decisions beyond the current session.

See the release decision process yourself.

Open a prepared GO, CONDITIONAL GO or NO-GO scenario, then change the evidence and watch the recommendation update.

Open the Release Risk SandboxRequest a release-process review

The public sandbox uses demo or manually entered information and does not connect to your repository or CI system.