Method / Scope / Limitations

A discrepancy is a starting point, not a conclusion.

Outcome Check compares supplied workflow records against explicit expectations. It evaluates defined relationships and, where supported by the available inputs, compares observed state with expected state. Findings identify discrepancies for investigation; they do not automatically establish root cause.

01 / Inputs

Begin with the records you can justify.

Workflow records

Supplied event records and downstream effect records, with stable identifiers and object references where available.

Expectations and state

Explicit rules defining expected relationships and counts, plus optional state snapshots for supported comparisons.

Exact accepted schemas and required columns must be confirmed against the current implementation before a production-facing input guide is published. Use synthetic or explicitly authorized, minimized data.
02 / Process

From supplied records to reviewable findings.

01 / VALIDATE

Check the input

Parse supported files and reject malformed input rather than silently treating it as valid evidence.

02 / COMPARE

Apply defined rules

Compare available relationships and state against explicit expectations supported by the engine.

03 / REVIEW

Trace the finding

Inspect the rule, relevant source records, explanation and limitations. Rerun fixed inputs where reproducibility is required.

03 / Evidence

A finding must be inspectable.

Where supported by the implementation, an evidence report should identify the finding code, applicable rule, expected and observed values, related object or record references, source-row evidence and an explanation. Severity labels must come from a defined rule system, not from an arbitrary marketing description.

What it can support

A specific discrepancy in the records supplied, evaluated against the rule that was applied.

What it cannot prove alone

Root cause, realized financial loss, completeness of unprovided records, or correctness of every business invariant.

04 / Current boundary

Local-first, file-based diagnostic.

Current product scope

  • Browser-based analysis of supplied files and a Node.js CLI, subject to current implementation verification.
  • Evidence and findings outputs where implemented.
  • Reusable GitHub Action and tests where present in the repository.

Not currently offered

  • Hosted accounts or customer workspace.
  • Direct production connections, continuous monitoring or alerts.
  • Automatic remediation, guaranteed detection or security certification.
A clean run is not proof that the entire workflow is correct. Results depend on input completeness, identifier quality and whether the rules correctly express the intended business behavior.
Next / Evaluation

Define one workflow and one verification question.

Discuss the available records, supported checks and acceptance criteria before any evaluation or data transfer.