Kekulé

Kekulé is a persistent molecular engineering workstation, not a decorative molecule viewer. Create a project before importing or editing a structure so each object has a research context, owner, and version history. The local demo data is illustrative; it does not mean a scientific calculation has run.

Choose one molecular problem per project or keep related structures in a named series. Record source, intended comparison, and any assumptions about protonation, stereochemistry, charge, or geometry before interpreting descriptor values. Those details can affect what looks like a small structural change.

Enter SMILES or import a supported molecular structure. When RDKit is available, Kekulé parses the input, sanitizes it, canonicalizes identity, generates 2D coordinates, and reports baseline descriptors. Inspect warnings instead of dismissing them. A successful parse confirms the software accepted the input; it does not validate whether the structure matches the intended experiment.

Use synchronized atom selection to understand correspondences between 2D and 3D views. Check aromaticity, formal charges, stereochemistry, coordinate orientation, and any omitted atoms or bonds. If the same entity is imported from another source, compare identity and provenance before deciding whether it is a duplicate or a distinct version.

Make each meaningful design change as a new revision. Explain why the change was made, what source or constraint prompted it, and which properties you want to examine next. Branching allows an alternative to remain visible without overwriting the prior structure. Compare revisions as scientific objects, not only as images.

The viewport and object inspector provide useful visual checks, but a rendered bond diagram is not a complete record. Keep atom identity, bond order, charge, stereochemical context, and source files with the object. Revisit the exact input file if the visualization and your intended chemistry disagree.

Open Calculations only after the molecule revision is stable enough for the intended compute task. Choose an engine from the capability registry, select the input version, and review every calculation parameter before submission. The product uses versioned contracts to connect with Planck and other supported engines; an unavailable engine is not silently substituted.

Check that the request has an explicit atom count, method, charge, spin or other applicable settings, and resource expectations. A queued request is not a computed result. Keep a job receipt and returned artifacts attached to the molecular version so later comparisons can identify which exact geometry was used.

When a supported engine returns results, inspect the status, provenance, and warnings alongside the values. Compare like-for-like methods and structures; note whether geometry optimization or other preprocessing altered the input. Do not infer reaction success, biological activity, or an experimentally validated property from baseline descriptors alone.

Export a `.qubosis` project archive to preserve the structure, history, decisions, and checksums for handoff. Review the archive manifest and validation outcome before sharing. A project package helps move the record; it does not replace independent verification of chemistry or calculation output.

Kekulé distinguishes implemented capabilities from planned or unavailable ones. RDKit-backed structure validation is present in the shipped chemistry service, while compute engines only execute when an adapter is actually available and configured. Use the visible registry to confirm what the current workstation can do rather than relying on a product roadmap or a disabled menu item.

The local workspace includes illustrative molecular examples. Do not cite their data as a calculation. If a structure file or chemistry dependency is missing, resolve the source or service setup first and preserve the unavailable state in the project record.

Create or open a project before changing a structure. The project holds scientific identity, revision history, source context, decisions, and any intended integration handoffs. Confirm the molecule's stable identifier and current revision before using it in a discussion or downstream request. Tenant-scoped persistence is part of the local service boundary.

The bundled workstation contains illustrative molecular records. Treat them as UI examples only. Start a clean project for real research and import a structure from a supported representation. A visual depiction is not proof of chemical validity; use the chemistry validation response and retain its source revision and status alongside your notes.

SMILES parsing passes through the local RDKit-backed chemistry service for sanitization and canonical identity. Review errors or warnings and compare the canonicalized form with the representation you intended to import. The implemented slice emphasizes structure identity and validation; do not infer unsupported file conversion or computation features from the presence of a molecule viewer.

The current foundation reports baseline descriptors and generates 2D coordinates. Check which descriptor values are actually returned and how the application labels their method. A descriptor should remain associated with the exact input revision, because even a small structural change can make a prior value stale. Experimental properties and biological activity are outside a deterministic depiction or descriptor calculation.

Use the 2D depiction to inspect connectivity and the 3D view to discuss spatial arrangement when coordinates are available. Selecting an atom in one view synchronizes selection in the other, helping a team discuss a specific atom rather than relying on an ambiguous screen coordinate. Keep the molecule name and revision visible when taking notes.

Generated coordinates are a visualization aid. They should not be mistaken for a validated conformer ensemble, a minimized geometry, or an experimentally resolved structure unless the source and method explicitly say so. Use the source panel to distinguish coordinates that came from an input file from coordinates generated for display.

Molecular design work often has competing structures. Keep alternative edits in separate revisions or branches instead of replacing the project record in place. Record the change reason, source, decision, and any comparison criteria that shaped the choice. Content hashes help identify an exact object state and support integrity checks on later exchange.

Immutable revisions let downstream records continue pointing at the version they actually used. If a later review selects another branch, create a new decision or request rather than relabeling an older calculation. A branch preserves provenance but does not automatically propagate changes into another Qubosis product.

The workstation uses an explicit command and integration contract. Commands can be idempotent, which prevents a repeated request from creating a second logical edit when the same request identifier is retried. Inspect the activity and audit record after an operation so you can verify which revision changed and whether the response came from the intended project.

The capability registry is the authority for an integration's current availability. If Planck, OpenMM, or another engine is absent, the UI should expose an unavailable state and its reason. Do not substitute a display-only status with a claim that a molecular calculation, energy evaluation, or simulation completed. The current repository is a local chemistry control-plane foundation, not a full compute environment.

Kekulé defines versioned request and evidence contracts for the Planck boundary. Before creating a handoff, pin the molecular revision and identify the requested calculation context, then inspect what evidence the receiving service requires. This contract makes the intended data exchange explicit and can support future integration.

A request object records intent; it does not itself submit a job or produce a result. Confirm the receiving Planck service and its capability state separately. When a result eventually returns through a supported integration, preserve its original job and result identifiers rather than attributing them to a local validation step.

Portable `.qubosis` project packages use ZIP structure, checksums, and safe archive validation. Export after confirming that the package includes the revisions, decisions, and records needed by the receiving team. Review the checksum manifest after transfer to detect altered files and retain the package version used in the handoff.

A checksum can establish that file bytes match the captured digest; it cannot establish that the structure is correct, that an external party is authorized to see it, or that a scientific conclusion follows from it. Check project classification and recipient permissions before sharing sensitive structures. Back up the local database and stored artifacts using the deployment's documented procedure.

The current implementation provides a working browser control-plane and chemistry-service slice: real structure parsing and sanitization when RDKit is configured, canonical identity, baseline descriptors, project persistence, immutable revisions, branches, decisions, provenance, and portable package validation. These capabilities form a solid molecular record and handoff layer.

The illustrative data does not establish that a molecule has been calculated. The presence of a Planck contract does not imply a live Planck connection, and the repository does not claim that OpenMM, reaction prediction, force-field simulation, or quantum computation ran. Consult the capability registry for the active installation and interpret every result according to its recorded source and status.