Week 2 HW: DNA Design — RootGuard TasA Prototype

Naufal Tsabitul Azmi · HTBAA Fall 2026 · Homework #2
Revised 2 October 2026. Kernel evidence was captured on 29 September–1 October; recovered sequence files were rechecked on 2 October. No wet-lab results are reported.

I designed a TasA expression prototype for my Homework 1 RootGuard concept. The assembled baseline is RootGuard_pHT01_Pveg_TasA_v2_DRAFT, an 8,734-bp pHT01-based construct containing native TasA CDS. Its actual Kernel GenBank export matches the prepared DNA. A separate 786-bp DNA Chisel candidate is a synonymous codon-usage comparison; it has not replaced the baseline.

This report answers Parts 0–6 and documents the available evidence. Host-specific codon optimization inside Kernel remains unresolved, and the exact course-workspace naming/membership also needs confirmation. The observed optimizer form did not offer Bacillus subtilis. I report the external alternative and its limits; instructor acceptance is not assumed. The assignment permits an imperfect design with explicit reasonable assumptions, but that does not waive this tool requirement.

Design brief: connecting HW1 to HW2

HW1 proposes RootGuard, a microbial inoculant carried on co-pyrolyzed cocoa pod husk and okara biochar, for eventual evaluation with maize under water limitation in Sumbawa. Its first goal is reproducible viable-cell loading and survival. Attachment, biofilm formation and plant benefit remain hypotheses. HW2 narrows that concept to a matrix-protein expression design; TasA is one component to investigate, not the complete inoculant.

Agenda itemDesign decisionEvidence or assumption
ChassisBacillus subtilis; production strain not selectedProposed host from HW1; NCIB 3610 is a sequence reference
InputConstitutive Pveg-driven transcriptionDNA design choice; biochar, nutrients and water limitation are conditions, not an encoded sensor input
OutputFull TasA protein, intended for extracellular matrixCoding sequence checked; expression, processing and localization untested
AssayTranscript/protein/localization, then matrix and viable-cell retentionProposed measurements; no biological assay data
Part comparisonPveg versus original Pgrac context; two RBS candidates; native versus synonymous CDSDecisions below; no measured performance ranking
Minimum constructPveg–RBS–spacer–TasA–terminator, within retained vector context953-bp cassette in an 8,734-bp computational construct
Annotation and orderTyped parts, coordinates, strand, frame and junction checksActual Kernel GenBank and local QC
PNG exportActual Kernel schematic plus a labeled editor screenshotIncluded below
Homework ReviewWorkspace, optimizer alternative and host/vector assumptionsQuestions at the end

Part 0 — Set up in Kernel

My Kernel repository is RootGuard-HTBAA2026, and my folder is azmi-rootguard-tasa. The baseline construct is RootGuard_pHT01_Pveg_TasA_v2_DRAFT, ID 306fda68-569a-4502-9a08-7cf18035d57e.

I explored existing parts and constructs. A part has an assigned biological role, such as promoter or CDS; a construct holds an assembled sequence and its annotations. A CDS imported into a construct container is still CDS-only unless vector DNA is actually present. I used the editor, functional part linking, sequence search, checker, sequence statistics, schematic export, Biosecurity sequence scanner and Kernel AI.

The screenshots show a workspace called HTGAA 2026, whereas the handout asks for HTBAA 2026. Repository and folder creation are documented; membership in the exact requested workspace needs course-team confirmation. The process documentation records the sequence of decisions and errors; the Notion journal retains the broader screenshot history.

Part 1 — Define the expression target

What molecule am I expressing?

TasA, a protein, is the selected expression target. The proposed role is to investigate one protein component of extracellular matrix in the RootGuard chassis. I am not encoding biochar synthesis, a complete biofilm pathway, drought sensing or a proven plant-growth effect.

What is the sequence, and where does it come from?

The sequence reference is B. subtilis NCIB 3610, chromosome NCBI NZ_CP020102.1, annotated feature complement(2553102..2553887), protein WP_004398632.1. The 786-bp native TasA CDS, including start and stop, matches iGEM BBa_K1701005 in the recorded full-length search. Download the complete native CDS and 261-aa protein sequence.

The imported strain-168 CDS is identical in this comparison. Consequently, the CDS match does not identify a strain background or prove that NCIB 3610 is the best production strain. NCIB 3610 remains the documented sequence source.

The chromosome feature lies on the reverse strand. For the construct, the CDS is represented in its own 5′→3′ coding direction, using the reverse complement of that chromosome interval. It starts ATG, ends TAA, contains 262 codons including the stop, and translates to 261 amino acids with no internal in-frame stop.

What is the chassis?

The intended expression host remains B. subtilis, consistent with HW1. An actual production strain still needs selection and qualification. I therefore do not claim that a named strain has been engineered, cultured or validated. Kernel metadata uses Other, with the intended Bacillus host stated in the description; a generic menu choice does not establish biological compatibility.

Where should the protein go?

The desired destination is extracellular matrix. I retain the full native N-terminal region and add no separate signal peptide or tag. Processing/export and the relevant SipW/TapA/matrix context must be checked in the eventual strain. The biological literature describes SipW-associated processing and matrix regulation in this system; it does not demonstrate performance of my construct. Terra et al. (2012), DOI 10.1128/JB.06780-11.

Part 2 — Design and compare the parts

Selected parts: type, sequence, source and justification

All expression-cassette sequences are supplied in the functional-parts FASTA. The annotation TSV pairs each sequence with its type, source, direction and coordinates. The complete reused vector context is included in the actual GenBank and reference FASTA.

Short nameKernel part typeSequence / length and sourceWhy use it for this host and target?
PvegPromoter97 bp; BBa_K143012Constitutive Bacillus-oriented prototype; gives a simple starting design without specifying an inducer
RBS K090505Ribosome binding siteAAAGGAGGTGT, 11 bp; BBa_K090505Candidate bacterial translation-initiation element; its effect with TasA must be measured
Spacer v15′ UTRAATTA, 5 bp; local designSeparates the selected RBS and ATG; spacing remains an explicit assumption
Native TasACDS (+start +stop)786 bp; NCBI reference and BBa_K1701005Encodes the documented full 261-aa TasA target without redesigning its protein sequence
Terminator K780000Terminator54 bp; BBa_K780000Provisional transcription-stop element; termination/read-through in the selected host is untested
pHT01 contextReused vector contextOriginal 7,956-bp reference FASTA; sequence record Addgene Vector Database 5885Supplies a Bacillus/E. coli shuttle-vector context; retained regions require physical-vector and boundary review before construction

The Pveg and terminator sequences, extracted from the actual Kernel export in forward orientation, are:

Pveg — 97 bp
AATTTTGTCAAAATAATTTTATTGACAACGTCTTATTAACGTTGATATAATTTAAATTTTATTTGACAAAAATGGGCTCGTGTTGTACAATAAATGT

Terminator — 54 bp
AAGAAGAAGTGTGAAAAAGCGCAGCTGAAATAGCTGCGCTTTTTTGTGTCATAA

There is no extra targeting element, because the full native N-terminal sequence is retained. There is no eukaryotic Kozak or poly(A) design: this is a bacterial expression cassette.

Candidate part comparison

LayerSelected candidateAlternativeDecision and remaining uncertainty
TranscriptionConstitutive PvegOriginal pHT01 Pgrac/lac-controlled expression contextKeep Pveg for continuity with v1 and a simple prototype; constitutive expression may cause burden, and no strength comparison has been measured
Translation initiationK090505: AAAGGAGGTGTK090506: AGAGGTGGTGTKeep K090505 as the initial candidate; test otherwise matched RBS/spacer variants rather than infer strength from the name
Coding sequenceNative 786-bp TasA CDSExternal synonymous codon-usage candidate, also 786 bpNative remains in assembled v2; the candidate tests a codon-usage hypothesis and is not a proven expression improvement

The selected RBS has a nominal AAAGGAGG core followed by TGT; with the designed AATTA spacer, this gives a nominal eight-base interval before ATG. This is a sequence description, not proof of optimal initiation spacing or mRNA structure.

Replication and selection context

The copied 7,956-bp pHT01 DNA matches the archived Addgene vector sequence. This verifies the digital sequence relationship, not a physical clone or present-day purchasing availability. The MoBiTec Bacillus vector manual describes shuttle-vector use and chloramphenicol/ampicillin selection context. The design retains reference-mapped cat/CmR, bla/AmpR, lacI and replication-associated regions outside the replacement.

ColE1 is the E. coli replication-origin annotation. Minimal Bacillus origin boundaries are not assigned here. Marker/regulator annotations remain mapped reference regions, not newly validated complete CDS models. I would confirm the exact vector and its Bacillus replication/selection context before physical construction.

Part 3 — Assemble the minimum construct and check direction

The expression order is Pveg → RBS → spacer → full native TasA CDS → terminator, within the pHT01-derived context. The original 953-bp v1 contained this cassette only. Its circular topology metadata did not supply a replication backbone. Current v2 contains 8,734 bp.

Functional annotationCoordinates in v2, 1-based inclusiveLengthDirection
Pveg_BBa_K1430122684–278097 bpForward
RBS Candidate BBa_K0905052781–279111 bpForward
Spacer_RBS_tasA_5nt_v12792–27965 bpForward
TasA_BBa_K1701005_local2797–3582786 bpForward
Terminator_BBa_K780000_local3583–363654 bpForward

I provisionally replaced pHT01 2684–2858, a 175-bp reference-mapped expression interval, with the 953-bp cassette: 7,956 − 175 + 953 = 8,734 bp. The left 2,683 bp and right 5,098 bp are unchanged. The replacement boundaries are engineering assumptions, not validated assembly junctions. Reference annotations were mapped by aligning an annotated NovoPro pHT01 variant to the exact copied DNA; differing variants were not assigned identical coordinates blindly. Residual lacI context remains.

Sequence-level checks and result

The actual Kernel GenBank export was checked against prepared v2 DNA. The original 1 October export QC passed 16 assertions. A separate 2 October re-verification passed 25 local checks, including length, unchanged flanks, cassette/CDS identity, typed forward annotations, start/stop, translation and the native–candidate comparison.

The RBS–spacer–start junction is AAAGGAGGTGT–AATTA–ATG. TasA is divisible by three, starts and stops at the intended positions, and has no accidental internal stop in its reading frame. Whole-v2 GC is 40.26%; native-CDS GC is 37.66%. Normalized v2 DNA SHA-256 is 23c372fad614d39adb670cf5291f002524fd956d518e39186b48047c7d81eba1. This DNA hash is distinct from the hash of the GenBank file bytes.

Actual Kernel-exported schematic of the RootGuard v2 construct Actual Kernel-exported schematic of the RootGuard v2 construct

Figure 1. Actual Kernel PNG export, unchanged. Part-name labels are absent from this transparent export; the table above and labeled editor screenshot below supply the legend.

Kernel editor showing the assembled v2 parts, repository, host description and 8734-bp length Kernel editor showing the assembled v2 parts, repository, host description and 8734-bp length

Figure 2. Original editor screenshot, 1 October 09:20 WIB. The functional definitions coexist with simpler feature labels; this does not mean extra copies of the DNA were inserted.

An earlier v2 checker showed 0 errors and 2 warnings, including a promoter-count inconsistency and an unrecommended local spacer. Typed functional parts were subsequently verified in the export. A complete updated v2 warning dialog is not supplied, so I do not claim that all v2 warnings disappeared. The documentation retains the earlier warning screenshot and explains its interpretation.

Part 4 — Optimize and quality-check

Codon optimization: what was attempted, returned and concluded

I inspected Kernel’s Simple v0.3 optimizer. The observed expression-organism menu offered Chinese hamster, human, E. coli and yeast, with no B. subtilis option. Kernel AI suggestions did not establish an available Bacillus setting. I did not substitute another host and call the result Bacillus optimization.

Kernel optimizer algorithm and expression-organism options observed on October 1 Kernel optimizer algorithm and expression-organism options observed on October 1

Figure 3. Original screenshot, 1 October 11:14 WIB. This documents the observed form, not a claim about every future Kernel version or workspace.

For a documented external comparison, I used DNA Chisel 3.2.16, CodonOptimize(method=“match_codon_usage”), and python_codon_tables 0.1.18 with b_subtilis_1423. The source is a species-level Kazusa/NCBI-derived table, not a selected production-strain or curated highly expressed-gene reference. Optimization covered the 261 sense codons, with seed 20261001. Constraints retained the protein, ATG start and TAA stop.

Different synonymous codons encode the same amino acid but may affect translation in a host. Matching a codon table offers a testable design hypothesis; it does not predict secretion or guarantee improved expression. DNA Chisel documentation and codon-table provider.

MetricNative CDSExternal candidate
Length786 bp786 bp
Translation261 aaSame 261 aa
Start / stopATG / TAAATG / TAA
GC37.66%42.49%
Longest homopolymer6 bases7 bases
Codon-profile discrepancy objective−88.18−12.36

The candidate contains 52 nucleotide substitutions across 47 synonymous codons. Closer to zero means a closer table-profile match for this objective; the score is not CAI and is not measured expression. No GC target, restriction-site avoidance, mRNA-folding, secretion-efficiency or vendor-acceptance constraint was imposed.

The candidate FASTA, generation QC, change table, script, dependency versions and codon-table snapshot make the comparison inspectable.

The separate Kernel entry RootGuard_TasA_Bsub_DNAChisel_candidate_v1_2026-10-01, ID 61e38ea9-3d0f-4cc4-9b8a-629c57ec7736, is CDS-only, with tasA 1–786 forward. Its Sequence Stats shows 786 bp / 42.49% GC; editor validation shows 0 errors / 0 warnings. Those checks do not prove biological function. Its complete Kernel re-export has not been hash-compared; the supplied candidate GenBank is an external file, not that missing re-export. Native assembled v2 remains unchanged.

Sequence search: identity and nearest visible matches

I submitted complete CDS sequences to Kernel’s global sequence search. The results concern Kernel’s indexed repositories, including public iGEM entries and local constructs; this was not a separate NCBI BLAST run. Exact algorithm parameters and database snapshot were not displayed.

Query and visible public hitIdentityQuery / subject coordinatesDisplayed E valueBit score
Native CDS → BBa_K1701005, 30 September100.0%1–786 / 1–7860.00e+01452.6
External candidate → BBa_K1701005, 1 October 12:2593.4%1–786 / 1–7860.00e+01164.5

The native query is consistent with the known TasA sequence. For the candidate, several public/native entries tie at 93.4%. 734 / 786 × 100 = 93.3842%, matching the rounded display after 52 substitutions. This is a redesigned DNA sequence relative to the native reference, while local translation confirms the same protein. It is not evidence of globally novel sequence or a new protein function.

Native TasA full-length sequence-search results Native TasA full-length sequence-search results

Figure 4. Native search, 30 September 17:15 WIB. BBa_K1701005 is a full-length 100% hit; other entries contain the same matching region.

External TasA candidate search with public 93.4 percent hits and local 100 percent self-match External TasA candidate search with public 93.4 percent hits and local 100 percent self-match

Figure 5. Candidate search, 1 October 12:25 WIB. The local candidate’s 100% self-match is not independent biological evidence. The visible filter is “Construct +1”; the additional entity type is not expanded. Subject coordinates differ between entries, including a reverse-oriented hit.

Biosecurity screening: what it checks and what happened

Kernel’s Biosecurity sequence scanner, powered by SecureDNA, compares nucleotide input against a database of potential biosecurity threats. The observed action button was Scan for Biohazards. The v2 workflow at 09:54 WIB and the candidate workflow at 12:14 WIB on 1 October reported No flagged sequences detected. Earlier v1 screening also reported no flags. Official Kernel documentation.

SecureDNA result recorded during the whole-v2 screening workflow SecureDNA result recorded during the whole-v2 screening workflow

Figure 6. Whole-v2 workflow result, 1 October 09:54 WIB.

SecureDNA result recorded for the external candidate CDS SecureDNA result recorded for the external candidate CDS

Figure 7. Candidate workflow result, 1 October 12:14 WIB.

The intended inputs were the 8,734-bp v2 and 786-bp candidate, and visible sequence endpoints agree with the source files. The screenshots do not independently establish full input length/hash, database version or a screening certificate. I retain this provenance limitation. No sequence flags in these runs does not establish living-strain safety, successful expression or suitability for environmental release. If a subsequent screen flags a region, I would review that region with the course team and screening provider rather than treat a digital pass as a substitute for review.

Historical QC files are kept unchanged. A generation-time field such as “candidate not imported or screened” describes that earlier snapshot; subsequent import, search and screening are documented here and in the dated re-verification record.

Part 5 — From design to build

How would I build one prototype?

I would start with a sequence-verified synthetic native cassette of 953 bp and an identified, compatible pHT01-derived vector. A fragment-based approach is reasonable for this modest cassette. Gibson assembly is a candidate route after the insertion boundaries and complementary overlaps are reviewed. I have not specified ready-to-order primers, overlaps or assembly scars, and no DNA has been ordered or built.

Minimum build requestDigital specification availableStill needed before ordering/building
One native expression insert953-bp cassette FASTA, with all five part sequencesSynthesis/fragment review and final junction/overlap design
One compatible vector contextOriginal 7,956-bp reference; retained digital flanks total 7,781 bpExact physical vector, Bacillus replication/selection context and insertion-boundary review
Final intended assembled DNA8,734-bp FASTA and actual Kernel GenBankPhysical assembly followed by insert/junction sequence verification

This is the minimum specification for review, not a completed commercial order. An entire 8.7-kb synthetic plasmid might be another route, but I have not checked vendor feasibility or cost and do not assume it is necessary for one prototype. A chip-derived oligo pool adds complexity that is not justified for this single initial cassette.

What does synthesis constrain?

Native CDS GC is 37.66%, its longest homopolymer is six bases, and it contains an EcoRI site at positions 150–155. That site matters if EcoRI is selected for restriction assembly; it does not inherently prevent an overlap-based assembly. The candidate’s longest homopolymer increases to seven bases, showing that codon-table matching does not automatically improve every synthesis property. These are CDS observations, not a full-vector vendor acceptance audit.

Before ordering fragments, I would review GC extremes, repeated or difficult regions, unwanted assembly-related sites and junctions. Splitting a difficult region into fragments may alter the build plan, but fragment assembly still needs sequence confirmation. There is no current vendor-specific difficulty report for this design.

Two assigned readings directly support this reasoning:

  • Gibson et al. (2009) describes joining overlapping DNA fragments using exonuclease, polymerase and ligase in an isothermal reaction. It supports the proposed overlap-assembly route, without validating my chosen junctions. DOI: 10.1038/nmeth.1318.
  • Carr et al. (2004) describes mismatch-protein-based error reduction in synthesized DNA. It supports considering synthesis errors and sequence verification of received DNA; I do not claim to have applied that error-correction method. Its historical error figures are not a current supplier guarantee. DOI: 10.1093/nar/gnh160.

Prototype versus scale

For a larger library of DNA variants, pooled synthesis and selective amplification, as in Kosuri et al. (2010), could become relevant. DOI: 10.1038/nbt.1716. This is distinct from scaling RootGuard production. After a strain and design are qualified, manufacturing focuses on cultivation, carrier formulation, recoverable viable cells and batch consistency; it does not require synthesizing new DNA for every inoculant batch. This keeps HW2 consistent with HW1’s proposed automated screening and later process-control workflow.

Part 6 — Three validation risks and how I would find out

Biggest unknownWhy it mattersNext measurement or design comparison
Regulatory parts may give inadequate expression, burden or read-throughCorrect DNA order does not establish useful TasA expressionCompare matched promoter/RBS/spacer variants and controls; measure TasA transcript/protein, downstream read-through and growth. Compare native and synonymous CDS under the same regulatory context if the candidate advances
TasA may not be processed, exported or assembled into matrixThe production strain is unselected; TasA alone may not supply the needed host contextCheck SipW/TapA/matrix context, extracellular TasA and structured matrix with appropriate controls; distinguish total protein from correctly localized/assembled product
Matrix may not improve RootGuard cell retention or plant outcomesBiochar compatibility, cell recovery and spore-mediated survival may confound interpretationCompare recoverable viable cells per gram, retention/storage, spore fraction and microscopy with matched free-cell, carrier-only and recovery controls; evaluate maize responses separately after strain qualification

Biochar can interfere with optical or colorimetric measurements, as already considered in HW1. Carrier blanks and recovery controls therefore matter. No matrix improvement, drought tolerance, maize-yield benefit or shelf-life claim follows from the software results.

Verified results versus assumptions

Verified within the supplied computational evidenceStill uncertain
Actual v2 export: 8,734 bp, native CDS, preserved flanks and intended typed cassette annotationsBiological validity of vector replacement boundaries and the eventual strain context
Native/candidate local files: 786 bp each, identical 261-aa protein, 52 substitutions and 47 synonymous codonsWhether the synonymous candidate improves expression; complete candidate Kernel re-export identity
Recorded search identity/coverage and observed SecureDNA no-flag messagesScreening input’s independently verified full hash/count; live-organism suitability
Actual PNG export and dated editor screenshotsComplete latest v2 warning state; acceptance of the external optimization alternative

The handout asks for a defensible design, not a perfect lab-ready plasmid. The result is a documented computational prototype with explicit unresolved requirements, not a validated RootGuard product.

Questions for Homework Review

  1. Does the visible HTGAA 2026 workspace satisfy the requested HTBAA 2026 workspace?
  2. Can the documented external Bacillus codon comparison satisfy Part 4, or which available Kernel workflow supports this host?
  3. Is TasA alone an appropriate HW2 scope, and which strain-context, replication and replacement-boundary checks should precede construction?

Documentation, files and evidence

Sources and AI disclosure

Requirements follow the supplied HTBAA Homework #2: DNA Design handout and HTBAA Fall 2026 Syllabus. Project continuity follows my published HW1 and its supplied PDF. Sequence, part, vector and software links appear beside the relevant claims. Build reasoning uses the assigned Gibson (2009), Carr (2004) and Kosuri (2010) readings; I do not imply that every assigned reading was needed to select this simple cassette.

I used ChatGPT by OpenAI to interpret requirements and screenshots, review provenance/direction/frame, prepare the provisional pHT01 draft, run the external DNA Chisel comparison, recover/check files and revise this report. English translations of prompts originally submitted in Indonesian include:

  • “How can I obtain it from an official source?”
  • “Is this what you meant by exporting the map? Now that I have reached this stage, what should I do next to complete Homework 2 and publish it?”
  • “Can you evaluate and analyze the entire narrative?”
  • “Please prepare a fully revised write-up, including documentation and results, that answers all of the questions in Homework 2.”

I also consulted Kernel AI about Bacillus optimizer support. The exact English prompt asks for available controls, an explicit limitation if unsupported, and no substitution of another host or modification of native v2. AI suggestions were checked against available controls and sequence evidence. Proposed biological behavior remains an assumption wherever marked.

Subsections of Week 2 HW: DNA Design — RootGuard TasA Prototype

RootGuard HW2 — Process Documentation in Kernel

Process documentation · revised 2 October 2026 · English translation prepared 2 October 2026. Times use Western Indonesian Time (WIB, UTC+7), unless explicitly stated as UTC.

Return to the HW2 report.

This record describes the work completed, the reasons for design decisions, and the questions that remain unresolved. It does not replace laboratory data. The more detailed history, including 51 original images, remains in the Notion journal.

1. Understanding the design files

Expression instructions can be understood as a recipe for producing a protein. TasA provides the coding instructions for one protein, while the promoter, RBS and terminator help control how those instructions are read. The backbone provides the context for maintaining DNA in a suitable host. This analogy helps explain the components; actual function still depends on the sequence, strain and experimental conditions.

ObjectContentsPurpose
Native TasA, 786 bpCDS only, including ATG and TAAGene reference and sequence comparison
RootGuard v1, 953 bpPromoter + RBS + spacer + CDS + terminatorInitial cassette history; no replication backbone
RootGuard v2, 8,734 bpNative cassette in the pHT01 contextMain assembled design for HW2
DNA Chisel candidate, 786 bpSynonymous CDS from an external comparisonCodon-usage comparison; has not replaced the CDS in v2

The Construct label in Kernel identifies a data container. It does not establish that the DNA inside is a complete plasmid. Similarly, circular metadata does not add a missing backbone.

2. Selecting a focused target from HW1

HW1 describes the RootGuard inoculant with a cocoa pod husk and okara biochar carrier, intended for evaluation with maize in Sumbawa. The initial goals are consistent viable-cell loading and survival. I selected TasA as one protein target associated with matrix structure; this choice does not establish that a single gene will produce a complete biofilm or a benefit to the plant.

The proposed chassis remains Bacillus subtilis. The production strain has not been selected. NCIB 3610 is the sequence reference. Future strain selection needs to consider identity, suitability for maize, growth, matrix formation and retention, and formulation stability, as proposed in HW1.

3. Retrieving the CDS from NCBI and checking its orientation

The chromosome reference is NZ_CP020102.1. The tasA feature is located at complement(2553102..2553887), with protein WP_004398632.1. The term complement indicates that the gene lies on the opposite strand relative to the displayed chromosome coordinates.

The expression design requires the CDS in the 5′→3′ coding direction. The full chromosome and an uncorrected plus-strand copy of that interval would not provide the intended coding sequence. The file used contains 786 bp, beginning with ATG and ending with TAA. Translation produces 261 aa, with no internal stop codon in the reading frame.

The initial guidance required two corrections: a strain 168 file should not be labeled NCIB 3610 without checking its source, and an earlier claim of a 1,384-bp design did not match the available CDS file. The comparison subsequently found the strain 168 CDS and this reference CDS to be identical. I therefore retained the documented source. An identical gene sequence does not establish strain identity or show that a more recently referenced strain is superior.

Download the native CDS and reference protein.

4. Creating and saving parts

The repository is RootGuard-HTBAA2026, and the folder is azmi-rootguard-tasa. The visible workspace is named HTGAA 2026, whereas the assignment refers to HTBAA 2026. The course team needs to confirm the naming and membership; the difference alone does not establish whether the workspace is correct.

The following parts were used:

PartAction takenProcess notes
Pveg, BBa_K143012Saved a local copy as Promoter and retained the original sourceThe visible public part type did not match the intended role; duplicate names needed to be distinguished and did not demonstrate damaged DNA
RBS BBa_K090505Saved an RBS candidate and reviewed BBa_K090506 as a comparisonNeither RBS has been evaluated experimentally for expression strength with TasA
Spacer AATTASaved Spacer_RBS_tasA_5nt_v1, typed as 5′ UTRLocal design; not an NCBI sequence or a validated assembly scar
TasA BBa_K1701005Checked the native sequence match, then created a local CDS when part search failedCDS (+start +stop) matched a CDS that already contained ATG and TAA
Terminator BBa_K780000Created and linked a local part typed as TerminatorTermination function still requires measurement in the final host and context

After a part was saved and visible in the folder, it could either be inserted as DNA or linked to an existing interval as a part definition. These are different operations. The cassette DNA was already present in v2, so linking its annotation to a part should not insert a second DNA copy.

5. Building cassette v1 and adding the backbone context in v2

The 953-bp v1 cassette follows the order Pveg → RBS → spacer → TasA → terminator. Its coordinates are 1–97, 98–108, 109–113, 114–899, and 900–953. The file contains no replication backbone, despite its circular metadata. Because the assignment requests a vector context, I prepared a separate v2 version.

The pHT01 DNA copied and provided on 30 September contains 7,956 bp and matches the archived sequence in Addgene Vector Database 5885. The NovoPro annotation variant used for mapping differed, so coordinates were mapped by alignment rather than copied directly.

The provisional design replaces pHT01 interval 2684–2858, a 175-bp segment, with the 953-bp cassette. The resulting length is 7,956 − 175 + 953 = 8,734 bp. DNA outside that interval is retained. The replacement boundaries are design assumptions; they do not yet constitute junction or primer designs ready for ordering.

I imported v2 as RootGuard_pHT01_Pveg_TasA_v2_DRAFT. Its host metadata was initially unsuitable and was corrected to Other, with a description stating that the intended host is B. subtilis and that the production strain has not been selected. Selecting Other documents the metadata choice; it does not validate host compatibility.

6. Linking functional parts to the map

After the initial import, several intervals remained simple annotations. A label such as Pveg in the sequence viewer could select the DNA while its functional part representation was still unlinked. A limited map display therefore did not establish that DNA was missing.

I completed the following workflow:

  1. Opened v2 in the Editor and checked the construct name and length.
  2. Selected an annotated interval and opened Part match to find a matching definition.
  3. Linked the appropriate Pveg and RBS parts to the existing DNA intervals.
  4. When TasA search failed, used the interval menu to create a local part from the existing sequence, selected CDS (+start +stop), saved it, and linked it.
  5. Created and linked the terminator with the Terminator type.
  6. Rechecked construct length, coordinates and orientation to ensure that part linking did not duplicate DNA.

TasA search still returned an error after a refresh at 07:44 on 1 October; repository-limited search also failed at 07:59. The local-part route was identified around 08:15, the CDS type was selected at 08:24, the local part was saved at 08:49, and it was linked in v2 at 09:07. The terminator was saved and linked at 09:20. These persistent search failures led to the local-part workflow.

V2 with linked functional parts and coordinates V2 with linked functional parts and coordinates

Evidence captured on 1 October at 09:20 WIB: 8,734-bp v2, five functional parts, host description and repository. Simple and functional labels can overlap because they refer to the same DNA interval.

7. Interpreting validator warnings

V2 validator warnings observed on 30 September V2 validator warnings observed on 30 September

At 20:51 on 30 September, v2 displayed 0 errors, 2 warnings. The dialog referred to a promoter/Kozak/UTR imbalance and a local spacer that was not recommended. Its promoter count of zero did not establish that Pveg DNA was missing; the functional promoter representation was incomplete at that stage. The later export includes the correct promoter type.

I did not add Kozak or poly(A) elements to the bacterial design to satisfy a generic validator message. I also retained the terminal TAA rather than removing it because of differences in validator or CDS-type handling. An appropriate stop at the end of a CDS differs from an internal stop in the reading frame.

A more recent complete dialog establishing that both v2 warnings have disappeared is unavailable. The 0 errors, 0 warnings result for the 786-bp candidate belongs to a different object and does not establish that the full v2 construct is free of warnings.

8. Exporting and checking the sequence and map

I exported and checked the v2 GenBank file around 09:30 on 1 October. Its DNA matched the prepared draft exactly; that check passed 16 assertions. The five functional parts had the intended positions and orientations. The native CDS, backbone flanks and RBS–spacer–ATG junction remained consistent.

The Kernel PNG was received around 10:09. The original PNG does not show part names, so the report pairs it with a coordinate table and a labeled editor screenshot. The PNG is retained without modifying its contents.

Original Kernel PNG export of v2 Original Kernel PNG export of v2

A digital map; it does not establish that protein or biofilm has been produced.

On 2 October, I rechecked the recovered files. All 25 local checks passed, covering CDS identity, translation, length, typed annotations, unchanged flanks and codon changes. The results are recorded in the reverification JSON. This was a local file check, without rerunning every Kernel tool or generating new experimental results.

9. Interpreting 100% and 93.4% sequence-search results

The successful route used Kernel global search, including Cmd+K on Mac, followed by pasting the complete CDS. After the BLAST results appeared, I checked hit names, repositories, percentage identity, and query and subject lengths and coordinates.

The native CDS showed 100% identity across 786 bp to BBa_K1701005 on 30 September. The synonymous candidate showed 93.4% identity across 786 bp at 12:25 on 1 October because 52 of its 786 bases had changed. Translation of the local files showed the same protein sequence: a DNA change does not necessarily change the encoded protein.

The candidate also produced a 100% local self-match. This helped identify the object but was not independent confirmation. The search covers repositories indexed by Kernel; I do not describe it as an independent BLAST search across the entire NCBI database. The displayed E value of zero is the tool’s numerical presentation, not a statement that the probability is exactly zero.

10. Codon optimization: constraint, alternative and evidence limits

The visible Simple v0.3 menu offered Chinese hamster, human, E. coli and yeast. No B. subtilis option appeared. I asked Kernel AI in English to keep the control names clear, but its response did not establish an available Bacillus option. I did not select another organism as an equivalent host.

The external alternative used DNA Chisel, the match_codon_usage method, the b_subtilis_1423 table and seed 20261001. The candidate retains ATG, TAA and all 261 aa. Its results were:

CheckResult
LengthUnchanged at 786 bp
ProteinIdentical, 261 aa
Changed bases52 substitutions
Changed codons47 synonymous codons
GC37.66% → 42.49%
Longest homopolymer6 → 7 bases
Profile-matching objective−88.18 → −12.36; not CAI or measured expression

I imported the candidate as a separate object. Its host metadata was corrected to Other, with the intended Bacillus host described. The 11:59 screenshot is consistent with the local file’s length and GC content; the editor validator showed zero errors and zero warnings.

Candidate statistics after correction to Other host metadata Candidate statistics after correction to Other host metadataEditor validator for the CDS-only candidate Editor validator for the CDS-only candidate

The displayed melting temperature of 98.78°C is not interpreted as a bacterial growth temperature; the calculation conditions were not shown. The candidate remains a CDS-only comparison. A complete candidate re-export from Kernel has not been compared with the source-file hash, and instructor acceptance of the external optimization alternative remains unconfirmed.

11. SecureDNA results and interpretation

The visible route was Tools → Biosecurity sequence scanner, using SecureDNA and Scan for Biohazards. The v2 workflow was checked at 09:54, and the candidate at 12:14, on 1 October. Both screens displayed No flagged sequences detected. V1 had previously also returned a no-flags result.

The intended nucleotide input was the complete v2 sequence or the complete candidate. The sequence ends visible on screen were consistent with the files, but the interface did not provide a full-input hash, an independent length count or a database version. The report therefore limits its conclusion to the screen evidence available.

A no-flags sequence result does not establish TasA expression, matrix formation or the safety of a living strain for environmental use. The official tool documentation provides further context.

12. Timeline and publication record

Date / timeEventResult or decision
29 SeptemberCDS and parts assembled as v1953-bp cassette without a plasmid backbone
30 September, 17:15Native sequence searchK1701005 match: 100% across the complete 786 bp
30 September, 19:23–20:26pHT01 DNA checked; v2 prepared and imported8,734-bp v2 with provisional replacement boundaries
30 September, 20:51Host metadata corrected; validator reviewed0 errors, 2 warnings; no eukaryotic elements added to the bacterial design
1 October, 06:58–09:20Functional parts corrected and linkedPveg, RBS, local TasA and local terminator available
1 October, 09:30–10:09GenBank QC, v2 screening and PNG exportMatching exported DNA; no screening flags; PNG received
1 October, 11:14–11:59Limited optimizer host options; external comparison and candidate importSeparate CDS-only candidate encoding the same protein
1 October, 12:14–12:25Candidate screening and searchNo flags; public hit 93.4%; local self-match 100%
2 OctoberReverification and package revisionConsistent local files; Parts 0–6 narrative and evidence updated
2 October, 20:34 WIBMain-report revision committed and publishedCommit a019cc5431192135213c789370ce6617d920201e; server time 13:34:23 UTC, equivalent to 20:34:23 WIB
2 October, after the commitLive publication checkedRevision date 2 October 2026 and Parts 0–6 visible; seven report images and five documentation images loaded (10 unique images combined); 21 unique downloads identical to local file bytes
2 OctoberPublication documentation finalizedFollow-up commit d5871fe8d9c1e47b75a6f709ae1e6e182b2bb2d4 recorded the publication and corrected documentation backlinks
2 OctoberEnglish translation preparedDocumentation translated into English; the preceding publication checks refer to revisions published before this translation

V1 was published on 30 September. The revised HW2 report was subsequently published through the browser to the course repository on 2 October 2026. The main-report commit records the revision that replaced the earlier narrative. The live HW2 report and live documentation page were both accessible. Publication documentation was finalized in the follow-up commit.

The live checks showed the revision date and Parts 0–6, all seven inline images in the main report, and all five inline images in the documentation (10 unique images across both pages). All 21 unique downloads from the main report matched local files byte-for-byte in the initial post-publication check. A screenshot of the public page was saved as HW2_published_2026-10-02.png among the accompanying output files. Successfully loaded live pages provide evidence of the build output; build logs were not inspected. The two documentation backlinks to the main report were changed to absolute URLs because Hugo had routed the previous ../ links to the homepage. The evidence manifest and package checksums were aligned with the publication record. These checks describe the published revisions preceding this English translation.

13. Evidence checklist and remaining work

EvidenceStatus at this revision
Repository and folder names, and construct IDRecorded in screenshots and the report
Typed parts, positions and orientationsRecorded in v2 screenshots and GenBank
Native CDS and protein, start/stop codons and reading frameRecorded in FASTA and QC files
Native and candidate sequence searchesRecorded in original screenshots
Optimizer host list and alternative methodDocumented; Bacillus-specific optimization in Kernel remains incomplete
Before/after codon comparisonRecorded in QC, CSV, script and table snapshot
Candidate statistics and validatorRecorded; distinct from the full-v2 warning state
V2 and candidate screening resultsRecorded, with limits on input provenance
Original Kernel PNGRetained; interpreted alongside the coordinate table and labeled screenshot
Biological measurementsUnavailable; the proposed measurements remain a validation plan
Revision commits and live pagesMain and publication-documentation commits recorded; both live pages accessible
Report and documentation imagesSeven and five inline images loaded; 10 unique images combined
Main-report downloads21 unique downloads identical to local bytes in the initial post-publication check
Evidence of build outputLive pages loaded successfully; build logs were not inspected

Publication and live-page checks for the preceding revisions are complete. Two course requirements still need confirmation: workspace naming and membership for HTGAA versus HTBAA 2026, and a Bacillus-specific optimization route in Kernel or instructor acceptance of the external alternative. Strain selection, TapA/SipW requirements, regulatory-part performance, vector boundaries and retention on biochar remain validation questions stated in HW2. Publication does not establish the design’s biological function.

I can proceed with Homework 3 while seeking confirmation of those two HW2 requirements. HW3 specifies a protein target, so this next assignment does not require waiting for changes to the RootGuard plasmid. Class notes, a glossary and study materials can be developed alongside that work.

Sources and AI assistance

The primary sources are the HW2 handout, syllabus, supplied HW1 material/PDF, NCBI/iGEM/vector/software references linked in the main report, actual export files, supplied screenshots and the Notion journal. This record was prepared with ChatGPT by OpenAI; Kernel AI was used to ask about host support. Examples of the requests and the complete English Kernel AI prompt are included in the package. A control that was not observed is not reported as having been used successfully.

I also used Codex desktop (OpenAI) on 2 October 2026 to recover the material, check coverage of Parts 0–6, review file consistency and prepare the upload package. No new optimization run, screening run or experiment was performed in this session. The original request was written in Indonesian; the following is an English translation of that request:

Please prepare the fully revised write-up, including documentation and results, answering every requirement and question in Homework 2, as Markdown for the website or as the files that need to be included on the site. Can the finished version also be uploaded directly?

Codex subsequently assisted with publishing the revision through the browser and checking the live pages on the same date. The following is an English translation of the original Indonesian publication request:

Can you help me promptly publish this Homework 2 assignment to the website, replacing the previous version?

This documentation was then translated into English on 2 October 2026. The English renderings of the two requests above are translations, not verbatim English prompts. The linked Kernel AI prompt remains in its original English wording.