Defining a first discovery engagement

A first conversation should establish what can be inspected and what a useful result would look like. This guide is a scoping checklist, not a fixed thirty-day programme or a promise of particular commercial availability.

#Start with the supported inputs

The current Discovery Engine reads supported Java, Python, C#, Kotlin, Go and JavaScript/TypeScript source and dependency manifests, certificate and key files on disk, and TLS settings written in code. Findings carry evidence; unresolved algorithms are reported as unknown. Live TLS endpoints and wider infrastructure discovery are planned.

#Agree the scope in writing

• Name the repositories, files and revisions that are in scope, and list exclusions.
• Confirm who is authorised to supply the inputs and who can review the findings.
• Agree the handling of source, certificates and key files through an appropriate process. Do not submit private keys or credentials through the website.
• Confirm access, deliverables, timing and commercial terms before work begins.

#Review findings before drawing conclusions

Look at the evidence for each finding, the source revision and any unresolved algorithms. Separate raw observations from distinct assets. A result from supported inputs does not establish the absence of cryptography in excluded systems.

#Keep the roadmap separate

Mapping, prioritisation and performance evaluation are planned modules. The published scoring method explains an approach; it does not establish the availability of automated scoring, integrations. Console: Announced (roadmap).

Do not assume an engagement includes a prioritised migration sequence, automated standards mapping or performance benchmarks. Any proposed deliverable needs its scope and availability confirmed.

#Use the examples as examples

This is a synthetic reference estate, not customer data or a measured pilot result. Its 42 assets and score of 75/100 illustrate the published method; they do not predict findings or accuracy on your systems.