Before any work can be scoped, the situation must be understood. Discovery & Diagnosis is where SafeCode learns your program, identifies the real pain points, and distinguishes the stated problem from its underlying cause. For straightforward engagements, this may be brief. For complex or troubled programs, it may be the most valuable work of the entire relationship.

Most clients arrive with a clear sense of what the problem is. That understanding deserves respect — and it is always the starting point. But there is a reason you would be troubled by a physician who scheduled surgery based on your own self-diagnosis, however informed. The value of an independent diagnostic perspective is not that the client is wrong. It is that a trained outside eye sees things that are invisible from the inside — and that operating on the wrong problem, however skillfully, does not produce the right outcome. SafeCode insists on the diagnostic phase for the same reason your doctor insists on examining you: because the cost of a correct diagnosis is small, and the cost of skipping it can be very large.

Discovery begins with an initial consultation focused on understanding the program context, the regulatory environment, the current state of the work, what has already been tried, and what outcome the client actually needs. It typically involves program management and key technical leads on the client side.

Diagnosis is where that understanding deepens. For some engagements, diagnosis is brief — the situation is clear and the path forward is not in dispute. For others, particularly recovery situations, integration failures, or programs that have been stuck for some time, diagnosis is substantive technical work: reviewing artifacts, examining code, analyzing requirements, assessing process outputs, or reconstructing the sequence of decisions that led to the current state.

The line between Discovery and Diagnosis is intentionally blurry. In practice, the diagnosis emerges from the discovery — there is no clean handoff between learning the situation and understanding what it means. What matters is that neither phase is rushed. A scoping conversation that precedes real understanding produces the wrong scope.

How this phase varies:

• For certification and process engagements, Discovery focuses on understanding the program's regulatory context, current process state, and relationship with the certification authority. Diagnosis may involve reviewing existing process documentation, evidence packages, or prior audit findings.
• For requirements and engineering engagements, Discovery involves understanding the system, the team structure, and the development state. Diagnosis may include reviewing existing requirements, architecture documents, or integration failure records.
• For verification and analysis engagements, Discovery establishes what has already been verified and what remains uncertain. Diagnosis identifies where coverage is weak, where analysis is needed, and what the evidence gaps actually are.
• For advisory engagements, Discovery and Diagnosis may happen quickly in a single session, with the emphasis on a specific decision point or upcoming milestone rather than a broad program assessment.