Release Evidence Package

Release Evidence Package: DEMO-1.0.0 Final

Group by

Order

Claims in this release

across 3 tickets and 3 severity bands

Worst band present Not met (1)

Distribution by severity band

Not met114%Noted114%Met571%

Testing process

Validation5 claims

Verification2 claims

Release Summary

Release

DEMO-1.0.0

Trigger

release/DEMO-1.0.0 branch opened

Assembled

2026-10-10, 21:33 UTC

Scope

3 tickets included: every ticket carrying Fix Version DEMO-1.0.0; all closed

Validation

Aligned 2 tickets
Discrepancy 1 ticket

Unrequested changes noted on 1 ticket

Verification

Aligned 2 tickets
Nothing to Verify 1 ticket

Declared test suite

Unit

How code was found

Every code location here was reached by static analysis - a test that imports a symbol and names it, or the symbols its own file calls, or a symbol a file it imports declares. Code at the top of its own call chain is outside all three: nothing imports it, and nothing already reached calls it - a command-line entry point, a handler a framework invokes by configuration, a job a scheduler runs. Such code may be thoroughly tested and will not appear in this report, so silence about it is a limit of this discovery method rather than a finding about the software.

Dovada does not recommend GO or NO-GO. The evidence in this package is provided to support that decision.

Claims

Not met 1

Not Met DEMO-102 A Slack message is sent only when a release actually closes Validation

Verdict	Not Met
Reasoning	Demo content seeded for KAN-487 - not a real model assessment.
Cited evidence	closeRelease() posts to Slack on every call, including the no-op path where the release was already closed - it does not check whether its own UPDATE changed a row first.

Noted 1

Unrequested DEMO-103 Also renamed max_concurrent_paid_calls to concurrency_limit in the example config Validation

Verdict	Unrequested
Reasoning	Demo content seeded for KAN-487 - not a real model assessment.
Cited evidence	config/dovada.example.yaml renames the key nothing in this ticket asked for it.

Met 5

acceptance criteria and behaviours met. Nothing here needs a decision.

Met DEMO-101 A test exercises writing one CSV row per audit event, in order Verification 1 covering

VerdictMet

Reasoningexport-csv.test.ts’s "produces one row per audit event, in event order" asserts the output rows match a three-event fixture’s own order - the same behavior Validation confirmed, now backed by a real test.

Symbol

Code location

Verdict

Why

exportAuditLog

src/audit/export-csv.ts

Met

1 covering test

Test	Test Type	Judged	Outcome	Release branch	Runs	Path
produces one row per audit event, in event order	Unit	judged meaningful		passed demo00000000	not cited by this verdict	src/audit/export-csv.test.ts

1 test is linked to this location and was judged not to exercise this code.

Met DEMO-101 A value containing a comma or a newline is escaped so the file still opens as one column per field Validation

Verdict	Met
Reasoning	Demo content seeded for KAN-487 - not a real model assessment.
Cited evidence	export-csv.ts quotes any field containing a comma, a newline or a quote.

Met DEMO-101 Export produces one row per audit event, in event order Validation

Verdict	Met
Reasoning	Demo content seeded for KAN-487 - not a real model assessment.
Cited evidence	export-csv.ts writes rows in the order it reads them from the log.

Met DEMO-102 A test exercises sending a Slack message when a release closes Verification 1 covering

VerdictMet

Reasoningpersist-release-closure.test.ts’s "notifies Slack on a real close" asserts the Slack call fires when a release actually closes - it does not assert the call is absent on a no-op close, which is the gap Validation’s own finding names.

Symbol

Code location

Verdict

Why

closeRelease

src/release-assembly/adapters/release/persist-release-closure.ts

Met

1 covering test

Test	Test Type	Judged	Outcome	Release branch	Runs	Path
notifies Slack on a real close	Unit	judged meaningful		passed demo00000000	not cited by this verdict	src/release-assembly/adapters/release/persist-release-closure.test.ts

Met DEMO-103 Each spend-ceiling key’s default and unit are documented Validation

Verdict	Met
Reasoning	Demo content seeded for KAN-487 - not a real model assessment.
Cited evidence	AR-016 now states the default and unit for every spend-ceiling key.

Coverage Observations

The question. The one Verification puts to the model: given the code the change touches and the tests linked to it, what test does not appear to exist?

How far Dovada looks

In this release, 1 of 3 judgments about linked tests (33%) found the test does not exercise the code it is linked to. A link says a test can reach the code, not that it was written to test it, so this figure is not a count of weak tests. At 0 of 2 code locations with a verdict (0%), counted once for each ticket whose claims show them, no linked test was judged to exercise the code; a test that does may exist beyond this reach.

How Dovada links tests to code, and where it stops

Dovada links tests to code by reading, never by running them. It follows a test from the functions it imports and names, through the functions those name in their own file, and on through imports into other files to a function no test reaches more directly. A file nothing else reaches can be linked to the test file named for it, and a test written on the ticket, where the ticket is a declared test source, is linked by its declaration to the functions the change touches. Beyond those, a test that reaches code only by a route reading does not follow - an import Dovada does not resolve, a framework, a running service - is not linked to it, and code a change adds is linked to repository tests outside the change's own files only once the default branch holds it. The reach is a deliberate limit: carrying tests across more files would link every test of a caller to everything it can reach, whether or not that test's path runs through it, and judging links takes paid model calls.

Tests that do not appear to exist for the changes in this release. Each is an observation about the evidence Dovada found, not an instruction: a test that exists and was not linked is unseen rather than absent, so these are read as places worth looking rather than as defects.

Dovada holds no answer to this question for one record in this release

DEMO-103no answer held

Nothing on this sheet covers this record, and that is a fact about what Dovada was able to do rather than about the change.

DEMO-101 1

Not scoped to one behaviour1

No test exercises exporting an audit log with zero events - whether exportAuditLog() still writes a valid, header-only CSV file when there is nothing to export.
- src/audit/export-csv.ts - exportAuditLog

DEMO-102 2

Not scoped to one behaviour2

No test exercises the Slack call itself failing or timing out - whether closeRelease() still completes the database update when notifySlack() rejects is not covered by any linked test.
- src/release-assembly/adapters/release/persist-release-closure.ts - closeRelease
No test exercises the no-op path - whether closeRelease() skips the Slack call when its own UPDATE changed no row is not covered by any linked test.
- src/release-assembly/adapters/release/persist-release-closure.ts - closeRelease

Test Results

Results from run demo-run-1 on release/DEMO-1.0.0, at its current head demo00000000.

Show

Every test the release-branch runs at the head named above reported, whether or not Dovada knows it, grouped by the test types this deployment declares by where its file lives; a test no single declared type covers is under Other tests in the run. These are the runs' own results: no test here is judged against this release's code, and no verdict on the Claims sheet changes with them.

Unitcode repository4 tests, 1 failed

passed375%

failed125%

not executed00%

Failed test	File
rejects an unknown event type	`src/audit/export-csv.test.ts`

The tests judged to exercise this release's code, with their results from the release-branch runs at the head named above. Which tests appear rests on those judgments as they stand, including where a later change to the code has overcome a judgment by events; the Claims sheet shows each test as its record's assessment judged it, so the two can differ for one test. No verdict on the Claims sheet changes with these results: each stays what its record's assessment concluded.

Unitrun demo-run-1code repository2 tests

passed2100%

failed00%

not executed00%

not in a report read00%

Result	Test	File	Covers code from
passed	produces one row per audit event, in event order	`src/audit/export-csv.test.ts`	DEMO-101
passed	notifies Slack on a real close	`src/release-assembly/adapters/release/persist-release-closure.test.ts`	DEMO-102

Glossary

Every verdict, answer and finding Dovada prints, with other words it uses to report them, as Dovada uses them.

Validation

What the record-level Validation answer says

Aligned: Every requirement Dovada judged against the ticket's pull requests was met. A requirement the ticket withdrew or left undecided does not count, and neither does one Dovada could not answer only because a diff cannot show it, the evidence was not shown to it, or the work is not in the linked pull requests. Changes the ticket did not ask for can sit beside this, listed as Noted.
Circuit Broken: Dovada stopped retrying Validation for this record after repeated failures. A statement about the run, not about the ticket or the change.
Discrepancy: At least one requirement is not met, or only partly met, by the ticket's pull requests. A shortfall outranks anything Dovada could not determine, so a record holding both reads Discrepancy. The claims beneath name which requirements.
No Implementation Found: The ticket carries real requirements and no pull request is linked to this record, so there is no implementation to grade. Not a judgment about the work - there is no work in view. The record is reassessed once a pull request is linked.
Not Assessable: Dovada could not measure the ticket against its pull requests at all: the ticket carried no usable requirements, or none of its content was captured.
Undetermined: Nothing came back unmet or partly met, and Dovada could not determine a requirement in a way that holds the record back: the requirement itself was ambiguous, no reason was recorded, or Dovada could determine none of them. A statement about what could be established, not a shortfall in the work.

What each Validation claim says

Cannot Determine: Dovada could not reach a Met or Not Met call on this requirement, for one of four reasons: the requirement is too ambiguous to judge, a diff cannot show it (a command's result, CI state, ticket metadata), the content that would show it was not shown to Dovada, or the work is not in the pull requests linked to this record. An unknown about the requirement, not a shortfall in the work.
Circuit Broken: Dovada stopped retrying Validation for this record after repeated failures. A statement about the run, not about the ticket or the change.
Met: The ticket's pull requests clearly implement this requirement.
No Implementation Found: The ticket carries real requirements and no pull request is linked to this record, so there is no implementation to grade. Not a judgment about the work - there is no work in view.
Not Assessable: Dovada could not measure the ticket against its pull requests at all: the ticket carried no usable requirements, or none of its content was captured.
Not Fully Examined: Part of the change was not shown to Validation - a file the code host returned no diff content for, or a combined diff clipped for size - so every verdict on this record was reached without it. A limit on what Dovada examined, not a finding about the change.
Not Met: The ticket's pull requests do not implement this requirement at all.
Not Yet Assessed: Neither Validation nor Verification has assessed this record. Nothing has been found; nothing has been looked for.
Nothing Itemized: The record was assessed and produced no itemized findings, so there is nothing beneath its rollup to show.
Open question: The ticket raises this as a decision and does not settle it, so the change can neither meet nor fail it. Where the change acts on the question anyway, the reasoning says which side it takes.
Partial: The ticket's pull requests implement part of this requirement but not all of it: a piece the ticket asked for is missing. A shortfall in what was delivered, never a requirement Dovada could not fully check, which reads Cannot Determine.
Unrequested: A change present in the diff that no acceptance criterion asked for. It is disclosed where a reason for it was recorded, in a commit message for example, and its claim says so where none was. Either way it does not count against the release; what a release decision maker is owed is that it happened.
Withdrawn: A later comment on the ticket took this requirement back - retracted it, declared it moot, or moved it to another ticket - so nothing is asked of the change for it. Not a judgment about the work: the record's Validation answer sets it aside, and the package shows no claim for it.

Verification

What the record-level Verification answer says

Aligned: Nothing Dovada examined for this record came back short. The claims beneath say what each behaviour rests on, and by what evidence.
Assessment Incomplete: Dovada could not finish examining this record. The gap is in what Dovada managed to examine, not in code that may be perfectly well tested.
Circuit Broken: Dovada stopped retrying this record after repeated failures. A statement about the run, not about the change.
Contradicted: At least one behaviour is covered by testing whose recorded outcome is a failure - a test that ran at the commit under review, or an outcome the ticket itself recorded. The most consequential answer here, and the only one that is active evidence rather than an absence.
Discrepancy: At least one behaviour is not established by the evidence Dovada found. The claims beneath name which, worst first.
Nothing to Verify: Dovada has no behaviour of this change left to verify: it carried none (a documentation or configuration change), everything it touched lies outside the product code declared in product_sources, or every behaviour Dovada derived from it rests only on code no longer found where it was recorded. A definition covers every record sharing this outcome, so it names every cause.
Undetermined: Tests that exercise this change exist, and Dovada found no record of any of them having run at the commit under review. A fact about the evidence rather than about the run - the next step is the test results. Where Dovada also could not finish checking a location, the claims beneath say so.

What each Verification claim says

Assessment Incomplete: Dovada failed to produce a judgment. The gap is in what Dovada managed to examine, not in code that may be perfectly well tested.
Cannot Determine: A meaningful test exists but no record of it having run. A fact about the evidence, not about the code - distinct from Assessment Incomplete, which is a fact about Dovada.
Circuit Broken: Dovada stopped retrying Verification for this record after repeated failures. A statement about the run, not about the change.
Contradicted: A meaningful, correctly-targeted test executed and failed. The only state here that is active evidence something may be broken, rather than an absence of evidence.
Met: Evidence was found that establishes this, and it was current when the verdict was computed. Other tests may be linked here that Dovada holds no result for; those neither support this verdict nor count against it, and beneath the location they are counted by what Dovada knows about them. What Dovada has not observed is not held against the code.
Not Met: No evidence Dovada could tie to this change was found for it. An absence of evidence, not proof that the software is wrong.
Partial: The evidence found falls short of establishing it. A family of outcomes rather than one state, so the reason is carried alongside and says which shortfall this is - a covering test carrying a record that it did not run, for instance. The level a test sits at is never the shortfall: a location is judged by the tests that meaningfully cover it, at whatever level those tests exist.

Why a verdict landed where it did

a covering test is recorded as failed: A test Dovada judged to exercise this location has an execution record saying it failed. This is active evidence that something is wrong, which is why it outranks every other outcome on the location rather than being averaged with them. The failing test is listed beneath the location.
a covering test is recorded as not run: A record exists for one of the covering tests here saying it did not run. Somebody decided that, which is why it counts against the location: it is a result, not an absence. A test Dovada holds no result for at all does not reach this state, because not having observed something is not the same as being told it did not happen. The tests are listed beneath the location with what each one did, so which one this is is answerable rather than implied.
a declared test source could not be examined in this run: The customer declared a place test definitions live, and this run could not read it - unreachable, out of credential, or cut short by a limit. Any statement that nothing covers this location would be resting on a search that did not happen, so the verdict is withheld instead. As above, this describes the run and not the code.
a linked test has no current judgment: A test is linked to this location and Dovada holds no judgment of it against the versions of the code and the test in play - it was never judged, or it was judged against a version of either that has since changed, or the model left it out of its answer. It may be the test that covers this code, so Dovada does not report the location as uncovered; the verdict is withheld as Dovada's own unfinished work. This describes the run, not the code, and a later run for this record that judges the test replaces this verdict.
Dovada could not complete its own check of this location: Something in Dovada's own traversal did not finish - a test it could not fetch, or a linked test that has since disappeared - so it cannot vouch for what it did find here, including anything that looked like a pass. The verdict is withheld rather than reported, because a partial view of the evidence can be confidently wrong in either direction. This is a fact about the run, and the next run for this record re-checks it. Nothing here asks a reader to inspect the code.
every covering test produced a result: Each test Dovada judged to exercise this location carried an execution result, and all of them passed. This is the unqualified case: nothing was set aside, so the verdict rests on every covering test rather than on a subset of them.
every covering test that produced a result passed, and all were unit tests: Every covering test here that produced a result passed, and all of them were unit tests. No test failed and none is recorded as unrun. The Partial beside it is stored from an earlier rule that held such a location below Met for the level of its tests; that rule is gone. A code location is now judged by its covering tests alone and their level is not an input, so this same location assessed today would read Met. Treat the Partial as a fact about when this was assessed, not about the code. The covering tests and their outcomes are listed beneath the location either way.
no candidate test was found to judge: The correlation mechanisms found no test to pair with this location, so there was nothing for Dovada to judge. This describes the search and not the codebase: a test may well exist and cover this location without any mechanism here linking the two, which is a limitation of discovery rather than a finding about the tests that were written. Treat it as "Dovada has nothing to show you here", not as "this code is untested".
no covering test produced a result Dovada could read: Tests were judged to exercise this location, and not one of them carried a result Dovada could read. So there is evidence the location is covered and no evidence of what happened when it ran. This is not a failure and not a pass; it is the absence of an outcome, and it is distinct from Dovada's own checking breaking, which reports itself separately.
some covering tests produced no result and were set aside: At least one test Dovada judged to exercise this location carried no result it could read, so the verdict was computed from the ones that did. Those tests are not counted against the location: Dovada holding no result is a fact about what it observed, not a statement that a test failed or was skipped. This reason exists so the difference between "all of them passed" and "the ones we could read passed" is on the row rather than left to a reader comparing two lists. Every covering test is listed beneath the location with what each one did.
tests are linked here, and none of them currently establishes this location: Tests are linked to this location, and not one of them is a current judgment that it is covered. That covers three situations and does not distinguish between them here: Dovada read the test and judged it would not fail if this code broke; it judged the pair once and the code has changed since; or it has not judged the pair yet. Beneath the location the linked tests are counted by which of those applies, so the distinction is answerable rather than lost. What this does not say is that no test exists - only that nothing linked here currently establishes the location.
the ticket recorded that testing failed: The ticket's own transition recorded a failure, and that is the evidence behind this verdict rather than a run report. It is weighed exactly like a recorded run - a declared result is a result - and it is named separately only so a reader can see which kind of record it was. Where a run report and a ticket both recorded a failure, the run report names the reason instead, because it rests on an execution rather than on a transition.
the ticket was declared passed: The ticket's own transition recorded that testing passed, and no test Dovada judged to exercise this location survived. Both are stated because they disagree: the verdict beside this says what the evidence supports, and this says a person recorded otherwise. Dovada says nothing here about whether anybody wrote a description of the testing - it reads the text on a ticket only where the customer declared it as a place test definitions live, so where nothing is declared there is nothing it could have looked at. A test may still be linked here and have been examined: where Dovada judged one not to exercise this location, that judgment is kept and shown beneath the claim.

Reading the evidence beneath a claim

Symbol: The function, class or type a verdict is about. Dovada judges code per symbol rather than per file, so one file with eight functions is eight separately-judged locations, and the column beside this one says which file the symbol lives in. Where a location is the file itself - a naming or path convention that matches a whole file rather than anything inside it - the column says so instead of naming a symbol.
Overcome by events: The link between this code and this test is no longer current: the default branch held the code and the test as Dovada judged them, and the code, the test, or both have changed there since. The row's Judged column shows the judgment this record's assessment made, and this marker shows what has changed since, refreshed every time the package is rendered until the release closes. A change not yet merged has overcome nothing, so it carries no marker; nor does a row showing the judgment as it now stands, where the record holds no copy of its own assessment's judgments (assessed before Dovada stored them, or a location its own run did not assess). Not neglect - a later Verification run whose change reaches this code can judge the test again.
Judged meaningful: Dovada read the test and judged that its assertions would fail if this code broke - the question a mutation-testing tool asks, not whether a line was executed. It is a judgment about this code and this test, not about any one behaviour the code takes part in.
Judged not to exercise this code: Dovada read the test and found it would still pass if this code were broken. The link is Dovada's, not the test author's. Dovada draws it by reading what a test imports and names, and on through what those functions call, so a linked test may never have been meant to test this code. It may be written for a caller, or name this code only to set something up, and be a sound test of what it was written for. On its own, this judgment is not a finding against the test. It points to a gap only where the test was meant to check this code and its checks could not catch a break: it confirms that a value exists or that a call happened rather than what the code produced, it replaces this code with a stand-in, or it compares against output recorded from this same code. Either way, a test existing is not evidence about this code.
Judged against a different version: When this record was assessed, the test had been judged only against a different version of the code or the test - an earlier one, or one another branch holds - so the verdict could not rest on it. A statement about Dovada's own work at that moment, not a finding about the test.
Not yet judged: A link between this code and this test exists, and Dovada has not yet judged whether the test proves anything about it.
Test no longer exists: The test this verdict cited has since disappeared. Reported rather than hidden, because dropping it would read as though nothing had ever covered this location.
No verdict recorded: No verdict was ever computed for this code location - distinct from one that is current.
Computed N versions ago: The verdict was computed against an older version of this code, which has since changed. A confident verdict that is out of date misleads in a way an absent one does not.
(none cited): No specific evidence was recorded for this verdict. Stated rather than omitted, so "nothing was recorded" is not mistaken for "nothing exists".
Declared on another ticket: A test whose steps were written on a different ticket, and whose result is that ticket's own recorded outcome. It is linked to this code, so it is listed - but it reports on the change that ticket described, at the moment that ticket recorded it, so Dovada does not count it toward this record. The ticket it belongs to is named in the row's location.
Test declared on a ticket: A test whose definition is written on the ticket itself, and whose result is that ticket's own recorded outcome rather than a run Dovada observed. It is evidence about this change at this moment: it is not executed again once the ticket closes, and it covers a later change only if it is declared again or captured somewhere it can be re-run. Test level is a separate question - a manual test held in a test management tool persists and is re-executed like any other, and carries none of this.
No [level] test is linked: A statement about the reach of Dovada's correlation, not about the world: no test at that declared level is linked to the stated scope by any mechanism Dovada trusts. A test may exist and be beyond what linking can see - one that reaches the code only through a helper, or through a file Dovada never paired with it, leaves no link to report. Each statement is made at the widest scope where it holds for everything beneath it, and only for levels whose latest repository scan examined their declared locations cleanly.

Whether a test actually ran

failed: A recorded failing outcome for this test - a run executed at the commit under review, or the outcome the ticket itself recorded. The only state here that is active evidence something may be broken, rather than an absence of evidence.
no execution record: Dovada holds no result for this test at the commit under review, and did not find it missing from a report either. Three things produce that and a reader cannot tell them apart from here: no report covering this test's file was published, none could be read, or Dovada held no stored identity to look this test up with. A statement about the evidence, not about the test - it may run perfectly well elsewhere. Distinct from a report that was read and did not mention it, which says so in its own words above.
not cited by this verdict: The test is linked to this code and the verdict shown here does not rest on it. A linked test Dovada judged not to exercise this code, has not yet judged, or judged against a different version is counted beneath the location rather than given a row, and a deleted one gets no row either. A row reading this is meaningful and current, and the verdict simply did not consult it - either it was computed before this test was linked, or by a run for a different change touching the same symbol, or the location carries no verdict yet, which its own standing line above says. Screening, not execution: nothing here is a claim about whether the test ran.
not executed: A record exists saying the test did not run - out of scope for the job, switched off, or declared defective by its own authors. Distinct from no record at all, because someone decided this.
not found in run report: Dovada read a run report that covered this test's own file, and this test was not in it. What that means is not established here and the two possibilities point opposite ways: the test may not have existed at the commit the report graded, or the identity Dovada stored may not match the name the runner printed. Neither is evidence the code is broken, and neither is evidence it is covered.
passed: A recorded passing outcome for this test - a run executed at the commit under review, or the outcome the ticket itself recorded for testing it describes. Qualifiers are shown beside it where they apply - an attempt number above one, a non-blocking lane, a test not selected to run. Dovada reports a qualified pass as a pass and leaves the judgment to the reader rather than overruling the release gate the team already set.
run detail not recorded: The outcome is known, but which environment it ran in, how long it took and which commit it graded were not stored with this verdict. True of every verdict computed before Dovada began recording that detail. Not a claim that the test ran nowhere.

Release

Scope and ticket findings

Descoped Ticket: The ticket is in scope with a resolution configured as one for which no implementation is expected.
No Code Expected: The ticket is in scope with no Change Evidence Record, and its resolution is configured as one for which no implementation is expected, so none was looked for. The finding cites the resolution rather than judging it.
No Evidence Found: The ticket is in scope and has no Change Evidence Record at all - an automatic backfill found no qualifying transition either.
Not Examined: The ticket was in scope and the release closed before Dovada examined it. Whether it shipped an implementation is unknown, not answered.
Out-of-Scope Ticket: A ticket outside the release's scope whose commits are in the release: a pull request's branch, a cherry-pick source's pull request branch or a commit message names it. Neutral - the code has a ticket behind it, just not one of this release's; a fix cherry-picked into an earlier release, whose original reached this one through main, reads this way, for example. The finding names the ticket's fix version, or says it has none, or that Jira returns no such ticket.
Unconfirmed Correlation: A commit tied to a ticket only by the AI correlation tier, not mechanically confirmed. A judgment, deliberately not presented as a fact.
Uncorrelated Change: A commit in the release that Dovada's free checks tied to no ticket of the configured Jira project - they read a key in the branch name of a pull request the commit was part of, or of its cherry-pick source's pull request, and a key in its message - and that the AI correlation tier could not tie to any ticket in scope either. It names a commit because no ticket was found for it - which is the finding. A commit whose check failed, or that the spend limit deferred, on the pass that assembled a package reads this way in that package too.
Unmerged: The ticket reached a terminal state with no verified-merged pull request linked to it.
Unobservable: Dovada can no longer see this ticket in the source system, so nothing further can be established about it.
Unshipped Ticket: The ticket is in the release's scope but has no merged pull request.

Reading this document

Where a claim comes from

Validation: Did we build the right thing? Compares what the ticket asked for against what the change contains.
Verification: Did we prove the right thing works? Compares what the change contains against the evidence that exercises it.
Reconciliation: An assertion about the release itself rather than about any change's content - what is in scope, what shipped, what could not be tied together.
Ticket status: The ticket's own disposition, which is not a finding about the change it carries.

How the claims are grouped

Contradicted: Every claim whose verdict is Contradicted, worst-first across the whole release.
Not met: Every claim whose verdict is Not met, worst-first across the whole release.
Partial: Every claim whose verdict is Partial, worst-first across the whole release.
Cannot determine: Every claim whose verdict is Cannot determine, worst-first across the whole release.
Noted: Real and not a problem: a change no requirement asked for, or a ticket whose resolution says no code was expected. Present so it is visible, not because it counts against the release. An unrequested change is disclosed only where a reason for it was recorded.
Met: Everything that passed, collapsed to a count so it cannot bury the claims that need a decision - and expandable, so no record is reduced to a number.
Dovada did not finish: Claims that say something about Dovada rather than about the release. Deliberately outside the severity order: nothing here has been found wrong with the code.
Open questions: Every claim whose verdict is Open questions, worst-first across the whole release.

What the report was produced against

Declared test suite: The test levels this report was produced against, drawn from the customer's own configuration - test_sources, plus manual whenever ticket test sources are declared. A statement of scope, not an assessment: it names what is declared and nothing that is not, and Dovada holds no position on what levels an organization ought to have.

Release Notes

What this release delivered, grouped by change type. Each item is the shipping ticket's own summary; its assessment is on the Claims sheet.

Changes

DEMO-101 Add CSV export for the audit log
DEMO-102 Send a Slack notification when a release closes
DEMO-103 Document the spend-ceiling configuration keys

Dovada - Release Evidence Package DEMO-1.0.0