The Singularity RDK includes "source code, build tools, test suites, design notes, and other background materials" that can be used to get started investigating and running Singularity. The resources include a 17 page document called "Building and Running Singularity" that walks through the processes of getting Singularity and the RDK setup. The download has more than 50 individual applications and projects that can be built and deployed, including a full test suite and a set of benchmarks.

The RDK also comes with several dozen Singularity Design Notes (SDN) that describe how certain features of Singularity or one of the projects are designed and expected to work. For example, "SDN 0: Singularity Design Motivation" includes talks about so-called Centers of Gravity

Four design points combine to produce an OS that is agile to future research and innovates in system reliability. These design points are: a type safe abstract instruction set as the system binary interface, a unified extension mechanism for applications and the OS, a strong process isolation architecture, and a ubiquitous metadata infrastructure describing code and data.

The Microsoft Research site and the RDK site had this overview of the Singularity project itself:

Advances in languages, compilers, and tools open the possibility of significantly improving software. For example, Singularity uses type-safe languages and an abstract instruction set to enable what we call Software Isolated Processes (SIPs). SIPs provide the strong isolation guarantees of OS processes (isolated object space, separate GCs, separate runtimes) without the overhead of hardware-enforced protection domains. In the current Singularity prototype SIPs are extremely cheap; they run in ring 0 in the kernel’s address space.

Singularity uses these advances to build more reliable systems and applications. For example, because SIPs are so cheap to create and enforce, Singularity runs each program, device driver, or system extension in its own SIP. SIPs are not allowed to share memory or modify their own code. As a result, we can make strong reliability guarantees about the code running in a SIP. We can verify much broader properties about a SIP at compile or install time than can be done for code running in traditional OS processes. Broader application of static verification is critical to predicting system behavior and providing users with strong guarantees about reliability.