CDL Technical Assessment

Technical Assessment Supporting Material Form

Please provide the following in preparation for your Venture’s Technical Assessment:

Please only provide material you are comfortable sharing.
Venture Name *: Examol Corporation
CDL-Seattle Stream
Select an option: Computational Health
Internal supporting documentation that outlines the venture’s scientific foundation, technology roadmap, technical team, etc. *
Please provide a link to or attach below any relevant materials that a CDL Scientists / Investigators can review to prepare for discussions (technology demonstrations, technical presentation decks or videos, etc.)
Technology foundation: Standard software engineering tools and practices
Software engineering:
Python programming language
Typescript programming language (
version control
CI/CD pipelines ()
Currently 100% unit test coverage for backend API server
Software Licensing
Planning on licensing the core platform code (codename “Bos”) as open source but are still making final decisions based on investor and customer feedback. Currently the code is in-house and not public. Our current proposal is a dual license inspired from which includes two different licenses:
which is the most restrictive copy-left license which would prohibit competitors from redistributing or providing services using the software without disclosure. Redistributed contributions must be also AGPLv3 so we would benefit from contributions and derivatives as well.
A special purpose commercial license available for a contract with us that allows for more permissive proprietary usage.
Software Bill of Materials, & Security
for SBOM and license compliance
for security scanning
Storage and Databases:
Primary application database using SQL (currently open source )
Object storage via industry de facto standard S3 protocol with support from all major cloud providers (
, , , ()).
Numerical array databases via a cloud native array database based on MIT licensed open source () software with mature MIT licensed open source , with enterprise support available.
Web technologies:
HTTP web communication following
REST API conforming to and publishing specifications
Commodity web browser with standards compliant features (including )
compliant browser side software
Platform software product developed using
projects delivered as a standard (CNCF Graduated) application.
Installation via standard Kubernetes packaging tools like
(CNCF Graduated) and when applicable
Docker and (previously known as Singularity, a project) containers for marketplace application delivery via standardized registry implementations (i.e. support for ).
Client libraries and SDKs delivered via standard Python packaging best practices (as described by
). Python is industry standard in our domain.
Chemical Informatics
Primarily use industry standard toolkits such as
Molecular representations using peer-reviewed and published canonicalization and encoding algorithms (see )
Technology Roadmap:
Demo link with login details
Technical Team
Sam Lotz
PhD Biochemistry & Molecular Biology from Michigan State University
Undergraduate degree in Biology w/ minors in bioinformatics, chemistry, and mathematics
8 peer-reviewed publications, first author on 5, h-index 8.
Programming in Python language for ~10 years
Main author on multiple major software projects
Research software engineer for 1.9 years at pharmaceutical company
Emiliano Deustua
PhD Theoretical Chemistry from Michigan State University
Dennis Nenno
PhD Theoretical Condensed Matter Physics from University of Kaiserslautern, Germany and College of Optical Sciences, University of Arizona
8 peer-reviewed publications, first author on 5, h-index 7.
Programming in FORTRAN and Python for ~8 years
Managing $M software projects within large-capital projects in the chemical industry
Scientific Foundation
Our primary software platform product has very little requirement on scientific development. Specialized chemical informatics that is required has been known in scientific literature for 20-30 years and has many mature software implementations (see ).
Individual claims for marketplace applications do not and will not encompass scientific “performance” or correctness, as this is highly contextual, and are explicitly provided as caveat emptor.
External supporting documentation that validates the venture’s scientific foundation
Please provide a list of titles and links to any peer reviewed publications, patents, conference presentations, reviews, etc. Please either title links or provide a short description of each item.
This review outlines how modern computational drug discovery needs to be able to handle massive datasets of molecules, as well as link them to methods specific to new design approaches (e.g. degraders). Both problems will be addressed by Examol’s platform and marketplace.
Computational approaches streamlining drug discovery, A. Sadybekov & V. Katritch Nature 616, 673 (2023).
This blog post describes the challenges of selling AI (and more general, software products) to Pharma companies and addresses the question: How to show that your company influences the one thing pharma cares about: developing approved drugs? Examol aims to derisk the computational pipeline by providing access to a wide variety of tools previously inaccessible to many companies, which elevates chances of approval later on in the funnel.
Technology Readiness Level (TRL) that demonstrates the level of venture’s maturity of technology
If familiar, please indicate the stage of your venture’s technology, based on the ISC Technology Readiness Level Scale:
Our current MVP would qualify for Level 8, as its Continuous Development and Deployment pipelines work successfully on our Cloud.
Additional features on current and foreseeable roadmap are in the range 4 and above.

Preparation for the Technical Assessment Call

Questions during the call are intended to generate more detailed information on your technology and technical team. You may reflect on the following questions to prepare:
Please reflect on your technical differentiation and roadmap for the coming year, including the timeline for prototyping, testing, validation, and other key steps specific to your technology.
Platform: We have already established a fast and robust pipeline and workflow for building and testing Kubernetes applications and have used that to build a complete application that is ready for deployment to customer systems. We only need to finish our integration with the Replicated platform for on-prem installation and support. The next phase of development is going to be performed using a “agile” methodology where user feedback on our initial system and so we do not have a long term roadmap for these features. Some expected challenges to predicted features are given below.
Marketplace: For the marketplace applications we will be developing a robust process for containerizing open source and customer software and then scaling up to apply to many different applications.
What are your largest anticipated technical risks / gaps / challenges?
Customer support and success for on-prem customers is challenging due to a lack of observability.
The pace of feature implementation will become challenging as customer expectations expand.
Application software has a very wide spectrum of software dependencies. Additionally scientific high-performance computing software has specialized requirements for compilation and deployment.
Initial software quality can also be low, and could require significant additional engineering.
How do you plan to overcome each of these technical risks / gaps / challenges?
We will use the Replicated product which provides tools for transacting with customers, de-risks installation to Kubernetes customers, and enables redacted remote support to provide observability to user installations for bug fixes and reports.
We already have a successful self-service developer experience and testing environment following principles (including test-driven development, continuous integration, DevOps) that will allow for a rapid pace. We are de-risking engineering team growth through industry developed best practices such as those in .
We will use a specialized and widely adopted software package manager for compilation and packaging of scientific software. Sam has successfully used Spack in the past to develop automated pipelines for exactly this purpose.
This is a very scalable software development problem as it is working on many independent software projects. We should be able to hire to increase capacity here.
Who on your team will be addressing these technical risks / gaps / challenges?
Emiliano Deustua and Samuel Lotz have similar capabilities and will share in the workloads outlined above. Final authority, decision making, and responsibility over operations will be with Emiliano (COO) and Sam (CTO) will be responsible for software engineering.
Dennis Nenno (CEO) will serve as a virtual customer to provide unbiased feedback and final quality control gates.
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
) instead.