Omnis Helix Positioning And Language System

This file is the canonical vocabulary system for Omnis Helix marketing, docs, demos, CLI output, and generated copy. When in doubt, preserve this language system instead of inventing new category terms.

Canonical category statement

Omnis Helix is the Genome IDE for defensible genome-editing decisions: a software-only, in silico workspace for design intent, constraint modeling, simulated evidence, policy review, replay verification, and signed export bundles.

Short form:

Omnis Helix is infrastructure for genome engineering decisions.

Safety form:

Omnis Helix is an in silico modeling, review, and governance platform. It does not provide wet-lab, in vivo, diagnostic, therapeutic, or clinical guidance.

What Omnis Helix is

• The First Genome IDE
• Decision infrastructure for genome engineering teams
• A software workspace for intent, authoring, constraints, simulation, review, verification, and export
• A deterministic, replayable, and verifiable modeling environment
• A producer of auditable software artifacts: manifests, checksums, provenance receipts, evidence JSON, review exports, reports, and signed bundles
• A governance layer for policy-bound review and artifact generation

What Omnis Helix is not

• Not AI magic
• Not a wet-lab automation system
• Not a protocol generator
• Not an in vivo or clinical workflow system
• Not a clinical pipeline
• Not a diagnostic tool
• Not a therapeutic recommendation system
• Not a substitute for medical judgment
• Not intended for patient specific decision making

Clinical boundary rules

• Keep all biology framed as software modeling: simulated edits, synthetic inputs, scoring functions, deterministic pipelines, verification, and artifact generation
• Do not accept or store patient identifiers
• Do not ingest patient clinical metadata
• Do not produce recommendations for treatment, diagnosis, or therapy
• Do not score edits in terms of patient outcomes
• Do not integrate with EHR systems, hospital workflows, or other clinical systems
• Do not use language that implies clinical use
• Do not provide protocols, steps, conditions, dosages, delivery methods, sample prep, cultivation, instrumentation, or optimization of real-world biological procedures

Category language

Use these phrases consistently:

• Genome IDE
• decision workflows
• decision infrastructure
• governed continuity
• design intent
• constraint modeling
• simulation and evidence
• policy review
• policy-gated export
• replay verification
• signed export bundle
• verified evidence bundle
• manifest
• provenance receipt
• checksum index
• offline verifier
• review-safe artifact
• evidence-linked workflow
• audit-ready export
• reproducible decision record

Avoid fragmenting the category with one-off synonyms. Prefer the exact phrase above unless a page needs a shorter variant for layout.

Canonical terminology enforcement

Use this table when writing marketing copy, docs, demo scripts, CLI messages, and UI labels.

If a synonym is needed for readability, introduce it only after the canonical term is established.

Preferred phrasing

• "Design, review, and govern genome editing decisions in one deterministic workspace."
• "Generate replayable evidence, policy-aware review artifacts, and exportable proof bundles."
• "Helix exists to make genome engineering decisions reproducible, reviewable, and governable."
• "Do not believe us, verify the bundle."
• "Intent becomes authored design, design becomes evidence, and evidence becomes a review-safe export."
• "Policy gates block exports when required evidence is missing."
• "Bundles carry manifests, hashes, provenance, evidence, exports, reports, and verifier commands."

Enterprise-safe wording

Prefer:

• reproducible
• replayable
• verifiable
• policy-bound
• evidence-linked
• review-safe
• audit-ready
• offline verification
• signed bundle
• retained provenance
• Verified Cross-Host Reproducibility

Use "deterministic" in high-value locations only:

• hero or SEO where trust positioning matters
• proof strip
• conformance or execution-class docs
• verifier docs
• bundle integrity docs

Do not repeat "deterministic" in every section. Rotate to the preferred adjacent trust language above.

Avoided messaging

Avoid:

• AI-powered revolution
• transforming biology
• AGI for biology
• autonomous biology
• cure
• miracle
• unlock life
• reinvent medicine
• wet lab execution language
• giant TAM hype
• vague futurism
• black-box AI claims
• generic "all-in-one platform" unless immediately grounded in workflow artifacts

Do not market Helix primarily as:

• AI for biology
• genome editing platform
• simulation suite
• bioinformatics suite
• notebook replacement

The strongest frame is:

Disciplined computational infrastructure for genome engineering decisions.

Forbidden marketing language

The following terms and claims are banned from Helix marketing, docs, demos, social posts, recruiting copy, and sales collateral unless they appear inside this file as examples of what not to say.

Hard bans:

• AI magic
• autonomous biology
• black-box optimization
• one-click cure
• guaranteed edit
• perfect reproducibility
• fully deterministic biology
• biology copilot
• self-driving biology
• push-button biology
• automated discovery engine
• no-code biology automation
• clinical-grade results
• therapeutic recommendation
• real-world edit execution

Soft bans:

• smart
• intelligent
• next-gen
• revolutionary
• cutting-edge
• disruptive
• breakthrough
• transformative
• unlock
• accelerate biology
• end-to-end AI

Soft-banned terms require a specific artifact-backed reason to appear. Prefer exact infrastructure language instead: replayable, verifiable, policy-bound, evidence-linked, offline verifier, signed bundle, provenance receipt.

Never claim:

• guaranteed biological outcomes
• perfect reproducibility across all environments
• fully deterministic biology
• real-world execution readiness
• clinical suitability
• autonomous decision-making
• replacement of reviewers, QA, or scientific judgment

Language rules

Allowed terms

• simulate
• simulation
• model
• score
• verify
• deterministic
• replayable
• reproducible
• synthetic data
• hypothetical
• scenario
• preclinical
• in silico
• exploration
• research use
• education
• schema
• contract
• bundle
• artifact
• manifest
• provenance
• policy gate

Forbidden terms

• patient
• diagnosis
• therapeutic
• therapy
• treatment
• prescribe
• cure
• efficacy
• clinical decision support
• medical device
• protocol
• dosage
• administer
• deliver
• transfection
• electroporation
• culture conditions
• animal model
• in vivo
• wet lab

If any forbidden term is necessary in documentation, it must appear only inside this file or inside a section explicitly describing what Omnis Helix is not.

Proof surface expectations

Trust-heavy positioning requires proof-heavy artifacts. When adding claims, prefer linking to or generating:

• downloadable evidence bundles
• manifests
• SHA-256 checksums
• provenance receipts
• verifier commands
• verification logs
• conformance reports
• architecture diagrams
• replay walkthroughs
• security and supply-chain docs

Marketing pages should make at least one proof artifact visible before asking for sales contact.

Reference trust corpus

Helix should maintain a canonical set of synthetic, software-only trust artifacts. These artifacts should be used as:

• docs references
• regression fixtures
• screenshot sources
• demo assets
• onboarding examples
• procurement examples
• security-review examples

The reference corpus should include:

Rules for reference artifacts:

• Use synthetic data only.
• Label synthetic/demo status clearly.
• Keep artifacts small enough to inspect directly.
• Prefer stable filenames and schema names.
• Keep examples deterministic and reproducible under version control.
• Use the same vocabulary as the Trust Model page and this positioning file.
• Do not include real customer data, real-world execution guidance, or clinical framing.

Trust surface visual grammar

Trust artifacts should look like a recognizable Helix evidence surface across marketing pages, docs, reports, and screenshots. A checksum block, provenance receipt, replay report, or policy-gate result should feel related even when rendered in different contexts.

Artifact surfaces

Use the shared visual grammar for:

• manifest blocks
• checksum blocks
• provenance receipts
• verification commands
• replay reports
• policy gate results
• signed bundle anatomy
• blocked-reason artifacts
• conformance summaries

Required visual traits

• Use monospace identifiers for hashes, manifest paths, schema names, run IDs, verifier commands, and artifact names.
• Use compact label/value rows for evidence metadata.
• Keep labels stable: Manifest, Provenance receipt, Evidence artifact, Review export, Checksum index, Verifier command.
• Make status language explicit: Verified, Blocked, Replayable, Policy-complete, Drift-detected.
• Treat hashes and digests as first-class visual objects, not footnotes.
• Keep colors restrained and functional. Use status contrast sparingly; do not use decorative alert styling.
• Label synthetic or demo data directly. Never let a sample artifact imply real customer data or real-world execution.
• Prefer visible artifact anatomy over abstract iconography.
• Keep proof surfaces scannable by procurement, QA, platform leads, and technical reviewers.

Status language

Preferred status words:

• Verified
• Blocked
• Replayable
• Policy-complete
• Drift-detected
• Evidence-linked
• Schema-valid
• Checksum-valid

Avoid vague status words:

• Done
• Ready
• Passed
• Good
• OK
• Complete

Use vague status words only inside raw logs or third-party tool output. User-facing Helix surfaces should prefer status language that names the trust property being asserted.

Diagram rules

Trust diagrams should explain systems, not decorate pages.

Prefer linear or loop diagrams such as:

Inputs
  -> Intent + Constraints
  -> Simulation Runtime
  -> Evidence Generation
  -> Policy Validation
  -> Signed Export Bundle
  -> Offline Verification
  -> Replay / Audit

Avoid:

• abstract molecule illustrations
• decorative network graphs with no artifact semantics
• vague "AI engine" diagrams
• screenshots without labels for manifest, provenance, policy, or verifier surfaces

Brand note

If someone asks whether Omnis Helix can be used clinically, the answer is:

Omnis Helix is for preclinical, in silico modeling, review, and governance only. It is not intended for diagnostic, therapeutic, in vivo, wet-lab, or clinical use.