Raven is an algorithm-driven molecular cloning tool . It accepts a list of target plasmids and a parts library as its input and returns a DNA assembly plan (see Guides for example Raven files). For any set of target parts, Raven determines an optimized plan for assembling the selected target plasmids with a supported DNA assembly method.
This version of Raven is open-source and the source code for the assembly algorithms is available on github. If you are interested in having Raven tailored for your company or have interest in other design-automation software, please contact Lattice Automation.
Have additional questions or wish to provide feedback to the developers? Please post to the Raven Forum.
Raven currently supports six cloning-based assembly methods: Gibson , MoClo (BBF RFC 94) , BioBricks (BBF RFC 10) , SLIC , CPEC , and GoldenGate . Each of these supported cloning methods has technology-specific constraints and these are automatically applied in the assembly solutions.
Additional cloning methods are not currently supported, however, Raven's core algorithm is highly generalizable and new methods can be added with relative ease. Please contact the developers if you are interested in Raven support for an assembly method that is not currently supported.
Raven calculates an assembly plan in two major parts: first, Raven determines all intermediate cloning reactions necessary to achieve the final constructs, then it selects optimized part junctions based on method-specific constraints. Calculations are made in this order because it is assumed that performing a successful cloning step is more costly and time consuming than performing a PCR reaction.
A unique feature of Raven is its ability to incorporate experimental data to modify the assembly solutions. Raven allows the user to input efficiency information for a variety of parameters and bias or force certain assembly intermediates from appearing in the assembly solution.
For example, a user might observe higher or lower assembly efficiencies than expected due to various experimental conditions such as cell competency, specific reaction conditions and other factors. To adjust for these considerations, a user may adjust the default efficiency values guiding the efficiency optimizations.
A user may also wish to bias or force certain intermediates from appearing or not appearing. Raven optimizes around these additional constraints unless they are so restrictive that no valid solution can be found. Intermediate parts and overhangs can be biased for (recommended), biased against (discouraged), forced or forbidden. These intermediates can be specified either manually in the design tab or automatically via Eugene  scripts and listed in Raven files.
These strategies are applied to all supported assembly methods to produce fast, modular and efficient assembly plans. Additional details can be found in the Raven publication.
NOTE: In scarless assembly methods (CPEC, Gibson, Golden Gate, SLIC), it cannot be guaranteed that all part junctions are unique in each cloning reaction. Please check assembly plan and primers carefully before implementing. If Raven selects an incompatible part junction for a specific cloning reaction, try changing the plan by forcing or biasing the intermediate steps.
This version of Raven 'stand-alone'. It does not consider genetic construct function or depend on any other tools or databases to provide optimized assembly plans. However, this tool is designed to be connected to a larger tool-chain such as the Clotho design automation platform. This tool chain uses a 'top-down' design flow and begins with the specification of device behavior and ends in physically implemented assembly.
One such specification tool in the Clotho design flow is Eugene , which generates a set of target constructs based on libraries of parts and genetic design rule sets. Raven can take this list of target constructs, determine the best way to build all target plasmids, and return a set of instructions for the assembly. These output instructions can be interpreted by liquid handling robots or microfluidics platforms to automatically assemble these plasmids from available resources. This flow allows a user to merely specify the behavior of a set of constructs and what resources they have and be returned a set of biological samples.
This section contains documentation about specific Raven features. More examples are coming soon. In the meanwhile, please contact us at email@example.com if you have further questions.
This is the full specification for the Raven input file. Files that do not conform to this standard will result in upload errors
Each row represents a part, vector, destination vector, or plasmid. None of the columns need to be unique, but the collection of all columns in one row must be unique and if all columns are blank, the row is ignored.
This field is used upon input to indicate if a part in the file is in the library and can be considered for re-use. If any character is in this column for a given row, it will be considered in the library for reuse. It is important that only parts that can be reused are marked in this section or else the outputs will be incorrect.
This is the field used to name the part.
In all cases this fields is optional, but without this field, complete primer designs will not be generated. Primer designs are not optimized, but are valid based for the selected assembly method.
These fields mark the overhangs of the parts generated. These overhangs are variables and not sequences. Library part reuse of is based on overhang when calculating the assembly plan. Plasmids, and destination vectors are all allowed to have overhangs.
The MoClo assembly algorithms only recognize overhangs with the numbers 1 -> 128 for reuse. They also recognize overhangs with the '*' character as reverse compliments of the standard 128 possible MoClo overhangs (i.e. '1*' is the reverse overhang of overhang '1').
The BioBricks assembly algorithms only recognize 'EX' for the left overhang and 'SP' for the right overhang. Upon input, this field is completely optional, but most outputs contain parts and vectors with overhangs, as this is necessary for assembly.
CPEC, SLIC, Gibson and GoldenGate algorithms do not use the overhang fields as the constructs are designed to be scarless.
This field is used to create assembly plan pictures using Pigeon-generated SBOLv-compliant glyphs.
All plasmids must have the key string 'plasmid' in this field.
Vectors need the key string 'vector' and destination vectors must be marked 'destination vector'.
NOTE: The difference between 'vector' and 'destination vector' is important. A 'vector' is a linear fragment that represents the vector backbone. A 'destination vector' is a vector with an insert, making it circular. This fragment is generally a lacZ cassette in Raven. Although the 'destination vector' is a circular, replicating plasmid, it should not be indicated as a 'plasmid' in Raven. MoClo and Golden Gate assemblies produce 'destination vectors' which can be re-used as part of the library.
All other entries are valid, and assumed to be basic part types. Part types not recognized by pigeon are assigned the wild-card glyph in Pigeon images.
The following key strings are recognized for pigeon images for basic parts:
Parts with type 'fusion' denote fusion proteins and the Name column is split with the '-' character to get all the fusion names. Parts with type 'resistance' denote a resistance cassette. Take note that restriction-based assembly cloning methods rely on cloning vectors that also have anti-biotic resistance within them.
This field is used to denote the antibiotic resistance of a vector or destination vector.
This field is used only for vectors and destination vectors. Destination vectors with level and overhangs are re-used in an assembly plan if possible. Levels start at '0'.
The vector field is used to indicate the vector backbones in which a construct lies. Complete plasmids will be re-used in assembly plans if it reduces cost. This field is also used to denote the vector backbone used by destination vectors. Destination vectors are always made of a vector backbone and the lacZ fragment as insert. For MoClo and Golden Gate assembly, which use destination vectors, the construction of destination vectors is not explicitly described in the assembly instructions, but for new destination vectors, primers are designed to amplify the lacZ fragment for insertion into the vector backbone after a SpeI digestion and ligation. To PCR this fragment with different flanking recognition sites, primers will need to be re-designed.
NOTE: The vector specified in this column is used to indicate which vector backbone a plasmid in the library currently has. For target parts that do not yet exist in the library, this field is ignored. Vector assignments for intermediates and final clones are all specified in the design tab in the user interface.
This field starts in the column below the headers and extends infinitely based on the size of the composition of the target construct. All target constructs must have a composition size of two or greater and only these constructs will be recognized as targets.
This field must be formatted in one of the following conventions:
The part name is mandatory. LeftOverhang and RightOverhang are optional. Direction is how a user can specify the strand or 'direction' of a part within a device. All parts are assumed to be forward (on the leading strand) in the absence of specification. The two acceptable directions are '+' and '-'. If a part in a device has Direction equal to '-' it is on the lagging strand.
The input file only recognizes four types of entries. Entries that do not fall into these categories will not be input correctly and/or cause invalid answers. Here are the acceptable entry types:
|Entry Type||Required Fields||Optional Fields||Forbidden Fields|
|Basic Part||Name, Type||Sequence||Resistance, Level, Left Overhang, Right Overhang, Composition, Vector|
|Plasmid||Name, Type (="plasmid"), Composition||Sequence, Left Overhang, Right Overhang, Vector||Resistance, Level|
|Vector||Name, Type (="vector"), Resistance||Sequence, Level||Left Overhang, Right Overhang, Composition, Vector|
|Destination Vector||Name, Type (="destination vector"), Left Overhang, Right Overhang, Resistance, Vector, Composition (="lacZ")||Sequence, Level|