PROOFClient overview · illustrative outputsKeep the Test. Change the Technology.
Select an application or capability. See how approved requirements, tests, build evidence, and findings can support a clearer release decision.
Choose from the PSPD portfolio →Reduce repeated traceability and reporting work. Preserve reusable business tests through technology changes. Make missing coverage and evidence easier to review. A measured pilot establishes value for your program.
Leidos’s historical TPVS award covers software lifecycle services and traveler enrollment/processing equipment.
Application mapping gap: The 59 retained application entries are discovery candidates. Neither catalog membership nor an I-94 help source establishes inclusion in a selected Leidos task order or another PSPD support contract.
Current disposition: candidate — prime/task-order applicability unverified. Each entry needs the applicable contract/task order, scope section and approved requirement reference before inclusion in an authoritative CRTM.
Original TPVS draft solicitation source lead · DRAFT-RFQ-20109228-CBP-PSPD-TPVS-BPA · August 8, 2019
Draft solicitation notice located; it states the formal RFQ would be released through GSA eBuy. Executed BPA/task-order SOW, application inventory and current modifications have not been retrieved. TPVS 2.0 planning sources are kept separate from TPVS 1.0.
Leidos TPVS BPA 70B04C20A00000008 / Task Order 7 70B04C24F00000739 — published award-record lead
Scope verification remains incomplete: no application-level prime contract mapping has been approved from these source leads.
CBP’s July 28, 2026 sole-source justification identifies Leidos under BPA 70B04C20A00000008 / Task Order 70B04C24F00000739 and records an extension through May 30, 2027 (§2). Its §3 names APIS, ADIS, I-94, Global Entry, MPC, EPP, DTOPS, ESTA, EVUS and Trusted Traveler Programs in TPVS operational context.
These references support prime/task-order and application context. They do not establish each application’s CLIN, complete technical rules, or approval of the 59-entry catalog. Executed scope and requirement mapping remain pending. TPVS 2.0 draft material is a separate future procurement.
PSPD · guided walkthrough
Discovery first: source-backed context and SI candidate interpretation, with explicit gaps. The execution lesson that follows is separately synthetic; it is not a discovered CBP requirement or actual run.
Review whether the selected build supports the agreed I-94 retrieval outcome.
Source traceability: CBP I-94 help, retrieved 2026-10-11
Approval status: Public source context only. Applicable contract scope and business expectations require confirmation by the designated authority; no approved requirement baseline is represented.
Open gaps: Authorized scope, approved source material and execution readiness remain to be confirmed.
DEMO-I94-001: An illustrative record must include a record reference before it can be accepted. Preconditions: an authorized synthetic test environment, a selected demo build and designated reviewers. This invented rule needs domain SME confirmation before use in a real scope.
Positive input: Record reference: DEMO-I94-100; no traveler fields. Expected: accepted, with one synthetic record. Negative input: Record reference: blank. Expected: rejected, with no accepted record created. Designated reviewers confirm business expectations and assess the evidence. These tests are described here, not generated or executed. Backend/API path: submit valid and missing-reference inputs, verify response and resulting record state. UI path, only if a corresponding screen exists: enter the same values, submit and inspect feedback; correlate with backend evidence. Actual endpoints, selectors and response codes are undiscovered.
Build I94-DEMO-B01 · release DEMO-R01 · environment DEMO-QA. The displayed execution is synthetic. Missing environment prerequisites would yield BLOCKED; execution/configuration exceptions would yield NOT_PROVEN. Neither means a confirmed business failure.
Illustrative negative-test result: expected rejection, observed acceptance and one synthetic record created. Verdict: DISPROVEN. Evidence reference: DEMO-I94-001-E01, a narrated example rather than an attached log or actual run. This business failure opens a finding; it does not establish release readiness.
Illustrative finding DEMO-I94-001-F01: required reference was not enforced. Review owner: designated application team, pending assignment. Proposed correction: enforce the approved validation. A correction alone does not close the finding. Rerun both tests against I94-DEMO-B02 · DEMO-R02; synthetic observations now match both expectations. The example is PROVEN only for this narrow stated rule; no live execution is claimed.
HI reviews the business baseline, exact build, positive and negative results, evidence and finding disposition. In this illustration, matching retest results could support closure after review. No reviewer approval, finding closure or release decision is actually recorded. PROVEN for one rule does not prove the entire application.
Agree on one business outcome, authorized source material, a real build, test environment, data and reviewers. Confirm acceptance criteria and effort baseline. A configured pilot must supply the actual tests, execution evidence and human dispositions that this teaching example does not contain.
← Return to scope portfolioCompare the three examples →Discuss an I-94 pilot →
Choose the project scope first, then filter its applications or workstreams below.
Explore the 59 entries retained from the AN8 PROOF working catalog. Inclusion does not establish current portfolio ownership, active modernization status, or completed assessment. Repeated names retain distinct catalog IDs pending confirmation.
Approved requirement → linked tests → selected build → execution evidence → findings → human release decision.
Designed to work with authorized Selenium, API testing, Jira/Xray, and existing delivery tools. Integration availability is confirmed during pilot scoping.
Distinguish coverage gaps, test failures, missing prerequisites, and unavailable evidence. Findings can support the existing defect and review process.
Audit tickets connect each finding or gap to its requirement, test, build, and evidence—so the team can see the review owner, next action, status, and evidence needed for closure.
Keep unresolved issues visible through correction, retest, and human review.
Explore sample audit findings & tickets →The client example is synthetic. Live ticket creation and tracking depend on the configured workflow and integrations confirmed during pilot scoping.
Continuous Proof connects business expectations to evidence for the selected build. Each build needs its own proof; human authority governs release decisions.
Explore Continuous Proof →Connect existing scripts to their business purpose and selected build. Runner integration and evidence capture are confirmed during pilot scoping.
Review capabilities →Trace changes to affected business expectations and tests. Missing mappings remain visible; automated impact selection requires configured integrations and validation.
Review findings and gaps →Functional and performance evidence can be included where expectations, execution tools, and authorized access are agreed. Human SMEs approve business expectations; the designated release authority decides.
Keep your existing automation. Connect its results to approved business expectations, the exact build, evidence, and the next decision.
Traditional automation runs tests and reports results. AN8 PROOF is designed to bring requirement-centered traceability, build-specific evidence, and governed follow-up into one workflow. Existing frameworks can provide many of these capabilities when configured well.
| Chokepoint | Intended AN8 PROOF response | Intended business benefit |
|---|---|---|
| Manual traceability | Reviewed requirement → test → build → evidence links. | Less manual mapping and evidence chasing. |
| Repeated test preparation | SI prepares candidate requirements and linked tests; designated SMEs validate and approve. | Less repetitive preparation, with SME approval retained. |
| Unclear business coverage | Requirement-centered coverage and unresolved gaps, with build-specific verdicts. | Clearer visibility into covered expectations and missing proof. |
| Results disconnected from builds | Results and evidence associated with the selected build, release, and environment. | More precise assessment of the release under review. |
| Confusing failure categories | Separate DISPROVEN business failures, NOT_PROVEN execution exceptions, and BLOCKED prerequisites. | More focused follow-up on business failures, execution exceptions, and missing prerequisites. |
| Scattered reports and follow-up | Consolidated evidence, findings, review ownership, next actions, retest, and closure evidence. | Less report assembly and clearer responsibility for next actions. |
| Uncertain release readiness | Evidence and unresolved outcomes support the designated human authority’s decision. | Faster informed review of readiness and remaining risk. |
| Modernization rework | Preserve approved business expectations while adapting technology-specific execution. | Less repeated work when the technology changes. |
These are intended capabilities. This site demonstrates synthetic outputs; configured integrations and measured pilot evidence must establish production operation and reduced effort.
Business owners resolve incomplete or conflicting requirements; designated SMEs provide domain knowledge and approval. Teams provision suitable test data, authorize access, stabilize environments, and restore downstream dependencies.
Engineers configure runners and integrations, repair flaky tests, improve execution speed and capacity, and correct application defects. Teams establish ownership, training, and handoff agreements.
AN8 PROOF can make these constraints visible and connect them to affected outcomes and next actions. Resolution remains with the responsible people and systems.
The sample supports execution-date filtering, a unique run ID, and browser-only archive, reopen, and restore controls. Permanent shared retention requires backend storage, access controls, and retention policies.
Explore sample execution history →Measure the value: compare traceability, test preparation, evidence review, reporting, and finding follow-up effort during a configured pilot. Include setup, integration, licensing, and operating costs.
Start with one agreed application scope. Identify the bottlenecks, establish a baseline, and measure the change during a configured pilot.
Identify your automation chokepoints →AN8 PROOF addresses key risks through SME approval, requirement-centered evidence, distinct outcomes, and human release authority.
These are design safeguards and synthetic demonstration features. Production mitigation requires implemented controls and observed evidence from the connected environment.
| Risk | Current design safeguard | Pilot or production verification needed |
|---|---|---|
| Incorrect SI-derived baseline | Designated authorities approve business expectations and review evidence. | Review quality, approval enforcement, and controlled baseline changes. |
| Incomplete coverage or misleading pass results | Requirement-centered evidence and unresolved gaps support review. | Coverage of agreed business rules, negative paths, prerequisites, and reliable assertions. |
| Evidence from the wrong build or environment | The workflow identifies the selected build, release, environment, and run. | Reliable association between those identifiers and actual execution evidence. |
| Incorrect failure classification | DISPROVEN, NOT_PROVEN, and BLOCKED distinguish different unsuccessful outcomes. | Classification accuracy using representative failures and exceptions. |
| Overreliance on a verdict | Designated humans retain release decision authority. | Access controls, approval records, and the agreed scope of each proof claim. |
| Integration overhead and SME bottlenecks | Existing-test reuse and pilot effort measurement are part of the proposed approach. | Net effort savings, integration costs, and SME review turnaround. |
| Sensitive data or protected implementation exposure | The public demonstration uses synthetic data and describes a high-level workflow. | Authorized data handling, access controls, and security review for real integrations. |
| Unreliable report retention | The demo explicitly limits archiving to browser-local sample status. | Shared evidence storage, access controls, integrity, and agreed retention policies. |
Pilot approach: run alongside the current process using one authorized scope. Compare results, investigate discrepancies, and measure total effort before considering AN8 PROOF as a release gate. Agree on acceptance criteria with the responsible reviewers.
Scope a pilot to verify safeguards and value →See the manual work AN8 PROOF targets and the constraints that still need team action.
Explore automation value →Review business outcomes and agreed response-time, throughput, and load expectations.
Review testing scope →Connect existing tests to business expectations and the selected build.
Review integration scope →Approved intent, release scope, execution environment, AN8 PROOF, and decision support.
Explore context diagram →Discovery → Define → Plan → Design → Build → Release → Proof.
Explore lifecycle diagram →CI builds. Continuous Proof verifies. CD delivers. Each build needs its own evidence.
Review Continuous Proof →Impact, ownership, next actions, and reviewed closure evidence.
Explore sample audit results →SI and HI: Intelligence-assisted analysis supports clearer coverage and findings. Designated human authorities approve business expectations and release decisions.
Built from hands-on federal QA experience, AN8 PROOF focuses on reusable business tests, build-specific evidence, and a shared view of readiness.
Functional: evaluate agreed positive and negative paths, validation rules, and expected business results against the selected build.
Performance: evaluate agreed response-time, throughput, and load expectations where authorized tools and test conditions are available.
Existing tests: reuse Selenium and API tests through configured runners, reviewed requirement mappings, and build-specific evidence capture.
Integration availability, execution scope, and measurable benefits are confirmed during pilot scoping.
Who it serves: QA, engineering, SMEs, and program teams managing maintenance, modernization, and contractor transitions.
Proof pathway: business expectation → linked tests → selected build → execution evidence → findings → human release decision.
SI and HI: Super Intelligence (SI) supports candidate preparation. Human Intelligence (HI), through designated SMEs, validates and approves the business baseline. Candidate results remain provisional until review.
Capabilities: requirement-centered traceability, existing Selenium and API test reuse, functional and performance evidence, build evidence, ALM reporting, findings and audit-ticket follow-up, and measured capacity improvement.
SME authority: designated human reviewers validate requirements, data fields, prerequisites, conditions, business rules, and expected results. Unresolved candidate mappings remain pending.
Planned release selection: approved release scope and reviewed test mappings can support suite selection; automatic impact selection is not represented as production-ready here.
Pilot measurement: measure test preparation, execution, evidence review, and reporting separately against the current process.
Maturity: this site provides synthetic examples and illustrative calculators. Production execution, ticket tracking, and integrations require a configured pilot; automated impact selection and production savings are not established by this page.
See where AN8 PROOF fits →Target operating model. Planned features require configured pilot validation.
Discovery → Define → Plan → Design → Build → Release → Proof. Select a lifecycle stage to review the product scope and maturity.
Review existing business expectations, source material, and reusable tests. Record missing information for designated SME review.
Lifecycle context only; execution and integrations require a configured pilot.
↑ Return to lifecycle diagramEstablish the approved business outcome, data fields, prerequisites, conditions, business rules, and expected results. Candidate expectations remain provisional until designated SME approval.
Lifecycle context only; execution and integrations require a configured pilot.
↑ Return to lifecycle diagramAgree on evaluation scope, priorities, dependencies, reviewer roles, and readiness gaps. Confirm the inputs and access needed for the selected proof run.
Lifecycle context only; execution and integrations require a configured pilot.
↑ Return to lifecycle diagramSpecify the target solution and the agreed functional and performance checks. Confirm how configured tools will execute the tests and provide evidence.
Lifecycle context only; execution and integrations require a configured pilot.
↑ Return to lifecycle diagramImplement the approved change and identify the exact build under review. Existing Selenium and API tests can be reused through configured integrations.
Lifecycle context only; execution and integrations require a configured pilot.
↑ Return to lifecycle diagramPrepare the versioned package or deploy it to the authorized test environment. Confirm the build, test data, and prerequisites. Production release approval remains with the designated authority.
Lifecycle context only; execution and integrations require a configured pilot.
↑ Return to lifecycle diagramExecute the approved checks against the selected build. Review expected versus observed results, the four verdicts, and unresolved findings. Human authority governs the release decision.
Lifecycle context only; execution and integrations require a configured pilot.
↑ Return to lifecycle diagramThis demonstration contains one pre-authored synthetic run. Archive status is saved only in this browser when storage is available; it is not a shared, secure, or permanent report repository. No real execution history is loaded.
| Run ID | Execution date (UTC) | Build / release | Status | Actions |
|---|---|---|---|---|
| DEMO-RUN-20261010-001 | 2026-10-10 12:00 UTC | MOD-DEMO-02 / DEMO-R02 | Active | Open report → |
No real evidence attachments are stored. Archiving changes visibility status only; it does not modify the sample verdicts or report contents.
Interactive sample · Application lifecycle management (ALM)
Find what passed, what failed, and what still needs attention before the release decision. Select a verdict, then follow its requirement, test, evidence, and next action.
Run DEMO-RUN-20261010-001 · executed 2026-10-10 12:00 UTC (illustrative). Entirely synthetic demonstration: 4 illustrative requirements for build MOD-DEMO-02, release DEMO-R02, environment DEMO-QA. These are not CBP requirements, actual executions, approvals, or a live integration.
One of four sample outcomes is proven. One business failure, one execution exception, and one missing prerequisite remain. This sample does not support a release recommendation. The designated authority decides after reviewing evidence and dispositions.
| Requirement / business outcome | Linked test | Verdict | Finding / next step |
|---|---|---|---|
| DEMO-001 · Preserve the approved record relationship | DEMO-T01 | PROVEN | No finding · review → |
| DEMO-002 · Reject an invalid record without creating a valid record | DEMO-T02 | DISPROVEN | DEMO-F01 · review → |
| DEMO-003 · Return the approved response after a valid request | DEMO-T03 | NOT_PROVEN | DEMO-F02 · review → |
| DEMO-004 · Preserve the approved outcome in a downstream handoff | DEMO-T04 | BLOCKED | DEMO-F03 · review → |
PROVEN Build MOD-DEMO-02 · Release DEMO-R02
Business outcome: Preserve the approved record relationship. This requirement and its test are illustrative, pre-authored outputs.
Expected: SAMPLE-A.
Observed: SAMPLE-A.
Sample evidence record
Requirement DEMO-001 → Test DEMO-T01 → Build MOD-DEMO-02
Environment DEMO-QA · captured 2026-10-10 12:00 UTC (illustrative)
Expected: SAMPLE-A
Observed: SAMPLE-A
Verdict: PROVEN
This displayed record is synthetic. No external log, actual test run, or verified evidence artifact is attached.
Review disposition →Impact: Business expectation met in this sample.
Review owner: None
Next action: Retain reviewed evidence for the release review.
Disposition: No corrective action in this sample.
DISPROVEN Build MOD-DEMO-02 · Release DEMO-R02
Business outcome: Reject an invalid record without creating a valid record. This requirement and its test are illustrative, pre-authored outputs.
Expected: Rejected; no valid record created.
Observed: Accepted; valid record created.
Sample evidence record
Requirement DEMO-002 → Test DEMO-T02 → Build MOD-DEMO-02
Environment DEMO-QA · captured 2026-10-10 12:00 UTC (illustrative)
Expected: Rejected; no valid record created
Observed: Accepted; valid record created
Verdict: DISPROVEN
This displayed record is synthetic. No external log, actual test run, or verified evidence artifact is attached.
Review disposition →Impact: Business failure: an invalid record was accepted.
Review owner: Application owner (illustrative)
Next action: Correct the failure, rerun the linked test, and review new evidence.
Disposition: Open; resolution and review pending.
NOT_PROVEN Build MOD-DEMO-02 · Release DEMO-R02
Business outcome: Return the approved response after a valid request. This requirement and its test are illustrative, pre-authored outputs.
Expected: Approved response.
Observed: Execution interrupted; no business result.
Sample evidence record
Requirement DEMO-003 → Test DEMO-T03 → Build MOD-DEMO-02
Environment DEMO-QA · captured 2026-10-10 12:00 UTC (illustrative)
Expected: Approved response
Observed: Execution interrupted; no business result
Verdict: NOT_PROVEN
This displayed record is synthetic. No external log, actual test run, or verified evidence artifact is attached.
Review disposition →Impact: Execution exception: no supported business verdict can be made.
Review owner: Environment owner (illustrative)
Next action: Resolve the execution exception and rerun the test.
Disposition: Open; resolution and review pending.
BLOCKED Build MOD-DEMO-02 · Release DEMO-R02
Business outcome: Preserve the approved outcome in a downstream handoff. This requirement and its test are illustrative, pre-authored outputs.
Expected: Approved downstream outcome.
Observed: Not executed; required dependency unavailable.
Sample evidence record
Requirement DEMO-004 → Test DEMO-T04 → Build MOD-DEMO-02
Environment DEMO-QA · captured 2026-10-10 12:00 UTC (illustrative)
Expected: Approved downstream outcome
Observed: Not executed; required dependency unavailable
Verdict: BLOCKED
This displayed record is synthetic. No external log, actual test run, or verified evidence artifact is attached.
Review disposition →Impact: Prerequisite missing: downstream readiness must be established.
Review owner: Integration owner (illustrative)
Next action: Restore the prerequisite, then execute and review the result.
Disposition: Open; resolution and review pending.
You see the decision-support output here. A focused demonstration explores the same view for your agreed project scope.
Start your application proof demo →Audit results · findings, gaps & next actions
Know what works, what remains unresolved, and who needs to act.
Stop piecing together status from test runs, spreadsheets, and follow-up messages. Review business expectations alongside build-specific evidence, then follow each exception to its impact, review owner, next action, and closure evidence.
Synthetic sample audit results. Authorized reviewers govern business expectations and assess findings and evidence. No real application audit, ticket creation, or approval is represented here.
A business failure, an execution exception, and a missing prerequisite stay distinct. A high pass count does not hide unresolved outcomes.
Explore →Each finding identifies the role that needs to review it and the next action. Actual assignment requires the owner's acceptance.
Explore →A reported correction remains open until a new run and reviewed evidence support closure.
Explore →| Finding | Impact |
|---|---|
| DEMO-F01 · DISPROVEN | Invalid record accepted; business expectation failed. Inspect finding → |
| DEMO-F02 · NOT_PROVEN | Execution interrupted; business outcome unknown. Inspect finding → |
| DEMO-F03 · BLOCKED | Dependency unavailable; downstream check not executed. Inspect finding → |
Synthetic sample only. All three findings remain open. Reviewer assignment, correction, retest, and approval are pending.
↑ Back to audit overview| Review role | Next action |
|---|---|
| Application owner | Review DEMO-F01, correct behavior, and rerun the linked test. Inspect finding → |
| Environment owner | Review DEMO-F02, restore execution, and rerun. Inspect finding → |
| Integration owner | Review DEMO-F03, restore the dependency, and execute. Inspect finding → |
Synthetic sample only. All three findings remain open. Reviewer assignment, correction, retest, and approval are pending.
↑ Back to audit overview| Finding | Required closure evidence |
|---|---|
| DEMO-F01 | New build-specific result meets the agreed rejection expectation. Inspect finding → |
| DEMO-F02 | Completed execution supports a business verdict. Inspect finding → |
| DEMO-F03 | Dependency readiness and downstream outcome verified. Inspect finding → |
Synthetic sample only. All three findings remain open. Reviewer assignment, correction, retest, and approval are pending.
↑ Back to audit overview| Finding / gap | Client impact | Review owner | Status |
|---|---|---|---|
| DEMO-F01 · Business failure | Invalid record accepted | Application owner (illustrative) | Open · review pending |
| DEMO-F02 · Execution exception | Business outcome remains unproven | Environment owner (illustrative) | Open · review pending |
| DEMO-F03 · Prerequisite gap | Downstream check could not execute | Integration owner (illustrative) | Open · review pending |
Result: Business failure.
Impact: Invalid record accepted.
Review owner: Application owner (illustrative; assignment pending).
Next action: Correct the behavior and rerun DEMO-T02.
Closure evidence: New build-specific evidence shows rejection and no valid record created.
Status: Open; no correction, retest, or approval recorded.
Result: Execution exception.
Impact: Business outcome remains unproven.
Review owner: Environment owner (illustrative; assignment pending).
Next action: Resolve the execution exception and rerun DEMO-T03.
Closure evidence: A completed run supports a business verdict against the agreed expectation.
Status: Open; no correction, retest, or approval recorded.
Result: Prerequisite gap.
Impact: Downstream check could not execute.
Review owner: Integration owner (illustrative; assignment pending).
Next action: Restore the required dependency and run DEMO-T04.
Closure evidence: Dependency readiness and the downstream outcome are supported by reviewed evidence.
Status: Open; no correction, retest, or approval recorded.
The value: less manual chasing, clearer accountability, and evidence to support the release decision within the reviewed scope.
See where your application stands →Compare the same recurring work before and after automation. Enter measured or proposed hours; the result is an estimate, not a savings commitment.
Default inputs are illustrative. Estimate excludes setup, licensing, and operating costs; pilot scoping must include them. Saved capacity does not automatically imply headcount reduction.
Bring your selected application and one business outcome. AN8 PROOF connects approved business requirements to build-specific test evidence. Confirm authorized scope, source material and test-environment readiness for a focused demonstration. Designated human authorities govern the baseline and release decision.
AN8 LLC is the company behind AN8 PROOF—Proof and Outcome Orchestration Framework.
Our focus is connecting business expectations with build-specific evidence, findings, and next actions to support clearer software readiness decisions.