Start with the outcome. Trace back to the run.

OutcomeTest is in problem discovery. The method below is a proposed operating design, not an available service, customer result, or proven process.

In a future pilot, a written readiness check would establish authority, scope, prohibited data, one workflow version, the expected outcome, and the single returned-evidence cycle before payment or intake.

Proposed eligibility

• One agency-owned or agency-authorized workflow architecture.
• Maximum 20 nodes or steps and three external integrations.
• Synthetic fixtures and redacted expected outcomes or known failures.
• No credential identifiers, tokens, URLs, customer content, PII, regulated data, or proprietary prompts/data.

An outcome invariant is a business condition that must remain true when the automation runs. Typical classes include correctness, freshness, completeness, entity matching, nonduplication, and permitted side effects. The actual invariant must come from the buyer's workflow and handoff obligation.

Generic checklists are not enough. If the buyer cannot state the intended result in testable terms, the scope remains unresolved.

The proposed packet would map the workflow, record assumptions and exclusions, and select applicable failure classes. It would then specify adverse tests, expected results, trace points, and safe stop conditions for the agency to run.

Failure classes considered when applicable

False success, missing run, semantic error, retry or idempotency failure, duplicate effects, timeout, rate limit, expired credential, schema drift, partial completion, and unsafe autonomous action.

The agency would execute every native diagnostic and adverse test in an environment it controls. OutcomeTest would not run the workflow, call a private model, hold credentials, or make a production change. The agency would return one complete, structured, redacted evidence batch.

A future assessment would connect each accepted result to the relevant invariant and test. Supported gaps would be classified as critical, high, or normal and translated into a prioritized repair specification. Unsupported conclusions would be marked unresolved, not filled with assumptions.

Planned packet

• Workflow map, intended outcome, assumptions, and exclusions.
• Invariant and failure register.
• Test-to-result traceability.
• Alert, reconciliation, approval, rollback, and runbook gaps.
• Prioritized repair specification and one consolidated async clarification round.

The proposed review cannot prove end-to-end production correctness, guarantee reliability, find every defect, certify compliance, or replace monitoring, internal QA, implementation testing, security review, and operational ownership.

Any future conclusion would be limited to the accepted artifacts and the one redacted evidence batch supplied by the buyer.