Deterministic evidence review

Truth Tools

Three launch-readiness status scenarios show the difference between artifact quality and program health: broken evidence, fixed evidence, and a facts-only report.

One report, three reviews

Both reviews run the same deterministic engine on the same story: a checkout migration launch that needs a rollback owner. The broken artifact embeds a raw Jira body, misses an evidence timestamp, keeps a stale snapshot, and lets two sources contradict each other. The fixed artifact contains metadata only, with fresh timestamps and reconciled dates. The facts-only artifact records only release.ready=false and intentionally omits a health assessment, so its final health is unknown.

— —

Artifact quality vs program health

Artifact quality

pass | needs_review | fail

Is the evidence structure of this artifact sound? Every claim must cite a known source, timestamps must be present and current enough, values must be typed scalars, and no two claims may contradict each other.

Program health

on_track | at_risk | blocked | unknown

What do the claims say about the program? Any explicit blocker means blocked; risks and unknowns mean at risk; on-track requires an explicit on-track health assessment plus active facts and no active risk, unknown, or blocker.

Freshness dimensions

observed_at is when the evidence was read or snapshotted. source_updated_at is the last change reported by the source system. The engine ages evidence against as_of; a source that changed after the snapshot is a freshness warning even if the snapshot itself is recent.

Explicit health dimensions

Disclaimer: Truth Tools reports the supplied assessment and deterministic claim floor; it does not prove real-world program health.

Categories, conflicts, actions

Claims by kind

Conflicts

    Findings

      Recommended actions

        Timeline drift

        The plan accepted on 2026-07-20 compared with the plan as of 2026-08-11. Drift is reported, never judged: moving the launch is not an evidence failure, but hiding the movement is.

        Baseline

          Current

            Changes

              Component truth

              Real sibling components run against the same fixtures: capture-truth normalizes the evidence-pack sources, timeline-truth rebuilds and diffs the plan, and Program Truth's canonical status artifact is mapped into this engine and reviewed here.

              Capture truth

                Facts-only candidate safety

                  Timeline truth diff

                    Program Truth review

                      Program Truth sources

                        Trust boundary

                        Truth Tools verifies the structure of the artifact it is given. It checks that citations resolve, timestamps are usable, typed values do not contradict each other, and blockers stay visible. It does not fetch URLs, read source bodies, or prove that a cited source supports a claim. A fabricated source reference can pass if its metadata is internally valid.

                        Raw source bodies are rejected by design: source content stays in its system of record, and claim text is exported verbatim. This demo renders claim text with textContent, never HTML, because claim text is not trusted markup.

                        The engine does not claim that the program is healthy or that a review proves anything. It reports what the supplied evidence can and cannot support.

                        Run it yourself

                        npm install
npm run demo        # verify all generated outputs against the engine
npm run demo:dev    # serve this page at http://127.0.0.1:4173/
npm test            # engine, CLI, MCP, contracts, drift tests
npm run eval        # synthetic evaluation cases and metrics

                        Static files only. No login, no network requests, no telemetry. The data you see here is the same JSON the engine verifies in npm run demo.