Each requirement must fit the selected prime contract/task order and workstream. The contract defines scope; approved requirements define the behavior to prove. Designated human authorities confirm applicability and approve the baseline.
ACE source and scope register · reviewed October 11, 2026
Baseline dimension
Current evidence / next verification
Prime / award context
Dev Technology bridge / C. Mack Solutions–Dev Technology JV support task — reported award leads; select and verify the applicable award
Available award source
ACE/ATAP support award report, 2025 Secondary award report — primary award verification pending. Award context only; not an approved requirement baseline.
Contract scope gap
Selected prime, executed ACE/ATAP task order, PWS/SOW and modifications are not loaded. ACE manuals and deployment notices support behavior discovery; they do not bind these candidates to a particular award.
Required scope traceability
Prime legal name; contract and task-order IDs; workstream; applicable SOW/PWS version, effective date and section; attachments and modifications; in-scope and out-of-scope disposition.
Required behavior traceability
Approved requirement ID/version and source section; data/schema and business-rule sources; preconditions; expected results; negative paths; test IDs; build/release and execution evidence.
Approval status
Not recorded. Retain reviewer, approving authority, approval date and baseline version. Public discovery and evaluator selection do not grant approval.
Next step: Confirm the applicable contract scope, source versions and approval status with the designated authority. Unresolved scope remains a visible gap.
Synthetic execution examples remain demonstrations and are not approved CBP requirements or actual execution evidence.
Prime scope alignment
Reported ACE/ATAP development and support awards identify relevant prime leads; the selected award and its executed scope remain unverified.
Application mapping gap: Import manifest, export manifest, electronic refunds and ACE Portal are business discovery candidates. No entry is assigned to a Dev Technology or joint-venture task order.
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.
Planning notice located. Draft SOW and Attachment E Cargo Applications referenced; their bytes and the final executed scope have not been retrieved. Award linkage pending.
Scope verification remains incomplete: no application-level prime contract mapping has been approved from these source leads.
Historical prime scope cross-check
A federal court record connects the 2019 CSPD award to Dev Technology and identifies the scope below. These areas are not fully represented by our four current discovery choices.
Current bridge and JV assignment mapping remains unconfirmed. Retain these as historical scope evidence until the applicable current SOW and amendments are checked.
ACE · guided walkthrough
Worked example: manifest submission validation
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.
Business outcome example: Manifest submission
Review whether the selected build supports the agreed manifest-submission outcome.
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.
1. Separate synthetic lesson: establish an invented outcome
DEMO-MAN-001: An illustrative manifest submission must include a submission reference before intake can accept it. This is not a CAMIR or CATAIR specification. 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.
2. Prepare candidate tests
Positive input: Submission reference: DEMO-MAN-100; no shipment or commercial data. Expected: accepted, with one synthetic record. Negative input: Submission 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.
3. Select the demo execution context
Build MAN-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.
4. Inspect a synthetic failure
Illustrative negative-test result: expected rejection, observed acceptance and one synthetic record created. Verdict: DISPROVEN. Evidence reference: DEMO-MAN-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.
5. Track correction and retest
Illustrative finding DEMO-MAN-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 MAN-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.
6. Review and decide
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.
7. Scope a real pilot
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.
Select the ACE workstream that matches your assignment. These candidate choices identify areas for discovery; The designated reviewer confirms the applicable project and current responsibilities.
Start with the business behavior that must remain correct through a technology change, then agree on the requirements, tests and build evidence to review.
Choose your application or capability
Choose the project scope first, then filter its applications or workstreams below.
SI assembled four candidate ACE workstreams from public CBP material. HI confirms the applicable assignment: select your area, correct names or add a missing one. This is not a verified contract roster.
Explore review categories, then select all areas that match your work. Your selections remain available when you filter or return.
Tell us where testing fits
Selections stay in this page’s memory. Nothing is submitted automatically. No project assessment or proof run is performed.
Your scope confirmation
Share this summary with AN8 LLC through your usual channel. After confirmation, AN8 PROOF can prepare workstream-specific requirements, proof scenarios and measurable pilot criteria.
Four candidate discovery workstreams; these do not represent four verified active contracts. The reviewer’s assignment and current scope require confirmation.
