A defined evaluation, with evidence at the end.
Agree the task, approved inputs and acceptance criteria before installing software. A useful evaluation records what worked, what failed and what remains to be engineered.
1. Select the task and product
Identify the decision to be made, the people doing the work and the capability needed. Separate analyst workflows from SDK engineering. Agree who will own the acceptance decision and which product release is in scope.
2. Describe sources and the operating boundary
List approved source families, representative inputs, hardware, identity, expected connectivity and handling restrictions. Establish installation, licence and access prerequisites. Exclude classified or sensitive case material from the initial briefing.
3. Agree measurable acceptance criteria
CORTEX: reconstruct a report revision and approval path. NERVE: recover an original from an evidence locator and test denied discovery. GTK: ingest and exploit representative imagery on target hardware. PAL.NET: exercise required typed operations against the compatibility manifest.
4. Test, inspect and record gaps
Review implementation constraints, run representative workflows and retain output evidence. Record unsupported formats, failed access cases, missing dependencies and required integration work. Distinguish an observed result from an assumption and agree whether each gap blocks the intended use.
5. Review findings and next steps
A briefing agenda can cover the task, source inventory, operating profile, acceptance tests and commercial scope. The evaluation record should include versions, test inputs, outcomes and unresolved questions. Trial availability, support and commercial terms are agreed individually. This HTML checklist can be printed; no unprovided worksheet download is offered.
Keep a reviewable acceptance record
Use approved test material and a named operator and reviewer. Define what should be retained, what should be discoverable, what an unauthorised account must not see, and how the final report or output can be checked.
Record installation and licensing prerequisites, hardware, identity, connectivity and handling restrictions before the demonstration. Set pass criteria before examining the results.
Distinguish results from dependencies
Keep the product versions, input records, observed outputs, access-denial results, failures and exceptions together. Separate a tested capability from a proposed configuration, a supplier statement or integration work that remains to be engineered.
Use that record to agree the next delivery step, its owner and the evidence needed for acceptance.
Acceptance evidence for PULSE and LINC
For PULSE, start with the decision, the area and a small set of intelligence requirements. Review whether a dated edition answers those requirements, exposes its sources, separates probability from confidence and records the cut-off and reviewer decision. Exercise a held release and a corrected edition as well as the ordinary delivery path.
For LINC, specify the source product, receiving system, message contract and authority boundary. Exercise durable acceptance, unavailable policy, revoked permissions, interrupted links, retries and durable destination acknowledgement. A successful connection alone does not satisfy an exchange acceptance test.
These are proposed evaluation criteria. Confirm the implemented scope and supported release before agreeing an acceptance plan. Cross-domain use depends on independently approved gateways, policies and accreditation for each named flow.