Why pre-execution analysis comes first
Repository content must be treated as untrusted before it reaches an execution environment. Build scripts, package lifecycle hooks, test fixtures, generated code and configuration can all contain harmful or unexpected behavior. A static preflight can reduce uncertainty before execution, but it does not convert untrusted code into trusted code.
What the Try DDC demo examines
The public demonstration resolves an exact immutable Git commit, applies bounded structural checks, looks for selected secret-exposure and static vulnerability patterns, examines common dependency and CI configuration signals, and adds DDC-specific observations around provenance and authority boundaries. Supported pinned dependencies may be checked against external vulnerability advisory data.
The demo deliberately does not install dependencies, invoke package managers, run repository hooks, execute tests or grant repository code network or filesystem authority. This keeps the public demonstration within a pre-execution boundary.
Why the result is reduced
A public demo is not a laboratory assessment. It returns representative findings and high-level remediation direction while withholding the complete evidence graph, full finding inventory and detailed exploit-oriented material. The output is also explicitly non-accredited and cannot establish that a repository is safe to execute.
From demo to full assessment
A scoped engagement can extend beyond the public demo by defining requirements, exact versions, environment, authority boundaries, evidence expectations and verification independence. Dynamic execution, where appropriate, requires a separately qualified isolated runner and does not inherit trust merely because static analysis found no high-risk signal.